Malware Researcher

Senior Malware Researcher

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

Security Evangelist at Gen

Threat Operations Analyst at Gen

Research

A fake invoice in your email is easy to ignore. A fake invoice inside your order history feels different.&nbsp;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;That phone number is where the scam really begins.&nbsp;<h4>Why the Shop app makes this more believable&nbsp;</h4>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;

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;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;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;That is not how a normal receipt should look.&nbsp;<h4>The brand is interchangeable&nbsp;</h4>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;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;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;<h4>What we know, and what we do not&nbsp;</h4>We have not found any evidence that any of the impersonated brands have been compromised.&nbsp;&nbsp;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;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;That is enough to warn users without overstating the technical evidence.&nbsp;<h4>How the scam works&nbsp;</h4>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.

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;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;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;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;<h4>Why this is harder for users to judge&nbsp;</h4>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;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;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;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;<h4>What to do if you see one&nbsp;</h4>Do not call the number in the receipt.&nbsp;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;If there is no matching charge, treat the receipt as a scam attempt.&nbsp;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;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;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;<h4>What to do if you have already called&nbsp;</h4>End the call.&nbsp;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;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;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;<h4>The lesson&nbsp;</h4>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;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;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;

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>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; &nbsp;<h2>The ABE Bypass&nbsp;</h2>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;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;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;<h2>Locating the v20_master_key in Browser’s Memory&nbsp;</h2>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;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;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;

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;

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. The actual pattern scanning is then performed in parallel with up to 64 worker threads, depending on the system.&nbsp;&nbsp;

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;

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;

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;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;Putting it all together and applying it to a concrete example from a browser memory dump, we get the following layout:&nbsp;

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;

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;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;<h2>Decrypting the v20_master_key via APC Injections&nbsp;</h2>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;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;

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;

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;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;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;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;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;<h2>Indicator of Compromise (IoC)&nbsp;</h2>459daa809751e73f60fbbe4384a7d1653c36bb06945e4eb3635270924241100a (Vidar 2.1)&nbsp;

A Technical Walkthrough of How Vidar Defeats Application-Bound Encryption

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

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;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;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;<h4>Why travel disruption works so well as a scam hook&nbsp;</h4>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;The scammer’s job is to make you think: “This could be real.”&nbsp;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;Each version uses the same pressure point: you are worried about losing money, losing your flight or being stranded.&nbsp;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;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;<h4>The scam may start before the message arrives&nbsp;</h4>A fake travel message becomes much harder to spot when it includes real information.&nbsp;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;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;<h4>What these scams can look like&nbsp;</h4>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;You may see messages like:&nbsp;“Your flight has been cancelled due to fuel supply issues. Claim your refund here.”&nbsp;“Your rebooking is pending. Confirm passenger details within two hours.”&nbsp;“Additional airport tax or fuel surcharge is required to keep your booking.”&nbsp;“Your hotel reservation will be cancelled unless payment is verified.”&nbsp;“Due to high call volume, please continue this request on WhatsApp.”&nbsp;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;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;<h4>Your real passenger rights can be used against you&nbsp;</h4>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;That information is useful for travelers, but it is also useful for scammers.&nbsp;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;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;<h4>How to check before you click&nbsp;</h4>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;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;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;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;Be especially suspicious of pressure. “You have 30 minutes to claim your refund” is not customer service. It is a tactic.&nbsp;<h4>What to do if you already clicked&nbsp;</h4>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;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;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;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;<h4>The real lesson for summer travel&nbsp;</h4>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;Scammers build around that behavior.&nbsp;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;

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? 

A fake job interview page is easier to trust than a fake ticket shop.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.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.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.

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

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.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.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.The login flow was the clearest part. Credentials were posted to:fifeq2026eqbackeq[.]onrender[.]com/api/loginThe 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.A page can look like it opened a Google login without ever handing control to Google.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;<h4>The recruitment lure went beyond FIFA</h4>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.Researchers found similar fake hiring pages abusing other major brands, including Heineken, Hilton, Coca-Cola, Netflix, PepsiCo, Delta,&nbsp;and Spotify. 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.

Additional hunting found two other recruitment-themed kits:hxxps://aquent-talent-jobs[.]com hxxps://hays-talent-opportunities[.]comThe 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.

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.<h4>Why fake recruitment pages work</h4>Recruitment gives attackers a clean excuse to ask for things that might otherwise raise suspicion.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.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.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.<h4>What job seekers should check before signing in</h4>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.”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.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.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.<h4>What companies can do</h4>Recruitment pages are public by design, which makes them easy to copy.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.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.<h4>Conclusion</h4>The fake FIFA hiring page worked because it did not feel unusual. It looked like a normal step in a hiring process.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.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.IOCs:hxxps://fifahiring[.]com hxxps://careers-fifahiring[.]com hxxps://fifajobs[.]com hxxps://fifa-mg[.]shop hxxps://heineken-careers[.]com hxxps://aquent-talent-jobs[.]com hxxps://hays-talent-opportunities[.]com fifeq2026eqbackeq[.]onrender[.]com/api/login

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

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.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.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.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.Here is how the market works, who pays for it, and what it can cost the household that unknowingly hosts it.<h2>What is a residential proxy</h2>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.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.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.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.<h2>How consumer devices end up in these networks</h2>There are several ways a home device can become part of a residential proxy network. Some are explicit. Others are easy to miss.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.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.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.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.<h2>Why the "consent" is rarely meaningful</h2>Even when consent technically exists, it is often not the kind of consent most people would recognize.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.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.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.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.<h2>The risks consumers actually carry</h2>When a household device becomes a residential proxy node, the user takes on risks created by someone else’s traffic.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.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.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.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.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.<h2>What our telemetry shows</h2>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; 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.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.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.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;

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.<h2>What consumers can do</h2>Most people will not identify a residential proxy component by name. But there are practical warning signs.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.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.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.<h2>The takeaway&nbsp;</h2>With residential proxiesthe user’s connection becomes an infrastructure for someone else’s business.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.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.

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?

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

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

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

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

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

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

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

Magniber ransomware and Lumma stealer are suspected

AliGater: Malvertising chasing users of outdated windows in Europe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Milánek

Posts by Milánek

AliGater: Malvertising chasing users of outdated windows in Europe

GuptiMiner: Hijacking Antivirus Updates for Distributing Backdoors and Casual Mining