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.

Security Evangelist at Gen

Threat Operations Analyst at Gen

Research

<p>A fake invoice in your email is easy to ignore. A fake invoice inside your order history feels different.&nbsp;</p><p>Norton customers have reported fake Norton invoices appearing inside the Shop app, the shopping and order-tracking app from Shopify. Public reports suggest the same technique is not limited to Norton. Similar suspicious Shop app notifications have used McAfee, Apple gift cards, iPhones, PayPal-style payment claims and other high-value purchases as bait. The impersonated brand may change, but the mechanics are familiar: make the user believe they have been charged, then give them a phone number to call.&nbsp;</p><p>That phone number is where the scam really begins.&nbsp;</p><h4>Why the Shop app makes this more believable&nbsp;</h4><p>Shop is a legitimate app. People use it to track packages, check receipts and receive order updates. According to Shop’s own documentation, the app can automatically track orders from several sources, including Gmail, Outlook, the email address linked to the user’s Shop account and orders paid through Shop Pay. If Gmail or Outlook is connected, Shop says it scans recent emails for keywords such as “tracking number” and “track your package” to populate deliveries in the Orders tab.&nbsp;</p>

<p>Shop also supports push notifications for delivery updates, payments and favorite products. So the first alert the victim sees may not be an email, an SMS or a calendar invite. It may be a notification from an app they already use for real purchases.&nbsp;</p><p>That context matters. The scam text is not especially polished. Some of the examples we reviewed contain awkward wording and obvious signs of fraud. But when the message appears inside an order-tracking app, surrounded by real receipts and shipping updates, users may give it more credibility than it deserves.&nbsp;</p><p>The screenshots reported to us show fake orders under generic seller names such as “My Store.” The receipts claim that a Norton or Norton LifeLock subscription has been activated or renewed, usually for several hundred dollars. The phone number appears in the product description, the receipt body or even the shipping address field.&nbsp;</p><p>That is not how a normal receipt should look.&nbsp;</p><h4>The brand is interchangeable&nbsp;</h4><p>Norton is the example we saw through customer reports. Norton support now warns that scammers may abuse Android and iOS shopping platforms or applications to generate fake order notifications that appear to be legitimate Norton purchases. Those notifications may include fake order confirmations, fake charges, trusted third-party app delivery and fake support phone numbers embedded in order details.&nbsp;</p><p>Public user reports point to a wider pattern. One Reddit user described receiving a Shop.app message about a transaction they did not recognize, with no follow-up email confirmation, and a message telling them to call support if the order was not placed by them. Another thread includes reports of unrecognized iPhone purchases under “My Store,” suspicious contact emails and users saying they saw no matching charges on their bank cards. Other reports mention fictitious Apple gift card purchases and iPhone orders using the same kind of wording: “If Order Not Placed By You,” followed by a phone number.&nbsp;</p><p>The choice of brand is part of the social engineering. A fake security subscription charge plays on two fears at once: being billed for something you did not buy, and being left unprotected if you ignore it. Apple products and gift cards create high-value purchase panic. PayPal-style wording makes users worry about payment account abuse. In each case, the fake order is there to push the victim toward a call.&nbsp;</p><h4>What we know, and what we do not&nbsp;</h4><p>We have not found any evidence that any of the impersonated brands have been compromised.&nbsp;&nbsp;</p><p>We also should not claim that Shop or Shopify was breached based on the evidence we have. The exact abuse path still needs confirmation. The fake order may be entering the app through a merchant/order workflow, through email parsing, through account association, or through another legitimate mechanism that scammers have found a way to misuse. Shop’s own documentation shows that orders can populate from multiple sources, so assuming one route would be premature.&nbsp;&nbsp;</p><p>What we can say is narrower and stronger: scammers are placing fake purchase claims inside shopping app order experiences, where users are used to seeing real receipts and order updates. Norton’s own support page now describes this class of shopping app scam, and public reports show similar lures using other brands and products.&nbsp;&nbsp;</p><p>That is enough to warn users without overstating the technical evidence.&nbsp;</p><h4>How the scam works&nbsp;</h4><p>The user receives a notification or sees a new order in the Shop app. The order looks like a receipt for something expensive: a security subscription, an Apple gift card, an iPhone, a MacBook or another high-value purchase.</p>

<p>The receipt says the charge has been processed, the subscription has renewed, or the order is being prepared. Somewhere in the order details, the scammer inserts a phone number, email address or support instruction.&nbsp;</p><p>The wording is often clumsy. We have seen phrases like “If Order Not Place By You” and “If Need Help.” Those errors may look obvious when reviewing a screenshot. They are easier to miss when a phone notification tells you that hundreds of dollars have just been charged.&nbsp;</p><p>If the victim calls, the scam moves off-platform. The person answering may claim to be billing support, Norton support, PayPal support or a cancellation department. The script can vary, but the request usually moves toward credentials, payment data, one-time codes or remote access software.&nbsp;</p><p>By that point, the fake receipt has done its job. It has created enough urgency for the victim to enter a conversation controlled by the scammer.&nbsp;</p><h4>Why this is harder for users to judge&nbsp;</h4><p>Most people understand that email can be spam. They may still fall for phishing, but at least the inbox is a place where scams are expected.&nbsp;</p><p>Order-tracking apps are different. Their purpose is to collect receipts, shipping updates and purchase information in one place. A notification from that environment can feel as if it has already passed through some layer of trust, even when the content inside the order is fraudulent.&nbsp;</p><p>We have seen the same logic with calendar invite scams. The message itself is not always convincing, but the delivery channel changes how people read it. A fake invoice in an inbox is one thing. A fake invoice inside a calendar reminder or shopping app receipt can feel closer to a real event.&nbsp;</p><p>For security products, this also creates a detection problem. The first visible alert may not be an email, SMS or malicious website. It may be a legitimate app notification carrying fraudulent text. The scam still depends on social engineering, but the delivery surface is harder to classify with the usual rules.&nbsp;</p><h4>What to do if you see one&nbsp;</h4><p>Do not call the number in the receipt.&nbsp;</p><p>Check the charge directly. Open your bank or credit card app. Open the official account for the brand being impersonated. If it claims to be Norton, go to your Norton account or official Norton support. If it claims to involve PayPal, open PayPal directly. Do not use the phone number, email address or link inside the suspicious order.&nbsp;</p><p>If there is no matching charge, treat the receipt as a scam attempt.&nbsp;</p><p>Report the suspicious store or message in the Shop app if the option is available. Shop’s help pages say suspicious Shop stores can be reported from the store page through the app, and Shopify also tells users to forward phishing messages to its phishing inbox.&nbsp;&nbsp;</p><p>Norton users can forward suspicious messages to Norton and should verify unexpected charges only through their Norton account or official Norton support channels.&nbsp;&nbsp;</p><p>Opening the receipt does not automatically mean your device was compromised. The risk increases if you call the number, share information, install software or follow instructions from the person on the phone.&nbsp;</p><h4>What to do if you have already called&nbsp;</h4><p>End the call.&nbsp;</p><p>If you shared payment details, contact your bank or card provider immediately using the number on your card or inside your banking app. If you gave away a password, change it from a different device if possible. Start with your email account, Apple ID or Google account, banking account and any account connected to the fake invoice.&nbsp;</p><p>If you installed remote access software, disconnect the device from the internet and remove the software. Run a security scan before using the device again for banking, email or shopping.&nbsp;</p><p>If you gave a one-time code to the caller, treat the related account as compromised. Change the password, review recovery options and check recent login activity.&nbsp;</p><h4>The lesson&nbsp;</h4><p>Scammers keep testing new places to put old tricks. For years, fake invoices were mostly an email problem. Then similar subscription notices appeared in calendar invites. Now we are seeing fake receipts inside shopping app order histories and push notification flows.&nbsp;</p><p>The safest response is to separate the alert from the action. If an app, email, text message or calendar invite says you have been charged, do not use the contact details inside that alert. Go directly to the account or payment provider yourself. Check whether the charge exists. Use official support channels.&nbsp;</p><p>The fake receipt, the fake support number and the fake emergency are all part of the same controlled environment. The moment you verify the charge somewhere else, the scam loses most of its power.&nbsp;</p>

Scammers are using order-tracking apps to place fake receipts where users expect to see real purchases, then pushing them to call fake support numbers. 

Fake invoices are moving from inboxes to shopping apps 

Threat Researcher at Gen

<h2>Introduction&nbsp;</h2><p>Infostealers are constantly evolving, and so are the techniques they use to bypass <a href="https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html" target="_blank" rel="noreferrer noopener">Application-Bound Encryption (ABE)</a>. In recent weeks, Vidar has been among the most actively developed stealers and, apart from <a href="https://x.com/GenThreatLabs/status/2064836539952361976" target="_blank" rel="noreferrer noopener">multiple updates to its string obfuscation</a> and <a href="https://x.com/GenThreatLabs/status/2061462524604649840" target="_blank" rel="noreferrer noopener">a reworked approach to protecting its configuration</a>, it has also introduced a novel technique for bypassing ABE. And while there have been many other changes in Vidar lately, with new versions dropping every week, in this blog post we focus solely on the ABE bypass and its technical aspects.&nbsp;<br>&nbsp;</p><h2>The ABE Bypass&nbsp;</h2><p>From a high-level perspective, Vidar’s approach to bypassing ABE is somewhat similar to that of Remus/Lumma, in that both try to extract the <code>v20_master_key</code> directly from the browser’s memory. What sets them apart, however, is how they achieve it. Since we’ve already covered the inner workings of ABE in earlier posts (<a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer" target="_blank" rel="noreferrer noopener">Remus</a>, <a href="https://www.gendigital.com/blog/insights/research/voidstealer-abe-bypass" target="_blank" rel="noreferrer noopener">VoidStealer</a>), we don’t revisit them here and focus instead on the bypass itself. For readers interested in the broader background, we encourage checking those earlier posts.&nbsp;&nbsp;</p><p>In short, the end goal of infostealers is to obtain the <code>v20_master_key</code>, as it alone is sufficient for decrypting any ABE-protected data tied to a specific application. This key can be obtained in one of two ways: either from disk, where it is protected by two layers of <code>CryptProtectData</code> (one applied in the context of the logged-in user and one as <code>NT AUTHORITY\SYSTEM</code>), or from the browser’s memory – the direction Vidar took.&nbsp;</p><p>In memory, however, the key is kept protected with <code>CryptProtectMemory</code> using the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag. This ensures that even if an attacker manages to read the encrypted form of the key from memory, they cannot simply decrypt it (they would need to invoke the complementary <code>CryptUnprotectMemory</code> function directly from within the browser process). That leaves attackers with two problems to solve: how to find the encrypted key in memory, and how to get it decrypted.&nbsp;</p><h2>Locating the v20_master_key in Browser’s Memory&nbsp;</h2><p>Vidar’s approach to locating the encrypted <code>v20_master_key</code> in memory involves scanning the entire memory of a running browser for a specific pattern. But that first requires a browser process to scan.&nbsp;</p><p>When the target browser is already running, Vidar reuses the existing process. However, it doesn’t read its memory directly. Instead, it creates a fork of it using <code>NtCreateProcessEx</code> with <code>SectionHandle</code> set to <code>NULL</code>, instructing the kernel to clone the address space of the process specified by the <code>ParentProcess</code> as a copy-on-write mapping. The resulting process has no threads and is never resumed – it exists purely as a static memory snapshot.&nbsp;&nbsp;</p><p>To perform the fork, Vidar first opens a handle to the target browser via <code>OpenProcess</code> with <code>PROCESS_QUERY_INFORMATION | PROCESS_CREATE_PROCESS | PROCESS_VM_READ</code>, falling back to <code>PROCESS_CREATE_PROCESS</code> if the initial call fails. It then passes this handle as the <code>ParentProcess</code> argument to <code>NtCreateProcessEx</code>, requesting <code>PROCESS_ALL_ACCESS</code> on the resulting child. If the fork fails, Vidar falls back to scanning the live browser process directly.&nbsp;</p>

<p>If no target browser process is found running, Vidar creates a new isolated desktop via <code>CreateDesktopA</code>, assigns it a name of the form <code>v20_%d</code> (where <code>%d</code> is replaced with the browser’s index in Vidar’s configuration), and launches the target browser in there. In the case of Vidar version 2.1, the browser is launched with the command line <code>--no-first-run --disable-gpu about:blank</code>, although the exact command line varies across versions. Since modern browsers use a multi-process architecture, there are typically multiple processes matching a given browser. Vidar enumerates all of them (up to 64) and applies the fork-and-scan procedure to each one independently.&nbsp;</p>

<p>With a handle to the forked process in hand, Vidar proceeds to enumerate its virtual memory regions using <code>NtQueryVirtualMemory</code>. It iterates through the entire browser’s address space, collecting regions that match a specific profile: committed (<code>MEM_COMMIT</code>), private (<code>MEM_PRIVATE</code>), and either readable (<code>PAGE_READONLY</code>) or read-write (<code>PAGE_READWRITE</code>). Vidar records up to 4096 memory regions matching these requirements, along with their base addresses and sizes.<strong> </strong>The actual pattern scanning is then performed in parallel with up to 64 worker threads, depending on the system.&nbsp;&nbsp;</p>

<p>Each thread scans its assigned regions using <code>NtReadVirtualMemory</code>, searching for a 32-byte pattern. When a match is found, the thread reads 8 bytes at offset +32 from the match, interprets them as a pointer, and validates that it points to committed, private, and readable memory (the expected memory state for the encrypted <code>v20_master_key</code>).&nbsp;&nbsp;</p>

<p>This naturally raises the question of what pattern Vidar searches for. The answer is a 32-byte signature: <code>76 32 30 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 03 00 00 00 00 01 ?? ?? ??</code>, where <code>??</code> denotes a wildcard (Vidar uses the byte <code>AA</code> as the wildcard marker in its internal representation). Notably, the first four bytes correspond to the ASCII <code>v20\x00</code>, which is a common prefix used for ABE-related data.&nbsp;&nbsp;</p>

<p>We assess with high confidence that this pattern is intended to match a node structure within Chromium’s <code>Encryptor::KeyRing</code>, the structure that holds the keys used by the <code>Encryptor</code> class. 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>, <code>std::optional</code>), which is why we frame this as a high-confidence rather than a certainty.&nbsp;&nbsp;</p><p>Our reasoning is as follows: <code>KeyRing</code> is <a href="https://github.com/chromium/chromium/blob/cf5d502bcaedb22927e3829a18be1ff6d8b6f598/components/os_crypt/async/common/encryptor.h#L132" target="_blank" rel="noreferrer noopener">defined</a> as <code>std::map&lt;/*tag=*/std::string, std::optional&lt;Key&gt;&gt;</code>, and <code>std::map</code> is typically implemented as a red-black tree, where each tree node stores three pointers (left child, parent, and right child) followed by the key-value pair. In this case, the pair is in the form of <code>std::pair&lt;/*tag=*/std::string, std::optional&lt;Key&gt;&gt;</code>, meaning that the <code>std::string</code> and the <code>Key</code> object might be laid out consecutively in memory within each node. For a <code>v20_master_key</code> entry, the tag corresponds to the string <code>v20</code>, which at 4 bytes including the null terminator fits within the small string optimization (SSO) buffer and is therefore stored inline rather than heap-allocated. The <code>Key</code> class that immediately follows <a href="https://github.com/chromium/chromium/blob/cf5d502bcaedb22927e3829a18be1ff6d8b6f598/components/os_crypt/async/common/encryptor.h#L93-L98" target="_blank" rel="noreferrer noopener">contains three member variables</a>: <code>std::optional&lt;mojom::Algorithm&gt; algorithm_</code>, <code>std::vector&lt;uint8_t&gt; key_</code>, and <code>bool encrypted_ = false</code>.&nbsp;</p><p>Putting it all together and applying it to a concrete example from a browser memory dump, we get the following layout:&nbsp;</p>

<p>Please note that while the exact layout may contain minor inaccuracies on our part, the overall structure should be roughly correct. For easier orientation, the following diagram illustrates how the individual structures are nested within each other:&nbsp;</p>

<p>At this point, it should be clear how the scan pattern maps onto the searched structure. The 32-byte match covers the <code>std::string</code> tag <code>v20\x00</code> and the beginning of the <code>Key</code> object up to and including <code>algorithm_</code>. The pointer at offset +32 from the start of the match then lands precisely on <code>key_.begin</code>, the first member of <code>std::vector&lt;uint8_t&gt;</code> that holds the encrypted <code>v20_master_key</code>.&nbsp;</p><p>Matches from all threads are collected into a shared buffer and subjected to a majority-voting scheme: candidates consisting mostly of zeroes are discarded, the rest are pairwise-compared, and each is scored by the number of identical copies found. This voting is performed independently for each browser process, producing one best candidate per process.&nbsp;</p><h2>Decrypting the v20_master_key via APC Injections&nbsp;</h2><p>For each browser process that produced a match, Vidar now holds a candidate address pointing to a potential encrypted <code>v20_master_key</code>. However, as already noted, since the key is protected with <code>CryptProtectMemory</code> using <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code>, it can only be decrypted by invoking <code>CryptUnprotectMemory</code> from within the browser process itself. Vidar solves this by injecting an Asynchronous Procedure Call (APC) into the live browser process.&nbsp;</p><p>Vidar supports two APC injection methods, selected based on whether ESET or Bitdefender is detected on the system. If either of these products is present, Vidar uses the first method, which it refers to as “classic” (based on decrypted strings) – it creates a suspended thread in the target browser via <code>CreateRemoteThread</code> (with <code>NtTestAlert</code> as the thread start address and the <code>CREATE_SUSPENDED</code> flag), queues an APC using <code>NtQueueApcThread</code>, resumes the thread, and then waits for it to complete via <code>WaitForSingleObject</code> with a randomized timeout. When the thread resumes, it calls <code>NtTestAlert</code>, which flushes the APC queue and executes the injected routine.&nbsp;</p>

<p>If neither product is detected, it uses the “special” method – it finds an existing thread in the target browser using a combination of <code>CreateToolhelp32Snapshot</code> and <code>Thread32First/Thread32Next</code>, opens it via <code>NtOpenThread</code>, and calls <code>NtQueueApcThreadEx2</code> with the <code>QUEUE_USER_APC_FLAGS_SPECIAL_USER_APC</code> flag. Unlike regular APCs, special user APCs execute immediately. Therefore, the target thread does not need to be in an alertable wait state.&nbsp;</p>

<p>In both cases, the APC routine to be executed is <code>CryptUnprotectMemory</code>, called with the following three arguments: the address of the encrypted <code>v20_master_key</code> candidate, its size (32 bytes), and <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> for the <code>flags</code> parameter.&nbsp;&nbsp;</p><p>Since <code>CryptUnprotectMemory</code> decrypts the data in place, once the APC executes, the key is decrypted directly in the live browser's memory. To read it, Vidar creates a second fork of the browser process and reads the key from the same address using <code>NtReadVirtualMemory</code>. It then compares the result against a snapshot of the encrypted key taken from the first fork before the APC call – if the data is unchanged, decryption failed, and Vidar moves on to the next browser process’s candidate.&nbsp;</p><p>If the data differs, Vidar uses the same second fork to perform an additional verification: it scans the forked process’s memory for the byte sequence <code>v20</code> and, treating each match as a potentially ABE-encrypted entry (cookie, password), attempts AES-256-GCM decryption with the key candidate using <code>BCryptDecrypt</code> (successful GCM tag verification confirms that the key is correct).&nbsp;</p><p>Whenever the data has changed (indicating that decryption of the key took place), Vidar re-encrypts the key in the browser’s memory by injecting another APC with <code>CryptProtectMemory</code> as the routine, preserving the browser’s state. If no candidate produced a successful decryption (i.e., the data remained unchanged after every APC call), Vidar takes a more aggressive approach: it terminates all browser instances, restarts the browser, and repeats the entire scan-decrypt-verify cycle.&nbsp;</p><p>By abusing APC injections instead of the more traditional approach of injecting code via <code>NtWriteVirtualMemory</code> that performs the decryption, Vidar trades one suspicious behavior for another. APC injections are arguably less common and may thus slip past some detection systems, though they are still well-known techniques monitored by AV and EDR solutions. But that is the nature of ABE bypasses – each has its own advantages and disadvantages, and that’s exactly why infostealers keep inventing new ones. &nbsp;</p><h2>Indicator of Compromise (IoC)&nbsp;</h2><p>459daa809751e73f60fbbe4384a7d1653c36bb06945e4eb3635270924241100a (Vidar 2.1)&nbsp;</p>

A Technical Walkthrough of How Vidar Defeats Application-Bound Encryption

Inside Vidar’s ABE Bypass: From Memory Scanning to APC Injections

<p>You have a summer flight booked. You have seen the headlines about jet fuel shortages, cancelled routes and higher travel costs. Then a text message arrives: your flight has been affected, and you need to click a link to confirm your refund or rebook before the offer expires.&nbsp;</p><p>That message feels plausible because the situation around it is real. In April, <a href="https://www.iata.org/en/pressroom/2026-releases/2026-04-17-01/" target="_blank" rel="noreferrer noopener">IATA warned</a> that Europe could start seeing flight cancellations by the end of May if jet fuel shortages materialized. Airlines and governments have since been trying to reassure travelers, while also publishing guidance on passenger rights, refunds and re-routing.&nbsp;&nbsp;</p><p>That is exactly the kind of confusion scammers like. They do not need to cause the disruption, they only need to arrive at the right moment, with the right brand logo and the right sense of urgency.&nbsp;</p><h4>Why travel disruption works so well as a scam hook&nbsp;</h4><p>Most scam messages fail because they arrive out of context. A random refund email from an airline you never use is easy to ignore. A refund message from the airline you are flying with next week, during a period of public travel disruption, is different.&nbsp;</p><p>The scammer’s job is to make you think: “This could be real.”&nbsp;</p><p>That can happen in several ways. You might receive a fake cancellation email that links to a refund form. You might search for an airline’s customer service number and land on a fake support page. You might post publicly on social media asking an airline for help, then receive a reply from an account that looks official. Or you might get a WhatsApp message that knows your hotel name, travel dates or booking reference.&nbsp;</p><p>Each version uses the same pressure point: you are worried about losing money, losing your flight or being stranded.&nbsp;</p><p>Criminals are already using disruption this way. In March, <a href="https://www.theguardian.com/money/2026/mar/15/travel-scam-airline-accounts-fake-refunds-iran-war-flight-disruption" target="_blank" rel="noreferrer noopener">The Guardian reported</a> that fake airline support accounts were targeting travelers affected by Middle East flight disruption. Some victims were looking for help or refunds, then received replies from accounts pretending to represent airlines. The scam moved into direct messages, where victims were asked for details and sent links that led to money being taken instead of refunded.&nbsp;&nbsp;</p><p>The jet fuel story gives scammers another pretext. A message can claim that your flight was cancelled, your fare changed, your fuel surcharge failed, or your refund must be claimed within a few hours. None of those claims needs to be true to be effective.&nbsp;</p><h4>The scam may start before the message arrives&nbsp;</h4><p>A fake travel message becomes much harder to spot when it includes real information.&nbsp;</p><p>This is the idea behind <a href="https://www.gendigital.com/blog/insights/research/reservation-hijack-scam" target="_blank" rel="noreferrer noopener">Reservation Hijack scams</a>, a form of targeted phishing where cybercriminals use real booking details to make a message look legitimate. In some cases, attackers may use information exposed through breaches or compromised travel systems. In other cases, they collect details from emails, social media posts, previous leaks or fake customer service interactions. Gen has previously described Reservation Hijack scams as scams that use real hotel booking details to make fraudulent payment or verification requests feel authentic.&nbsp;&nbsp;</p><p>That distinction matters. A scam message does not need your credit card number to fool you. Knowing your name, your destination, your travel dates and your booking platform may be enough.&nbsp;</p><h4>What these scams can look like&nbsp;</h4><p>A travel disruption scam usually does not begin with a strange offer. It begins with something boring and administrative. That is part of the trick.&nbsp;</p><p>You may see messages like:&nbsp;</p><p>“Your flight has been cancelled due to fuel supply issues. Claim your refund here.”&nbsp;</p><p>“Your rebooking is pending. Confirm passenger details within two hours.”&nbsp;</p><p>“Additional airport tax or fuel surcharge is required to keep your booking.”&nbsp;</p><p>“Your hotel reservation will be cancelled unless payment is verified.”&nbsp;</p><p>“Due to high call volume, please continue this request on WhatsApp.”&nbsp;</p><p>The exact wording changes, but the structure is familiar. There is a problem, a deadline and a link. The message may also move you away from the official channel into SMS, WhatsApp, Telegram, direct messages or a phone call. Once that happens, the scammer controls the conversation.&nbsp;</p><p>There is another detail worth watching: some messages do not ask for money immediately. They start by asking for your booking reference, last name, phone number or one-time password. That can still be dangerous. Those details can help scammers access a booking, impersonate you to customer support, reset an account or make the next message more convincing.&nbsp;</p><h4>Your real passenger rights can be used against you&nbsp;</h4><p>If an airline cancels your flight, you may have rights to a refund, re-routing or assistance, depending on where you are travelling and the rules that apply. The European Commission said passengers affected by cancellations continue to have rights to reimbursement, re-routing or return, airport assistance and compensation for last-minute cancellations in relevant circumstances. It also said airlines cannot retroactively add fuel surcharges to already published final ticket prices.&nbsp;&nbsp;</p><p>That information is useful for travelers, but it is also useful for scammers.&nbsp;</p><p>A fake refund message becomes more believable when people already know refunds are possible. A fake rebooking link becomes more believable when airlines are genuinely changing schedules. A fake “fuel surcharge” demand becomes more dangerous when fuel prices are in the news, even though legitimate retroactive charges may not be allowed in many cases.&nbsp;</p><p>This is why the safest route is not to judge the message only by whether the story sounds plausible. During travel disruption, many scam stories will sound plausible. Judge the channel instead.&nbsp;</p><h4>How to check before you click&nbsp;</h4><p>Start from the airline or booking platform’s official app or website. Do not use the link in the message. Open the app yourself, type the website address yourself, or use the contact details listed on your original booking confirmation.&nbsp;</p><p>Check whether the same cancellation, refund or payment request appears inside your account. If the message is real, the airline or hotel should be able to confirm it through an official channel.&nbsp;</p><p>Be careful with social media support. If an account replies to your public complaint, check whether it is linked from the airline’s official website. Look at the handle carefully. Fake support accounts often copy logos and names, but have small differences in spelling, low follower counts or recently created profiles. The Guardian reported that fraudsters often scan social media for passengers trying to contact legitimate airline accounts and reply to them first, which makes the scam harder to spot.&nbsp;&nbsp;</p><p>Do not share one-time passwords, payment card details or login credentials with anyone who contacts you unexpectedly. A real airline or hotel does not need your banking OTP to send you a refund.&nbsp;</p><p>Be especially suspicious of pressure. “You have 30 minutes to claim your refund” is not customer service. It is a tactic.&nbsp;</p><h4>What to do if you already clicked&nbsp;</h4><p>If you entered payment details, contact your bank or card provider immediately. Ask whether the transaction can be blocked or reversed, and request a new card if needed.&nbsp;</p><p>If you shared login details for an airline, hotel or booking platform, change the password from the official site or app. Use a unique password, not one you use elsewhere. Turn on two-factor authentication where it is available.&nbsp;</p><p>If you shared a one-time password or authentication code, assume the account may have been accessed. Check your booking details, payment methods and recent account activity.&nbsp;</p><p>Report the scam to the airline, hotel or booking platform being impersonated. If the scam came through social media, report the account as impersonation. If money was taken, report it to the relevant fraud authority in your country.&nbsp;</p><h4>The real lesson for summer travel&nbsp;</h4><p>Travel disruption changes how people behave. They search for support numbers in a hurry. They post publicly because customer service queues are long. They accept strange instructions because they are worried about losing a flight or refund.&nbsp;</p><p>Scammers build around that behavior.&nbsp;</p><p>The safest assumption is simple: if a message about your flight, hotel or refund creates urgency and gives you a link, pause. Go back to the official source. A real cancellation will still be there when you check through the airline or booking platform. A scammer needs you to act before you do.&nbsp;</p>

Travel disruption gives scammers the one thing they need most: a believable reason to rush you

Your flight was cancelled. Is the refund message real? 

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

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

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

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

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

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

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

Threat Research Team Lead

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

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

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

Who's Really Using Your Home Internet Connection?

<h2><strong>Key Points</strong></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><strong>Introduction&nbsp;</strong></h2><p>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;</p><p>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;</p><p>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;</p><p>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;</p><h5><strong>Living Off the Land: Vulnerable Drivers Edition&nbsp;</strong></h5><p>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;</p><h6><strong>N-Day BYOVD Exploits&nbsp;</strong></h6><p>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;</p><h6><strong>Zero-Day BYOVD Exploits&nbsp;</strong></h6><p>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;</p><h6><strong>Beyond BYOVD&nbsp;</strong></h6><p>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;</p><p>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;</p><p>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;</p><p>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;</p><h2><strong>CVE-2024-21338&nbsp;</strong></h2><p>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 <em>smart hash</em> 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;</p><p>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;</p><p>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;</p>

<p>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;</p><p>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;</p><p>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 <em>local service-to-kernel</em> rather than <em>admin-to-kernel</em>. 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;</p>

<p>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;</p><p>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;</p><p>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;</p>

<p>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;</p><h4><strong>Exploitation&nbsp;</strong></h4><p>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;</p>

<p>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;</p><p>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;</p>

<p>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;</p><p>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;</p><p>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;</p><p>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;</p><h2><strong>The FudModule Rootkit</strong></h2><p>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;</p><p>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;</p><p>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;</p>

<p>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;</p><p>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;</p><h6><strong>Debug Prints&nbsp;</strong></h6><p>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;</p><p>As an example, let us mention the string <code>get rop function addresses failed</code>. Assuming <em>rop</em> stands for <em>return-oriented programming</em>, 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;</p>

<p>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 <em>vaccine</em> 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 <em>antivirus</em> (바이러스 백신), a compound word with the literal meaning <em>virus vaccine</em>. 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 <em>vaccine</em> 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;<br>&nbsp;<br><code>cmd.exe /U /c wmic /namespace:\\root\securitycenter2 path antivirusproduct get displayname &gt; vaccine.txt</code></p><p>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;</p><p>Finally, there is also the debug message <code>disableV3Protection passed</code>. Judging from the context, the rather generic term <em>V3</em> here refers to <em>AhnLab V3 Endpoint Security</em>. 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;</p><h4 id="techniques"><strong>0x01 – Registry Callbacks&nbsp;</strong></h4><p>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;</p><p>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;</p><p>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;</p><p>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;</p><h4><strong>0x02 – Object Callbacks&nbsp;</strong></h4><p><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;</p><p>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;</p><p>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;</p><h4><strong>0x04 – Process, Thread, and Image Kernel Callbacks&nbsp;</strong></h4><p>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;</p><p>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;</p><p>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;</p><p>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;</p>

<h4><strong>0x08 – Minifilter Drivers&nbsp;</strong></h4><p><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;</p><p>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;</p><p>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;</p>

<p>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;</p>

<p>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;</p><h4><strong>0x10 – Windows Filtering Platform&nbsp;</strong></h4><p><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;</p><p>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;</p><p>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;</p>

<p>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;</p><h4><strong>0x20 – Missing&nbsp;</strong></h4><p>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;</p><h4><strong>0x40 – Event Tracing for Windows: System Loggers</strong></h4><p><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;</p><p>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;</p><p>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;</p><p>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;</p>

<h4><strong>0x80 – Event Tracing for Windows: Provider GUIDs&nbsp;</strong></h4><p>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;</p><p>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;</p><p>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;</p><p>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;</p><p>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;</p>

<p>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;</p><h4><strong>0x100 – Image Verification Callbacks&nbsp;</strong></h4><p>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;</p><p>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;</p><p>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;</p><h4><strong>0x200 – Direct Attacks on Security Software&nbsp;</strong></h4><p>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;</p><p>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;</p><p>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;</p><h6><strong>Handle Table Entry Manipulation&nbsp;</strong></h6><p>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;</p><p>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;</p><p>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;</p><p>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;</p>

<p>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;</p><p>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;</p>

<p>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;</p><p>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;</p><h2><strong>Conclusion&nbsp;</strong></h2><p>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;</p><p>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;</p><h4><strong>Indicators of Compromise (IoCs)&nbsp;</strong></h4><p>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>.</p>

Zero-Day Exploit Powers Advanced Rootkit

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

<p>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.</p><p>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.</p><p>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.</p>

<h2><strong>Background</strong></h2><p>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.</p><p>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 <em>Warcraft III: The Frozen Throne</em>. 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.</p><p>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.</p><p>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.</p><h2><strong>Just Testing</strong></h2><p>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.</p>

<p>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;</p><p>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;</p><p>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.</p>

<p>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;</p>

<p>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:</p><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>

<p>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.</p><h2><strong>The Backdoor</strong></h2><p>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;</p><p>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).</p>

<p>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).</p><p>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>.</p>

<p>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.</p>

<p>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.</p><h2><strong>Parting Thoughts</strong></h2><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><h3><strong>Indicators of Compromise (IoCs)</strong></h3>

Exploiting V8 in Popular Games

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

<p>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;</p><p>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.</p><p>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;</p><p>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.</p>

<p>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.</p><h2><strong>Overview</strong></h2><p>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;</p><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>

<p>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.</p>

<h2><strong>The Bag of Tricks</strong></h2><p>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.</p><h4><strong>Segment registers</strong></h4><p>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.</p>

<p>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.</p><p>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.</p><p>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.</p><h4 id="ntdll_gadgets"><strong>APC injection through a random ntdll gadget</strong></h4><p>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>.</p><p>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;</p>

<p>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.</p><h4><strong>Checking read/write performance on write-combined memory</strong></h4><p>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.</p><h4 id="shellcode_hiding"><strong>Hiding shellcode from plain sight</strong></h4><p>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;</p>

<p>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;</p>

<h4><strong>Ret2Kernel32</strong></h4><p>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.</p><p>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.</p>

<h4><strong>MulDiv bug</strong></h4><p><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.</p><p>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>.</p><h4><strong>Tampering with return addresses stored on the stack</strong></h4><p>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;</p><p>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.</p><h4><strong>Exception-based checks</strong></h4><p>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.</p><p>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.</p><p>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;</p>

<p>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.</p><p>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.</p><h4><strong>Large executable mappings</strong></h4><p>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>).</p>

<p>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.</p><h4><strong>Detecting process suspension</strong></h4><p>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.</p><h4 id="indirect_registry"><strong>Indirect registry writes</strong></h4><p>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.</p><p>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;</p><h4><strong>Checking VBAWarnings</strong></h4><p>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.</p><h4><strong>Command line wiping</strong></h4><p>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.</p>

<h4><strong>Additional tricks</strong></h4><p>Aside from the techniques described so far, Roshtyak uses many less sophisticated tricks that are commonly found in other malware as well. These include:</p><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><strong>Obfuscation</strong></h2><p>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;</p><p>In the rest of this section, we’ll go through the main obfuscation techniques used by Roshtyak.</p>

<h4><strong>Control flow flattening</strong></h4><p>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;</p><p>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>.</p><p>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;</p><p>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.</p>

<h4><strong>Function activation keys</strong></h4><p>Roshtyak’s obfuscated functions expect an extra argument, which we call an <em>activation key</em>. 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.</p><p>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.</p><p>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.</p><p>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.</p><h4><strong>Variable masking</strong></h4><p>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.</p><h4><strong>Loop transformations</strong></h4><p>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.</p><h4><strong>Packing</strong></h4><p>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.</p><p>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.</p>

<h4><strong>Other obfuscation techniques</strong></h4><p>In addition to the above-described techniques, Roshtyak also uses other obfuscation techniques, including:</p><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><strong>Core Functionality</strong></h2><p>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.</p><h4><strong>Persistence</strong></h4><p>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>.</p><p>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:</p><p><code>RUNDLL32.EXE SHELL32.DLL,ShellExec_RunDLL REGSVR32.EXE -U /s "C:\Windows\Temp\wcdp.etl."</code></p><p>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.</p><p>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>.</p>

<h4><strong>Privilege escalation</strong></h4><p>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.</p><p>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.</p><p>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>.</p><p>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:</p>

<p>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.</p>

<p>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.</p><p>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.</p><h4><strong>Lateral movement</strong></h4><p>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.</p><p>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;</p><p>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>.</p><p>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;</p>

<p>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>).</p><p>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>.</p><h4><strong>Profiling the victim</strong></h4><p>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.</p><p>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.</p><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><strong>Beaconing</strong></h4><p>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.</p><p>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.</p><p>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.</p>

<p>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.</p><p>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.</p><p>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).</p><p>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).</p><h2><strong>Conclusion</strong></h2><p>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.</p><p>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.</p><h3><strong>Indicators of Compromise (IoCs)</strong></h3><p>IoCs are available at&nbsp;<a href="https://github.com/avast/ioc/tree/master/RaspberryRobin">https://github.com/avast/ioc/tree/master/RaspberryRobin</a>.</p>

Innovative Evasion Techniques in Roshtyak

Raspberry Robin’s Roshtyak: A Little Lesson in Trickery

<p>Many applications can be updated automatically and without any user interaction. This is commonly considered a good practice from the security point of view, since it allows for quick distribution of patches for critical vulnerabilities. However, automatic updates also carry an additional risk because they allow the software developers to push arbitrary code to users’ machines. Unfortunately, users often have no choice but to trust the developers that they will only use the update channel for its intended purpose and that they will protect it from malicious third parties.</p><p>In this blog post, we’ll show that this trust might sometimes be misplaced. Specifically, we’ll show how one torrent client and three adblockers surreptitiously installed the FakeMBAM backdoor through automatic updates. We reverse engineered this backdoor and describe its inner workings in the second part of this post.</p><h2><strong>An unexpected infection vector</strong></h2><p>We recently <a href="https://blog.avast.com/fake-malwarebytes-installation-files-distributing-coinminer">reported on a fake Malwarebytes installer</a> that we detected on over 100,000 machines protected by Avast. This installer attempted to pass itself off as the legitimate Malwarebytes installer, mimicking it to a great extent – it was distributed under the same filename, it used the same icon and it created a Malwarebytes installation directory containing legitimate PE files digitally signed by Malwarebytes. However, that was all just a pretense, because the installer did not actually install Malwarebytes. In fact, the installer’s main purpose was to open a backdoor to attacker-controlled servers in order to give its operators the ability to push additional malicious payloads to the infected machines.&nbsp;</p>

<p>In our first report, we stated that we did not know how this fake installer was being distributed. Since then, we spent some time reverse engineering the malware and investigating its infection vector. We found that the fake installer was pushed to the victims’ machines through automatic updates of one torrent client (<code>download[.]studio</code>) and three adblockers (<code>netshieldkit[.]com</code>, <code>myadblock[.]com</code> and <code>netadblock[.]com</code>). Listed on the websites of these applications are three different companies that are supposedly behind these applications, “Sigma Software”, “GRAND MEDIA, TOV” and “Birmon Software”. However, based on high code similarities and shared infrastructure (and on the fact that they all distributed the very same piece of malware), we consider it very likely that there is one actor behind all four applications.&nbsp;</p><h3><strong>Download Studio</strong></h3><p>To investigate the infection vector used to distribute the fake installer, we first turned to the metadata that was submitted to us when we detected the installer in the wild. This provided us with two important clues: The installers were supposed to be executed with the command line arguments <code>/SP- /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /NOCANCEL /NOICONS</code>, by a process named <code>dstudio-gui.exe</code>. The first clue suggested that the installer was not supposed to be spread through social engineering, because the above arguments instruct Inno Setup to install software silently in the background. The second clue hinted at the possible suspect: Download Studio.</p>

<p>Download Studio is a free torrent client popular in Russia and Ukraine. It features an embedded library of torrent files, offering a wide selection of movies, software, video games, music and more. As is usually the case with torrent downloaders, there is a lot of copyrighted material that can be easily downloaded for free using this software, which seems to be the main reason why it is so widespread. Download Studio is detected by some anti-malware software as a potentially unwanted program (PUP) or as riskware, because it encourages illegal behavior and puts its users at risk through downloading torrents of unknown origin.</p>

<p>To clear up some potential confusion, let us state that there is also another piece of software named Download Studio: <a href="http://www.conceiva.com/products/downloadstudio/default.asp">a download manager developed by Conceiva</a>. Apart from the name, this software has nothing in common with the torrent client described in this blog post and there is therefore no reason to doubt its legitimacy. In the rest of this blog post, the name Download Studio will denote the torrent client described in the previous paragraph.</p><p>Since Download Studio can be used to download various software, it would make sense to think that the fake Malwarebytes installer was distributed through it as a regular torrent file (after all there were 609 results when we searched for “Malwarebytes” inside Download Studio). However, that would not explain the command line arguments that we observed in the wild. They simply indicated that running the installer was not a user-initiated action and that the user might not have been aware of the installer at all. Furthermore, the number of users that we protected from the fake installer matched our estimates of the number of Avast users running Download Studio, which made it look like Download Studio itself was somehow responsible. Therefore, we decided to reverse engineer it to see if it contained hidden malicious code.&nbsp;</p><p>We immediately found some evident code similarities with the FakeMBAM backdoor. Both Download Studio and the backdoor were developed using the Qt framework and they both used the very same string obfuscation methods. One of the obfuscation methods was particularly interesting, because it was not very effective at, well, obfuscation. It consisted of XORing the obfuscated string twice with the same mask, so the plaintext was clearly visible in the disassembly.</p>

<p>Other code similarities were found in a piece of code that computed HMAC of custom HTTP headers or in a piece of code that created scheduled tasks using the <code>ITaskService </code>COM interface. We also found that Download Studio contained a string with the exact command line arguments that we mentioned earlier. These arguments were used to execute application updates silently in the background. By reverse engineering Download Studio, we also found that the application updates are supposed to be executed from a temporary directory the name of which can be described by the regular expression <code>ds-\d{7}\.tmp</code>, which further matched our metadata from detections of the fake installer.</p>

<p>At this point, it seemed almost certain that the backdoor was distributed through the automatic updates of Download Studio. However, we wanted to be absolutely sure that this was the case, so we monitored the updates and logged the filename and hash of each observed update. This gave us the following list:</p><p><br>&nbsp;</p>

<p>Just based on the filenames alone, the last two entries immediately stand out. Indeed, while all the previous entries correspond to legitimate updates of Download Studio, the last two hashes are the fake Malwarebytes installers that we have been investigating. They were executed in the same way as all the other automatic updates, silently in the background and without the users’ awareness.&nbsp;</p><p>This means that someone tried to infect all users of Download Studio with the FakeMBAM backdoor. While we do not know precisely what happened behind the scenes, there are three possible scenarios that come to mind. The first one would be that the developers of Download Studio wished to “monetize” their large install base in a very unethical way. Code reuse between Download Studio and the FakeMBAM backdoor would suggest that this could be the case. Another explanation is that the backdoor was spread by a group of rogue employees who acted without the knowledge of the rest of the company. Finally, it is also possible that some unknown attacker hacked Download Studio and carried out a successful supply chain attack.</p><p>We were looking for some answers and so we reached out to the developers of Download Studio, asking about the backdoor. They claimed that they detected a security incident on their continuous integration server in August 2020 and that they have since thoroughly investigated this incident and put additional security measures in place. They did not respond to our additional inquiries about how many of their users could be impacted by this incident and if they notified the impacted users.</p><h3><strong>Adblockers</strong></h3><p>Download Studio was not the only software that distributed the FakeMBAM backdoor. We also found three adblockers whose automatic updates were abused in the same fashion. These adblockers are NetShield Kit (<code>netshieldkit[.]com</code>), My AdBlock (<code>myadblock[.]com</code>) and Net AdBlock (<code>netadblock[.]com</code>).</p>

<p>While these adblockers are being advertised as three different products, they are almost the same under the hood. The ad blocking itself is implemented in Golang, using the open-source <a href="https://github.com/pmezard/adblock">adblock package</a>. The websites offering downloads of the individual adblockers also look very similar and are even hosted from the same IP address (<code>62.112.11[.]43</code>). It seems like two more adblockers might be launched in the future, since <code>adblockpro[.]net</code> and <code>adblockfree[.]com</code> also resolve to this IP address.&nbsp;</p>

<p>We also identified code similarities between the adblockers and Download Studio, which suggests that they were developed by the same group. What’s more, some installers of Download Studio also present an opt-out offer to install My AdBlock.</p>

<p>Same as with Download Studio, we do not know if the primary purpose of these adblockers is to spread malware. But if this is a supply chain attack or an action of rogue employees, it would be hard to explain why the domain <code>bitminer[.]tech</code> (which hosted XMRig-based coinminers not unlike the ones distributed by the FakeMBAM backdoor) used to resolve to the same IP address as the websites of these adblockers. Also very suspicious-looking is the FAQ section on the NetShield Kit website.</p>

<p>There might be another “catch” that is not mentioned in this answer.</p><h2><strong>Analysis of the FakeMBAM backdoor</strong></h2><p>Now that we’ve shown how the fake Malwarebytes installer is delivered to its victims, let’s examine what it actually does. When the malicious installer is executed, it creates a fake Malwarebytes installation directory where it hides the FakeMBAM backdoor. This directory is made to look identical to the legitimate Malwarebytes installation directory, the only difference being one added malicious DLL file, one maliciously modified DLL file and a new <code>data.pak</code> file containing random-looking data.</p>

<p>Even though the fake installer is supposed to be executed silently in the background, the malware authors still tried to make it appear as if it is the legitimate Malwarebytes installer, in an attempt to fool anyone who would actually analyze it. However, there are still some noticeable differences. First of all, unlike the legitimate installer, the fake installer is not digitally signed. The fake installer was also created using Inno Setup, which makes it look different than the legitimate Malwarebytes installer. The default installation directory varies slightly as well. While the fake installer installs itself into <code>%ProgramFiles%\Malwarebytes</code> (or <code>%ProgramFiles(x86)%\Malwarebytes</code> on 64-bit Windows), the legitimate Malwarebytes usually gets installed to <code>%ProgramFiles%\Malwarebytes\Anti-Malware\</code>. This distinction was probably introduced deliberately by the malware authors, who wanted to avoid a clash between the malware and the legitimate Malwarebytes.</p><p><br>&nbsp;</p>

<p>Packed inside the fake installer are all the usual PE files that one would expect in a Malwarebytes installation directory. All of those except for the two malicious DLLs are validly signed by either Malwarebytes or Microsoft. The first of the two malicious DLL files is called <code>Qt5WinExtras.dll</code>. As the name suggests, it is part of the <a href="https://www.qt.io/">Qt framework</a> and a DLL with the same name can also be found in a legitimate Malwarebytes installation. This malicious DLL file looks almost the same as the legitimate <code>Qt5WinExtras.dll</code>, the only important difference is in the function <code>setCurrentProcessExplicitAppUserModelID</code>, where the malware authors inserted a call to a function exported from <code>Qt5Help.dll</code>.&nbsp;</p>

<p><code>Qt5Help.dll</code> is the other malicious DLL file. Unlike <code>Qt5WinExtras.dll</code>, a file named <code>Qt5Help.dll</code> cannot be found in a legitimate Malwarebytes installation directory. This DLL file was added by the cybercriminals and it implements the actual backdoor functionality. Note that the main Malwarebytes executable, <code>mbam.exe</code>, imports <code>Qt5WinExtras.dll</code> and calls the exported function <code>setCurrentProcessExplicitAppUserModelID</code>. As described above, <code>Qt5WinExtras.dll</code> in turn imports <code>Qt5Help.dll</code> and calls a function that exposes the malicious functionality. This means that running the legitimate <code>mbam.exe</code> executable while having these two DLL files planted in the same directory will inevitably pass the control flow to the FakeMBAM backdoor that’s hidden in <code>Qt5Help.dll</code>.</p><p>The installation process of Inno Setup executables is guided by their setup scripts. These scripts are compiled inside the installers, but they can be extracted and decompiled. The script embedded in the fake Malwarebytes installer is relatively simple. First, it copies all the files that are packed inside the installer into the installation directory. Then, it creates some registry values, among others <code>HKLM\SOFTWARE\Malwarebytes\LicenseKey</code>, where a random-looking hexadecimal string gets stored. As we’ll see later, this string is read by <code>Qt5Help.dll</code> and it contains the malware’s initial configuration, in an encrypted form. Next, <code>mbam.exe</code> is added to the Windows Firewall’s exclusions. Finally, <code>mbam.exe</code> gets executed with the command line argument <code>/install</code>. As was already mentioned, this is the legitimate <code>mbam.exe</code>, digitally signed by Malwarebytes. Due to the way the malicious DLL files have been planted in the same directory, it will inevitably load and execute the main malicious payload, which is hidden inside <code>Qt5Help.dll</code>.</p>

<h3><strong>Qt5Help.dll</strong></h3><p><code>Qt5Help.dll</code> is responsible for the backdoor’s persistence, configuration updates and delivery of additional payloads. It was developed using the Qt framework and it uses functionality provided by the framework for cryptographic operations, as well as for interaction with the underlying operating system. Only basic obfuscation is used – most noticeable are encrypted strings, which get constructed on the stack and are decrypted at run-time using elementary obfuscation methods, such as a simple XOR cipher with a one-byte key.&nbsp;</p>

<p>Specific actions performed by <code>Qt5Help.dll</code> are determined by the command line arguments. If the current process was spawned with the <code>/install</code> argument, <code>Qt5Help.dll</code> will create a new service designed to automatically start <code>mbam.exe</code> during system startup. If <code>/remove</code>, <code>/start</code> or <code>/stop</code> were passed on the command line, this service will get deleted, started or stopped, respectively.&nbsp;</p><p>If there are no command line arguments, <code>Qt5Help.dll</code> assumes that it is already being executed in a service process and calls <code>StartServiceCtrlDispatcher</code>. As mentioned above, the Inno Setup script initially executes <code>mbam.exe</code> with the <code>/install</code> command line argument. This installs the service and immediately starts it. The service name of the newly created malicious service is <code>MBAMSvc</code> and the display name is <code>Malwarebytes Service</code>. The legitimate Malwarebytes service is named <code>MBAMService</code>, so this can be seen as yet another attempt to mimic Malwarebytes without actually choosing a conflicting service name.</p>

<p>When the malware is executed as a service, it enters an infinite loop where it polls the <a href="https://decoded.avast.io/janvojtesek/fakembam-backdoor-delivered-through-software-updates/#cnc">C&amp;C server</a> for configuration updates. The malware’s configuration is saved as an encrypted hexadecimal string in the registry, under <code>HKLM\SOFTWARE\Malwarebytes\LicenseKey</code> (or <code>HKLM\SOFTWARE\Wow6432Node\Malwarebytes\LicenseKey</code> on 64-bit Windows). The configuration can be decrypted using AES in CTR mode with the key <code>cefd8928fd7411b4c9cef7ec35cc827c</code> and the IV <code>260743d9b464883ecc7f144bfa06e36d</code> (as can be seen in <a href="https://gchq.github.io/CyberChef/#recipe=AES_Decrypt(%7B&amp;apos;option&amp;apos;:&amp;apos;Hex&amp;apos;,&amp;apos;string&amp;apos;:&amp;apos;cefd8928fd7411b4c9cef7ec35cc827c&amp;apos;%7D,%7B&amp;apos;option&amp;apos;:&amp;apos;Hex&amp;apos;,&amp;apos;string&amp;apos;:&amp;apos;260743d9b464883ecc7f144bfa06e36d&amp;apos;%7D,&amp;apos;CTR&amp;apos;,&amp;apos;Hex&amp;apos;,&amp;apos;Raw&amp;apos;,%7B&amp;apos;option&amp;apos;:&amp;apos;Hex&amp;apos;,&amp;apos;string&amp;apos;:&amp;apos;&amp;apos;%7D)JSON_Beautify(&amp;apos;%20%20%20%20&amp;apos;,false)&amp;input=OWRlZTI3MjY0YjUyNGY4N2ZjMTA5MDUyYTU4OTg1NmNiMzgwMjRkOTM5ZTg4ZGRjYWUwMjdmODIyM2NkNzdiYjAzZmQwZWMwMzU0YTQ0OWE4Zjk5ZDhjZDFhZjI3NGY0ZDVmNTE1NDQwYmRkYWMzZTUwYmE2MjgzMjkxYzQ3MDVlMTBiYjBjZjgwODlmNTNhMGZhNDY3NzBmODMyMmE0NTU2YmQ4MTRiNDNlZGQ1ZmM2ODI4ZDg4NWQzYWYxNjYzMGQxMTNhMjEyYzdhNzViYmYxYjM2ZjQxNDZmNDEyNDcyYjZmY2ExZWJiOTkzMWUzNzBmNjQyNzMwMDc1MjJlOGE5ODM3Y2UyMDFmYzFiOWI4NTMxZmRmODE3MGEyZjE5ZTkxNzYzNTc3NmQ2ZTYxZTkzMzcyNzM4ODE5YmMxZTViZjZiMzc2ODIyZjcyZDEzYTRhZTdjMzZhZDAwZDMzZGQ3YjEwOGM5NWJlMDYwYTdmYWUyNjU0ZDRlMGI1M2ViMWU5MWY5M2FhMmI2OGNlMjFkYTdmNDJhYjc0YmMyMjExOTQ2MmQ2MzAyMTM1NTEyODdjMWU1NDA2OGFhNzVlYjYxMDc3MDJiNDJkZDRhOWFjY2JiYjI3Nw">this CyberChef recipe</a>). The key and IV are generated as MD5 digests of the hard-coded strings <code>MGZ_th#l}{JmC^!:4525719127089151290</code> and <code>?0@1!elVN]9L.)2.</code> respectively, which means that they are the same for all victims.</p>

<p>Configuration updates are performed via HTTP GET requests using custom HTTP headers. The malware makes requests containing the <code>X-Build-ID</code> and <code>X-Build-Sign</code> headers, where <code>X-Build-ID</code> is set to the malware’s build number concatenated with the MD5 hexadecimal digest of the encrypted payload configuration (will be described later) and <code>X-Build-Sign</code> is set to the <a href="https://gchq.github.io/CyberChef/#recipe=HMAC(%7B&amp;apos;option&amp;apos;:&amp;apos;Latin1&amp;apos;,&amp;apos;string&amp;apos;:&amp;apos;JXaZy7brRJ&amp;apos;%7D,&amp;apos;SHA256&amp;apos;)&amp;input=MS5jZjA0YTdhOWM2N2ZhOGJhNTlkYWY4NmU3YjlmNDUyYQ">HMAC-SHA256 authentication code of the X-Build-ID header</a> computed using the hard-coded key <code>JXaZy7brRJ</code>. The C&amp;C server checks the HMAC’s validity and returns the <code>404 (Not Found)</code> response code if it is invalid. Otherwise, if the signature is valid, the C&amp;C server responds with the <code>204 (No Content)</code> status code. However, this doesn’t mean that the C&amp;C server does not send back any data. It simply means that the response body is empty. The actual response from the C&amp;C server is encoded in the custom <code>X-Payload</code> HTTP response header. When the malware sees such a header, it updates its configuration with the header’s decrypted content.</p>

<p>The decrypted configuration is a JSON string that contains up to five keys in the top-level object. The following keys are supported by the malware:</p><p><br>&nbsp;</p>

<h3><strong>Persistent payloads</strong></h3><p>The FakeMBAM backdoor might also drop some persistent payloads, which it will reinstall in regular intervals in case they get removed or terminated. So far, the only persistent payloads we have seen were cryptocurrency miners, but the malware is able to handle multiple persistent payloads at the same time, so other malicious payloads may be added in the future.</p><p>Persistent payloads are stored encrypted in a file named <code>data.pak</code>, located in the fake Malwarebytes installation directory. Decryption can be performed using AES in CTR mode using the same key and IV as for decrypting the configuration. When decrypted, the <code>data.pak</code> file should start with the magic bytes <code>71 72 65 73</code> (<code>qres</code>), which identifies the file format: <a href="https://github.com/qt/qtbase/blob/315257eabea010bf697415cdc0f6ec1e29b74d2b/src/corelib/io/qresource.cpp">Qt binary resource</a>. This is basically a custom archive format that can be unpacked using API functions provided by the Qt framework.</p><p>The <code>data.pak</code> archive always contains a file named <code>config.json</code>, which holds the payload configuration. In the example <code>config.json</code> shown below, there is only one payload, named <code>app5</code>. To install this payload, the malware first extracts all the files from the <code>app5</code> directory in the <code>data.pak</code> archive into <code>payload['path']</code> (<code>C:\ProgramData\VMware\VMware Tools\</code> in this case). Then, it performs several setup actions based on the values of <code>payload['type']</code> and <code>payload['pre']</code>, which will be explained later. When all the setup actions are finished, the backdoor executes the file specified as <code>payload['file'][0]</code> while passing it <code>payload['file'][1]</code> on the command line. For the example configuration shown below, the command line of <code>"C:\ProgramData\VMware\VMware Tools\vm3dservice.exe" /detach</code> would get executed.</p>

<p>The third element of <code>payload['file']</code> specifies the method used to execute the payload. The malware can either run the payload directly by creating a new process, or it can create a one-time scheduled task that will execute the payload in one minute and automatically delete the task afterward. The payload can also be executed either in the security context of the malicious service or with lower privileges. To lower the privileges, the malware attempts to steal the access token of an active user and to execute the payload with the stolen token. There are several techniques used to steal the token, for example, using the API functions <code>WTSGetActiveConsoleSessionId</code>/<code>WTSEnumerateSessions</code> together with <code>WTSQueryUserToken</code> or using <code>OpenProcessToken</code> on the <code>explorer.exe</code> process. All in all, there are six methods in which the persistent payload can be executed:</p>

<p>The <code>payload['type']</code> configuration parameter allows the malware to perform some custom actions based on the type of the payload. Currently, there is only one custom action specified and it is performed only if <code>payload['type']</code> equals <code>1</code>. If that is the case, the malware searches for a file named <code>config.json</code> inside the current persistent payload and replaces all occurrences of the placeholder <code>{params}</code> with the value of <code>params</code> from the volatile configuration. This is used to specify the mining pool URL in the XMRig config file.</p>

<p>The final configuration parameter left to describe is <code>payload['pre']</code>. This is an array describing various setup actions that the malware is going to perform before actually running the persistent payload. Each action is fully specified by its integer type and a string that should be interpreted in the context of the specific type. Currently, the malware supports three setup action types:</p><p><br>&nbsp;</p>

<h2><strong>Conclusion</strong></h2><p>This blog post reports how cybercriminals abused the update process of Download Studio and three adblockers in an attempt to deliver the FakeMBAM backdoor to hundreds of thousands of victims. It also presents technical analysis of this backdoor, with special attention given to documenting how the malware stores and protects its configuration and what the individual configuration parameters represent. This information should help incident responders deal with this piece of malware. The C&amp;C communication protocol was also documented, which should help create network-based detection rules, as well as implement trackers that would monitor the C&amp;C activity.</p><h3><strong>Indicators of Compromise</strong></h3><p>The full list of IoCs is available at <a href="https://github.com/avast/ioc/tree/master/FakeMBAM">https://github.com/avast/ioc/tree/master/FakeMBAM</a>.</p>

<h4><strong>Download URLs</strong></h4><p><br>&nbsp;</p>

<h4><strong>Miner payloads</strong></h4><p><br>&nbsp;</p>

<h4><strong>Private mining pool IP addresses</strong></h4><p><br>&nbsp;</p>

Jan Vojtěšek

Posts by Jan Vojtěšek

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

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

Raspberry Robin’s Roshtyak: A Little Lesson in Trickery

FakeMBAM: Backdoor delivered through software updates