Security Evangelist at Gen

Threat Analysis Engineer at Gen

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.

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

<p>Imagine receiving a message on LinkedIn from a recruiter offering an enticing opportunity: a well-paid front-end development project that seems almost too good to be true. It’s a scenario many aspiring programmers dream of, especially those eager to land their first job in the tech industry. However, as this story reveals, the dream can quickly turn into a cybersecurity nightmare.&nbsp;</p><h2><strong>The Setup&nbsp;</strong></h2><p>The attack begins innocuously enough. A recruiter reaches out on LinkedIn, pitching an appealing development project with an impressive salary. The target? Entry-level front-end developers, often beginners in the field and eager to seize opportunities. Once the victim expresses interest, the recruiter provides a link to a code repository, ostensibly containing the project files.&nbsp;</p><p>In one known case, the recruiter’s high salary offer raised suspicions. This wariness led the targeted individual to scrutinize the repository, revealing malware embedded within the code. The victim wisely decided against proceeding, avoiding infection entirely. Shortly thereafter, the recruiter’s LinkedIn profile disappeared, leaving questions about their next steps unanswered.&nbsp;</p><h2><strong>A Firsthand Example&nbsp;</strong></h2><p>This story came to light when we became aware of a similar job offer on LinkedIn. The recruiter claimed to be developing a decentralized application (DApp) for purchasing and claiming ownership of video games using NFTs. The project aimed to provide a seamless cross-platform experience and was allegedly seeking skilled web developers to help with their UI/UX redesign.&nbsp;</p>

<p>After a few messages, the recruiter shared a Bitbucket repository link. At first glance, the project appeared legitimate, with standard documentation and architecture diagrams detailing the NFT-based system. However, deeper investigation revealed a suspicious obfuscated JavaScript file, <strong>onfig-overrides.js</strong>, containing malicious code. This file, overlooked by an untrained eye, was designed to:&nbsp;</p><ul><li>Steal login credentials</li><li>Exfiltrate crypto wallet data</li><li>Deploy and execute a Python loader&nbsp;</li></ul><p>The recruiter’s polished approach and seemingly genuine project made the scam particularly deceptive.&nbsp;</p>

<h2><strong>The Mechanism&nbsp;</strong></h2><p>The attack exploits standard industry practices. In many coding interviews or preparation tasks, candidates are asked to clone a repository, run a local server, and work on the application offline. This is commonplace for front-end developers testing web applications. However, in this case, the repository included concealed malware designed to compromise the developer’s system.&nbsp;</p><h2><strong>The Step-by-Step Anatomy of the Attack</strong>&nbsp;</h2><p>Once executed, the obfuscated JavaScript file initiated a multi-stage attack process, consisting of two main phases: the initial JavaScript execution and the subsequent Python-based payloads.&nbsp;</p><p><em>Phase 1: JavaScript Execution&nbsp;</em></p><ol><li><strong>Information Stealing</strong>: The initial script acted as an infostealer, targeting:</li></ol><ul><li>Solana wallet configurations and stored crypto wallet data.</li><li>Login credentials stored in web browsers such as Firefox and Chrome.</li><li>Other sensitive information that could be used for further attacks.</li></ul><ol start="2"><li><strong>Python Loader Deployment</strong>: The JavaScript file downloaded and executed a Python-based loader, which was responsible for delivering the next set of malicious payloads.&nbsp;</li></ol><p><em>Phase 2: Python-Based Payloads&nbsp;</em></p><ol start="3"><li><strong>Remote Access Trojan (RAT)</strong>: The Python loader executed a RAT with keylogging and advanced spying capabilities, including:</li></ol><ul><li><strong>Remote shell commands</strong>: Enabling attackers to execute commands on the victim’s machine.</li><li><strong>Clipboard exfiltration</strong>: Capturing and transmitting clipboard data to the attacker.</li><li><strong>Payload downloads</strong>: Downloading and executing additional malicious files.</li><li><strong>Browser process termination</strong>: Killing Chrome and Brave browser processes to disrupt user activity.</li><li><strong>Sensitive file exfiltration</strong>: Searching for and exfiltrating critical files such as .env, readme, and .git.</li></ul><ol start="4"><li><strong>XMRig Cryptominer</strong>: As part of the second Python stage, the XMRig cryptominer was deployed, exploiting the victim’s computing resources to mine cryptocurrency, which resulted in degraded system performance and increased power consumption.&nbsp;</li></ol><p>This structured attack exemplifies the multi-layered and highly intrusive nature of this attack, ilustrating how it moves beyond simple credential theft to fully compromising the victim’s machine.&nbsp;</p><h2><strong>The Lazarus Group Connection?&nbsp;</strong></h2><p>Interestingly, the tools used in this attack, named "BeaverTail" and "InvisibleFerret," have been attributed to the notorious Lazarus group in the past. We have strong indications that the attack was orchestrated by the Lazarus group, given their history of sophisticated cyber campaigns and their association with the tools used. The attackers leveraged tools previously linked to high-profile cybercrime, making it critical to approach such situations with caution. While the involvement of Lazarus cannot be confirmed with absolute certainty, the evidence strongly suggests their involvement.&nbsp;</p><h2><strong>The Broader Implications&nbsp;</strong></h2><p>While this specific attack focused on credential theft and cryptojacking, the Remote Access Trojan (RAT) also allows attackers to maintain long-term control over infected systems. This could be used for espionage, further malware deployment, or data exfiltration. Additionally, the potential harm could extend far beyond. The perpetrators could use such schemes to:&nbsp;</p><ul><li>Compromise company systems through stolen credentials, allowing further infiltration and unauthorized access.</li><li>Utilize the compromised system for ransomware deployment or additional malware infections.</li><li>Leverage the infected machine as a launching point for future cyberattacks, amplifying the scope of the breach.&nbsp;</li></ul><p>The idea of attackers genuinely hiring developers to create malicious tools is not far-fetched, though it seems unlikely in this instance.&nbsp;</p><h2><strong>Lessons for Job Seekers&nbsp;</strong></h2><p>This incident serves as a crucial reminder for job seekers, particularly those new to the field, to exercise vigilance when assessing job offers. Here are some tips to protect yourself:&nbsp;</p><ol><li><strong>Have an online interview before proceeding</strong>: Before starting any test or downloading files, request a video call with the recruiter to verify their legitimacy and discuss the job offer in detail.</li><li><strong>Verify the recruiter’s credentials</strong>: Cross-check their profile and company information. If something seems off, trust your instincts.</li><li><strong>Scrutinize repositories</strong>: Before cloning or running any code, scan the files for anomalies. Use reputable security tools to analyze suspicious files.</li><li><strong>Question too-good-to-be-true offers</strong>: Unrealistically high salaries or overly eager recruiters can be red flags.</li><li><strong>Use sandbox environments</strong>: Run unfamiliar code in isolated environments to prevent potential infections.</li><li><strong>Stay informed</strong>: Keep up with the latest cybersecurity threats to recognize warning signs early.&nbsp;</li></ol><h2><strong>Conclusion&nbsp;</strong></h2><p>Threat actors are increasingly targeting individuals with highly personalized and sophisticated methods, exploiting both technical vulnerabilities and human psychology. This case serves as a sobering reminder of the lengths cybercriminals will go to exploit human trust and technological processes. For aspiring developers and job seekers, awareness and skepticism are critical defenses. As we face increasingly sophisticated threats, a collective effort to educate and inform will play a crucial role in minimizing risks. By staying vigilant, leveraging security tools, and promoting best practices, we can create a safer digital landscape for everyone—one where opportunities are genuine, and trust is protected.&nbsp;</p>

Beware of Fake Job Offers: How Hackers Are Targeting Developers with Malware

How Cybercriminals Are Turning Job Offers Into Malware Traps 

<p class="text-align-justify">In early June, we discovered a sample that was exploiting a new zero-day vulnerability within Winsock driver (<strong>CVE-2024-38193</strong>) to achieve local privilege escalation to deploy a new version of FudModule rootkit. We determined that the sample was part of a Lazarus Group operation that was targeting potentially sensitive industries such as aerospace and cryptocurrency engineering to gain access to their corporate networks.</p><p class="text-align-justify"><strong>CVE-2024-38193</strong> is a use-after-free vulnerability in the <code>AFD.sys</code> driver which is responsible for kernel-mode support for the Windows socket (Winsock) interface used in network communication. This flaw allowed attackers to tamper with certain values in kernel structures, leading to read/write access which was leveraged by FudModule to execute a Direct Kernel Object Manipulation technique. This vulnerability is present on Windows 11 Version 23H2 (and earlier) and Windows 10.</p><p class="text-align-justify">The FudModule itself has also undergone a significant evolution. In addition to its usual arsenal, it started to disable crash dumps to further complicate any investigation. It is also more closely tied to the payload it aims to protect, which it injects into a process secured by Protected Process Light. These extensive changes led us to a decision to denote this version as FudModule v3.0.</p><h2>Initial access</h2><p class="text-align-justify">Previous versions of FudModule (v2.0) were <a href="https://decoded.avast.io/luiginocamastra/from-byovd-to-a-0-day-unveiling-advanced-exploits-in-cyber-recruiting-scams/">delivered by Kaolin RAT</a>, utilizing another zero-day exploit (<strong>CVE-2024-21338</strong>) to gain read/write access to the kernel memory. Unfortunately, we’ve been unable to determine how <strong>CVE-2024-38193</strong> was delivered, along with FudModule v3.0, to the victim’s device.</p><p class="text-align-justify">On August 19, 2024, Microsoft identified a North Korean threat actor exploiting a Chromium remote-code-execution (RCE) zero-day vulnerability (<strong>CVE-2024-7971</strong>) which was based on a type of confusion issue in the V8 JavaScript engine and WebAssembly engine. <a href="https://www.microsoft.com/en-us/security/blog/2024/08/30/north-korean-threat-actor-citrine-sleet-exploiting-chromium-zero-day/">Microsoft noted</a> that Citrine Sleet used Chromium exploit to deploy a FudModule rootkit, nevertheless, they did not specify more technical details on the rootkit. The RCE vulnerability was used to deploy a shellcode containing another exploit (<strong>CVE-2024-38106</strong>) that was used to escape Chromium’s sandbox and deploy the downloaded FudModule rootkit into the memory.&nbsp;</p><p class="text-align-justify">Due to the timing of this attack and a close presumed relation between Citrine Sleet and Lazarus group, we presume that the FudModule v3.0 and Winsocks exploit (<strong>CVE-2024-38193</strong>) may have been delivered in a very similar manner.</p><h2 class="text-align-justify">FudModule Rootkit delivery</h2><p class="text-align-justify">In the first version of the FudModule, referred to as FudModule v1.0, the attacker required the ability to modify kernel memory structures, potentially resulting in the deactivation of Windows monitoring features. To achieve this, they employed the Bring Your Own Vulnerable Driver (BYOVD) technique, a well-known method where attackers load a legitimate, signed, and vulnerable kernel driver to bypass the Driver Signature Enforcement (DSE) policy. The attacker then used this known vulnerability to obtain read/write access to the kernel space.</p><p class="text-align-justify">They accomplished this by loading vulnerable drivers such as <code>dbutil_2_3.sys</code> (Dell driver) and <code>ene.sys</code> (RGB lightning control driver), exploiting them using N-day vulnerabilities. This is a straightforward method, as there are numerous publicly available proof-of-concept exploits for various vulnerabilities. However, the downside is that the attacker must drop the vulnerable driver onto the filesystem and load it with administrator privileges.</p><p class="text-align-justify">The second version of the FudModule, referred to as FudModule v2.0, was discovered by Gen. In this case, the attackers exploited a zero-day vulnerability (<strong>CVE-2024-21338</strong>) in the Windows’ <code>appid.sys</code> (Application Identity driver). The key advantage of this choice is that this driver is already present on Windows 10 and Windows 11 by default, eliminating the need to drop “your” own vulnerable driver.</p><p class="text-align-justify">However, a challenge with this approach is that the attacker needed administrator privileges to send the vulnerable IOCTL code (<code>0x22A018</code>) to the <code>appid.sys</code> driver. For more technical details about this exploit, see our <a href="https://decoded.avast.io/janvojtesek/lazarus-and-the-fudmodule-rootkit-beyond-byovd-with-an-admin-to-kernel-zero-day/">previous blogpost</a> on this vulnerability.</p><p class="text-align-justify">In this new instance, the attackers discovered a way to exploit a vulnerability in the default driver without requiring administrator privileges to interact with it. &nbsp;They identified a zero-day vulnerability in the <code>AFD.sys</code> (Winsocks driver) to achieve read/write (R/W) access in kernel space. After triggering the vulnerability in <code>AFD.sys</code>, the attackers first had to gain increment primitive, crafting a specific kernel address to achieve temporary R/W primitive. With these temporary primitives, they were able to corrupt the <code>PreviousMode</code> field of the current thread in the <code>KTHREAD</code> structure. By modifying the <code>PreviousMode</code>, they could bypass kernel mode checks within system calls such as <code>NtReadVirtualMemory</code> or <code>NtWriteVirtualMemory</code>, and stealthily deploy FudModule v3.0.</p><h2>FudModule rootkit</h2><p class="text-align-justify">The FudModule v1.0 was discovered by the <a href="https://www.virusbulletin.com/uploads/pdf/conference/vb2022/papers/VB2022-Lazarus-and-BYOVD-evil-to-the-Windows-core.pdf">ESET</a> and AnhLab in September 2022. They described 7 techniques used to disarm security solutions and monitoring tools.In June of last year, our discovery of the FudModule 2.0 lead to a sample featuring nine techniques, out of which four were new and three were improved, with another two remaining unchanged.</p><p class="text-align-justify">In FudModule 3.0, eight techniques from the previous version remain unchanged, and one technique was removed in favour of two new techniques. The unchanged functions, are:</p><ul><li>Disable a security solution ability to monitor registry operations</li><li>Disable object callbacks routine which is which is used to execute a custom code response to thread, process, and desktop handle operations.</li><li>Disable process, thread and image kernel callbacks</li><li>Disabling all monitoring and antivirus file system minifilters</li><li>Disable network traffic filtering (happens only if Kaspersky drivers are present and at the same time Symantec/Broadcom drivers are absent).</li><li>Two approaches to Disabling all system loggers in a more generic way in Event Tracing for Windows (ETW)</li><li>Disable monitoring of <code>MsMpEng.exe</code> process (Microsoft Defender) via handle table manipulation. For <code>asdsvc.exe</code> (AhnLab Smart Defense Service), the rootkit clears the <code>_EPROCESS.Protection</code> byte, reducing it to a standard, non-protected process after the modification.</li></ul><p>The function responsible for disabling image verification callbacks is no longer present in FudModule v3.0.&nbsp;</p><p>Now, we’ll dive into the two new techniques included in FudModule v3.0.</p>

<h3>Disabling crash dump</h3><p class="text-align-justify">In FudModule v3.0 rootkit, disabling a crash dump is the first technique to be executed after a successful exploitation. Since FudModule v3.0 directly manipulates kernel structures, which could potentially cause a system crash, it employs a method to prevent the creation of crash dump files. Crash dump files capture the system's memory at the time of an error, including loaded drivers, running processes, and active kernel data. If a crash dump file caused by the rootkit were saved, it could provide leads to the exploit during the crash investigation, which could expose the zero-day before gaining foothold on the device.</p><p class="text-align-justify">To disable crash dump, the rootkit first locates the virtual address of the data sections of the <code>crashdmp.sys</code> driver and <code>ntoskrnl.exe</code> (kernel image) in memory. It then scans for pointer in the data section of <code>ntoskrnl.exe</code>; more specifically it is looking for a pointer pointing to the data section of <code>crashdmp.sys</code> which is a global pointer named CrashdmpDumpBlock. It then zeroes out this pointer which effectively prevents the system from generating a crash dump.</p>

<h3>Shellcode Injections</h3><p class="text-align-justify">The second technique, shellcode injection, is rather peculiar in the sense that it makes a shift from FudModule v2.0 as a final payload to FudModule v3.0 used as a stager for another payload. The process involves two consecutive shellcode injections into different processes: one into <code>services.exe</code> and the other into <a href="https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec"><code>msiexec.exe</code></a>.</p><p class="text-align-justify">Initially, memory pages are allocated within these processes, their permissions modified to allow execution, and <code>_EPROCESS.MitigationFlags</code> is cleared to avoid instability if the handle table manipulation goes awry.</p>

<p class="text-align-justify">In the case of <code>services.exe</code> injection, FudModule uses a non-protected process. This should protect it from acquiring a handle to processes protected by PPL (Protected Process Light) such as <code>services.exe</code>, <code>wininit.exe,</code> or <code>csrss.exe</code>. Nevertheless, FudModule exploits the kernel Read/Write primitive to gain direct access to the handle table. This way, it can craft a custom handle table entry, gaining control over both referenced object and its access bits, effectively bypassing PPL. Then <a href="https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec"><code>msiexec.exe</code></a> process is spawned from within this context.</p>

<p class="text-align-justify">Previously in v2.0, FudModule used a dummy thread to insert an entry into the handle table and subsequently modified the referenced object to target specific processes (in order to disable security solutions). In v3.0, a more sophisticated approach is used: FudModule uses <code>NtDuplicateObject</code> function to duplicate the current process handle, creating another entry in the handle table. This new entry points to the <code>_OBJECT_HEADER</code> of the target <code>_EPROCESS</code> – in our case <code>services.exe</code>.</p><p class="text-align-justify">The second injection, targeting the <a href="https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec"><code>msiexec.exe</code></a> spawned by the first injection, simply aims to decrypt and prepare a payload before executing it. This payload is passed as an argument by the initial 0-day containing shellcode.</p><p class="text-align-justify">This development marks an interesting shift in the FudModule's functionality. Instead of being the final payload by itself, it serves as a loader that abuses its access into PPL-protected processes to improve stealthiness of the final payload and hinder detection and tracing.</p><h2>Conclusion</h2><p class="text-align-justify">The Lazarus cybercriminal group, one of the long-standing APT (Advanced Persistent Threat) groups, has once again surprised the cybersecurity community. Lazarus continues to aggressively utilize new zero-day vulnerabilities, targeting not just operating systems but also browsers to effectively deliver their payloads. This time, they even went one step further by going from BYOVD to directly exploiting system drivers.</p><p class="text-align-justify">Since the discovery of the FudModule, it has been clear that this rootkit is under active development. Its aim appears to be achieving long-term persistence and improved stealth capabilities to bypass built-in security features and evade detection from security vendors. Its latest evolution seems to shift its purpose from a standalone rootkit for disarming security solutions to a more generic rootkit that also actively protects the associated payload. Despite our extensive research, we have not yet uncovered the exact method used to deliver the Local Privilege Escalation (LPE) exploit alongside the FudModule v3.0 rootkit. However, based on the research from Microsoft, we now believe that the LPE exploit could have been delivered through a Remote Code Execution (RCE) vulnerability in Google Chrome.</p><h2>Indicators of Compromise (IoCs)</h2><p>A YARA rule for the FudModule v3.0 is available at <a href="https://github.com/avast/ioc/tree/master/FudModule#yara">github.com/avast/ioc</a></p>

Evolution of Lazarus ‘FudModule - no longer (stand)alone’

<h2><strong>Key Points</strong></h2><ul><li>Avast discovered a new campaign targeting specific individuals through fabricated job offers.&nbsp;</li><li>Avast uncovered a full attack chain from infection vector to deploying <code>“FudModule 2.0”</code> rootkit with 0-day <code>Admin -&gt; Kernel</code> exploit.&nbsp;</li><li>Avast found a previously undocumented <code>Kaolin</code> RAT, where it could aside from standard RAT functionality, change the last write timestamp of a selected file and load any received DLL binary from C&amp;C server. We also believe it was loading FudModule along with a 0-day exploit.&nbsp;</li></ul><h2><strong>Introduction</strong></h2><p>In the summer of 2023, Avast identified a campaign targeting specific individuals in the Asian region through fabricated job offers. The motivation behind the attack remains uncertain, but judging from the low frequency of attacks, it appears that the attacker had a special interest in individuals with technical backgrounds. This sophistication is evident from previous research where the Lazarus group exploited vulnerable drivers and performed several rootkit techniques to effectively blind security products and achieve better persistence.&nbsp;</p><p>In this instance, Lazarus sought to blind security products by exploiting a vulnerability in the default Windows driver, appid.sys (<a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21338">CVE-2024-21338</a>). More information about this vulnerability can be found in a corresponding <a href="https://decoded.avast.io/janvojtesek/lazarus-and-the-fudmodule-rootkit-beyond-byovd-with-an-admin-to-kernel-zero-day/">blog post</a>.&nbsp;</p><p>This indicates that Lazarus likely allocated additional resources to develop such attacks. Prior to exploitation, Lazarus deployed the toolset meticulously, employing fileless malware and encrypting the arsenal onto the hard drive, as detailed later in this blog post.&nbsp;</p><p>Furthermore, the nature of the attack suggests that the victim was carefully selected and highly targeted, as there likely needed to be some level of rapport established with the victim before executing the initial binary. Deploying such a sophisticated toolset alongside the exploit indicates considerable resourcefulness.&nbsp;</p><p>This blog post will present a technical analysis of each module within the entire attack chain. This analysis aims to establish connections between the toolset arsenal used by the Lazarus group and previously published research.&nbsp;</p><h2><strong>Initial access&nbsp;</strong></h2><p>The attacker initiates the attack by presenting a fabricated job offer to an unsuspecting individual, utilizing social engineering techniques to establish contact and build rapport. While the specific communication platform remains unknown, previous research by &nbsp;<a href="https://www.mandiant.com/resources/blog/dprk-whatsapp-phishing">Mandiant</a> and <a href="https://www.welivesecurity.com/en/eset-research/lazarus-luring-employees-trojanized-coding-challenges-case-spanish-aerospace-company/">ESET</a> suggests potential delivery vectors may include LinkedIn, WhatsApp, email or other platforms. Subsequently, the attacker attempts to send a malicious ISO file, disguised as VNC tool, which is a part of the <a href="https://securelist.com/apt-trends-report-q3-2023/110752/">interviewing process</a>. The choice of an ISO file is starting to be very attractive for attackers because, from Windows 10, an ISO file could be automatically mounted just by double clicking and the operating system will make the ISO content easily accessible. This may also serve as a potential Mark-of-the-Web (MotW) bypass.&nbsp;</p><p>Since the attacker created rapport with the victim, the victim is tricked by the attacker to mount the ISO file, which contains three files: <code>AmazonVNC.exe</code>, <code>version.dl</code>l and <code>aws.cfg</code>. This leads the victim to execute <code>AmazonVNC.exe</code>.&nbsp;&nbsp;</p><p>The <code>AmazonVNC.exe</code> executable only pretends to be the Amazon VNC client, instead, it is a legitimate Windows application called <code>choice.exe</code> that ordinarily resides in the <code>System32</code> folder. This executable is used for sideloading, to load the malicious <code>version.dll</code> through the legitimate <code>choice.exe</code> application. Sideloading is a popular technique among attackers for evading detection since the malicious DLL is executed in the context of a legitimate application.&nbsp;&nbsp;</p><p>When <code>AmazonVNC.exe</code> gets executed, it loads <code>version.dll</code>. This malicious DLL is using native Windows API functions in an attempt to avoid defensive techniques such as user-mode API hooks. All native API functions are invoked by direct syscalls. The malicious functionality is implemented in one of the exported functions and not in DLL Main. There is no code in <code>DLLMain</code> it just returns 1, and in the other exported functions is just Sleep functionality.&nbsp;</p><p>After the DLL obtains the correct syscall numbers for the current Windows version, it is ready to spawn an <code>iexpress.exe</code> process to host a further malicious payload that resides in the third file, <code>aws.cfg</code>. Injection is performed only if the Kaspersky antivirus is installed on the victim’s computer, which seems to be done to evade Kaspersky detection. If Kaspersky is not installed, the malware executes the payload by creating a thread in the current process, with no injection. The <code>aws.cfg</code> file, which is the next stage payload, is obfuscated by VMProtect, perhaps in an effort to make reverse engineering more difficult. The payload is capable of downloading shellcode from a Command and Control (C&amp;C) server, which we believe is a legitimate hacked website selling marble material for construction. The official website is <code>https://www[.]henraux.com/</code>, and the attacker was able to download shellcode from <code>https://www[.]henraux.com/sitemaps/about/about.asp&nbsp;</code></p><p>In detailing our findings, we faced challenges extracting a shellcode from the C&amp;C server as the malicious URL was unresponsive.&nbsp;&nbsp;</p><p>By analyzing our telemetry, we uncovered potential threats in one of our clients, indicating a significant correlation between the loading of shellcode from the C&amp;C server via an ISO file and the subsequent appearance of the <code>RollFling</code>, which is a new undocumented loader that we discovered and will delve into later in this blog post.&nbsp;</p><p>Moreover, the delivery method of the ISO file exhibits tactical similarities to those employed by the Lazarus group, a fact previously noted by researchers from <a href="https://www.mandiant.com/resources/blog/dprk-whatsapp-phishing">Mandiant</a> and <a href="https://www.welivesecurity.com/en/eset-research/lazarus-luring-employees-trojanized-coding-challenges-case-spanish-aerospace-company/">ESET</a>.&nbsp;</p><p>In addition, a <code>RollSling </code>sample was identified on the victim machines, displaying code similarities with the <code>RollSling </code>sample discussed in <a href="https://www.microsoft.com/en-us/security/blog/2023/10/18/multiple-north-korean-threat-actors-exploiting-the-teamcity-cve-2023-42793-vulnerability/">Microsoft’s research</a>. Notably, the <code>RollSling </code>instance discovered in our client’s environment was delivered by the <code>RollFling </code>loader, confirming our belief in the connection between the absent shellcode and the initial loader <code>RollFling</code>. For visual confirmation, refer to the first screenshot showcasing the SHA of <code>RollSling</code> report code from <a href="https://www.microsoft.com/en-us/security/blog/2023/10/18/multiple-north-korean-threat-actors-exploiting-the-teamcity-cve-2023-42793-vulnerability/">Microsoft</a>, while on the second screenshot is the code derived from our <code>RollSling </code>sample.&nbsp;</p>

<p>In the next paragraphs, we are going to explain every component in the execution chain, starting with the initial <code>RollFling</code> loader, continuing with the subsequently loaded <code>RollSling</code> loader, and then the final <code>RollMid</code> loader. Finally, we will analyze the <code>Kaolin</code> RAT, which is ultimately loaded by the chain of these three loaders.&nbsp;</p><h2><strong>Loaders</strong></h2><h3><strong>RollFling</strong></h3><p>The <code>RollFling</code> loader is a malicious DLL that is established as a service, indicating the attacker’s initial attempt at achieving persistence by registering as a service. Accompanying this <code>RollFling</code> loader are essential files crucial for the consistent execution of the attack chain. Its primary role is to kickstart the execution chain, where all subsequent stages operate exclusively in memory. Unfortunately, we were unable to ascertain whether the DLL file was installed as a service with administrator rights or just with standard user rights.&nbsp;</p><p>The loader acquires the System Management BIOS (SMBIOS) table by utilizing the Windows API function <code>GetSystemFirmwareTable</code>. Beginning with Windows 10, version 1803, any user mode application can access SMBIOS information. SMBIOS serves as the primary standard for delivering management information through system firmware.&nbsp;</p><p>By calling the <code>GetSystemFirmwareTable</code> (see Figure 1.) function, <code>SMBIOSTableData</code> is retrieved, and that <code>SMBIOSTableData</code> is used as a key for decrypting the encrypted <code>RollSling</code> loader by using the XOR operation. Without the correct <code>SMBIOSTableData</code>, which is a 32-byte-long key, the <code>RollSling</code> decryption process would be ineffective so the execution of the malware would not proceed to the next stage. This suggests a highly targeted attack aimed at a specific individual.&nbsp;</p><p>This suggests that prior to the attacker establishing persistence by registering the <code>RollFling</code> loader as a service, they had to gather information about the <code>SMBIOS</code> table and transmit it to the C&amp;C server. Subsequently, the C&amp;C server could then reply with another stage. This additional stage, called&nbsp; <code>RollSling</code>, is stored in the same folder as <code>RollFling</code> but with the <code>".nls"</code> extension.&nbsp;&nbsp;</p><p>After successful <code>XOR</code> decryption of <code>RollSling</code>,&nbsp; <code>RollFling</code> is now ready to load decrypted <code>RollSling</code> into memory and continue with the execution of <code>RollSling</code>.&nbsp;</p>

<h3><strong>RollSling</strong></h3><p>The <code>RollSling</code> loader, initiated by <code>RollFling</code>, is executed in memory. This choice may help the attacker evade detection by security software. The primary function of <code>RollSling</code> is to locate a binary blob situated in the same folder as <code>RollSling</code> (or in the Package Cache folder). If the binary blob is not situated in the same folder as the <code>RollSling</code>, then the loader will look in the Package Cache folder. This binary blob holds various stages and configuration data essential for the malicious functionality. This binary blob must have been uploaded to the victim machine by some previous stage in the infection chain.&nbsp;&nbsp;</p><p>The reasoning behind binary blob holding multiple files and configuration values is twofold. Firstly, it is more efficient to hold all the information in a single file and, secondly, most of the binary blob can be encrypted, which may add another layer of evasion meaning lowering the chance of detection.&nbsp;&nbsp;</p><p><code>Rollsling</code> is scanning the current folder, where it is looking for a specific binary blob. To determine which binary blob in the current folder is the right one, it first reads 4 bytes to determine the size of the data to read. Once the data is read, the bytes from the binary blob are reversed and saved in a temporary variable, afterwards, it goes through several conditions checks like the MZ header check. If the MZ header check is done, subsequently it looks for the <code>“StartAction”</code> export function from the extracted binary. If all conditions are met, then it will load the next stage <code>RollMid</code> in memory. The attackers in this case didn’t use any specific file name for a binary blob or any specific extension, to be able to easily find the binary blob in the folder. Instead, they have determined the right binary blob through several conditions, that binary blob had to meet. This is also one of the defensive evasion techniques for attackers to make it harder for defenders to find the binary blob in the infected machine.&nbsp;</p><p>This stage represents the next stage in the execution chain, which is the third loader called <code>RollMid</code> which is also executed in the computer’s memory.&nbsp;</p><p>Before the execution of the <code>RollMid</code> loader, the malware creates two folders, named in the following way:&nbsp;</p><ul><li>%driveLetter%:\\ProgramData\\Package Cache\\[0-9A-Z]{8}-DF09-AA86-YI78-[0-9A-Z]{12}\\&nbsp;</li><li>%driveLetter%:\\ProgramData\\Package Cache\\ [0-9A-Z]{8}-09C7-886E-II7F-[0-9A-Z]{12}\\&nbsp;</li></ul><p>These folders serve as destinations for moving the binary blob, now renamed with a newly generated name and a <code>".cab"</code> extension. <code>RollSling</code> loader will store the binary blob in the first created folder, and it will store a new temporary file, whose usage will be mentioned later, in the second created folder.&nbsp;&nbsp;</p><p>The attacker utilizes the <code>"Package Cache"</code> folder, a common repository for software installation files, to better hide its malicious files in a folder full of legitimate files. In this approach, the attacker also leverages the <code>".cab"</code> extension, which is the usual extension for the files located in the <code>Package Cache</code> folder. By employing this method, the attacker is trying to effectively avoid detection by relocating essential files to a trusted folder.&nbsp;</p><p>In the end, the <code>RollSling</code> loader calls an exported function called <code>"StartAction"</code>. This function is called with specific arguments, including information about the actual path of the <code>RollFling</code> loader, the path where the binary blob resides, and the path of a temporary file to be created by the <code>RollMid</code> loader.&nbsp;</p>

<h3><strong>RollMid</strong></h3><p>The responsibility of the <code>RollMid</code> loader lies in loading key components of the attack and configuration data from the binary blob, while also establishing communication with a C&amp;C server.&nbsp;</p><p>The binary blob, containing essential components and configuration data, serves as a critical element in the proper execution of the attack chain. Unfortunately, our attempts to obtain this binary blob were unsuccessful, leading to gaps in our full understanding of the attack. However, we were able to retrieve the <code>RollMid</code> loader and certain binaries stored in memory.&nbsp;</p><p>Within the binary blob, the <code>RollMid</code> loader is a fundamental component located at the beginning (see Figure 3). The first 4 bytes in the binary blob describe the size of the <code>RollMid</code> loader. There are two more binaries stored in the binary blob after the <code>RollMid</code> loader as well as configuration data, which is located at the very end of the binary blob. These two other binaries and configuration data are additionally subject to compression and AES encryption, adding layers of security to the stored information.&nbsp;&nbsp;</p><p>As depicted, the first four bytes enclosed in the initial yellow box describe the size of the <code>RollMid </code>loader. This specific information is also important for parsing, enabling the transition to the subsequent section within the binary blob.&nbsp;</p><p>Located after the <code>RollMid</code> loader, there are two 4-byte values, distinguished by yellow and green colors. The former corresponds to the size of <code>FIRST_ENCRYPTED_DLL</code> section, while the latter (green box) signifies the size of <code>SECOND_ENCRYPTED_DLL</code> section. Notably, the second 4-byte value in the green box serves a dual purpose, not only describing a size but also at the same time constituting a part of the 16-byte AES key for decrypting the <code>FIRST_ENCRYPTED_DLL</code> section. Thanks to the provided information on the sizes of each encrypted DLL embedded in the binary blob, we are now equipped to access the configuration data section placed at the end of the binary blob.&nbsp;</p>

<p>The <code>RollMid</code> loader requires the <code>FIRST_DLL_BINARY </code>for proper communication with the C&amp;C server. However, before loading <code>FIRST_DLL_BINARY</code>, the <code>RollMid</code> loader must first decrypt the <code>FIRST_ENCRYPTED_DLL</code> section.&nbsp;</p><p>The decryption process applies the AES algorithm, beginning with the parsing of the decryption key alongside an initialization vector to use for AES decryption. Subsequently, a decompression algorithm is applied to further extract the decrypted content. Following this, the decrypted <code>FIRST_DLL_BINARY</code> is loaded into memory, and the <code>DllMain</code> function is invoked to initialize the networking library.&nbsp;</p><p>Unfortunately, as we were unable to obtain the binary blob, we didn’t get a chance to reverse engineer the <code>FIRST_DLL_BINARY</code>. This presents a limitation in our understanding, as the precise implementation details for the imported functions in the <code>RollMid</code> loader remain unknown. These imported functions include the following:&nbsp;</p><ul><li><code>SendDataFromUrl&nbsp;</code></li><li><code>GetImageFromUrl</code>&nbsp;</li><li><code>GetHtmlFromUrl&nbsp;</code></li><li><code>curl_global_cleanup&nbsp;</code></li><li><code>curl_global_init&nbsp;</code></li></ul><p>After reviewing the exported functions by their names, it becomes apparent that these functions are likely tasked with facilitating communication with the C&amp;C server. <code>FIRST_DLL_BINARY</code> also exports other functions beyond these five, some of which will be mentioned later in this blog.&nbsp;&nbsp;</p><p>The names of these five imported functions imply that <code>FIRST_DLL_BINARY</code> is built upon the <a href="https://curl.se/libcurl/">curl library</a> (as can be seen by the names <code>curl_global_cleanup</code> and <code>curl_global_init</code>). In order to establish communication with the C&amp;C servers, the <code>RollMid</code> loader employs the imported functions, utilizing HTTP requests as its preferred method of communication.&nbsp;</p><p>The rationale behind opting for the curl library for sending HTTP requests may stem from various factors. One notable reason could be the efficiency gained by the attacker, who can save time and resources by leveraging the HTTP communication protocol. Additionally, the ease of use and seamless integration of the curl library into the code further support its selection.&nbsp;</p><p>Prior to initiating communication with the C&amp;C server, the malware is required to generate a dictionary filled with random words, as illustrated in Figure 4 below. Given the extensive size of the dictionary (which contains approximately hundreds of elements), we have included only a partial screenshot for reference purposes. The subsequent sections of this blog will delve into a comprehensive exploration of the role and application of this dictionary in the overall functionality of malware.&nbsp;</p>

<p>To establish communication with the C&amp;C server, as illustrated in Figure 5, the malware must obtain the initial C&amp;C addresses from the <code>CONFIGURATION_DATA</code> section. Upon decrypting these addresses, the malware initiates communication with the first layer of the C&amp;C server through the <code>GetHtmlFromUrl</code> function, presumably using an HTTP GET request. The server responds with an HTML file containing the address of the second C&amp;C server layer. Subsequently, the malware engages in communication with the second layer, employing the imported <code>GetImageFromUrl</code> function. The function name implies this performs a GET request to retrieve an image.&nbsp;</p><p>In this scenario, the attackers employ steganography to conceal crucial data for use in the next execution phase. Regrettably, we were unable to ascertain the nature of the important data concealed within the image received from the second layer of the C&amp;C server.&nbsp;</p>

<p>We are aware that the concealed data within the image serves as a parameter for a function responsible for transmitting data to the third C&amp;C server. Through our analysis, we have determined that the acquired data from the image corresponds to another address of the third C&amp;C server.&nbsp; Communication with the third C&amp;C server is initiated with a POST request.&nbsp;&nbsp;</p><p>Malware authors strategically employ multiple C&amp;C servers as part of their operational tactics to achieve specific objectives. In this case, the primary goal is to obtain an additional data blob from the third C&amp;C server, as depicted in Figure 5, specifically in step 7. Furthermore, the use of different C&amp;C servers and diverse communication pathways adds an additional layer of complexity for security tools attempting to monitor such activities. This complexity makes tracking and identifying malicious activities more challenging, as compared to scenarios where a single C&amp;C server is employed.</p><p>The malware then constructs a URL, by creating the query string with GET parameters (name/value pairs). The parameter name consists of a randomly selected word from the previously created dictionary and the value is generated as a random string of two characters. The format is as follows:&nbsp;</p><p><code><em>"%addressOfThirdC&amp;C%?%RandomWordFromDictonary%=%RandomString%"</em>&nbsp;</code></p><p>The URL generation involves the selection of words from a generated dictionary, as opposed to entirely random strings. This intended choice aims to enhance the appearance and legitimacy of the URL. The words, carefully curated from the dictionary, contribute to the appearance of a clean and organized URL, resembling those commonly associated with authentic applications. The terms such as <code>"atype"</code>, <code>"User"</code>,” or <code>"type"</code> are not arbitrary but rather thoughtfully chosen words from the created dictionary. By utilizing real words, the intention is to create a semblance of authenticity, making the HTTP <code>POST </code>payload appear more structured and in line with typical application interactions. &nbsp;</p><p>Before dispatching the <code>POST</code> request to the third layer of the C&amp;C server, the request is populated with additional key-value tuples separated by standard delimiters “?” and “=” between the key and value. In this scenario, it includes:&nbsp;</p><p><code>%<em>RandomWordFromDictonary</em> %=%sleep_state_in_minutes%?%size_of_configuration_data%&nbsp;&nbsp;</code></p><p>The data received from the third C&amp;C server is parsed. The parsed data may contain an integer, describing sleep interval, or a data blob. This data blob is encoded using the base64 algorithm. After decoding the data blob, where the first 4 bytes indicate the size of the first part of the data blob, the remainder represents the second part of the data blob.&nbsp;</p><p>The first part of the data blob is appended to the <code>SECOND_ENCRYPTED_DLL</code> as an overlay, obtained from the binary blob. After successfully decrypting and decompressing&nbsp;<code>SECOND_ENCRYPTED_DLL</code>, the process involves preparing the <code>SECOND_ENCRYPTED_DLL</code>, which is a Remote Access Trojan (RAT) component to be loaded into memory and executed with the specific parameters.&nbsp;</p><p>The underlying motivation behind this maneuver remains shrouded in uncertainty. It appears that the attacker, by choosing this method, sought to inject a degree of sophistication or complexity into the process. However, from our perspective, this approach seems to border on overkill. We believe that a simpler method could have sufficed for passing the data blob to the <code>Kaolin</code> RAT.&nbsp;&nbsp;</p><p>The second part of the data blob, once decrypted and decompressed, is handed over to the <code>Kaolin</code> RAT component, while the <code>Kaolin</code> RAT is executed in memory. Notably, the decryption key and initialization vector for decrypting the second part of the data blob reside within its initial 32 bytes.&nbsp;&nbsp;</p><h2><strong>Kaolin RAT</strong></h2><p>A pivotal phase in orchestrating the attack involves the utilization of a Remote Access Trojan (RAT). As mentioned earlier, this <code>Kaolin</code> RAT is executed in memory and configured with specific parameters for proper functionality. It stands as a fully equipped tool, including file compression capabilities. &nbsp;</p><p>However, in our investigation, the <code>Kaolin</code> RAT does not mark the conclusion of the attack. In the previous blog post, we already introduced another significant component – the <a href="https://decoded.avast.io/janvojtesek/lazarus-and-the-fudmodule-rootkit-beyond-byovd-with-an-admin-to-kernel-zero-day/">FudModule</a> rootkit. Thanks to our robust telemetry, we can confidently assert that this rootkit was loaded by the aforementioned <code>Kaolin</code> RAT, showcasing its capabilities to seamlessly integrate and deploy <code>FudModule</code>. This layered progression underscores the complexity and sophistication of the overall attack strategy.&nbsp;</p><p>One of the important steps is establishing secure communication with the RAT’s C&amp;C server, encrypted using the AES encryption algorithm. Despite the unavailability of the binary containing the communication functionalities (the RAT also relies on functions imported from <code>FIRST_DLL_BINARY</code> for networking), our understanding is informed by other components in the attack chain, allowing us to make certain assumptions about the communication method.&nbsp;</p><p>The <code>Kaolin</code> RAT is loaded with six arguments, among which a key one is the base address of the network module DLL binary, previously also used in the <code>RollMid</code> loader. Another argument includes the configuration data from the second part of the received data blob.&nbsp;</p><p>For proper execution, the <code>Kaolin</code>&nbsp;RAT needs to parse this configuration data, which includes parameters such as:&nbsp;</p><ul><li>Duration of the sleep interval.&nbsp;</li><li>A flag indicating whether to collect information about available disk drives.&nbsp;</li><li>A flag indicating whether to retrieve a list of active sessions on the remote desktop.&nbsp;</li><li>Addresses of additional C&amp;C servers.&nbsp;</li></ul><p>In addition, the <code>Kaolin</code> RAT must load specific functions from <code>FIRST_DLL_BINARY</code>, namely:&nbsp;</p><ul><li><code>SendDataFromURL&nbsp;</code></li><li><code>ZipFolder&nbsp;</code></li><li><code>UnzipStr</code>&nbsp;</li><li><code>curl_global_cleanup</code>&nbsp;</li><li><code>curl_global_init</code>&nbsp;</li></ul><p>Although the exact method by which the <code>Kaolin</code> RAT sends gathered information to the C&amp;C server is not precisely known, the presence of exported functions like <code>"curl_global_cleanup"</code> and <code>"curl_global_init"</code> suggests that the sending process involves again API calls from the curl library.&nbsp;</p><p>For establishing communication, the <code>Kaolin</code> RAT begins by sending a <code>POST</code> request to the C&amp;C server. In this first <code>POST</code> request, the malware constructs a URL containing the address of the C&amp;C server. This URL generation algorithm is very similar to the one used in the <code>RollMid</code> loader. To the C&amp;C address, the <code>Kaolin</code> RAT appends a randomly chosen word from the previously created dictionary (the same one as in the <code>RollMid</code> loader) along with a randomly generated string. The format of the URL is as follows:&nbsp;</p><p><code><em>"%addressOfC&amp;Cserver%?%RandomWordFromDictonary%=%RandomString%"</em>&nbsp;</code></p><p>The malware further populates the content of the <code>POST</code> request, utilizing the default <code>"application/x-www-form-urlencoded"</code> content type. The content of the <code>POST</code> request is subject to AES encryption and subsequently encoded with base64.&nbsp;</p><p>Within the encrypted content, which is appended to the key-value tuples (see the form below), the following data is included <code>(<em>EncryptedContent)</em></code>:&nbsp;</p><ul><li>Installation path of the <code>RollFling</code> loader and path to the binary blob&nbsp;</li><li>Data from the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Iconservice&nbsp;</li><li><code>Kaolin</code> RAT process ID&nbsp;</li><li>Product name and build number of the operating system.&nbsp;</li><li>Addresses of C&amp;C servers.&nbsp;</li><li>Computer name&nbsp;</li><li>Current directory&nbsp;</li></ul><p>In the <code>POST</code> request with the encrypted content, the malware appends information about the generated key and initialization vector necessary for decrypting data on the backend. This is achieved by creating key-value tuples, separated by “&amp;” and “=” between the key and value. In this case, it takes the following form:&nbsp;</p><p><code><em>%RandomWordFromDictonary%=%TEMP_DATA%&amp;%RandomWordFromDictonary%=%IV%%KEY%&amp;%RandomWordFromDictonary%=%EncryptedContent%&amp;%RandomWordFromDictonary%=%EncryptedHostNameAndIPAddr%</em>&nbsp;</code></p><p>Upon successfully establishing communication with the C&amp;C server, the <code>Kaolin</code> RAT becomes prepared to receive commands. The received data is encrypted with the aforementioned generated key and initialization vector and requires decryption and parsing to execute a specific command within the RAT.&nbsp;</p><p>When the command is processed the <code>Kaolin</code> RAT relays back the results to the C&amp;C server, encrypted with the same AES key and IV. This encrypted message may include an error message, collected information, and the outcome of the executed function.&nbsp;</p><p>The <code>Kaolin</code> RAT has the capability to execute a variety of commands, including:&nbsp;</p><ul><li>Updating the duration of the sleep interval.&nbsp;</li><li>Listing files in a folder and gathering information about available disks.&nbsp;</li><li>Updating, modifying, or deleting files.&nbsp;</li><li>Changing a file’s last write timestamp.&nbsp;</li><li>Listing currently active processes and their associated modules.&nbsp;</li><li>Creating or terminating processes.&nbsp;</li><li>Executing commands using the command line.&nbsp;</li><li>Updating or retrieving the internal configuration.&nbsp;</li><li>Uploading a file to the C&amp;C server.&nbsp;</li><li>Connecting to the arbitrary host.&nbsp;</li><li>Compressing files.&nbsp;</li><li>Downloading a DLL file from C&amp;C server and loading it in memory, potentially executing one of the following exported functions:&nbsp;<ul><li><code>_DoMyFunc&nbsp;</code></li><li><code>_DoMyFunc2&nbsp;</code></li><li><code>_DoMyThread (executes a thread)</code>&nbsp;</li><li><code>_DoMyCommandWork</code>&nbsp;</li></ul></li><li>Setting the current directory.</li></ul><h2><strong>Conclusion</strong></h2><p>Our investigation has revealed that the Lazarus group targeted individuals through fabricated job offers and employed a sophisticated toolset to achieve better persistence while bypassing security products. Thanks to our robust telemetry, we were able to uncover almost the entire attack chain, thoroughly analyzing each stage. The Lazarus group’s level of technical sophistication was surprising and their approach to engaging with victims was equally troubling.&nbsp;It is evident that they invested significant resources in developing such a complex attack chain. What is certain is that Lazarus had to innovate continuously and allocate enormous resources to research various aspects of Windows mitigations and security products. Their ability to adapt and evolve poses a significant challenge to cybersecurity efforts.&nbsp;</p><h2><strong>Indicators of Compromise (IoCs)&nbsp;</strong></h2><p>ISO<br>b8a4c1792ce2ec15611932437a4a1a7e43b7c3783870afebf6eae043bcfade30&nbsp;</p><p>RollFling<br>a3fe80540363ee2f1216ec3d01209d7c517f6e749004c91901494fb94852332b&nbsp;</p><p>NLS files<br>01ca7070bbe4bfa6254886f8599d6ce9537bafcbab6663f1f41bfc43f2ee370e<br>7248d66dea78a73b9b80b528d7e9f53bae7a77bad974ededeeb16c33b14b9c56&nbsp;</p><p>RollSling<br>e68ff1087c45a1711c3037dad427733ccb1211634d070b03cb3a3c7e836d210f<br>f47f78b5eef672e8e1bd0f26fb4aa699dec113d6225e2fcbd57129d6dada7def&nbsp;</p><p>RollMid<br>9a4bc647c09775ed633c134643d18a0be8f37c21afa3c0f8adf41e038695643e&nbsp;</p><p>Kaolin RAT<br>a75399f9492a8d2683d4406fa3e1320e84010b3affdff0b8f2444ac33ce3e690&nbsp;</p>

Luigino Camastra

Posts by Luigino Camastra

How Cybercriminals Are Turning Job Offers Into Malware Traps

Evolution of Lazarus ‘FudModule - no longer (stand)alone’

From BYOVD to a 0-day: Unveiling Advanced Exploits in Cyber Recruiting Scams