Threat Researcher at Gen

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

Security Evangelist at Gen

Research

<p>A fake job interview page is easier to trust than a fake ticket shop.</p><p>In samples reviewed by Gen threat researchers, scammers used branded hiring pages that looked like ordinary recruitment flows: a company logo, a recruiter profile, a 30-minute meeting, and a button to continue with Google or Facebook. There was no attachment to open and no software to install. The credential theft attempt sat inside a step many job applicants already expect: signing in to schedule a call.</p><p>FIFA is an obvious lure ahead of the 2026 World Cup. On May 22, ESET reported fake FIFA-themed websites that copied ticket and merchandise flows to steal money and personal data. Our researchers later found another FIFA-themed domain, hxxps://fifa-mg[.]shop, which followed a naming pattern not mentioned in that report. Domains like these can be short-lived, often appearing for hours or days before they are blocked, abandoned, or taken down.</p><p>Our researchers also found a different kind of FIFA lure: hxxps://fifahiring[.]com, a fake hiring page that encouraged users to schedule a call with an alleged FIFA recruiter. When a user tried to register with a personal Gmail address, the page asked for a business email instead. The page was steering victims toward credentials with more value: accounts that could provide access to a company environment.</p>

<h4>The FIFA hiring page did not point to FIFA</h4><p>The fake page looked believable at first glance.</p>

<p>It used FIFA branding, presented a recruiter identity, and copied parts of the experience users see on legitimate recruiting and scheduling platforms. The recruiter’s name and photo appeared to match a real LinkedIn profile, which made the page feel more credible. For publication, we should keep that person’s identity redacted.</p><p>The domain did not match FIFA’s real hiring infrastructure. FIFA’s legitimate careers pages are jobs.fifa.com and fifa.pinpointhq.com. The fake page used neither. It also loaded the favicon from the real FIFA recruitment site hosted at pinpointhq.com, giving the page a small visual cue borrowed from the legitimate service.</p><p>Other signals pointed in the same direction. The domain and certificate were newly created, from May 23. The site used commodity hosting infrastructure, including Vercel and Render, rather than a corporate environment. Those signs are not enough on their own, but they fit the rest of the evidence.</p><p>The login flow was the clearest part. Credentials were posted to:</p><p>fifeq2026eqbackeq[.]onrender[.]com/api/login</p><p>The Google sign-in prompt was not a real Google authentication window. It was rendered inside the page itself. The visible controls and links did nothing, and the page did not send the user into a genuine Google sign-in flow. According to the analysis, the only Google asset loaded was the favicon, apparently to make the fake window look familiar.</p><p>A page can look like it opened a Google login without ever handing control to Google.</p><p>Researchers also observed hxxps://careers-fifahiring[.]com, which later became inactive, and hxxps://fifajobs[.]com, which showed the same content and was indexed by Google.&nbsp;</p><h4>The recruitment lure went beyond FIFA</h4><p>The FIFA page was one version of a wider recruitment phishing pattern. The brand can change. The flow stays familiar: recruiter profile, meeting prompt, business email, fake sign-in.</p><p>Researchers found similar fake hiring pages abusing other major brands, including <strong>Heineken, Hilton, Coca-Cola, Netflix, PepsiCo, Delta,&nbsp;</strong>and<strong> Spotify</strong>. In the Heineken case, the page appeared to use the identity of someone who, according to LinkedIn, really works as a recruiter at the company.</p>

<p>Additional hunting found two other recruitment-themed kits:</p><p>hxxps://aquent-talent-jobs[.]com<br>hxxps://hays-talent-opportunities[.]com</p><p>The Hays-themed version targeted Facebook credentials instead of Google credentials. Researchers assessed that the Aquent and Hays pages shared code, although they differed from the earlier FIFA examples.</p>

<p>This flexibility makes the campaign harder to frame as a single World Cup scam. FIFA provides the timely hook, but the mechanism is recruitment phishing. A scammer can swap the logo, recruiter name, and sign-in provider while keeping the same basic path to the victim’s credentials.</p><h4>Why fake recruitment pages work</h4><p>Recruitment gives attackers a clean excuse to ask for things that might otherwise raise suspicion.</p><p>A candidate expects to click a scheduling link. They expect a recruiter profile. They expect a calendar prompt. In some cases, they may also expect to use a work email, especially for corporate, contractor, or partner-facing roles.</p><p>The fake login window turns that ordinary flow into credential theft. Users are used to “Continue with Google” and “Continue with Facebook” buttons, but the button itself proves nothing. A genuine authentication flow should take the user to the provider’s domain and controls. A fake page can draw a convincing copy while keeping the victim inside the attacker-controlled site.</p><p>The business email prompt is also a warning sign. A page that rejects a personal email and asks for a work address may be trying to raise the value of the stolen account.</p><h4>What job seekers should check before signing in</h4><p>Start from the company’s official careers page, not from a link in a message, ad, search result, or forwarded post. For FIFA, that means checking jobs.fifa.com or fifa.pinpointhq.com, not trusting a domain because it contains “fifa,” “career,” “hiring,” or “jobs.”</p><p>Look closely at the domain before entering credentials. Scam pages often add plausible hiring words around a brand name: career, talent, jobs, hiring, portal, or connect. A polished page on a new domain is still a new domain.</p><p>Treat the sign-in step as the real checkpoint. If a page offers Google or Facebook login, check whether the flow actually opens a real provider-controlled authentication page. A fake window embedded inside the original site, broken controls, inactive links, or a provider logo used only as decoration should stop the process.</p><p>Use security software that includes web and phishing protection. These tools can block known malicious pages before they load, which is especially useful when scam domains look polished, appear in search results, or are shared through otherwise legitimate channels.</p><h4>What companies can do</h4><p>Recruitment pages are public by design, which makes them easy to copy.</p><p>Security teams should monitor for newly registered domains combining their brand with hiring-related terms. They should also watch for pages that reuse favicons, recruiter photos, job descriptions, and calendar-booking language from legitimate hiring flows.</p><p>HR and recruiting teams should make the official hiring path easy to verify. Candidates should not have to guess whether a domain is legitimate. A clear careers page, consistent recruiter communication, and warnings about unofficial scheduling links can remove some of the ambiguity attackers rely on.</p><h4>Conclusion</h4><p>The fake FIFA hiring page worked because it did not feel unusual. It looked like a normal step in a hiring process.</p><p>Attackers do not need to invent new behavior when they can copy one people already trust. A branded scheduling page, a recruiter profile, and a familiar sign-in button can be enough to move a victim from interest to credential entry.</p><p>The decision point is the login. Before entering a work email or password, check the domain, check where the authentication flow really goes, and verify the role through the company’s official careers site. Security software with web and phishing protection adds another layer, especially against short-lived scam pages that may only stay online for hours or days.</p><p><strong>IOCs:</strong></p><p>hxxps://fifahiring[.]com<br>hxxps://careers-fifahiring[.]com<br>hxxps://fifajobs[.]com<br>hxxps://fifa-mg[.]shop<br>hxxps://heineken-careers[.]com<br>hxxps://aquent-talent-jobs[.]com<br>hxxps://hays-talent-opportunities[.]com<br>fifeq2026eqbackeq[.]onrender[.]com/api/login</p>

Scammers are copying recruitment and calendar-booking flows to make fake Google and Facebook sign-ins look routine. 

Fake hiring pages abuse FIFA and other major brands to steal work credentials 

Threat Research Team Lead

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

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

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

Who's Really Using Your Home Internet Connection?

<h4>Key Points&nbsp;</h4><ul><li data-list-item-id="e43a143fd054561c50dba51071686adff">Gen Threat Labs has been tracking GoFlateLoader, a widespread Golang loader used to deliver multiple infostealers, including Amatera, Remus, Lumma, Vidar and StealC.&nbsp;</li><li data-list-item-id="e3d3b5d0814ea5b26aa75a8d3d6013a39">GoFlateLoader appears both in x86 (32-bit) and x86-64 (64-bit) variants, matching the bitness of the payload it is supposed to execute.&nbsp;</li><li data-list-item-id="e51ccafcfb8c418d894aeb685004a0ba5">The loader is designed for in-memory payload execution and is deliberately inflated with a massive PE overlay to hinder detection</li><li data-list-item-id="ec4bafef8a1113d24bc2b4b3a943228d1">The two main delivery paths are via supposedly cracked software and a <a href="https://research.checkpoint.com/2026/impersonation-click-hijacking-and-tds-inside-a-malware-distribution-ecosystem/" target="_blank" rel="noreferrer noopener">malicious TDS recently documented by Check Point Research</a>, which may redirect users to dedicated landing pages serving password-protected archives containing GoFlateLoader.&nbsp;</li></ul><h4>Introduction&nbsp;</h4><p>Not every threat that matters is technically sophisticated, and that is also the case with GoFlateLoader, which is a rather simple loader written in Go, whose sole purpose is to decode and execute the payload in memory. What stands out the most is not what the loader does but rather what it does not do – it comes without anti-debugging, anti-VM, or sandbox-evasion checks, and also lacks API hashing or CFG obfuscation, the kind of tricks that loaders almost always come with. Instead, GoFlateLoader relies on one of the simplest yet still effective tricks to stay under the radar – it appends a massive PE overlay at the end of the file, deliberately inflating the binary's size (hence the name GoFlateLoader).&nbsp;</p><p>Nevertheless, it is important to understand that malware does not necessarily need to be elegant or stealthy. In the end, the only thing that matters to attackers is whether it can successfully deliver the final payload. And if that is the only metric, GoFlateLoader appears to be working fairly well for its operators, as we continue to see it widely distributed across our user base. Since the beginning of April, we have protected more than 33,000 unique users from it, with the most affected countries including Brazil, India, Argentina, Mexico, Turkey and Spain.&nbsp;</p>

<h4>GoFlateLoader’s Execution Flow&nbsp;</h4><p>If we strip away the obfuscation noise that the Go compiler and the author’s decoy code add, the loader’s execution flow is short and linear:&nbsp;</p><ul type="disc"><li data-list-item-id="efa51af3b2859fd9c684efca0c82d3b66">Copy the encoded payload blob from the <code>.rdata</code> section onto the stack.&nbsp;</li><li data-list-item-id="e879bb970c6d1a81b8a42512222aceaa4">Decode the payload using a small, multi-stage, custom byte-level transformation into a valid PE.&nbsp;</li><li data-list-item-id="ebff4f340af15b75cbea0d682b26b7645">Parse the PE headers of the decoded payload (image base, image size, sections, data directories, etc.).&nbsp;</li><li data-list-item-id="e37fb26cad3d18a4a0c8bf9b2595d661f">Allocate an RWX memory region using <code>VirtualAlloc</code> with <code>MEM_COMMIT | MEM_RESERVE</code> and <code>PAGE_EXECUTE_READWRITE</code> flags, trying the payload’s preferred <code>ImageBase</code> first and falling back to an OS-assigned address if that fails.&nbsp;</li><li data-list-item-id="ebbde6d77cdc942c0a6bac79f4f8a6c28">Map the decoded payload into the allocated memory region by copying the PE headers first, then walking the section table and writing each section to its target virtual address.&nbsp;</li><li data-list-item-id="ed16738229e0f5c70a981c0c5f9b715f9">Apply relocations (only if preferred base mapping fails).&nbsp;</li><li data-list-item-id="e76cde4bae1be6c21b897c350c6fd15db">Resolve imports by walking the standard <code>IMAGE_IMPORT_DESCRIPTOR</code> table and rebuild the IAT in place via <code>LoadLibrary</code> and<code> GetProcAddress</code>.&nbsp;</li><li data-list-item-id="e786887a3d34fc7ce344ee8375944799e">Transfer execution to the final payload using Go’s <code>syscall.Syscall</code>.&nbsp;</li></ul><p>&nbsp;</p><p>This is essentially a textbook example of manual PE loading with the payload reconstructed and executed entirely in memory so that it never touches the disk.&nbsp;&nbsp;</p>

<p>Notably, GoFlateLoader transfers execution to the final payload via <code>syscall.Syscall</code>. In Go, <code>syscall.Syscall</code> has the signature <code>Syscall(trap, nargs, a1, a2, a3)</code>, where <code>trap</code> is the function pointer to invoke, <code>nargs </code>is the argument count, and <code>a1</code>, <code>a2</code>, and <code>a3</code> are the first three arguments passed to the target function. Here, trap is set to point to the final payload’s entry point, <code>nargs</code> is set to <code>1</code>, and since the execution is transferred to that entry point, the remaining arguments serve only as filler values and are never used by the invoked payload. In other words, GoFlateLoader is not issuing a <code>syscall</code> at all, but abusing <code>syscall.Syscall</code> as a generic call gate to hand control to the payload.&nbsp;&nbsp;</p><p>It is worth emphasizing that GoFlateLoader consistently sets these arguments to the hardcoded values <code>1</code>, <code>2</code>, <code>3</code>, and <code>4</code>, which is unusual enough to stand out as a potential detection opportunity (combined with other patterns).&nbsp;</p>

<p>The loader also carries substantial junk/decoy code, which varies across builds and serves no purpose other than padding the control flow and complicating static analysis.&nbsp;&nbsp;</p><p>&nbsp;</p><h4>Inflated PE Overlay&nbsp;</h4><p>GoFlateLoader’s defining characteristic is its massive size (typically 700-950 MB), caused by an artificially inflated PE overlay appended to the original loader.&nbsp;</p>

<p>This is a deliberate design choice intended to bypass detection, as excessively large executable files may pose challenges for AVs and EDRs, primarily due to performance and resource constraints. As a result, to preserve performance and avoid noticeable impact to end users, these solutions often enforce practical file-size limits for deep scanning and/or emulation.&nbsp;</p><p>The same logic extends to automated analysis pipelines – bloated files frequently cause timeouts during heuristic analysis and effectively prevent the sample from being uploaded to cloud-based sandboxes or threat intelligence platforms, which enforce their own strict upload limits to manage bandwidth and storage costs. A prime example is VirusTotal, which enforces a strict 650 MB upload limit. The fact that GoFlateLoader consistently sits just above this threshold strongly suggests that VirusTotal is one of the platforms it specifically aims to evade.&nbsp;&nbsp;</p><p>In most cases, GoFlateLoader’s PE overlays are filled with null bytes, though we have also observed builds with random padding.&nbsp;&nbsp;</p>

<p>Crucially, adding such a PE overlay comes at virtually no distribution cost for attackers, as the inflated data compresses to a fraction of its original size (assuming constant padding).&nbsp;</p><p>&nbsp;</p><h4>Delivered Final Payloads&nbsp;</h4><p>The final payloads distributed through GoFlateLoader are predominantly information stealers, with the most prevalent currently being Amatera, <a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer" target="_blank" rel="noreferrer noopener">Remus</a>, and Lumma. Beyond these, we have also observed it distributing Vidar, StealC, and SvitStealer.&nbsp;</p><p>GoFlateLoader comes in both x86 and x86-64 variants, with each variant matched to the architecture of the payload it is intended to execute.&nbsp;&nbsp;</p><p>As for how GoFlateLoader binaries are distributed, we have observed at least two notable delivery paths. The first is through supposedly cracked software. The second involves the payload being served via <a href="https://research.checkpoint.com/2026/impersonation-click-hijacking-and-tds-inside-a-malware-distribution-ecosystem/" target="_blank" rel="noreferrer noopener">the malicious TDS recently described by Check Point Research</a>, which redirects users to a landing page that offers a downloadable archive and separately displays the password required to extract it. This approach provides several advantages for the threat actor. First, compression significantly reduces the binary size due to the constant-padded PE overlay. Second, because the archive password is displayed separately on the landing page, it makes it harder for AV and EDR solutions to obtain it and decrypt the archive. As a result, the payload may remain concealed until the victim manually extracts it.&nbsp;</p><p>&nbsp;&nbsp;</p><h4>Summary&nbsp;</h4><p>GoFlateLoader is a reminder that prevalence and sophistication are not the same thing. At its core, it is a rather simple manual in-memory PE loader written in Go, with no novel anti-analysis tricks under the hood. Whatever evasion it achieves comes not from obfuscation or other anti-analysis tricks but from its size – the appended PE overlay is built to slip past size-constrained scanners and automated analysis pipelines. Yet, despite its low level of sophistication, GoFlateLoader remains an active and relevant threat, used to deliver a wide range of prevalent information stealers.&nbsp;&nbsp;</p><p>Gen products protect our users against both GoFlateLoader and the payloads it delivers.&nbsp;</p><p>&nbsp;</p><h4>Indicators of Compromise (IoCs)&nbsp;</h4><p>Note: The files listed in the IoCs that are not archives all exceed 650 MB in size and are therefore not available on VirusTotal.&nbsp;</p><p>b88c5744975d2abb447aecc6c090fee9f8580413f4612eecdc6ed1973e8a1739 (password-protected archive containing GoFlateLoader x64 variant loading Remus; pwd: 1234)&nbsp;</p><p>ed5ae7f36453c5a23e9868a5729d67e0549a11f6dea54f5f52d654a8f51d4902 (archive containing GoFlateLoader x64 variant loading Remus)&nbsp;</p><p>841c9297cb8a2e0ff89433d13c05bfc760eb2e98e251cb8fa785d2ad7cbac05f (archive containing GoFlateLoader x86 variant loading Amatera)&nbsp;</p><p>ece7c48eb411b24f26762ede83badb4a644c41d5777129381ac2541804d64fc2 (archive containing GoFlateLoader x86 variant loading Lumma)&nbsp;</p><p>421ce2d2f49c23bbe9f60ef3b9cd38d7eb912ce02e56a61837656210069bd9e2 (archive containing GoFlateLoader x64 variant loading Vidar)&nbsp;</p><p>121c2dc793b3873f75a29ec02241f94136de19c049382a50a50d0d5b99507073 (GoFlateLoader x64 variant loading StealC)&nbsp;</p><p>2415db5081cec9bfd14ad6da1a66169fd96f13a49010c319a73d1ed6fafd4efa (GoFlateLoader x64 variant loading Vidar)&nbsp;</p><p>d9917ade3b4c125a95b5d3e6343cde26145dfbf569bd7e2a843fd0c6fc8ddc28 (GoFlateLoader x64 variant loading Remus)&nbsp;</p><p>4cf6893756f441522b94b36f10e5de0e47aeed4743f95c51650746d1ecf97e3d (GoFlateLoader x64 variant loading SvitStealer)&nbsp;</p><p>8b89d6c9152d3aab97aadd515ecb69ca72654db2f25425759ba4b646853d737d (GoFlateLoader x86 variant loading Lumma)&nbsp;</p><p>90ce4ff9da23ac150da0a8e17930cab1e369aa349fdc1b65691b70369145664a (GoFlateLoader x86 variant loading Amatera)&nbsp;</p>

 Intentionally Inflated Go Binaries That Use Massive PE Overlays to Bypass Detection

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers

Malware Researcher

<p>When we published the first part of this research, we said the investigation was still ongoing. That was not a closing line. We were already looking at the infrastructure, the signals behind the attacks, and the scale of the reservation data abuse we were seeing in our telemetry.&nbsp;</p><p>Then something else happened.&nbsp;</p><p>Friends, colleagues, and other contacts started forwarding us messages they had received from Booking.com. The messages warned that unauthorized third parties may have accessed information linked to their reservations. Shortly after, media outlets began reporting the same thing: Booking.com had notified affected customers, reset reservation PINs, and said the accessed information could include names, email addresses, phone numbers, booking details, and information shared with accommodations. Booking.com said financial information was not accessed from its systems.&nbsp;</p><p>The timing mattered, but not because it started our investigation. It mattered because it publicly confirmed the kind of reservation-data exposure our first article had described from the attack side.&nbsp;</p><p><a href="https://us.norton.com/blog/online-scams/reservation-hijacking-scam" target="_blank">Reservation Hijack scams</a> work because criminals do not have to guess. A traveler receives a message about a real booking. The message contains details that make sense: the right accommodation, the right trip context, sometimes the right contact information. The link then opens a fraudulent page built around the same accommodation.&nbsp;</p><p>A generic <a href="https://us.norton.com/blog/online-scams/what-is-phishing " target="_blank">phishing message</a> has to create trust from nothing. This scam steps into a relationship that already exists between the traveler, the booking platform, and the accommodation.&nbsp;</p><p>While those public warnings were appearing, Gen Threat Labs continued canvassing the data we had available: blocked URLs, fraudulent landing pages, SMS messages, emails, WhatsApp messages, in-app message evidence, and other signals connected to attacks we had already stopped. We used AI-assisted analysis to connect pieces that would otherwise remain scattered: messages, landing pages, accommodation names, URLs, templates, and infrastructure patterns. Human analysts reviewed the results and separated what we could prove from what we could only suspect.&nbsp;</p><p>The result is a much clearer picture.&nbsp;</p><p>We identified more than <strong>350 compromised accommodations</strong> linked to the Reservation Hijack scam flows, spread across <strong>50 countries</strong>. These were not abstract indicators or generic travel-themed pages. In the cases we analyzed, victims had already received reservation-specific information before being pushed to a fraudulent page customized around the accommodation tied to that booking.&nbsp;</p><p>That is the difference between ordinary travel phishing and this model. The attackers are not guessing who is traveling. They already have enough reservation context to make the fraud feel normal.&nbsp;</p><p>And they are doing it at scale.&nbsp;</p>

<h3>How we connected the evidence&nbsp;</h3><p>The second phase of our investigation was already underway when Booking.com’s customer notifications started circulating publicly.&nbsp;</p><p>Gen’s view of this activity comes from attacks we blocked before they could complete. No single signal tells the whole story. An SMS or WhatsApp message may show the <a href="https://us.norton.com/blog/emerging-threats/what-is-social-engineering " target="_blank">social engineering</a>. A URL may show the redirect path. A landing page may show the accommodation being impersonated. An in-app message may show where the attacker entered the trusted communication flow. A repeated page structure may link incidents that look separate at first.&nbsp;</p><p>Put together, those pieces show how reservation data moves from compromise to fraud.&nbsp;</p><p>AI helped us work through that evidence at scale. We used it to normalize accommodation names, cluster similar messages, compare landing-page structures, connect URLs with page content, and flag repeated patterns across channels. This was not “AI says these attacks are connected.” It was AI-assisted triage followed by human review.&nbsp;</p><p>From that process, we extracted and cleaned accommodation names from captured fraudulent landing pages and identified <strong>350 compromised accommodations</strong>.&nbsp;</p><p>We use “compromised accommodations” carefully here. It means reservation context tied to those accommodations was compromised and used in an attack flow we intercepted. The source of compromise may vary: a hotel account, a booking platform partner account, an email inbox, a property management system, a guest messaging workflow, or a third-party service provider.&nbsp;</p><p>The end result for the traveler is the same. Criminals had access to information that should have stayed inside the booking relationship.&nbsp;</p><p>This is also a conservative number. It only includes attacks where we had enough evidence to connect the flow to a specific accommodation. It does not include people who received a message and never clicked, attacks outside our telemetry, landing pages we did not capture, or cases where the accommodation name could not be reliably extracted.&nbsp;</p><p>So 350 is not the size of the problem. It is the part we could see clearly.&nbsp;</p><h3>From scam pattern to repeatable operation&nbsp;</h3><p>A single compromised hotel account can explain a few victims. A copied phishing kit can explain a short campaign. Hundreds of accommodation-specific scam flows across 50 countries point to something more organized.&nbsp;</p><p>The model we see is consistent.&nbsp;</p><p>Reservation context enters the fraud chain, sometimes through compromised accommodation-side accounts, inboxes, partner tools, or data obtained from other criminal actors. That context is then used to contact travelers with details that make the message feel legitimate.&nbsp;</p><p>The wording, the property, the country change. The logic does not.&nbsp;</p><p>That is why this follow-up is not simply “we found more cases.” The first article explained <a href="https://www.gendigital.com/blog/insights/research/reservation-hijack-scam">how Reservation Hijack scams work</a>. This one shows how far the model has spread.&nbsp;</p><h3>A worldwide footprint, led by Europe&nbsp;</h3><p>The highest number of compromised accommodations in our dataset were linked to <strong>Germany</strong>, followed by <strong>France</strong>, the <strong>United Kingdom</strong>, <strong>Italy</strong>, <strong>Spain</strong>, and the <strong>United States</strong>.&nbsp;</p><p>Germany accounted for 49 compromised accommodations in the dataset. France followed with 35, the United Kingdom with 31, Italy with 24, Spain with 20, and the United States with 19.&nbsp;</p><p>Together, the top five European countries, Germany, France, the United Kingdom, Italy, and Spain, accounted for <strong>159 compromised accommodations</strong>, about <strong>45%</strong> of the full dataset.&nbsp;</p>

<p>The European concentration makes sense. Europe has a dense travel market, a high volume of cross-border bookings, many independent and mid-sized accommodation providers, and a strong dependency on online booking platforms and pre-arrival guest messaging.&nbsp;</p><p>Those conditions give criminals useful cover. Travelers expect messages before arrival. They expect payment questions, check-in instructions, policy reminders, and booking updates. A well-timed fake message does not feel unusual.&nbsp;</p><p>But the country distribution also shows that this is not a single-region problem. The activity spreads across <strong>50 countries</strong>, with a long tail of destinations beyond the largest clusters.&nbsp;</p>

<p>That long tail matters. It suggests the model is not limited to a few obvious tourist destinations or a handful of famous hotel brands. Once criminals have access to reservation data and a working scam flow, the same approach can be adapted to different countries, languages, property types, and booking habits.&nbsp;</p><p>The property does not need to be famous. It only needs to be real, tied to a real reservation, and recognizable to the victim.&nbsp;</p><h3>Not just hotels&nbsp;</h3><p>Hotels make up the largest share of the dataset, but they are not the whole story.&nbsp;</p><p>We identified compromised accommodations across several property types: hotels, aparthotels, apartments, inns, motels, lodges, resorts, guesthouses, B&amp;Bs, hostels, villas, bungalows, and capsule hotels.&nbsp;</p>

<p>This is a useful reminder of how fragmented the travel ecosystem really is. A traveler may book a large hotel chain, a family-run guesthouse, a serviced apartment, a hostel, or a villa through similar platforms and messaging flows.&nbsp;</p><p>From the traveler’s point of view, the trust model is almost the same. They made a booking. They expect communication. They may not know whether the message came from the property, the platform, a channel manager, a property management system, or a compromised account sitting somewhere in between.&nbsp;</p><p>That is exactly the gap criminals are abusing.&nbsp;</p><h3>How big could this problem be?&nbsp;</h3><p>To understand the potential scale of Reservation Hijack scams, we looked at the accommodation properties appearing in our research dataset.&nbsp;</p><p>In total, we identified <strong>350 accommodation entries</strong> linked to reservation hijack scam activity. These were not all the same kind of business. The dataset included hotels, aparthotels, resorts, hostels, guesthouses, villas, apartments and other accommodation types. For each one, we estimated the number of rooms, units, beds or capsules, depending on the property type, and used that to calculate the likely maximum guest capacity.&nbsp;</p><p>Across the deduplicated dataset, these properties represented an estimated maximum capacity of around <strong>82,000 guests at any given time</strong>. Using a conservative occupancy rate of <strong>50%</strong> and an average length of stay of <strong>2.5 nights</strong>, this translates into approximately <strong>6 million guest stays per year</strong>.&nbsp;</p><p>That does not mean 6 million people were scammed. It does not mean 6 million people had their data exposed. What it shows is the size of the opportunity criminals may be looking at when they compromise accommodation or booking communication channels.&nbsp;</p><p>A single compromised workflow can give scammers something much more valuable than a random phone number or email address. It can give them context: the name of the accommodation, the dates of the stay, the booking amount, the channel the guest expects to be contacted through, and the right moment to create urgency.&nbsp;</p><p>That is why Reservation Hijack scams are so convincing. The scam does not feel like spam. It feels like part of the trip.&nbsp;</p>

<h3>The activity does not look random&nbsp;</h3><p>We are still investigating the infrastructure behind these attacks, so we are not attributing the activity to a named group.&nbsp;</p><p>But the evidence does not look like hundreds of unrelated actors randomly copying one another.&nbsp;</p><p>Across the dataset we analyzed, the same fingerprints kept appearing. Many pages used the same internal paths for scripts, images and styles. Several included the same unusual overlay component, repeated internal asset paths, and the same card-validation language, including claims that funds would be reserved and refunded within 10 minutes.&nbsp;</p><p>The pages were also built to look specific to the victim. Hotel names appeared in page titles and visible content. Prices varied from one case to another. Check-in and check-out dates were inserted into the page. In some cases, page metadata and images were synchronized with the accommodation being impersonated. The evidence points to a repeatable process for turning reservation context into property-specific phishing pages. Taken together, those patterns are consistent with a phishing kit designed to generate accommodation-specific pages at scale, rather than pages built manually for each victim.&nbsp;</p><p>The phishing pages also included a fake live support chat. To the victim, it looked like part of the booking or payment process, but it was controlled from the phishing infrastructure. The payment step could therefore become a live interaction: someone behind the page could react to the victim’s input, ask for another card, explain away a failed “validation”, push the victim to continue, or try to capture a one-time code while the victim still believed they were talking to booking support.&nbsp;</p><p>Some of the infrastructure also uses legitimate internet services, including services such as Cloudflare, to place a layer between the visible scam page and the systems behind it. That does not make those services malicious. It means criminals are abusing the same infrastructure that normal websites use, including protective layers that can obscure hosting details, traffic paths, and backend systems.&nbsp;</p><p>For investigators, this kind of setup makes the infrastructure harder to trace. For travelers, it removes many of the usual warning signs. They see a page that loads normally, shows the right accommodation, includes a support chat, and refers to the trip they actually booked. At that point, many people will treat the request as part of the reservation process, even when it is not.&nbsp;</p><h3>Correct information is not proof of legitimacy&nbsp;</h3><p>For years, people have been told to watch for bad spelling, odd sender names, generic greetings, and suspicious links. That advice still helps, but it does not solve this problem.&nbsp;</p><p>A message can include the right accommodation, the right destination, and details from a real stay, and still be malicious. A page can show the correct hotel name, dates, and a plausible payment amount, and still be fake. A request can arrive at the moment when a traveler expects a check-in or payment message, and still be fraud.&nbsp;</p><p>Page behavior can create false confidence too. In some of the phishing pages we analyzed, the fake support chat looked like part of the booking or payment process. If the victim had a question, or if the card “validation” failed, the page could keep the interaction going instead of simply collecting data and stopping there.&nbsp;</p><p>That is what makes Reservation Hijack scams difficult for travelers to judge. The victim is not being tricked only by a fake brand or a fake website. They are being pushed through a process built around real context, at the moment when that context feels normal.&nbsp;</p><p>Travelers expect hotels and booking platforms to contact them. They expect last-minute requests, check-in instructions, payment checks, ID forms, and confirmation messages. Criminals are not fighting that expectation. They are using it.&nbsp;</p><h3>What travelers should do&nbsp;</h3><p>The safest rule is simple: <strong>do not treat correct booking information as proof that a message is legitimate.</strong>&nbsp;</p><p>If a message asks you to verify payment details, confirm a reservation, re-enter card information, pay a balance, reset a PIN, or avoid cancellation, do not use the <a href="https://us.norton.com/blog/online-scams/i-clicked-on-a-phishing-link" target="_blank">link in the message</a>.&nbsp;</p><p>Open the booking platform or hotel app directly. Go to the official website yourself. Use contact details from the original booking confirmation. If needed, call the property using a verified number. Check whether the same request appears inside your official booking account.&nbsp;</p><p>This applies even if the message mentions the right hotel, the right destination, or details from your stay.&nbsp;</p><p>Booking.com has told customers that it will not ask guests to share credit card details by email, phone, WhatsApp, or text, or ask for a bank transfer that differs from the payment policy in the booking confirmation.&nbsp;</p><p>If you already entered payment details into a suspicious page, contact your bank immediately, freeze or cancel the card, and monitor for follow-on fraud. Criminals may reuse the card data later, or sell it to others.&nbsp;</p><h3>What accommodations should take from this&nbsp;</h3><p>For hotels and other accommodation providers, this is not only a guest-awareness issue. Guest communication has become part of the attack surface.&nbsp;</p><p>The systems and workflows between the property and the guest are now valuable targets. That can include hotel staff accounts, booking platform partner accounts, email inboxes, property management systems, guest messaging tools, channel managers, and third-party service providers.&nbsp;</p><p>The lures we have seen on the accommodation side are not exotic. They look like normal hotel work. Some impersonate Booking.com and claim there is a guest complaint waiting for a response. Others say that a paid reservation needs urgent verification, or that the property’s visibility or ranking may be affected if staff do not act quickly. We have also seen payment and invoice-themed messages designed to make staff open attachments or documents that can lead to credential theft or <a href="https://us.norton.com/blog/malware/signs-of-malware" target="_blank">malware infection</a>.&nbsp;</p>

<p>That is why the first visible sign of a Reservation Hijack scam may not be the message sent to the guest. It may start earlier, with an email to a shared hotel inbox, a fake partner-support notice, a malicious attachment, or a document that looks like part of normal accounting or reservation handling. Once reservation context is obtained, whether directly or through another actor in the criminal ecosystem, it can be used later to make guest-facing scams much more convincing.&nbsp;</p><p>For accommodation providers, staff training needs to cover the workflows criminals are actually abusing. Urgent complaints, reservation-verification requests, payment advice emails, invoice notifications, security-update prompts, and any message asking staff to open an attachment, enable content, sign in again, or act under time pressure should all be treated as possible entry points into the same fraud chain.&nbsp;</p><p>The defensive work starts with account protection, but it should not stop there. Accommodation providers need strong <a href="https://us.norton.com/blog/account-safety/multi-factor-authentication" target="_blank">multi-factor authentication</a>, tight control over who can access guest data, monitoring for unusual logins or message patterns, and a clear process for responding when an account may have been abused. The devices used to manage reservations, guest messages, invoices and payment-related emails should also be protected with reliable security protection. Some of the lures we observed were designed to make staff open attachments or documents that could install malware or steal credentials. In those cases, <a href="https://us.norton.com/antivirus" target="_blank">antivirus</a> or endpoint protection may be the last barrier before a compromised inbox becomes a compromised booking workflow.&nbsp;</p><p>Payment-related communication deserves special attention. If a guest receives a payment or verification request, there should be a reliable way to confirm whether it is real. If an account is suspected of being compromised, guests need to be warned quickly and clearly.&nbsp;</p><p>The reputational damage can be painful. Even when the property is also a victim, the traveler may remember the incident as “the hotel message that stole my card details.” That makes workflow security part of customer trust.&nbsp;</p><h3>What the wider travel ecosystem should learn&nbsp;</h3><p>Reservation Hijack scams sit between several parts of the travel industry. The booking platform may see unusual partner activity. The hotel may see confused guests. The traveler sees a convincing message. The bank sees card fraud. A security company sees the landing page.&nbsp;</p><p>Each view is partial, and that delay helps the scam continue.&nbsp;</p><p>The useful signals are often scattered: unusual partner logins, repeated payment-verification language, guest-message spikes, reused templates, fake landing pages, redirects, and infrastructure overlaps. Sharing those signals faster would make it easier to see when separate complaints are really part of the same operation.&nbsp;</p><p>One compromised accommodation can look like a local incident. Hundreds of compromised accommodations across 50 countries point to a repeatable abuse model.&nbsp;</p><h3>The next phase of travel fraud&nbsp;</h3><p>Reservation Hijack scams exploit a simple mistake in how we judge trust online.&nbsp;</p><p>Travelers think: “This message knows my booking, so it must be real.”&nbsp;</p><p>Criminals know: “If we have the booking context, the victim will do much of the trust work for us.”&nbsp;</p><p>The message does not have to be perfect. The website does not have to be flawless. The attacker does not need to convince the victim from zero. They only need to appear inside a relationship that already exists.&nbsp;</p><p>Our latest data shows that this model has spread well beyond isolated cases. We identified <strong>350 compromised accommodations across 50 countries</strong>, covering hotels, apartments, hostels, resorts, guesthouses, villas, and other accommodation types. Together, those properties represent a large travel footprint and millions of estimated annual guest interactions.&nbsp;</p><p>The investigation is still ongoing. We are continuing to analyze infrastructure, campaign overlaps, and the clues suggesting connected activity behind parts of the operation.&nbsp;</p><p>For travelers, the lesson is simple.&nbsp;</p><p>Trust your booking. Do not automatically trust the message.&nbsp;</p>

After our first report, Booking.com began warning customers that reservation data had been accessed. Our continuing investigation shows how criminals are using that data at scale. 

When Hotel Scams Know Your Booking: 350 Compromised Accommodations Across 50 Countries 

Threat Research Team

<p>Attackers replaced selected official download links with malicious installers that deployed a Python bot, r77 rootkit components, and Windows policy-based defense evasion.</p><p>On May 6, 2026, attackers compromised the official JDownloader website and swapped download links to serve trojanized installers. The JDownloader developers <a href="https://www.reddit.com/r/jdownloader/comments/1t6goqe/is_the_website_hacked/">confirmed the breach</a> within hours, restored clean files, and disclosed a timeline, but acknowledged they didn't know what the malicious installers actually do. We took the malware apart to answer that question.</p><p>&nbsp;</p><p>What we found goes well beyond a typical trojanized installer. The payload is a multi-component attack framework: a Python bot protected by PyArmor v9, an r77 rootkit stager with AMSI bypass, and a Windows Defender Application Control (WDAC) policy that blocks 50 security executables from running, including Avast, AVG, Avira, Windows Defender, HitmanPro, and Kaspersky Virus Removal Tool. We reversed the full C2 protocol from the obfuscated Python bytecode and recovered the campaign configuration from the dropper's encrypted strings.</p><p>&nbsp;</p><h2>The infection chain</h2><p>The trojanized installer is unsigned. Windows SmartScreen blocks it, and users who ran it had to manually bypass the warning. Inside, it wraps the legitimate JDownloader installer alongside an XOR-encrypted second-stage PE:</p>

<p>Stage 2 acts as the campaign's quartermaster. It deploys five components from XOR-encrypted resources embedded in its PE (key: <code>fywo</code>):</p><table class="table"><thead><tr><th>Component</th><th>Purpose</th></tr></thead><tbody><tr><td><strong>PyArmor bot</strong></td><td>The main payload, a Python script with obfuscated bytecode</td></tr><tr><td><strong>PyArmor runtime</strong></td><td>DLL that decrypts the bot's bytecode at execution time</td></tr><tr><td><strong>r77 rootkit stager</strong></td><td>Native x86 PE that hides the bot's process, files, and registry keys</td></tr><tr><td><strong>WDAC Code Integrity policy</strong></td><td>Blocks 50 AV/EDR executables from running after reboot</td></tr><tr><td><strong>Python 3.14.3 installer</strong></td><td>The legitimate Python runtime (needed to run the bot)</td></tr></tbody></table><p>Before doing any of this, Stage 2 calls <code>WaitForSingleObject</code> with a 300-second timeout — three times in sequence. This 5-minute-per-call delay is designed to outlast automated sandboxes, which typically give samples 2-5 minutes of execution time. One sandbox vendor recorded an 8-minute total wait before any malicious behavior appeared.</p><p>&nbsp;</p><h2>Killing your antivirus before it can fight back</h2><p>The most operationally significant component is the WDAC Code Integrity policy.</p><p>Windows Defender Application Control (WDAC) policies tell the operating system which executables are allowed to run. The attackers deploy a deny-list policy to <code>%WINDIR%\System32\CodeIntegrity\SIPolicy.p7b</code> that blocks 50 executable paths across six security vendors plus core Windows security services:</p><table class="table"><thead><tr><th>Target</th><th>Blocked executables</th></tr></thead><tbody><tr><td><strong>Avast</strong></td><td>AvastSvc.exe, AvastUI.exe, afwServ.exe, aswEngSrv.exe, aswidsagent.exe, aswToolsSvc.exe, wsc_proxy.exe, Icarus components, Overseer</td></tr><tr><td><strong>AVG</strong></td><td>All executables under Program Files\AVG\Antivirus</td></tr><tr><td><strong>Avira</strong></td><td>Security, VPN, Fallback Updater, Optimizer Host, Endpoint Protection SDK</td></tr><tr><td><strong>Windows Defender</strong></td><td>MsMpEng.exe, MpCmdRun.exe, MpDefenderCoreService.exe</td></tr><tr><td><strong>Windows Security</strong></td><td>SecurityHealthHost.exe, SecurityHealthService.exe, SecurityHealthSystray.exe</td></tr><tr><td><strong>Windows Update</strong></td><td>MoUsoCoreWorker.exe, wuauclt.exe, wusa.exe</td></tr><tr><td><strong>Others</strong></td><td>HitmanPro, Kaspersky Virus Removal Tool, Farbar Recovery Scan Tool</td></tr></tbody></table><p>After the next reboot, none of these executables can start. The AV service is effectively dead. It won't run, it can't scan, and Windows Update can't push signature updates. One victim in the Reddit thread reported that Windows Defender disappeared entirely after running the trojanized installer.</p><p>This is a known but uncommon TTP (MITRE T1562.001). It requires the installer to run elevated, which the SmartScreen bypass dialog would have prompted for. Users who clicked through both warnings — SmartScreen and UAC — gave the malware everything it needed.</p><h2>&nbsp;</h2><h2>How the dropper provisions the bot</h2><p>Stage 2's strings are all XOR-obfuscated with the same <code>fywo</code> key used for its resources. After deobfuscation, we recovered 122 strings including registry paths, API names, and encrypted configuration values.</p><p>The dropper writes the bot's initial configuration to <code>HKCU\SOFTWARE\Python</code>. Both the registry value names and data are RC4-encrypted and hex-encoded — making the registry entries look like random hex strings to casual inspection. We recovered two configuration values:</p><ul><li data-list-item-id="e15e9100cccadef17d91598e244b0b038"><strong>CampaignID</strong> a unique identifier for this campaign, used during bot registration with the C2 server.</li><li data-list-item-id="e7a2666057614636498fba93e483028cf"><strong>DDRList</strong> six dead-drop resolver URLs that the bot uses to discover its C2 servers (detailed in the next section).</li></ul><p>Notably, the dropper does not write a C2 server list directly. The bot discovers its command-and-control addresses exclusively through the dead-drop resolver mechanism — a design choice that makes the infrastructure resilient to takedowns.</p><p>&nbsp;</p><h2>Dead-drop resolvers: how the bot finds its C2</h2><p>A dead-drop resolver (DDR) is an intermediary, a legitimate web page where the operator publishes encrypted C2 addresses. The bot fetches the page, extracts and decrypts the content, and connects to whatever C2 servers it finds. If the operator needs to rotate infrastructure, they update the DDR page and every infected machine follows automatically.</p><p>The bot reads its DDR list from the registry, fetches each URL, and RC4-decrypts the page content. Valid payloads start with the prefix <code>VAL:</code> followed by a semicolon-separated list of C2 URLs.</p><p>We extracted all six dead-drop resolver URLs from the dropper and probed them:</p><table class="table"><thead><tr><th>URL</th><th>Status</th><th>Decrypted content</th></tr></thead><tbody><tr><td><code>telegra[.]ph/tr02-05-02</code></td><td>Live</td><td>C2 list: parkspringshotel[.]com + auraguest[.]lk</td></tr><tr><td><code>telegra[.]ph/ki06-05-02</code></td><td>Live</td><td><code>VAL:XX</code> — placeholder for future C2 rotation</td></tr><tr><td><code>rentry[.]co/zzk7opdu</code></td><td>Live</td><td>Same C2 list</td></tr><tr><td><code>rentry[.]org/wayc2qqz</code></td><td>Live</td><td><code>VAL:XX</code> — placeholder</td></tr><tr><td><code>codeberg[.]org/etienne74/guix/...</code></td><td>404</td><td>Removed or never created</td></tr><tr><td>`2wxjoz6lkdxkniksujbdknkugweemx7uvxdr4ejgyipce4tnvktvbvqd.onion/t`</td><td>Not probed</td><td>Tor hidden service DDR</td></tr></tbody></table><p>The operator has two live C2 servers and four reserve dead-drop pages — two stubs ready for C2 rotation and one Tor fallback. If the current C2 infrastructure gets burned, the operator updates a Telegraph or Rentry page and every infected machine picks up the new address on its next poll cycle.</p><p>Beyond the dead-drop mechanism, the bot has a domain generation algorithm (DGA) as a last-resort fallback. It combines four seeds (<code>XNerWs4I</code>, <code>e55gegnW</code>, <code>RjWN0Y9m</code>, <code>AemOU1co</code>) with 14 TLDs and an ISO-week-based rotation to produce 56 candidate domains per week. We probed all current DGA domains — none are registered. The operator is running purely on dead-drop infrastructure for now, but the DGA ensures the botnet can survive even if all resolver pages and C2 servers are taken down simultaneously.</p><p>&nbsp;</p><h2>The C2 protocol: RSA-OAEP wrapping AES-GCM</h2><p>We reversed the bot's full communication protocol from the PyArmor-protected bytecode. It uses a layered encryption scheme designed to prevent passive interception and session tampering:</p>

<p>The bot wraps a fresh AES-256 key with the hardcoded RSA-2048 public key (OAEP, SHA-256) and sends it to the C2. The server proves possession of the private key by returning <code>"ok"</code> encrypted with AES-GCM. From that point, every message in both directions is AES-256-GCM encrypted with a per-direction sequence counter as authenticated associated data — preventing replay and reordering.</p><p>After the handshake, the bot registers with the campaign ID provisioned by the dropper. The server returns a <code>bot_id</code> and <code>bot_pass</code> that the bot stores in the registry for subsequent polling. The bot's primary capability is arbitrary Python code execution — the attacker can ship any Python code and the bot will run it and return the output.</p><p>All identified C2 and staging servers are compromised <a href="https://qloapps.com/">QloApps</a> hotel reservation websites:</p><table class="table"><thead><tr><th>Domain</th><th>Role</th><th>IP</th><th>PHP</th><th>Location</th></tr></thead><tbody><tr><td><code>parkspringshotel[.]com</code></td><td>C2 panel</td><td>172.96.172[.]91</td><td>8.3.30</td><td>Ghana</td></tr><tr><td><code>auraguest[.]lk</code></td><td>C2 panel</td><td>209.133.215[.]178</td><td>8.3.30</td><td>Sri Lanka</td></tr><tr><td><code>checkinnhotels[.]com</code></td><td>Linux payload staging</td><td>66.29.137[.]25</td><td>7.4.33</td><td>—</td></tr></tbody></table><p>The two C2 servers share identical JARM fingerprints and run the same PHP version, confirming the same C2 panel software is deployed on both. The third domain, <code>checkinnhotels[.]com</code>, was used to host the Linux payload disguised as an SVG file (<a href="https://www.bleepingcomputer.com/news/security/jdownloader-site-hacked-to-replace-installers-with-python-rat-malware/">BleepingComputer</a>). All three run QloApps — an open-source hotel booking CMS — suggesting the attacker specifically targets this software to build their infrastructure. None of the domains had malicious detections on VirusTotal at the time of discovery. We confirmed both C2 servers remain operationally live as of May 11.</p><h2>&nbsp;</h2><h2>The r77 rootkit stager</h2><p>The rootkit stager is a 176 KB native x86 PE based on the open-source <a href="https://github.com/bytecode77/r77-rootkit">r77 rootkit</a>. It contains an embedded .NET assembly that performs four operations:</p><ol><li data-list-item-id="e9ca3772c2bd6052d86931268e23d036a"><strong>AMSI bypass</strong> — a PowerShell cradle patches <code>AmsiScanBuffer</code> in memory, disabling Windows' Antimalware Scan Interface before any script payload runs.</li><li data-list-item-id="e01c27cd4c721b2dabe18b819d05c84fe"><strong>Reflective DLL injection</strong> — injects the r77 hooking DLLs (32-bit and 64-bit variants) into <code>winlogon.exe</code>. These DLLs hook Windows API functions to hide any process, file, or registry key whose name starts with the <code>$77</code> prefix.</li><li data-list-item-id="e254d7da7ebd6dfd7d57f7c5f67760ba3"><strong>Registry persistence</strong> — stores the stager assembly as a binary blob in <code>HKLM\SOFTWARE\$77stager</code> and reloads it at every boot via .NET reflection.</li><li data-list-item-id="ef200c38559748bd535edaf6a0d5aa3d5"><strong>Service creation</strong> — installs a Windows service (<code>$77svc</code>) to ensure the rootkit survives reboots independently of the registry mechanism.</li></ol><p>Once r77 is active, the <code>$77</code> prefix acts as an invisibility cloak. The Python bot calls <code>r77_hide_self()</code> and <code>r77_hide_registry_path()</code> to rename its own process and registry hive with this prefix, making them invisible to Task Manager, <code>regedit</code>, and most security tools.</p><h2>&nbsp;</h2><h2>The Python bot under PyArmor v9</h2><p>The final payload is a Python script protected by <a href="https://pyarmor.dashingsoft.com/">PyArmor</a> v9, a commercial bytecode obfuscation tool. PyArmor encrypts each function's bytecode individually and decrypts it at runtime through a native DLL — making static analysis significantly harder than standard Python malware.</p><p>We built a custom tool to decrypt and disassemble the protected bytecode, recovering 30 functions totaling 7,326 lines of disassembly. The bot is cross-platform (Windows and Linux), uses gevent for asynchronous I/O, and handles the full lifecycle: configuration management, C2 discovery via dead-drop resolvers and DGA, encrypted communication, task execution, and rootkit integration.</p><p>The bot's primary capability is executing arbitrary Python code received from the C2 server. Combined with the Python 3.14 runtime installed by the dropper, this gives the operator the ability to deploy any follow-on payload — keyloggers, credential stealers, lateral movement tools — without needing to push new binaries to the victim.</p><h2>&nbsp;</h2><h2>Impact and recommendations</h2><p>Users who downloaded JDownloader from the official website between May 6 and May 7, 2026, using the "Download Alternative Installer" links (Windows) or the Linux shell installer link are potentially compromised. The <a href="https://jdownloader.org/incident_8.5.2026.html">official incident report</a> lists eight malicious installer hashes across x86/amd64 and multiple JRE versions. The attackers exploited an unpatched CMS vulnerability to swap download links — the actual installer files hosted externally were never modified. In-app updates, macOS downloads, and package manager installs (Flatpak, Winget, Snap) were not affected.</p><p>The Linux attack chain, [first reported by BleepingComputer](https://www.bleepingcomputer.com/news/security/jdownloader-site-hacked-to-replace-installers-with-python-rat-malware/), follows a different delivery path. We downloaded the trojanized shell installer and its payload to verify the claims and dig deeper.d. The modified install4j script requires root, checks for x86_64 architecture, and downloads a 20 MB tar.gz from <code>checkinnhotels[.]com/img/logo1.svg</code> (disguised with <code>Content-Type: image/svg+xml</code> — still live as of May 11). The archive contains two files: a 3 KB SUID-root helper (<code>systemd-exec</code>) and a 21 MB PyInstaller bundle (<code>pkg</code>). The helper is a minimal ELF that calls <code>setuid(0)</code>, <code>setgid(0)</code>, and <code>execvp()</code> — installed to <code>/usr/bin/systemd-exec</code> with <code>chmod 4755</code>. Persistence is created via <code>/etc/profile.d/systemd.sh</code>, which launches the payload masquerading as <code>/usr/libexec/upowerd</code>.</p><p>We decrypted the PyArmor-protected Python bytecode from the Linux payload and confirmed it is <strong>the same bot source code</strong> as the Windows variant — identical RSA public key, DGA seeds, RC4 keys, C2 protocol, and DDR handler logic. The same campaign ID (<code>NdcHsJPM</code>) and all six DDR URLs are written to <code>~/.local/share/</code> as RC4-encrypted files (mirroring the Windows registry approach). The only difference is the Python runtime: the Linux bundle uses Python 3.12 (packaged via PyInstaller) versus Python 3.14 on Windows.</p><p>The JDownloader developers restored clean downloads on May 9 and published a detailed incident timeline. Users who already had JDownloader installed and received updates through the application's built-in updater were not affected — only fresh downloads from the website during the compromise window were trojanized.</p><p><strong>If you ran the trojanized installer:</strong></p><ul><li data-list-item-id="e78c8637f87f47adb2a6c0e9e37ff1466">The WDAC policy may have disabled your antivirus. Check <code>%WINDIR%\System32\CodeIntegrity\SIPolicy.p7b</code> — if it exists and you didn't create it, delete it and reboot.</li><li data-list-item-id="e5a9344602452a9e77dfe81e30c45fd8c">The registry keys <code>HKCU\SOFTWARE\Python</code> (bot config) and <code>HKLM\SOFTWARE\$77stager</code> (rootkit) are strong indicators of compromise — but if r77 is active, its API hooks hide all <code>$77</code>-prefixed registry keys and the bot's own hive from standard tools like <code>regedit</code>. To inspect these, boot from a Windows recovery environment or mount the registry hives offline.</li><li data-list-item-id="edcbc2f271c7b2885893f8f995fe252eb">A clean OS reinstall is the safest remediation. The r77 rootkit's reflective injection into <code>winlogon.exe</code> and AMSI bypass make partial cleanup unreliable.</li></ul><p><strong>For defenders:</strong></p><ul><li data-list-item-id="efcd7ce434d65f159da0dbff097d5fb44">The bot uses the default Python User-Agent <code>Python-urllib/3.14</code>. While not unique on its own, it can help correlate connections to the C2 URLs and DDR pages listed below.</li><li data-list-item-id="e35fe4757c01a79131defbd71e6762bfb">Monitor for DNS queries to the DGA pattern: 15-character lowercase alphanumeric hostnames on TLDs including <code>.top</code>, <code>.cfd</code>, <code>.sbs</code>, <code>.cyou</code>, <code>.icu</code>, <code>.casa</code>.</li><li data-list-item-id="e41ab2df0dd210b9e338012701bdf4398">The mutex name <code>Global\0C3C1D37</code> can serve as a host-based indicator.</li><li data-list-item-id="e68e99d7961368cd02568989f8e767d08">Block the dead-drop resolver pages: <code>telegra[.]ph/tr02-05-02</code>, <code>telegra[.]ph/ki06-05-02</code>, <code>rentry[.]co/zzk7opdu</code>, <code>rentry[.]org/wayc2qqz</code>.</li></ul><h2>&nbsp;</h2><h2>Indicators of Compromise</h2><p>Full IOC list available on <a href="https://github.com/avast/ioc">GitHub</a>.</p><h3>Hashes (SHA-256)</h3><table class="table"><thead><tr><th>Artifact</th><th>Hash</th></tr></thead><tbody><tr><td>Stage 1 — Windows (analyzed variant)</td><td><code>5a6636ce490789d7f26aaa86e50bd65c7330f8e6a7c32418740c1d009fb12ef3</code></td></tr><tr><td>Stage 1 — Linux shell installer</td><td><code>6d975c05ef7a164707fa359284a31bfe0b1681fe0319819cb9e2c4eec2a1a8af</code></td></tr><tr><td>Stage 2 (C++ dropper)</td><td><code>77a60b5c443f011dc67ace877f5b2ad7773501f3d82481db7f4a5238cf895f80</code></td></tr><tr><td>Stage 3 — Windows (PyArmor bot)</td><td><code>5fdbee7aa7ba6a5026855a35a9fe075967341017d3cb932e736a12dd00ed590a</code></td></tr><tr><td>PyArmor runtime DLL</td><td><code>33318499489cdb82543c0bfea699b98f5928c7a360966df6e958a9cbc2eab3fe</code></td></tr><tr><td>r77 rootkit stager</td><td><code>5c887054cb1dce077943afa955db43306f66795f7cbda8233d8ba25230a23d41</code></td></tr><tr><td>WDAC CI policy</td><td><code>5ee86c177dc5bdba05e3bdc67b07115c66097f825fff257bf0d4a999bbb8a1ea</code></td></tr><tr><td>Linux payload archive (logo1.svg)</td><td><code>6550672cac21e036882921dd934ee06552dc74d3b0a9e1ddc26f952855e11371</code></td></tr><tr><td>Linux SUID helper (systemd-exec)</td><td><code>25744e90bfa44cbcbf1f3d3c3cb90dd79dd32a6e359df9d2660ff251d6d03b46</code></td></tr><tr><td>Linux PyInstaller bot (pkg)</td><td><code>bf47585bd0b39f0731f044b37a95eb7e311ad31b23b50306a113a3aa777dbfab</code></td></tr></tbody></table><p>Six additional Windows installer variants are listed in the <a href="https://jdownloader.org/incident_8.5.2026.html">official incident report</a>. Full hash list on <a href="https://github.com/avast/ioc/tree/master/JDownloaderRAT">GitHub</a>.</p><h3>Network indicators</h3><table class="table"><thead><tr><th>Type</th><th>Value</th><th>Context</th></tr></thead><tbody><tr><td>C2 URL</td><td><code>parkspringshotel[.]com/m/Lu6aeloo.php</code></td><td>Active C2</td></tr><tr><td>C2 URL</td><td><code>auraguest[.]lk/m/douV2quu.php</code></td><td>Active C2</td></tr><tr><td>Staging</td><td><code>checkinnhotels[.]com/img/logo1.svg</code></td><td>Linux payload (still live)</td></tr><tr><td>C2 IP</td><td><code>172.96.172[.]91</code></td><td>parkspringshotel.com</td></tr><tr><td>C2 IP</td><td><code>209.133.215[.]178</code></td><td>auraguest[.]lk</td></tr><tr><td>Staging IP</td><td><code>66.29.137[.]25</code></td><td>checkinnhotels.com</td></tr><tr><td>Dead-drop resolver</td><td><code>telegra[.]ph/tr02-05-02</code></td><td>Live, serves encrypted C2 list</td></tr><tr><td>Dead-drop resolver</td><td><code>rentry[.]co/zzk7opdu</code></td><td>Live, serves encrypted C2 list</td></tr><tr><td>Dead-drop resolver</td><td><code>telegra[.]ph/ki06-05-02</code></td><td>Stub, reserved for C2 rotation</td></tr><tr><td>Dead-drop resolver</td><td><code>rentry[.]org/wayc2qqz</code></td><td>Stub, reserved for C2 rotation</td></tr></tbody></table><h3>Host indicators</h3><table class="table"><thead><tr><th>Type</th><th>Value</th></tr></thead><tbody><tr><td>Mutex</td><td><code>Global\0C3C1D37</code></td></tr><tr><td>Registry (bot config)</td><td><code>HKCU\SOFTWARE\Python\*</code> (hex-encoded RC4-encrypted value names)</td></tr><tr><td>Registry (r77)</td><td><code>HKLM\SOFTWARE\$77stager</code>, <code>$77dll32</code>, <code>$77dll64</code>, <code>$77svc</code></td></tr><tr><td>WDAC policy</td><td><code>%WINDIR%\System32\CodeIntegrity\SIPolicy.p7b</code> (GUID <code>{31351756-3F24-4963-8380-4E7602335AAE}</code>)</td></tr><tr><td>Bot process</td><td><code>pythonw.exe</code> (Python 3.14, User-Agent <code>Python-urllib/3.14</code>)</td></tr><tr><td>Tor drop path</td><td><code>C:\ProgramData\tor\tor\tor.exe</code></td></tr><tr><td>Linux SUID binary</td><td><code>/usr/bin/systemd-exec</code></td></tr><tr><td>Linux payload</td><td><code>/root/.local/share/.pkg</code></td></tr><tr><td>Linux persistence</td><td><code>/etc/profile.d/systemd.sh</code></td></tr><tr><td>Linux masquerade</td><td><code>/usr/libexec/upowerd</code></td></tr></tbody></table><h3>MITRE ATT&amp;CK</h3><table class="table"><thead><tr><th>Technique</th><th>ID</th></tr></thead><tbody><tr><td>Supply Chain Compromise: Compromise Software Supply Chain</td><td>T1195.002</td></tr><tr><td>Obfuscated Files or Information</td><td>T1027</td></tr><tr><td>Impair Defenses: Disable or Modify Tools</td><td>T1562.001</td></tr><tr><td>Process Injection: Dynamic-link Library Injection</td><td>T1055.001</td></tr><tr><td>Web Service: Dead Drop Resolver</td><td>T1102.001</td></tr><tr><td>Dynamic Resolution: Domain Generation Algorithms</td><td>T1568.002</td></tr><tr><td>Encrypted Channel: Asymmetric Cryptography</td><td>T1573.002</td></tr><tr><td>Rootkit</td><td>T1014</td></tr><tr><td>Create or Modify System Process: Windows Service</td><td>T1543.003</td></tr><tr><td>Modify Registry</td><td>T1112</td></tr></tbody></table><p>For customers using Norton, Avast, AVG, Avira or any other security product, the most important question is whether the malicious installer was executed. If you downloaded an affected installer but did not run it, delete the file, download a fresh installer from the official JDownloader site, and run a full scan with up-to-date protection. If you ran the installer, or cannot rule out that you ran it, treat the system as compromised. JDownloader recommends a clean operating system reinstall in this situation, and we agree that this is the safest baseline. The Windows payload includes rootkit behavior, persistence, encrypted configuration and policy-based defense evasion, so a normal scan may reduce risk but cannot guarantee that every persistence mechanism has been removed. Until the system has been rebuilt or inspected from a trusted recovery environment, avoid using it for sensitive activity. Do not log in to email, banking, work accounts, password managers or other important services from that machine. Change important passwords from another trusted device, and monitor accounts for unusual activity.</p><p>&nbsp;</p>

Malware that hid itself on infected systems and disabled antivirus protection.

Inside the JDownloader Supply-Chain Attack: An r77 Rootkit Bot That Kills Your Antivirus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Lumma Rebrand We’ve Been Waiting For?

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

<h2>Key Points&nbsp;</h2><ul type="disc"><li data-list-item-id="e59deb5ed92385418b6c648bee2751bf3">VoidStealer is the first infostealer observed in the wild adopting a novel debugger-based Application-Bound Encryption (ABE) bypass technique that leverages hardware breakpoints to extract the <code>v20_master_key</code> directly from browser memory.&nbsp;</li><li data-list-item-id="ee23cdbf8bdc0aabe684c5884f164ed93">The bypass requires neither privilege escalation nor code injection, making it a stealthier approach compared to alternative ABE bypass methods.&nbsp;</li><li data-list-item-id="e9aad20d0fd1b9a44cdb3bdc4c74ad104">In this technical blog post, we dissect the bypass technique step-by-step, from locating the target address for breakpoint placement to extracting the <code>v20_master_key</code>.&nbsp;</li><li data-list-item-id="e1808ce54ff39fc88832d5379553d4e3b">To support the defense community, Gen Threat Labs provides practical detection strategies and indicators to help defenders identify and mitigate this novel bypass technique.&nbsp;</li></ul><h2>Introduction&nbsp;</h2><p>When Google introduced <a href="https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html" target="_blank" rel="noreferrer noopener">Application-Bound Encryption</a> (ABE) in July 2024 with Chrome 127, it didn't mark the end of infostealers –⁠⁠⁠⁠⁠⁠ as expected, infostealers adopted quickly and came up with various methods to bypass it. Still, it undoubtedly raised the bar for accessing sensitive browser data, and, more importantly, significantly increased the visibility of such data theft attempts, as bypassing ABE now requires attackers to perform additional steps that are inherently more suspicious. Various bypass techniques have emerged since then, and since each comes with its own trade-offs, new approaches continue to appear as threat actors seek to minimize the footprint and evade detection.&nbsp;</p><p>In this technical blog post, we dissect a novel debugger-based ABE-bypass technique that is both technically elegant and offers a significant advantage over other existing bypass methods: a much lower detection footprint. The technique relies on attaching to the browser process as a debugger and setting breakpoints at carefully selected locations to extract the <code>v20_master_key</code> directly from the browser process memory. We demonstrate the technique on VoidStealer, the first emerging infostealer we have observed using this approach in the wild.&nbsp;&nbsp;</p><h2>VoidStealer&nbsp;</h2><p>VoidStealer is a MaaS infostealer that began being marketed on several darkweb forums since mid December 2025 and has been actively developed since then.&nbsp;</p>

<p>Considering the first version of VoidStealer from December 12, 2025, as the earliest date we have identified it being offered, the VoidStealer development timeline is approximately as follows (please note that exact dates may vary slightly, as we rely on announcements made by the malware developers themselves on HackForums):&nbsp;</p>

<table class="table"><tbody><tr><td><strong>VoidStealer version</strong></td><td><strong>Release Date</strong></td></tr><tr><td>v1.0</td><td>Dec 12, 2025&nbsp;</td></tr><tr><td>v1.1&nbsp;</td><td>Jan 16, 2026&nbsp;</td></tr><tr><td>v1.2&nbsp;</td><td>Jan 19, 2026&nbsp;</td></tr><tr><td>v1.3&nbsp;</td><td>Feb 3, 2026&nbsp;</td></tr><tr><td>v1.4&nbsp;</td><td>Feb 4, 2026&nbsp;</td></tr><tr><td>v1.5&nbsp;</td><td>Feb 22, 2026&nbsp;</td></tr><tr><td>v1.6&nbsp;</td><td>Mar 3, 2026&nbsp;</td></tr><tr><td>v1.7&nbsp;</td><td>Mar 9, 2026&nbsp;</td></tr><tr><td>v1.8&nbsp;</td><td>Mar 10, 2026&nbsp;</td></tr><tr><td>v1.9&nbsp;</td><td>Mar 10, 2026&nbsp;</td></tr><tr><td>v2.0&nbsp;</td><td>Mar 13, 2026&nbsp;</td></tr><tr><td><p lang="EN-US">v2.1&nbsp;</p></td><td><p lang="EN-US">Mar 18, 2026&nbsp;</p></td></tr></tbody></table><p>&nbsp;</p>

<p>The version 2.0, reported on Mar 13, 2026, introduced the novel ABE bypass technique.&nbsp;</p>

<p>To keep the blog post to the point, we focus mainly on the bypass technique itself rather than VoidStealer's capabilities.&nbsp;</p><h2>ABE Bypass(es)&nbsp;</h2><p>Similarly to other infostealers, VoidStealer does not rely on a single ABE-bypass technique but implements two distinct methods in case one fails. The first is a well-documented approach that involves injecting into the browser process and invoking <code>IElevator::DecryptData</code> from the browser's context via the COM interface. Since this is a well-known and thoroughly documented technique, we will not detail it here (for those interested, it is extensively documented in the <a href="https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption" target="_blank" rel="noreferrer noopener">ChromElevator project</a>). Nevertheless, it is worth noting that, however reliable it is, this technique relies on process injection, which is noisy and suspicious and might easily get flagged by security tools. The second (novel) approach is stealthier in this regard – it relies solely on the WinAPI function <code>ReadProcessMemory</code> and debugger attachment, which are considerably less suspicious than direct browser memory injection.&nbsp;</p><p>To clarify how the bypass operates and what it exploits, let's take a step back and briefly recap what the idea behind Application-Bound Encryption is and how Chrome uses it to protect passwords and other sensitive data. Chrome passwords are encrypted and stored in a SQLite3 database located at <code>%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data</code> (assuming standard Chrome installation on Windows) and can be accessed, for example, by running the following Python script:&nbsp;</p>

<p>The script output for a single record would look roughly as follows (note the <code>v20</code> prefix in the encrypted password, indicating ABE-protected data):&nbsp;</p>

<p>The password value is encrypted using AES-GCM with the <code>app_bound_key</code>, which we will refer to as the <code>v20_master_key</code> going forward. The decryption process begins by removing the <code>v20</code> prefix from the encrypted string, then extracting the following 12 bytes to use as the nonce, and finally treating the remaining data as the combined ciphertext and authentication tag. Below is a simple Python script demonstrating this decryption process:&nbsp;</p>

<p>At this point, it is crucial to highlight that the knowledge of the <code>v20_master_key</code> is sufficient for decrypting <strong>any ABE-protected data</strong> tied to the application (in this case, Chrome). Where does this key come from, though? Chrome stores it in an encrypted form on disk in a JSON file <code>%LOCALAPPDATA%\Google\Chrome\User Data\Local State</code> under the <code>["os_crypt"]["app_bound_encrypted_key"]</code> field. Extracting the actual key in unencrypted form (<code>v20_master_key</code>) requires base64-decoding the value, removing the <code>APPB</code> prefix, calling <code>CryptUnprotectData</code> as <code>NT AUTHORITY\SYSTEM</code>, then calling it again as the logged-in user, and finally, specifically for Chrome, performing additional post-processing that we will not cover in detail here (for those interested, see the <a href="https://github.com/chromium/chromium/blob/main/chrome/elevation_service/elevator.cc#L229-L239" target="_blank" rel="noreferrer noopener">Chromium source code</a>). The ABE-protected password decryption workflow is illustrated in Figure 7.&nbsp;</p>

<p>To summarize, the fundamental security mechanism behind ABE lies in that the <code>v20_master_key</code>, which is used to encrypt/decrypt the sensitive browser data, is protected by <code>CryptProtectData</code> invoked as <code>NT AUTHORITY\SYSTEM</code>, the highest-privileged account on Windows.&nbsp;&nbsp;</p><p>Chrome, however, runs in the context of the logged-on user, not as <code>SYSTEM</code>. So how does it decrypt the key? To bridge that gap, Google implemented a separate service, Google Chrome Elevation Service (<code>elevation_service.exe</code>), which runs with <code>SYSTEM</code> privileges and handles the decryption. When Chrome needs to decrypt the <code>app_bound_encrypted_key</code>, it invokes <code>IElevator::Decrypt()</code> via a COM interface. The elevation service "validates" that the caller is Chrome, and if the check passes, returns the decrypted <code>v20_master_key</code> (the word validates is quoted as the check is not particularly robust and opens the door to another bypass). Chrome can then use the <code>v20_master_key</code> to encrypt or decrypt sensitive data such as cookies and passwords.&nbsp;</p>

<p>It is obvious that if the malware managed to run as <code>NT AUTHORITY\SYSTEM</code>, it could simply replicate all the steps and directly decrypt the <code>app_bound_encrypted_key</code> (and that is also one of the ABE bypass techniques). However, such a bypass still requires SYSTEM-level privileges, limiting its applicability to only some environments. Therefore, infostealers typically use it as a complementary method when other approaches fail, rather than relying on it as their primary technique.&nbsp;&nbsp;</p><p>There is also the option of injecting into Chrome and making the key decryption request directly from within the context of the browser, a commonly used bypass technique that VoidStealer itself employs. While this approach avoids the need for <code>SYSTEM</code> privileges, it still requires the injection, which is noisy.&nbsp;&nbsp;&nbsp;</p><p>This perfectly illustrates our earlier point – ABE does not prevent data theft, but it undoubtedly forces attackers into more visible actions, thus introducing great detection/hunting opportunities for us, defenders.&nbsp;&nbsp;</p><p>What prevents infostealers from reading the <code>v20_master_key</code> directly from the browser's memory, though? Chrome implements several protective measures to prevent it. First, the key is retained in memory in plaintext only for the minimum duration required to complete the cryptographic operation, minimizing its exposure. Additionally, the key is encrypted using the <code>CryptProtectMemory</code> function with the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag, ensuring that even if an attacker could read the encrypted form of the key from memory, they would still need to invoke the complementary decryption function, <code>CryptUnprotectMemory</code>, directly from the Chrome process to decrypt it. And that would require a code injection, which is noisy.&nbsp;&nbsp;</p><p>Nevertheless, despite these safeguards, there is still a critical weakness. Regardless of how small the key exposure window is, there is still a moment in which the <code>v20_master_key</code> is present in memory <strong>in plaintext</strong>. And that is precisely what the novel technique exploits. By attaching to the browser process as a debugger and setting a breakpoint at the precise moment when the key is present in plaintext, an attacker can extract it directly from the memory. Importantly, this can be done without any privilege escalation and, when using hardware breakpoints rather than software ones, without any writes to the browser process.&nbsp;</p><p>Note that the VoidStealer developers did not invent the technique. They directly adopted it from the open-source <a href="https://github.com/Meckazin/ChromeKatz/tree/main/ElevationKatz" target="_blank" rel="noreferrer noopener">ElevationKatz</a> project, developed by Meckazin, the same author behind CookieKatz and CredentialKatz, which were among the first tools capable of bypassing ABE since its introduction. Although there are some differences, based on our analysis, it is evident that VoidStealer's implementation is directly based on ElevationKatz, which has now been public for over half a year. Yet, VoidStealer is the first malware we are aware of employing this technique in the wild.&nbsp;</p><p>In the following section, we focus specifically on VoidStealer's implementation of the bypass.&nbsp;</p><h2>Technical Walkthrough of VoidStealer's Implementation of the Novel ABE Bypass&nbsp;</h2><p>&nbsp;<br>The success of the entire technique boils down to finding the right address on which to set the breakpoint. VoidStealer begins by spawning a browser process via <code>CreateProcessW</code> with the <code>CREATE_SUSPENDED</code> and <code>SW_HIDE</code> flags. It then resumes the main thread and immediately attaches a debugger to the newly spawned process via <code>DebugActiveProcess</code>.&nbsp;&nbsp;</p><p>While it may not be immediately obvious, beginning with this step is deliberate and strategically important as browsers typically load cookies into memory during startup. And since the cookies are ABE-protected, the browser must decrypt the <code>v20_master_key</code> during its initialization. This makes the browser startup an ideal opportunity to intercept and steal the key.&nbsp;</p>

<p lang="EN-US">It is unclear to us why VoidStealer launches the browser in a suspended state (an additional suspicious indicator), only to resume and attach a debugger immediately afterward, rather than directly spawning the browser under a debugger. Nevertheless, we have verified that the same bypass technique works equally well when the browser is spawned directly using <code>CreateProcessW</code> with the <code>DEBUG_ONLY_THIS_PROCESS</code> flag. We assume that this is simply a consequence of copy-pasting the code from ElevationKatz, which follows the same approach.&nbsp;</p><p>Once attached as a debugger, VoidStealer begins listening for debug events via <code>WaitForDebugEvent</code>.&nbsp;</p>

<p>Since VoidStealer targets only Chrome and Edge (like ElevationKatz), the code address the bypass tries to find resides in either <code>chrome.dll</code> or <code>msedge.dll</code> (though it could readily be extended to other Chromium-based browsers). Because VoidStealer attaches to the browser as a debugger almost immediately after launch,&nbsp;before all DLLs have been loaded, it cannot simply search for the target module right away. Instead, it waits for <code>LOAD_DLL_DEBUG_EVENT</code> (sent to the debugger whenever a new DLL is loaded into the debugged process memory) and checks each loaded module against the target DLL.&nbsp;</p>

<p>Once the target DLL is loaded, VoidStealer scans its entire <code>.rdata</code> section using <code>ReadProcessMemory</code> to find the string <code>OSCrypt.AppBoundProvider.Decrypt.ResultCode</code>, or more precisely, its address.&nbsp;</p>

<p>A good question is: why this particular string? The answer lies in the <a href="https://github.com/chromium/chromium/blob/2852519ad41d6809df1786b3854fe5055b364687/chrome/browser/os_crypt/app_bound_encryption_provider_win.cc#L137" target="_blank">Chromium source code</a>, which reveals that this string appears immediately after the call to <code>os_crypt::DecryptAppBoundString</code>. Thus, this is precisely the point at which the <code>v20_master_key</code> is present in the browser's memory in plaintext.&nbsp;&nbsp;</p>

<p>Furthermore, there is only one cross-reference to that string, making it a perfect target for the breakpoint.&nbsp;</p>

<p>Following the cross-reference in <code>chrome.dll</code>, we can see that the disassembled code corresponds to the source code and that the cross-reference comes from a <code>LEA</code> instruction.&nbsp;</p>

<p>The important bytes from the <code>LEA</code> instructions are the last four, as they specify the 32-bit displacement used to calculate the actual address, which is to be loaded into the <code>RCX</code> register.&nbsp;&nbsp;</p>

<p>The CPU essentially calculates the address as follows: <code>RCX = (instruction_address + 7) + (signed int32) disp32</code>. To find the <code>LEA</code> instruction referencing the target string, VoidStealer scans the whole <code>.text</code> section and searches for the byte sequences <code>48 8D 0D</code> (the beginning of the <code>LEA</code> instruction), extracts the following 4 bytes (the 32-bit displacement), and calculates the referenced address. It then compares each calculated address against the <code>OSCrypt.AppBoundProvider.Decrypt.ResultCode</code> string address to identify the matching <code>LEA</code> instruction referencing it, which becomes the target address for the breakpoint.&nbsp;</p>

<p>If the search is successful, VoidStealer sets a hardware breakpoint at this address across all browser threads by resolving <code>NtGetNextThread</code> from <code>ntdll.dll</code> and iterates through each thread, suspends it, writes the breakpoint address into <code>DR0</code>, enables it via <code>DR7</code>, and resumes the execution.&nbsp;</p>

<p>To ensure complete coverage, VoidStealer’s debug loop also handles <code>CREATE_THREAD_DEBUG_EVENT</code> events to set up the hardware breakpoint for any newly created thread.&nbsp;</p>

<p>At this point, it might be worth explaining why hardware breakpoints are chosen over software ones. Setting a software breakpoint requires patching the binary by overwriting the target address with, for example, an <code>INT3 (0xCC)</code> instruction, necessitating a memory write into the browser’s memory. And that is precisely what attackers aim to avoid. Hardware breakpoints, on the other hand, can be configured entirely through <code>SetThreadContext</code> without ever modifying the browser’s memory, making the bypass stealthier.&nbsp;&nbsp;</p><p>Once the breakpoints are in place, all that is left is to wait for them to trigger. Since cookies are protected by ABE and the browser needs to load them at startup, it must request the <code>v20_master_key</code> decryption shortly after launching to decrypt them from disk. Therefore, there is a high chance that the breakpoint will be triggered shortly after the browser starts.&nbsp;</p>

<p>If the breakpoint is placed on the <code>LEA RCX</code>, <code>OSCrypt.AppBoundProvider.Decrypt.ResultCode</code> address, then in current builds, the <code>R14</code> register (for Edge) or <code>R15</code> register (for Chrome) holds a pointer to the <code>v20_master_key</code>. From there extracting the key straight from the memory is only two <code>ReadProcessMemory</code> calls away.&nbsp;&nbsp;</p><p>To make it easier to grasp the big picture of the entire bypass, we have illustrated the complete workflow in Figure 23.&nbsp;</p>

<h2>Detection Strategies for Defenders&nbsp;</h2><p>We should first emphasize that different malware authors will likely adapt the bypass technique in various ways – for example, they may not target the <code>v20_master_key</code> usage immediately after startup (in which case they could leverage an already-running browser instance). For detection purposes, it is crucial to identify what is unlikely to change across all possible variations. Regardless of implementation details, the bypass fundamentally relies on setting hardware breakpoints at strategic locations, which requires either attaching a debugger or launching the browser under a debugger, along with browser memory reads.&nbsp;&nbsp;&nbsp;&nbsp;</p><p>These invariants provide strong detection opportunities, especially in sandboxed environments, as legitimate applications do not debug browsers. What about legitimate debuggers, though? Even those require users to explicitly specify which application to debug. Therefore, if an application starts debugging a browser autonomously, it should be a clear red flag.&nbsp;&nbsp;&nbsp;&nbsp;</p><p>But beyond that, there are other detection opportunities. While reading browser memory may seem less suspicious than writing to it, as this bypass demonstrates, it actually can be. Therefore, monitoring reads from browser memory can provide valuable detection signals, as benign applications rarely have legitimate reasons to access it.&nbsp;&nbsp;</p><p>Lastly, the technique requires a running browser instance, which malware will typically try to hide from the user. Whether by launching it via <code>CreateProcess</code> with the <code>SW_HIDE</code> flag, running it in headless mode, creating a new desktop and running it from there, or positioning the browser window off-screen. These evasion tactics can serve as additional indicators of such malicious activity.&nbsp;</p><h2>Summary&nbsp;&nbsp;</h2><p>VoidStealer is the first infostealer observed in the wild employing a debugger-based ABE bypass technique (directly adapted from the publicly available ElevationKatz project), highlighting the continuously evolving landscape of Application-Bound Encryption bypasses. Unlike traditional bypass methods, it requires neither privilege escalation nor code injection, making it a stealthier alternative.&nbsp;&nbsp;</p><p>Given these advantages, combined with the availability of a public PoC (ElevationKatz), it is only to be expected that more infostealers will adopt the bypass technique in the future.&nbsp;</p><h2>IoC&nbsp;</h2><p>f783fde5cf7930e4b3054393efadd3675b505cbef8e9d7ae58aa35b435adeea4 (VoidStealer v2.0)&nbsp;</p>

A Novel Debugger-based ABE Bypass Spotted in the Wild

VoidStealer: Debugging Chrome to Steal Its Secrets 

<h2>Key points</h2><ul><li data-list-item-id="efa2702de580247f6397d254301188d2c">AuraStealer is an emerging malware-as-a-service (MaaS) infostealer observed in recent Scam-Yourself campaigns.</li><li data-list-item-id="ece552b6979ea0952bbe94abad912ebef">To hinder both static and dynamic analysis, AuraStealer employs a wide range of anti-analysis and obfuscation techniques, including indirect control flow obfuscation and exception-driven API hashing.</li><li data-list-item-id="e35d31d421cc5db86bac17645f30515a2">In this technical blog post, we provide a deep dive into the malware’s execution flow and functionality and provide practical tips and workflows for defeating its obfuscation.</li><li data-list-item-id="edc17181ba17c41a7dc5f94a739ae72cf">To support the defense community, Gen Threat Labs provides multiple scripts to assist defenders in analyzing AuraStealer, including a string decryption script and a dedicated configuration extractor.</li></ul><h2>Introduction</h2><p>AuraStealer is a rapidly growing infostealer-as-a-service, actively promoted across multiple underground forums since July 2025. The stealer is developed in C++ with a build size of ~500-700 kB and targets Windows systems from Windows 7 to Windows 11. It is marketed as a supposedly highly efficient, low-footprint stealer capable of stealing data from more than 110 browsers, 70 applications (including wallets and 2FA tools), as well as over 250 browser extensions, with the ability to further expand its collection scope through a customizable configuration. Contrary to the advertised claims, AuraStealer still contains multiple flaws that undermine its stealth and evasion capabilities, offering clear detection opportunities for defenders.</p>

<p>The infostealer is offered through a tiered subscription model, with the <strong>Basic</strong> <strong>plan</strong> priced at $295/month and the <strong>Advanced</strong> <strong>plan</strong> at $585/month. The tiers differ primarily in terms of configuration flexibility, data filtering, and operational scalability. A third tier, <strong>Team plan</strong>, is currently under development and is expected to introduce features tailored for collaborative use. Additionally, a temporary <strong>Trial tier</strong> was also offered, priced at $165 for a two-week subscription, which included all the features of the <strong>Basic plan</strong>. The <strong>Trial tier</strong> was available for purchase only during a 30-day window, aiming to attract new users before they committed to a full subscription.</p><p>The subscriptions include access to a dedicated web panel for managing and viewing stolen data, built on the Tabler template. Given that both the panel and the stealer were originally offered exclusively in Russian, it is reasonable to assume the developers operate within Russian‑speaking cybercriminal communities. However, this does not necessarily indicate their precise origin. The panel has since been updated and now supports both Russian and English.</p>

<h2>Landscape</h2><p>AuraStealer primarily spreads through Scam-Yourself campaigns, with&nbsp;<a href="https://undercodenews.com/tiktoks-dark-trick-aura-stealer-malware-masquerades-as-product-activation-guides/" target="_blank">TikTok videos</a> disguised as product activation guides being one of them. In these videos, victims are lured by an apparently easy tutorial promising free activation of otherwise paid software. Viewers are instructed to manually retype and run a displayed command in an administrative PowerShell, which, however, instead of activating the software, quietly downloads and executes the malicious payload. Concrete examples of these videos, along with the full execution chain and additional IoCs, can be found&nbsp;<a href="https://isc.sans.edu/diary/32380" target="_blank">here</a>.&nbsp;</p><p>Apart from TikTok Scam-Yourself campaigns, AuraStealer is also distributed through supposedly cracked games or software, with delivery chains of varying complexity. In the simplest cases, only a UPX-packed version of AuraStealer is executed, without additional stages, whereas the more elaborate campaigns employ multi-stage execution flows, involving custom loaders, DLL sideloading, injection into legitimate processes, or other intermediary steps. We have also observed AuraStealer being delivered together with GlassWorm via a malicious VS Code extension. Taken together, these observations indicate that AuraStealer is sold purely as the stealer itself, without a loader layer or additional delivery mechanisms.</p><p>Determining the exact scope of the AuraStealer threat is challenging, as we often block its delivery chains at earlier stages before the final payload can be executed. While the proactive defense is crucial for keeping our users safe, it also results in many AuraStealer payloads never reaching the system. As a result, it becomes inherently difficult not only to observe and quantify the full scope of the threat, but also to determine with certainty whether the blocked payloads were indeed intended to deliver AuraStealer.</p><p>Should it, for example, be delivered through ClickFix, one of the most widely adopted delivery techniques lately, we would proactively defend against those attacks right at the clipboard stage with our&nbsp;<a href="https://www.gendigital.com/blog/news/family-of-brands/clipboard-protection" target="_blank">Clipboard protection</a> feature. ClickFix typically refers to a technique in which users are presented with artificially generated errors or problems that must be resolved to continue, while simultaneously being provided with step-by-step instructions to address the issue. The steps usually include copying a command and running it via the Windows Run dialog or another system prompt, which, however, rather than resolving the issue, silently retrieves and executes the malicious payload.</p><p>To summarize, AuraStealer is not yet as widespread and popular as the more established infostealer families currently dominating the threat landscape, such as Lumma Stealer, StealC or Vidar. However, according to an&nbsp;<a href="https://g0njxa.medium.com/approaching-stealers-devs-a-brief-interview-with-aura-9b513369e117" target="_blank">interview</a> conducted by&nbsp;<a href="https://x.com/g0njxa" target="_blank">g0njxa</a> with the AuraStealer developers, the malware is backed by a committed team that continuously improves and evolves its functionality, aiming to become the number one in the infostealer market. This suggests that AuraStealer could become a more significant player in the future.</p><h2>AuraStealer Obfuscation</h2><p>AuraStealer incorporates a wide range of techniques designed to hinder both static and dynamic analysis. These include control flow obfuscation, string encryption, constant obfuscation, as well as standard anti-debug, anti-tamper, and anti-VM checks. It further employs advanced techniques such as exception-driven API-hashing, leveraging the Heaven’s Gate for suspicious NTDLL calls, and performing checks to detect breakpoints on return addresses.</p><h3>Indirect Control Flow Obfuscation</h3><p>The first obfuscation technique an analyst is likely to encounter when opening AuraStealer in a disassembler, such as IDA Pro, is its indirect control flow obfuscation. The obfuscation is not only immediately noticeable, but also one of the most troublesome obstacles that must be overcome to properly analyze the stealer. The obfuscation is based on systematically replacing direct jumps and calls with indirect ones, where the actual target address is computed only at runtime. This method effectively disrupts static analysis, as the disassemblers are left with a set of seemingly unrelated basic blocks, effectively breaking any control-flow graph analysis or decompilation.&nbsp;</p><p>To demonstrate how this obfuscation works in practice, and how it can be defeated, we focus on the&nbsp;<code>WinMain</code> function, which is both the longest and the most complex function of the stealer. Several examples illustrating the obfuscation mechanism at the assembly level are shown in Figure 4 below, with the instructions relevant to computing each target address highlighted in a distinct color. Notably, the screenshot also illustrates that the obfuscation successfully confused IDA, causing it to misinterpret the entire&nbsp;<code>WinMain</code><em><strong>&nbsp;</strong></em>function as a single basic block.</p>

<p>As illustrated, the target addresses are computed in several different ways depending on the branching context, ranging from simple arithmetic sum of two values (highlighted in green, blue, and red) to more complex ones, where the resulting target address may take multiple possible forms, with the final choice determined by a conditional instruction such as <code>cmovz</code><strong>&nbsp;</strong>(highlighted in pink).</p><p>At that point, a reader could easily conclude that a bit of pattern matching, emulation, and patching would be enough to remove the obfuscation – and that was our initial assumption as well. However, it turned out that AuraStealer uses multiple variations of these indirect control flow obfuscation schemes, some of which employ far more elaborate patterns. For example, the target address may even depend on the return values of multiple preceding function calls, since its computation involves conditional instructions driven by those results (see Figure 5).&nbsp;</p>

<p>Nonetheless, despite the diversity and potential complexity of these obfuscation schemes, there are still ways to deal with them and reconstruct the original control flow. First, the most basic scheme used to obfuscate function calls, which relies solely on the sum of two values can be resolved with a simple trick in IDA Pro. In these cases, it is sufficient to hint to IDA that the offsets contributing to the sum operation are in fact constant. Once treated as constant operands, IDA can evaluate the arithmetic on its own and optimize it accordingly, allowing the decompiler to reveal the actual call’s target address.</p>

<p>Figures 7 and 8 illustrate the effect of this trick and the resulting difference in the decompiled output. As can be seen, even such a minor adjustment can substantially improve the analysis, as it replaces these otherwise meaningless offset sum calculations with direct references to the actual target functions.&nbsp;</p>

<p>Since these offset references often appear in consecutive blocks (Figure 9), it is practical to automate their processing, for which the IDA Python snippet shown in Figure 10 is particularly useful.&nbsp;</p>

<p>Unfortunately, this trick alone is insufficient to address the conditional jumps and other schemes of AuraStealer's indirect control flow obfuscation. Nonetheless, given how many calls are obfuscated with this simple scheme, applying it still provides meaningful progress and can serve as a solid starting point for further deobfuscation. Moreover, AuraStealer applies the same obfuscation scheme to hide certain function arguments as well, making it applicable for those cases as well.&nbsp;</p><p>To tackle the more sophisticated patterns, <strong>backward slicing</strong> proved to be the most effective approach. For those interested in a more detailed explanation of how this technique works, the articles <a href="https://cloud.google.com/blog/topics/threat-intelligence/lummac2-obfuscation-through-indirect-control-flow" target="_blank"><em>LummaC2: Obfuscation Through Indirect Control Flow</em></a> by Nino Isakovic and Chuong Dong, and <a href="https://cyber.wtf/2025/11/19/rhadamanthys-loader-deobfuscation/" target="_blank"><em>Rhadamanthys Loader Deobfuscation</em></a> by Melissa Eckardt provide excellent explanations and are definitely worth reading.&nbsp;</p><p>In short, backward slicing is a program analysis technique that identifies instructions that may influence a specific register or memory address at a specific program point by following data and control dependencies. The resulting set of instructions (also referred to as “slice”) can then be used for further analysis, such as emulation or symbolic execution, to recover the value of the targeted register or memory location.</p><p>In our case, we employed a heuristic heavily inspired by backward slicing but simplified and tailored specifically for AuraStealer. The heuristic can be summarized in the following steps:</p><ol><li data-list-item-id="ecd3253d0603374eaf8d20dd66172b91d">Locate the indirect <code>jmp/call</code> instruction.</li><li data-list-item-id="e7b880facf92a03037d90860f993fcb36">Add the register used as the target operand of this indirect <code>jmp/call</code> instruction to the <code>tracked_regs</code><em><strong>&nbsp;</strong></em>set.</li><li data-list-item-id="ec092ae366c82f77e5499781619650e26">Iterate through instructions in reverse (from the indirect <code>jmp/call</code> towards lower addresses), analyzing each instruction whether it affects any of the tracked registers.<ol><li data-list-item-id="e40093d39d8dbbc2cec042d383218e369">If an instruction <strong>modifies</strong> a tracked register, mark it as <strong>relevant</strong>.</li><li data-list-item-id="e85efd9ec51801adf2201c1174b60bc36">For a relevant instruction, determine if it completely overwrites a tracked register (e.g., <code>MOV reg, imm</code>, <code>XOR reg, reg</code><em><strong>,&nbsp;</strong></em>etc.), and if so, remove that register from <code>tracked_reg</code>, ending its dependency chain.</li><li data-list-item-id="e6dacf6f0c3c4ec55bc5360ef989126fa">Otherwise, identify all source registers of that relevant instruction and add them to the <code>tracked_reg</code><em><strong>&nbsp;</strong></em>set to propagate the dependency further back.</li></ol></li><li data-list-item-id="e83fa1ba035c370537e28dcd5d09a12fe">Stop the process if any of these conditions occur:<ol><li data-list-item-id="e5c6a6b0ded1afb1454ccfef52dbad329">The <code>tracked_regs</code><strong>&nbsp;</strong>set is empty (all dependencies have been resolved).</li><li data-list-item-id="efc5e5e4260697b4e98da073e4bbbf2dc">A control-flow instruction is encountered (<code>call</code>, <code>jmp</code>, <code>ret</code>), indicating a basic block boundary.</li><li data-list-item-id="e609dc4e0defe8e4c288899b3140d9e72">A maximum instruction limit is reached (fail-safe).</li></ol></li><li data-list-item-id="e191479030aa8e4a2fea1ead5fb74aaab">Finally, return the address of the earliest (lowest address) relevant instruction found, marking the start of the slice.</li></ol><p>For clarity, this heuristic is not meant to implement complete backward slicing. It deliberately omits memory‑write tracking and focuses solely on register flows. However, it is important to note that this limitation is intentional, as register-level analysis is sufficient for the deobfuscation of the indirect control flow obfuscation employed by AuraStealer. We use the heuristic solely to identify the slice’s starting address, from which we then perform symbolic execution with Angr to compute the target address(es). That said, if AuraStealer’s obfuscation were to change, the heuristic could be readily extended to also account for memory interactions.</p><p>The reason we chose symbolic execution over emulation is that symbolic execution is inherently designed to explore all possible execution paths, making it easier to implement. In terms of computational requirements, it remains feasible since we only symbolically execute small code chunks.</p><p>Attentive readers may have noticed that this approach has a minor imperfection. The heuristic terminates upon encountering a <code>call</code> instruction. However, as shown in Figure 5, the target address of some <code>jmps</code> can depend on the results of previous function calls, which may lead to an incorrectly identified slice start. To handle such cases, whenever a register is unconstrained, we assign it a symbolic boolean value (0 or 1), under the assumption that any function influencing such jumps returns a boolean value. Such cases, however, are relatively rare.&nbsp;</p><p>The whole process can be automated with a bit of scripting and the recovered target addresses can be pushed back into IDA as comments, which already gives a good baseline for navigating the code.&nbsp;</p>

<p>However, we can go further – our real goal is to make IDA reconstruct the original control flow graph, not just annotate it. Once the target addresses of the indirect <code>jmps/calls</code> are retrieved, there are several ways to proceed. One option would be to patch the binary. However, due to the variability of the patterns involved and the presence of an anti‑tamper protection in AuraStealer, we have opted for a different approach.&nbsp;</p><p>Instead of patching the binary, which is destructive and easily detectable by malware, we leveraged the IDA SDK to hook directly into the instruction analysis process. The idea is simple – rather than letting IDA analyze the instructions on its own, we intervene in the analysis process and modify how the instructions are decoded. For this purpose, IDA provides <a href="https://cpp.docs.hex-rays.com/structpost__event__visitor__t.html" target="_blank"><code>post_event_visitor_t</code></a>, a class that allows listening and reacting to specific events in IDA by overriding the virtual function <code>handle_post_event</code>.&nbsp;</p>

<p>Among all the possible event codes, the interesting one is the <code>processor_t::ev_ana_insn</code>&nbsp;(analyze instruction), which is triggered right after IDA calls the processor module’s instruction decoder, but before the resulting <code>insn_t</code> structure is finalized and committed to the database. At that point, we can inspect, or even modify, the decoded instruction. In other words, we can alter IDA’s perception of the code without ever touching the underlying binary.</p><p>At this point, several observations are worth highlighting:</p><ul><li data-list-item-id="e9716e59925daa3e95f26cbf1ac5d78db">The indirect calls almost always have a single target.</li><li data-list-item-id="e3dffdbde351ed5c51120005ea6540ddf">Many conditional jumps have only two targets, one of which is the immediately following instruction.</li></ul><p>Resolving the indirect call obfuscation is therefore straightforward. Whenever we intercept the <code>processor_t::ev_ana_insn</code> event, we check whether the analyzed instruction is an indirect call (<code>call reg</code>). If the target address is known and it is the only possible target, we replace the <code>call reg</code> instruction with <code>call &lt;calculated_target_address&gt;</code>.</p><p>For indirect conditional jumps, it would, in principle, be possible to determine the exact branch type by analyzing the conditional move used to compute the target address and replacing the <code>jmp</code> instruction with the corresponding conditional jump instruction. However, we opted for a much simpler and more pragmatic strategy. Many of these indirect jumps are, in fact, only obfuscated loops or <code>if-then/if-then-else</code> constructs with one of the target address pointing to the immediately following instruction. So, whenever we encounter an indirect <code>jmp</code> instruction with precisely two possible targets, one of which is the fall-through address, we replace the <code>jmp</code> instruction with <code>jnz</code> (jump if not zero) pointing to the non-fall-through target address.</p><p>This transformation does not yield a perfectly accurate decompilation. However, if we accept the fact that some comparisons may appear as&nbsp;<code>condition != 0</code> rather than their exact form, we end up with a control flow that is already much easier to follow. Moreover, whenever the precise condition semantics matter, the original condition can always be examined directly in the disassembly. Although it would be possible to reconstruct and substitute the exact conditional jump for every case, we do not believe it is worth the effort.</p>

<p>Regarding indirect jumps with multiple possible targets, or those for which none of the targets is the immediately following instruction, we simply add user-defined cross-references in IDA.</p><p>Using these steps, we managed to fully recover the AuraStealer’s control flow.</p>

<p>Note that due to the heavy control&nbsp;flow obfuscation with many references to code locations, IDA often struggles to recognize proper function boundaries. It is thus often necessary to manually adjust where the function begins and ends to ensure IDA analyses the whole function.</p><h3>Exception-Driven API Hashing</h3><p>To obfuscate its usage of WinAPI functions, AuraStealer employs the API hashing technique. For these purposes, it first resolves all the functions required by the binary via PEB-walking and builds two hash-based lookup tables that maps hashes to XOR-masked addresses.&nbsp;</p><p>The reason for maintaining two tables is that AuraStealer does not invoke these function directly. Instead, it deliberately triggers an exception, which, however, is intercepted by a custom exception handler. The handler inspects the address from which the exception originates and uses that information to dispatch the appropriate function address.</p><p>To resolve a specific function, AuraStealer takes the precomputed <code>MurmurHash3</code> value (seeded with <code>0xDEADBEEF</code>) of the function’s name, re-hashes it with <code>FNV-1a</code>, and uses both values to query the first precomputed lookup table. The query returns the XOR-masked address from which the exception is to be thrown, together with the mask used to protect it. AuraStealer then unmasks the address and makes a call to it, intentionally throwing an <code>EXCEPTION_ACCESS_VIOLATION</code>, which is intercepted by the custom exception handler.&nbsp;</p><p>The exception handler rehashes the originating address using <code>FNV-1a</code> and uses both values to query the second precomputed lookup table. This query returns the XOR-masked address of the actual target function, again along with the mask. The two values are XORed together and the resulting address is loaded into the <code>EIP</code> register, effectively invoking the requested WinAPI function.</p>

<p>The MurmurHash3 values of the target functions are further obfuscated using an XOR mask (see Figure 16). In this example, <code>0x130B0F3C ^ 0x25A36E25 = 0x36A86119</code>, which is equal to the value returned by <code>MurmurHash3(“GetModuleHandleA”, seed: 0xDEADBEEF</code>)<em>.&nbsp;</em>Since the result value is produced only by a XOR of two constants, IDA’s decompiler can optimize the expression and directly display the deobfuscated value (see Figure 17).&nbsp;</p><p>This allows us to precompute the hashes for all API-hashed functions and replace the decompiler-computed constants with the corresponding function names. However, it is important to note that this approach relies on IDA’s decompiler, which may produce incomplete results if the control flow is not fully deobfuscated. That said, the constants could also be recovered by combining backward slicing to isolate the instructions that influence the final constant value, and emulating them with an emulation framework (for example, Unicorn). In this case, removing the obfuscation would be considerably easier than for the indirect control flow obfuscation, as the constant obfuscation is merely an XOR, requiring emulation of only a few instructions. Moreover, these instructions are consistently located in the same basic block where the deobfuscated constant is used.</p>

<p>The exception handler is installed within the initterm routines, i.e., before the program reaches <code>WinMain</code>, making its presence easy to overlook. As part of this setup, AuraStealer not only registers the exception handler itself but also allocates a memory blob via <code>VirtualAlloc</code>, which is later used to build the lookup tables and as a memory region from which the exceptions are triggered. &nbsp;</p>

<p>This mechanism effectively adds another layer of obfuscation. &nbsp;Although the custom handler ultimately processes the deliberately triggered exceptions, a debugger intercepts them first. Consequently, anyone analyzing AuraStealer in a debugger is flooded with <code>EXCEPTION_ACCESS_VIOLATION</code>, making the program appear unstable and obscuring its real behavior. This can easily lead the analyst to disable exception notifications only to make the program run. However, by doing so, they deliberately hide the malware’s custom exception handler in the process, causing an important part of its logic to go unnoticed. Additionally, the exception spam also serves as an anti‑debugging technique, as the overwhelming stream of exceptions disrupts the debugging workflow.</p><h3>String Obfuscation</h3><p>Although most strings in AuraStealer are obfuscated, the names of the functions that are dynamically resolved and intended to be hidden via API-hashing remain in plaintext.</p>

<p>Their addresses, however, are obfuscated using the same arithmetic-based obfuscation used to obfuscate the target addresses of indirect calls (Figure 22).</p>

<p>Still, since the computation relies solely on constant values, it is possible to use the same trick presented above – marking the variable used in the computation as constant – to let IDA’s decompiler to compute the target address. This is another excellent example of how this trick can significantly accelerate the analysis. Instead of meaningless offsets, the decompiled code directly reveals the function name being referenced (see Figure 23).</p>

<p>The remaining strings are encrypted using a stack-based XOR obfuscation. The encrypted string and its corresponding XOR key are first concatenated in memory from constant values, XORed together, and stored in memory. An example of how such a decryption routine looks at the assembly level is shown in Figure 24.</p>

<p>These decryption routines generally follow the same logic but include slight variations, and their length varies depending on the length of the decrypted string. The main challenge is that emulating instructions withing isolated basic blocks and reading the strings from memory once the decryption is finished is not sufficient to recover all strings, as many of the constants involved in the string-decryption logic are reused throughout the function. Therefore, the necessary context is distributed across the entire function. As a result, recovering all strings requires emulating much larger code regions to preserve the full context, a task that can quickly become error-prone and time-consuming.&nbsp;</p><p>Therefore, to decrypt AuraStealer strings, we implemented a simplified form of function emulation using the Unicorn emulation framework. Rather than emulating the entire function, we selectively step through its instruction, while skipping call instructions and loops. When reaching conditional branches (e.g., <code>if</code><em><strong>&nbsp;</strong></em>or <code>switch</code> constructs), we fork the execution to explore and cover all relevant paths. This streamlined approach was sufficient to recover most of the obfuscated strings without resorting to full, heavyweight emulation.&nbsp;</p>

<p>A <a href="https://github.com/avast/ioc/blob/master/AuraStealer/extras/aurastealer_decrypt_strings.py" target="_blank">reference script</a> implementing the decryption workflow is available on our GitHub. The script is intended to be run from IDA Pro. &nbsp;</p><h2>Anti-Analysis Execution Chain</h2><p>During its execution, AuraStealer performs multiple anti-analysis checks, ranging from basic to more sophisticated techniques. Some of these checks are executed unconditionally, while others depend on configuration parameters specific to the particular infostealer build. The execution flow is displayed in Figure 26.</p>

<h3>Running Protected Check</h3><p>AuraStealer’s anti-analysis chain begins by checking whether the binary is executed from a protective layer such as a loader, packer, or crypter. Depending on that outcome, it either performs or skips additional checks, which include an anti-tampering check and a dialog box check.&nbsp;</p><h3>Anti-Tampering Check</h3><p>The anti-tampering check is done using the <code>MapFileAndCheckSumW</code> WinAPI function, which computes the file’s checksum and compares it against the value stored in the PE header. If those values differ, AuraStealer stops its execution.</p><p>The purpose of this check is to prevent analysts from patching or otherwise altering the executable. With that in mind, analysts should be cautious about any changes made to the binary (including software breakpoints) and remain vigilant during dynamic analysis, as the malware may deliberately exhibit misleading behavior if tampering is detected.&nbsp;</p><h3>Dialog Box Check</h3><p>Similar to what <a href="https://outpost24.com/blog/lummac2-anti-sandbox-technique-trigonometry-human-detection/" target="_blank">Lumma</a>, and more recently also <a href="https://research.checkpoint.com/2025/rhadamanthys-0-9-x-walk-through-the-updates/" target="_blank">Rhadamanthys</a>, does, if AuraStealer detects that it is being run unprotected, it displays a dialog box prompting the user to enter a code to continue. Unlike Lumma and Rhadamanthys, it requires the user not only to click the OK button but also to correctly enter the displayed code. On the other hand, it does not display any warning message that malware is to be run, which is what both Lumma and Rhadamanthys display in the message box.</p>

<p>This mechanism halts AuraStealer’s execution until the correct value is provided and is aimed at forcing the malware distributors to deliver the stealer with an additional protective layer. Additionally, it also serves as an anti-sandbox protection since automated sandboxes would hardly ever perform OCR over that text and try to paste it. Both the window title and the code to be entered are randomly generated at runtime, based on the Mersenne-Twister pseudorandom number generator.&nbsp;</p><h3>Geolocation Check</h3><p>To avoid execution in specific countries, AuraStealer performs a geolocation check by retrieving the system and user language settings using the WinAPI functions <code>GetUserDefaultLCID</code> and <code>GetSystemDefaultLCID</code><strong>,</strong> and obtains the country code through <code>GetLocaleInfoA</code>. The retrieved country codes are then compared against a predefined blacklist, and if any match is found, the malware terminates its execution.</p>

<p>Notably, in addition to avoiding execution in CIS countries, the stealer also omits the Baltic states (Lithuania, Latvia, and Estonia). &nbsp;&nbsp;</p><p>According to the AuraStealer developers, an extra IP check is allegedly performed on the server side. However, we were unable to confirm that claim.</p><h3>Anti-Sandbox Checks</h3><p>If all previous checks pass, the process continues to the anti-sandbox stage, which comprises three primary checks.</p><p>First, AuraStealer evaluates whether the <code>Sleep</code><em>&nbsp;</em>function has been hooked or modified. To do so, it records the system time using <code>GetSystemTimePreciseAsFileTime</code>, invokes <code>Sleep(1000 ms)</code>, and queries the system time again. If the measured delay is less than 900 ms, the stealer assumes that the <code>Sleep</code> function has been tampered with.</p><p>Next, it performs a Microsoft Defender emulation check by comparing the values returned by <code>GetUserNameW</code> and <code>GetComputerNameW</code> against the well-known emulator artifacts <code>JohnDoe</code> and <code>HAL9TH</code>.&nbsp;</p><p>Finally, AuraStealer inspects the list of currently loaded modules and compares them against the following list of blacklisted DLLs:</p>

<h3>Configuration Extraction</h3><p>The configuration for each AuraStealer build is embedded directly in the binary and is protected with AES-CBC encryption. The encrypted configuration is stored as a single contiguous block, with a linear, serialized layout. The encrypted configuration structure is as follows:</p>

<p>Since all information required to decrypt the configuration is contained within the binary, it is possible to decrypt the content and extract the malware configuration.</p>

<p>Based on the configuration, AuraStealer performs additional anti-analysis checks. If all checks pass, it attempts to establish connection with the C2 servers listed in the configuration and initiates the data-stealing process. The configuration also allows setting custom user agents, defining a start delay, and choosing whether the malware should delete itself after completing the stealing process. Interestingly, although anti‑debugging appears as a configurable option in the configuration, it cannot be disabled from the panel. Furthermore, even though proxy support is not explicitly listed in the configuration, AuraStealer is expected to handle proxy usage. This is indicated by both the available build options in the AuraStealer panel and the strings observed in the configuration-parsing logic within the binary.</p>

<p>To streamline the process of retrieving build configuration data from AuraStealer samples, we provide a <a href="https://github.com/avast/ioc/blob/master/AuraStealer/extras/aurastealer_config_extractor.py">configuration extraction script</a>. The script is publicly accessible on our GitHub.</p><h3>Human Checks</h3><p>The human check comprises two subchecks, both implemented as infinite loops.&nbsp;</p><p>The first check monitors whether the user input changes over time. It begins by measuring the number of ticks between two <code>GetTickCount</code> calls with a <code>Sleep(1000 ms)</code> in between. A while loop then repeatedly performs a <code>Sleep(500 ms)</code> followed by a call to <code>GetLastInputInfo</code>, which returns a <code>LASTINPUTINFO</code> structure. This structure contains a variable, <code>dwTime</code>, representing the tick count at which the last input event occurred. Then, another call to <code>GetTickCount</code> is made, and <code>dwTime</code> is subtracted from it. If the result is less than the previously measured number of ticks measured by the one-second <code>Sleep</code>, the check passes. Otherwise, the loop repeats until the check passes.&nbsp;</p><p>The second check begins by a call to <code>GetForegroundWindow</code>, which returns a handle to the current foreground window. A while loop then repeatedly calls <code>Sleep(500 ms)</code> and checks <code>GetForegroundWindow</code> again. If the returned handle differs from the initial one, the check passes. Otherwise, the loop continues until the foreground window changes.&nbsp;</p><h3>Anti-VM Checks</h3><p>The Anti‑VM check consists of multiple subchecks. First, the presence of a hypervisor is checked using the <code>cpuid</code> instruction. When <code>cpuid</code> is executed with <code>EAX = 1</code>, the 31st bit of <code>ECX</code> indicates the environment – it is <code>0</code> on a physical machine and <code>1</code> on a virtual machine.</p><p>Next, a combination of the WinAPI functions <code>GetDesktopWindow</code> and <code>GetWindowRect</code> is used to obtain the <code>right</code> variable from the resulting <code>RECT</code> structure, which is then compared against <code>1024</code> (it is expected to be greater). Finally, <code>GlobalMemoryStatusEx</code> is called, and the <code>ullTotalPhys</code> variable of the returned <code>MEMORYSTATUSEX</code> structure is checked to ensure it is not <code>0</code>.</p><p>If all of these checks pass, AuraStealer calls <code>GetSystemInfo</code> and inspects the returned <code>SYSTEM_INFO</code> structure to verify that <code>dwNumberOfProcessors</code> is not less than four. If the system has four or more processors, the Anti‑VM check is considered passed. If the processor count is below this threshold, the malware performs one additional verification using <code>EnumProcesses</code> to retrieve the list of running processes. It then checks whether the total number of running processes is at least <code>200</code>, which is assumed to be typical for a real, non‑virtualized system.</p>

<h3>Anti-Debug Checks</h3><p class="text-align-justify">The anti-debug check comprises several subchecks, beginning with inspecting well-known debug flags in the <code>PEB</code>, including <code>BeingDebugged</code> and <code>NtGlobalFlag</code>, as well as the <code>KUSER_SHARED_DATA</code> structure. A detailed explanation of how these flags can be used to detect a debugger can be found <a href="https://anti-debug.checkpoint.com/techniques/debug-flags.html">here</a>.</p>

<p>If all previous check pass, AuraStealer creates a new debug object using <code>NtCreateDebugObject</code> and makes a subsequent call to <code>NtQueryObject</code>. Since the object was just created, there should exist only a single handle to it – the one held by the program itself. However, if a debugger or other monitoring tool is attached (which often hooks these functions or duplicates handles for analysis), the <code>HandleCount</code> may be greater than one. In that case, AuraStealer proceeds to compare the names of all running processes against a hardcoded blacklist, and if any match is found, it terminates its execution.</p>

<p>Notably, as careful readers may notice in the decompiled anti-debug and anti-VM check functions, AuraStealer employs an additional anti-debugging technique that is utilized across various functions within its codebase. The technique works by inspecting the opcodes located at the function’s return address. If a breakpoint instruction (<code>INT3</code> or <code>INT&nbsp;3</code>) or a <code>UD2</code><em><strong>&nbsp;</strong></em>instruction (commonly used for hooking) is detected, a random value between 64 and 127 is generated and added to a stack variable at offset <code>−4</code> from the return address. The intent behind this technique is not to crash the program immediately, but to plant a subtle corruption that only results in a crash later during execution, making it very hard to determine the crash origin.</p>

<h2>AuraStealer Execution Flow</h2><p>The high-level execution flow of AuraStealer can be summarized as follows. First, the malware installs the custom exception handler and creates the two lookup hash tables used for its exception-driven API hashing. Next, it performs multiple anti-analysis checks described above and decrypts its embedded configuration. If all checks pass, it proceeds with mutex creation.&nbsp;</p><p>Based on the hosts specified in the configuration, it attempts to establish a connection with its C2 servers, which respond with additional configuration specifying what information and files should be collected. Finally, the malware begins collecting the targeted data and exfiltrating it to its remote infrastructure.&nbsp;</p>

<p>As for the AuraStealer’s capabilities, it targets nearly every aspect of the user’s digital life. Specifically, it is capable of collecting:</p><ul><li data-list-item-id="ee8f738bb398ebf4b98d308b3e83f7ba9">Sensitive data from both Chromium-based and Gecko-based browsers</li><li data-list-item-id="ef6e95e7a4b7566401304a3ac2c1bb99e">Cryptocurrency wallets from desktop applications and browser extensions</li><li data-list-item-id="e46204802ac7c574e54061fbe7715f64d">Active session tokens (Discord, Telegram, Steam)</li><li data-list-item-id="e1402956eda9d7b9e9ca2f50084aa8b53">2FA tokens (Authenticator)</li><li data-list-item-id="ebfbbc8ff75ab08f22978d0e4d853c0b9">Recovery data (recovery seeds, private keys, and mnemonic phrases)</li><li data-list-item-id="ea5cfba5a39e294f4b4d425d13f586f36">Credentials and API keys</li><li data-list-item-id="edbbd9e9dda770df72e0adc3e82e03cf8">Remote access and FTP configurations (AnyDesk configurations, FileZilla credentials)</li><li data-list-item-id="e63d9a0d397bf3f49f53fdf30a2c8bdce">Password manager databases (KeePass, Bitwarden,&nbsp;1Password,&nbsp;LastPass)</li><li data-list-item-id="ebf62d564d3b18ae02881d21d0e8178ff">VPN configurations (OpenVPN, NordVPN, ProtonVPN)</li><li data-list-item-id="e407c5c635ddee8cc7ea0a4caa0728141">Clipboard contents</li><li data-list-item-id="e499de30c13fcd2f06971c7091c9e5a01">Screenshots of the victim’s device</li><li data-list-item-id="e8df9f43c63afc51e163e786a3a89171f">A list of running processes, along with general system fingerprinting data</li></ul><p>However, this is not an exhaustive list as AuraStealer allows to include additional custom configuration modules for specific builds (including wildcard-based file search with configurable masks, paths, and recursion), effectively enabling the theft of virtually any file of interest.</p><p>Beyond data theft, AuraStealer is also capable of executing additional payloads.&nbsp;</p>

<h3>Dynamically Generated Mutex</h3><p>To prevent multiple instances from running simultaneously, AuraStealer utilizes dynamically generated mutexes based on build-specific and time-dependent values. The malware first loads the <code>build_id</code> value from its configuration (for example, <code>a0858933-16a7-433f-a9cc-68490ace0576</code>) and computes a <code>djb2</code> hash over it. The hash is then added to the result of an integer division <code>_Xtime_get_ticks()/36000000000</code>, which effectively produces a value that changes once per hour. The final sum serves as a seed for a Mersenne-Twister pseudorandom number generator, which is used to generate a random alphanumeric string between 16 and 32 characters in length. The generated string is prepended with <code>Global\</code>, forming the final mutex name.&nbsp;</p>

<p>The fact that the mutex changes every hour highlights that the stealer is designed to run only for a short period of time – a trend that has become increasingly common among modern infostealers. The goal is to execute briefly, steal as much data as possible, and, preferably, remove all traces of its presence.</p><h2>Application-Bound Encryption Bypass</h2><p>To extract sensitive data from Chromium-based browsers, AuraStealer must first overcome Application-Bound Encryption (ABE), which it achieves by spawning the target browser in headless mode using <code>CreateProcessW</code>, with the process created in a suspended state, followed by a code injection. From within the injected context, the malware invokes <code>IElevator::Decrypt</code> to decrypt the <code>app_bound_encrypted_key</code>, which enables the decryption of any ABE-protected data, including passwords and cookies.</p>

<p>The injection itself is implemented by creating a shared section via <code>NtCreateSection</code> and mapping it into the target browser process using <code>NtMapViewOfSection</code>, after which the injected payload is executed using <code>NtCreateThreadEx</code>. All of the NTDLL calls involved in the injection are executed through Heaven’s Gate, a technique that allows 64-bit code to be executed from a 32-bit process on a 64-bit OS. This ensures both compatibility with 64-bit browsers and also helps evade detection.</p>

<p>The injected payload is a position-independent shellcode, slightly modified at runtime for each target browser process. At predefined offsets within the shellcode, AuraStealer fills two randomly generated file names with the paths of the form<br><code>C:\Users\&lt;user&gt;\AppData\Local\Temp\&lt;random_alphanumeric_string_len_16_to_32&gt;</code>,<br>along with a value identifying the browser type, which is later used to select the appropriate CLSID and IID for the <code>CoCreateInstance</code> invocation. These two files serve as an inter-process communication mechanism between AuraStealer and the injected shellcode. The first file is used to pass the encrypted <code>app_bound_encrypted_key</code> to the injected shellcode, while the second file is used by the shellcode to write back the decrypted key for retrieval by the stealer.</p><p>Although AuraStealer is capable of decrypting the <code>app_bound_encrypted</code> key, required to decrypt appbound-encrypted data, from certain Chromium-based browsers, it still does not work reliably across all of them, suggesting that the product has not yet reached a fully polished state.</p><h2>Network Traffic</h2><p>AuraStealer’s network traffic can be divided into four stages. The stealer first verifies internet connectivity by checking the reachability of <code>1.1.1.1:53</code> (Cloudflare). Upon success, it attempts to establish communication with its C2 infrastructure by querying the <code>/api/live</code> endpoint and expecting a response<code> true</code>. If any of the servers are reachable, it then requests <code>/api/conf</code>, together with its <code>build_id</code>, to retrieve a build-specific configuration defining the data to be collected (a <a href="https://github.com/avast/ioc/blob/master/AuraStealer/extras/aurastealer_config.json">sample configuration</a> is publicly available on our GitHub repository). Finally, the collected files are split into smaller archives and sent in parts as they are collected via the <code>/api/send</code> endpoint.</p>

<p>All network traffic is encrypted using AES-CBC in a manner very similar to the configuration encryption, with the difference that the encrypted data is additionally Base64‑encoded. The encryption keys and initialization vectors are generated randomly at runtime.&nbsp;</p>

<h2>Key Takeaways and Defensive Measures</h2><p>AuraStealer&nbsp;is a rapidly growing infostealer that employs a wide range of obfuscation and&nbsp;anti-analysis techniques to evade both static and dynamic detection. Apart from targeting nearly every aspect of users’ digital life, it also allows for the inclusion of additional custom configurations with configurable masks, paths, and recursion, effectively enabling the theft of virtually any file of interest.</p><p><strong>What You Can Do:</strong></p><ul><li data-list-item-id="eb280f4b40c8c43a487e430bf4e03ce08"><strong>Use reputable security software&nbsp;</strong>with real-time protection. Products from Norton, Avast, AVG, and Avira automatically protect users against the attacks and threats described in this analysis.</li><li data-list-item-id="ed7873c63b2df660cc976bfc5cfa76db3"><strong>Avoid copying and pasting commands&nbsp;</strong>from unknown or suspicious sources into system dialogs like Windows Run or PowerShell.</li><li data-list-item-id="ea6982ffdde4d0fb169e72869e66b63a4"><strong>Verify software sources&nbsp;</strong>– avoid downloading cracked games, software activators, or suspicious browser/IDE extensions.</li></ul><h3>IoCs</h3><p>0223E39D9C26F065FABB1BCB8A1A03FE439BB18B8D14816646D8D236A6FD46A3 (AuraStealer 1.0.0)</p><p>01E67139B59EED0FE1FCB4C66A9E88AD20DD8B55648C077AEC7FA2AE3431EA5F (AuraStealer 1.1.0)</p><p>9A46C8D884F4C59701D3AF7BEAD1E099E3DDEB1E2B75F98756CC5403D88BD370 (AuraStealer 1.1.1)</p><p>FD3875225C1AB60E6DC52FC8F94B4D389624592B7E7B57EE86E54CEBE5D3EB6A (AuraStealer 1.1.2)</p><p>EC7BA08B1655963D6C9F7D996F3559C58893769A2C803DA1F99610A0AAA1224A (AuraStealer 1.2.0)</p><p>0F691762DA02ABBD94046381ECEDFD8B31CCBB835DED6049E9D6CD2AFDD3F551 (AuraStealer 1.2.1)</p><p>F6E7341AB412EF16076901EA5835F61FBC3E94D0B9F2813355576BAD57376F29 (AuraStealer 1.2.3)</p><p>D19274A14B905679DBD43FFB374CA0E11F9DC66FDB9E17236829A9A56F3E7D31 (AuraStealer 1.3.0)</p><p>F0F7AE1FC2D569B8B9267D2EC81F7E539DB4BEAF275BCA41962C27ECFA5361BF (AuraStealer 1.4.0)</p><p>158369AD66EA4BACEEE19051425C21F657FFC1B3483EA812323816B612F324BD (AuraStealer 1.5.0)</p><p>F816558972F62D206757BAD4A95EE75290615F520F3B24D814FFBCDFC6998C6C (AuraStealer 1.5.1)</p><p>F7D0F099D042DE83AA2D0A13100640BEA49D28C77C2EB3087C0FB43EC0CD83D7 (AuraStealer 1.5.2)</p><p>apachesrv[.]cfd (C2)<br>argametop[.]cfd (C2)<br>armydevice[.]shop (C2)<br>browsertools[.]shop (C2)<br>calibrated[.]cfd (C2)<br>chicagocigars[.]shop (C2)&nbsp;<br>clocktok[.]cfd (C2)<br>connupdate[.]cfd (C2)<br>coralpoint[.]cfd (C2)<br>cybertool[.]shop (C2)<br>gamedb[.]shop (C2)<br>glossmagazine[.]shop (C2)<br>goldenring[.]cfd (C2)<br>greenapi[.]cfd (C2)<br>magicupdate[.]cfd (C2)<br>mscloud[.]cfd (C2)<br>mushub[.]cfd (C2)<br>opencamping[.]shop (C2)<br>privateconnect[.]cfd (C2)<br>searchagent[.]cfd (C2)<br>searchservice[.]cfd (C2)<br>softytoys[.]shop (C2)<br>stmservice[.]cfd (C2)<br>sysrequest[.]cfd (C2)<br>systemupdate[.]cfd (C2)<br>unknowntool[.]shop (C2)<br>updservice[.]cfd (C2)</p>

A technical walkthrough of obfuscation, anti-analysis and data theft capabilities

Defeating AuraStealer: Practical Deobfuscation Workflows for Modern Infostealers

<h2 class="text-align-justify">Key Points</h2><ul><li><p class="text-align-justify">Gen Threat Labs has discovered and analyzed an elaborate Traffic Direction System infrastructure delivering FakeCaptcha, tech scams and other malware campaigns to select users.&nbsp;</p></li><li><p class="text-align-justify">The campaign entry points are infected or otherwise attacker-controlled streaming websites, file sharing services, as well as malvertising campaigns.&nbsp;</p></li><li><p class="text-align-justify">Victims are evaluated based on geolocation, IP address, and browser fingerprinting; for example, connections through VPNs or headless browsers are detected and rejected.&nbsp;</p></li><li><p class="text-align-justify">The FakeCaptcha campaign is increasing its stealth by mimicking legitimate software websites.&nbsp;</p></li><li><p class="text-align-justify">A new variant of FakeCaptcha spreading information stealers and RATs avoids detection by employing Unicode math fonts.&nbsp;</p></li></ul>

<h2>Introduction</h2><p>The <a href="https://www.gendigital.com/blog/insights/research/global-surge-in-fake-captcha-attacks" target="_blank" rel="noreferrer noopener">FakeCaptcha campaigns</a> have become a widespread malware infection vector, using clever social engineering and exploiting internet users’ confusion about common CAPTCHA practices to trick victims into infecting their own computers, typically with information-stealing malware like LummaC2, by pasting malicious commands into the Windows Run dialog.&nbsp;</p><p>We have discovered an elaborate infrastructure actively used to deliver multiple variants of FakeCaptcha and other malicious content to select users. At the core of the operation is an attacker-controlled Traffic Direction System network. It has a single purpose—to fingerprint the visitor’s device and network details to determine what type of content to deliver. This could be malicious, monetized or decoy content, or no content at all. For reasons we will describe later, we are calling this infrastructure HelloTDS.</p>

<p>As shown in the graphic above, the scope of the campaign is massive; in April and May 2025 alone, we have protected over 4.3 million users worldwide. In terms of absolute numbers, the most affected regions include the United States, Brazil, India, and Western Europe. However, when adjusting for population size and user base, a different trend emerges: the highest relative risk is concentrated in the Balkan countries of Europe and in parts of Africa, particularly Rwanda, Egypt, Tanzania, and Kenya.</p><h2>Attack Chain</h2><p>At a high level, the attack works as follows: The victim visits an infected website or clicks on a malicious ad. The entry website requests a JavaScript file from the initial HelloTDS endpoint, which fingerprints the connection and decides whether to serve content or stay idle. If the user is not deemed a suitable victim, the attack stops here. Otherwise, the server responds with a script that further fingerprints the browser, logs mouse movements and similar, eventually sending another request to receive the final payload containing a redirect to the malicious landing page. Among users who passed the initial check, FakeCaptcha was observed to be the most prevalent malicious landing page, with Fake Updates, file downloads containing encrypted malware, tech scams and other fraudulent campaigns also having a share.&nbsp;</p>

<p class="text-align-justify">One specific example of the full attack chain is illustrated in the next figure: We visited the website dailyuploads[.]net, uploaded an arbitrary image file, and navigated to the link generated by the service. The resulting page included a script from HelloTDS, and when we clicked the download link, we were involuntarily redirected to a FakeCaptcha landing page attempting to trick visitors into executing the Emmenhtal loader.</p>

<h2>From Movie Streaming or File Sharing to Malware</h2><p class="text-align-justify">Besides ad networks, the primary source of traffic for HelloTDS are legitimate-looking, properly functioning websites, such as movie streaming sites, torrent mirrors, file-sharing services, link shorteners, or porn websites. However, these websites are specifically crafted or manipulated—presumably also by the attacker—to cooperate with the attacker’s infrastructure and load malicious scripts. This tactic completely bypasses the need for malvertising campaigns through “legitimate” advertising companies, as these websites request the attacker’s scripts directly.</p><p class="text-align-justify">Moreover, we have observed a repeating pattern in some of these websites, which offer file sharing services and promise their users financial gains. These include dailyuploads[.]net, streamtape[.]{com,net,to}, watchadsontape[.]com, bigwarp[.]art or savefiles[.]com to name a few. Security or data privacy is clearly not a priority for these services, as anyone can sign up with any e-mail address without verification. We suspect that these websites are cloned from some existing file sharing service and controlled by the same threat actor who controls HelloTDS and eventually delivers FakeCaptcha, for the primary purpose of embedding malicious popups and redirects within the page (although email &amp; password harvesting could be a “welcome” byproduct).</p>

<h2>The Anatomy of a HelloTDS Domain</h2><p class="text-align-justify">An “entry point” website, like those described previously, will usually statically embed one or more HTML snippets loading remote JavaScript that look like this:</p>

<p class="text-align-justify">(In case of file-sharing websites described above, this snippet will be included in the page with the uploaded file, i.e. the one you share the link to, but not on the main page itself.)</p><p class="text-align-justify">The source domain is randomly rotated and both path segments are randomly generated (although their length and character sets are always the same), presumably to prevent static detection. Despite this, it is easy to spot these URLs with a human eye (or a clustering algorithm). All the HelloTDS domains we have seen so far have the same format: The apex domain consists of 2-3 (pseudo)words with a “.top”, “.shop” or sometimes “.com” TLD; optionally, a short subdomain is used, consisting of usually 2, but up to 4 random letters.&nbsp;</p><p class="text-align-justify">Examples of these domains include:</p><ul><li>yr[.]unasonoric[.]com</li><li>gq[.]binesyorker[.]com</li><li>sb[.]rowlandpodogyn[.]shop</li><li>nutatedtriol[.]com</li></ul>

<p class="text-align-justify">Apart from the distinctive domain names, another sign that speaks for HelloTDS is that the domain names are almost exclusively registered in Panama through the Pananames registrar, and the servers reliably present Let’s Encrypt certificates during TLS handshakes.</p><p class="text-align-justify">In an attempt to make tracking HelloTDS infrastructure difficult, the authors designed it to be highly dynamic, frequently rotating active domains and their DNS records. Even so, we have identified that all domains associated with this infrastructure are registered under AS7979 (SERVERS-COM) within the following IP ranges:</p><ul><li>23.83.64.0/22</li><li>23.109.120.0/22</li><li>23.109.128.0/19</li><li>23.109.170.0/24</li><li>94.242.232.0/21</li><li>172.240.104.0/21</li><li>172.241.48.0/21</li><li>172.255.96.0/20</li><li>173.0.146.0/23</li><li>173.237.64.0/20</li><li>188.42.104.0/21</li><li>188.42.240.0/21</li><li>209.192.192.0/18</li><li>212.117.184.0/21&nbsp;</li></ul>

<p class="text-align-justify">Another interesting aspect shared by all HelloTDS servers is the usage of the non-standard HTTP header “megageocheckolololo”, which we believe is not commonly used by any well-known service. Its presence in the “Access-Control-Allow-Headers” HTTP response header is another indicator of a HelloTDS server.</p>

<p class="text-align-justify">Lastly, domains belonging to HelloTDS can be reliably identified using the information they expose via “robots.txt”:</p>

<p>The “/hi” endpoint always returns a simple HTML response with a single text node that says “Hello!” — hence the name HelloTDS.</p><h2><br>First Stage: Fingerprinting Based on Network Information</h2><p class="text-align-justify">The first decision is made by the HelloTDS server immediately upon receiving the request sent from one of the entry point websites. Since we can only send requests and observe the servers’ responses, it is difficult to tell the exact shape of the server’s decision tree. We suspect that several factors, such as IP/geolocation checks, timeouts, or maybe even pure randomness, may contribute to the result in some way.</p><p class="text-align-justify">From the user’s point of view, there are two possible outcomes. In one case, the server responds with a no-op script (usually an empty function or a single-line comment containing 2 or 3 letters, like “// ipx” or “// mt”, likely codes used for “debugging” the TDS), meaning the user will not get any malicious content (from that endpoint). Alternatively, the server will respond with a large JavaScript that performs heavy client-side fingerprinting and eventually performs a subsequent request to another HelloTDS endpoint. Either way, the server sets a pair of cookies in the response; these encode information about the client’s browser, operating system and network, as detected by the server, and may be used as a client-side cache for further requests (although we have found that tampering with them is generally not useful).</p>

<p class="text-align-justify">The cookie values contain Zlib-compressed binary data encoded in Base64. Although the low-level data format is unknown, the data itself contains readable ASCII strings like the client’s IP address, country, or ISP, which reveal the purpose these cookies likely serve.</p>

<h2>Second Stage: Fingerprinting in the Browser</h2><p class="text-align-justify">Contrary to the logic executed on the server, the next fingerprinting routine is performed in the browser (by the returned JavaScript) and can thus be reverse-engineered. The exact code returned from different HelloTDS endpoints varies somewhat in structure and complexity (at the very least, the server appends a timestamp comment to hinder hash-based detection), but all of them share the same basic high-level functionality.</p><p class="text-align-justify">Crucially, the JavaScript sent by the server contains an encrypted configuration variable — a JSON string where each alphanumeric character is substituted with some other. This part of the code can be easily identified: Look for a function call with two arguments, the first being the encrypted JSON string and the second being the key: A concatenation of the characters a-z, 0-9 and a random permutation thereof. This obfuscation is not unique to HelloTDS; however suspicious it may be for an ad network to employ this technique, we have also observed this behaviour in scripts employed by the Czechia-based Clickadu ad network, which happens to share certain characteristics with the threat actor’s infrastructure.</p><p class="text-align-justify">The number of key-value pairs in the configuration object varies, but some common ones we regularly encounter are “url”, “zone_id”, “uuid_url”, “rot_url”, “metric_url”, “timezone_offset” and/or “timezone_diff”. Other keys that particularly stand out due to their names are “devtools_protection” and “philanthropic_level”, which were set to “true” and 0 respectively whenever we inspected a chain that landed on FakeCaptcha in the end.</p><p class="text-align-justify">The “*_url” keys contain further HelloTDS URLs, which are used to retrieve a sort of unique identifier (“uuid_url”), the target URL (“rot_url”), an endpoint to report errors and other metrics to (“metric_url”), and an endpoint for mouse movement and device sensors tracking (“url”). Notably, the “rot_url” always contains a special parameter named “md” with a placeholder for the fingerprinting information collected by the script.</p>

<p>The JavaScript collects the following information:</p><ul><li><p class="text-align-justify">Basic browser info: window width and height, document referrer, window location (URL), browser language, current datetime, time zone offset, and whether the site is shown in a top-level window or an iframe,</p></li><li><p class="text-align-justify">the “user id” previously returned by the UUID endpoint,</p></li><li><p class="text-align-justify">whether or not a mobile browser is used (by checking if the deprecated window.orientation property is defined),</p></li><li><p class="text-align-justify">whether or not a touch screen is present (by reporting the value of the window.navigator.maxTouchPoints property),</p></li><li><p class="text-align-justify">page title information, most common words in the host webpage as well as any keywords declared in the host document’s head element,</p></li><li><p class="text-align-justify">the approximate amount of physical memory and the number of processor cores,</p></li><li><p class="text-align-justify">battery status (level, charging state),</p></li><li><p class="text-align-justify">WebGL vendor and renderer,</p></li><li><p class="text-align-justify">a “sandbox score” consisting of 6 flags, e.g., whether the browser is Headless Chrome, or whether specific video codecs are supported,</p></li><li><p class="text-align-justify">network information, e.g., network type (Wi-Fi, Ethernet, cellular, …), effective and maximum bandwidth, or the estimated round-trip time,</p></li><li><p class="text-align-justify">screen orientation and colour depth,</p></li><li><p class="text-align-justify">whether cookies are enabled.</p></li></ul>

<p class="text-align-justify">A JSON object containing this information (as well as some keys from the config) is Base64-encoded and sent in the md parameter to the rotated URL from the config via a POST request. The response contains a JSON object with a “url” key as well as a TTL and bidding details.</p>

<p class="text-align-justify">The returned URL is the last HelloTDS endpoint in the whole chain.</p><h2>Third Stage: Final Payload with Redirect to Landing Page</h2><p class="text-align-justify">The final step in the HelloTDS pipeline is a simple JavaScript-based redirect to the target URL.</p>

<p class="text-align-justify">In this case, bestfree4u[.]com simply responded with a 301 redirect to a FakeCaptcha landing page at finding-from-internet[.]fly[.]storage[.]tigris[.]dev/seacrh-result[.]html. However, when accessed from a different environment, the same domain may seem harmless. In other cases, the final HelloTDS redirect leads to tech support scams, malicious file downloads, fake browser updates, potentially unwanted browser extensions, or cryptocurrency investment platforms.</p><h2>The Destination: FakeCaptcha Redirectors</h2><p class="text-align-justify">In the past months, we have seen a highly predictable pattern in the malicious URL payloads served by HelloTDS: Almost universally, they were machine-generated domains consisting of a couple of English words and a “.com”, “.shop”, “.online”, “.info”, “.live”, “.pro” or similar TLD, and the URL path was a string with 24 hexadecimal digits, the first two usually being 67 or 68. These URLs served as simple redirects, either to FakeCaptcha, or sometimes to a decoy—usually some (benign but potentially unwanted) browser extension or cryptocurrency product website. We have seen multiple of these URLs redirect to both a FakeCaptcha landing page and a decoy at different times, which removes any doubt about this being an inherently malicious service. Example URLs include the following:</p><ul><li><p class="text-align-justify">actednow[.]com/675cb495c39bc481ddf8edd6,</p></li><li><p class="text-align-justify">buzzflying[.]shop/6767af2ee2aa535e92d62a64,</p></li><li><p class="text-align-justify">goldtera[.]live/6758b1d6467532a801fa06c4,</p></li><li><p class="text-align-justify">orbito[.]online/677120fb2cca41d88a7392a2.</p></li></ul><p class="text-align-justify">The domains used by this service could be reliably identified by being registered under Namecheap in Reykjavik, Iceland, using a Let’s Encrypt TLS certificate, and resolving to one of the following IP addresses:</p><ul><li><p class="text-align-justify">5.161.37.228,</p></li><li><p class="text-align-justify">5.161.110.119,</p></li><li><p class="text-align-justify">5.161.178.111,</p></li><li><p class="text-align-justify">23.105.163.27,</p></li><li><p class="text-align-justify">23.105.163.55,</p></li><li><p class="text-align-justify">34.142.174.238,</p></li><li><p class="text-align-justify">172.104.80.249.</p></li></ul><p>Recently, the attacker has started employing more sophisticated masking even at the level of the final payload.Additionally, the structure of served URLs redirecting to FakeCaptcha has changed – they now often include parameters with placeholders, which may not even be filled in, yet the victim can still be redirected to a FakeCaptcha landing page. We have seen different variations of these URLs, some of which omit specific parameters.</p>

<p class="text-align-justify">Interestingly, some of the URLs served by HelloTDS redirect victims to FakeCaptcha landing pages, but when accessed in a controlled environment, they often mimic some legitimate websites and serve some benign content. One example of such a website is&nbsp;</p><p class="text-align-justify">hxxps[://]avs4u[.]net/?sub1=39388&amp;sub2=…&amp;sub3=ID&amp;sub4=677886&amp;sub5=0.0004752 — while it often redirects the victims to FakeCaptcha landing pages, it may also display mimicked content of the legitimate website www.avs4you.com, a software for processing videos and images. The downloadable binary is also legitimate, indicating an attempt to conceal malicious activity.</p><p>Another example of a URL redirecting victims to FakeCaptcha but serving legitimate content in a controlled environment is hxxps[://]arcadeclassic[.]org/?sub1=681978&amp;sub2=0.00037565.</p><p>&nbsp;</p>

<p class="text-align-justify">We therefore tried to understand the reasoning behind the decision of whether malicious content is served. As part of this effort, we explored the potential influence of the cookies being set, which we mentioned earlier. Ultimately, we have concluded that the decision is probably based solely on the IP address of the client. We suspect that if the IP address originates from a known VPN or other anonymizing services, the victim is consistently redirected to some benign content, likely because such users are not target victims and may potentially be security analysts. In such cases, HelloTDS delivers benign content to obscure its actual behavior, effectively evading analysis and avoiding detection.</p><h2>Delivered Malicious Content</h2><p class="text-align-justify">In our analysis of HelloTDS landing page redirectors, we observed that they serve a mix of both malicious and legitimate content. These “clean” redirects, however, often lead to investment-related sites, especially those involving cryptocurrencies. We believe that this choice is deliberate. Firstly, generating traffic to advertisers through non-consensual clickjacking may serve as an alternative, more predictable source of income for the attacker without “stepping into the dark” and serving hard malware. Furthermore, if the primary objective of FakeCaptcha is to infect victims with information stealers that ubiquitously target crypto wallets, redirecting users who were not deemed as ideal victims to a crypto investment platform may be the most logical strategy for the attacker in the long run.</p><p class="text-align-justify">On the unequivocally malicious side, various forms of FakeCaptcha were predominant, but we have also encountered Fake Updates, tech scams, download links with encrypted archives delivering LummaC2, and various other scams. Some specific examples are listed below.</p>

<h2>Key Takeaways and Defensive Measures</h2><p>The HelloTDS infrastructure behind FakeCaptcha campaigns demonstrates how attackers continue to refine their methods to bypass traditional protections, evade detection, and selectively target victims. By leveraging sophisticated fingerprinting, dynamic domain infrastructure, and deception tactics (such as mimicking legitimate websites and serving benign content to researchers) these campaigns achieve both stealth and scale.</p><p><strong>What You Can Do:</strong></p><ul><li><strong>Use reputable security software</strong> with real-time protection to block known TDS and FakeCaptcha domains. Products from Norton, Avast, AVG, and Avira automatically protect users against these threats.</li><li><strong>Enable browser-level protections</strong> like anti-tracking and ad-blocking extensions, which may prevent the initial malicious scripts from loading.</li><li><strong>Be cautious with file-sharing and streaming sites</strong>, especially those that promise monetary rewards or allow anonymous uploads without verification.</li><li><strong>Avoid copying and pasting commands</strong> from unknown or suspicious websites into system dialogs like Windows Run.</li><li><strong>Inspect suspicious domains manually or through security tools</strong>—look for signs like oddly-structured URLs, frequent domain rotation, or generic domain names.</li></ul><p class="text-align-justify">FakeCaptcha is not just a social engineering trick. It's the final step in a well-orchestrated system that filters, evaluates, and targets users with precision. Understanding the infrastructure—HelloTDS in this case—is key to disrupting the full chain of attack.</p><h2>Indicators of Compromise (non-exhaustive)</h2><p>You can find the complete list of IoCs on our <a href="https://github.com/avast/ioc/tree/master/HelloTDS">GitHub</a>.</p><h3>File Sharing Entry Websites</h3><p>dailyuploads[.]net</p><p>streamtape[.]to</p><p>streamtape[.]net</p><p>streamtape[.]to</p><p>watchadsontape[.]com</p><p>bigwarp[.]art</p><p>savefiles[.]com</p><h3>HelloTDS Domains</h3><p>yr[.]unasonoric[.]com</p><p>gq[.]binesyorker[.]com</p><p>sb[.]rowlandpodogyn[.]shop</p><p>nutatedtriol[.]com</p><p>mixscoggan[.]shop</p><p>bu[.]unrimedironize[.]shop</p><h3>FakeCaptcha Redirectors</h3><p class="text-align-justify">actednow[.]com/675cb495c39bc481ddf8edd6</p><p class="text-align-justify">buzzflying[.]shop/6767af2ee2aa535e92d62a64</p><p class="text-align-justify">goldtera[.]live/6758b1d6467532a801fa06c4</p><p class="text-align-justify">orbito[.]online/677120fb2cca41d88a7392a2</p><p class="text-align-justify">bestfree4u[.]com</p><p class="text-align-justify">avs4u[.]net/</p><p class="text-align-justify">arcadeclassic[.]org</p><h3>FakeCaptcha Landing Pages</h3><p>adelaidavizcaino[.]com/cpw</p><p>partage-de-medias[.]fly[.]storage[.]tigris[.]dev/affiliate-link[.]html</p><p>finding-from-internet[.]fly[.]storage[.]tigris[.]dev/seacrh-result[.]html</p>

Vojtěch Krejsa

Posts by Vojtěch Krejsa

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers

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

VoidStealer: Debugging Chrome to Steal Its Secrets

Defeating AuraStealer: Practical Deobfuscation Workflows for Modern Infostealers

Say hi to HelloTDS: The infrastructure behind FakeCaptcha

Vojtěch Krejsa

Posts by Vojtěch Krejsa

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers

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

VoidStealer: Debugging Chrome to Steal Its Secrets

Defeating AuraStealer: Practical Deobfuscation Workflows for Modern Infostealers

Say hi to HelloTDS: The infrastructure behind FakeCaptcha

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers