Author at Avast Threat Labs

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

Threat Researcher at Gen

Research

<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

Security Evangelist at Gen

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?

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

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

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

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

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

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

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

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers

Despite the substantial risks involved, the irresistible temptation to acquire high-quality software at no cost persists, leading many people to download illegal software. Therefore, distributing such software remains an effective method for widely spreading malware. This analysis reveals that cracked software often contains hidden scripts that deploy attackers’ malware on victims’ computers, sometimes even containing additional malware itself.Our focus is on examining the usage of an <code>AutoHotkey</code> script attached to pre-hacked software. This script triggers the release of a variant of <code>AsyncRAT</code> malware that we’ve named <code>HotRat</code>. However, the first step of the deployment process requires administrative rights. Given that abused software often requires high privileges by default, victims do not find the request for additional permissions suspicious. Furthermore, the deployment process compromises system security by disabling antivirus protections before installing <code>HotRat</code> onto the victim’s machine.<code>HotRat</code> malware equips attackers with a wide array of capabilities, such as stealing login credentials, cryptocurrency wallets, screen capturing, keylogging, installing more malware, and gaining access to or altering clipboard data. Our research underscores the importance of steering clear of unauthorized software downloads and emphasizes the vast risks tied to these actions, including multiple malware infections and the potential leak of sensitive information. We advise sourcing software from legitimate and approved providers as it ensures safety, legality, and continuous support. Users should also uphold system security measures, like antivirus programs, to safeguard against these evolving cyber threats.<h4>Weaponization and Delivery</h4>Threat actors are seizing cracks available online through torrent sites or suspicious web pages, and they craft a malicious <code>AutoHotkey</code> script, turning it into an executable that carries the same icon as the hijacked crack. The attackers accomplish this by compiling the script using the <code>Ahk2Exe</code> compiler (version 1.1.36.00). As a result, the executable involves several stages that ultimately deploy a .NET implementation of <a href="https://github.com/NYAN-x-CAT/AsyncRAT-C-Sharp">AsyncRAT</a>, which we have named <code>HotRat</code>, and this includes the aspect of persistence.This mode of infection has been seen in various types of cracked software, and it can theoretically be inserted into both illegal and legal software installers. The most commonly affected group is typically Adobe (Illustrator, Master Collection, Photoshop) and Microsoft (Office, Windows) software. The second group primarily consists of video games such as Battlefield 3, Age of Empires IV, Red Alert 2, and The Sims 4. Lastly, the final significant group is composed of premium software used as system and development tools (e.g.,&nbsp;IObit Driver Booster, VMware Workstation, Revo Uninstaller Pro, etc.).<h4>Installation</h4>The installation process involves multiple stages, as depicted in Figure 1, to deploy the final <code>HotRat</code> malware and ensure its persistence on the infected system. It begins with a stripped-down version of an expected cracked software setup. The only function of this setup is to initiate a malicious <code>AutoHotkey</code> script. Interestingly, the setup shares the same icon and metadata as the expected software. There’s also a separate folder containing malicious materials alongside the expected software to be “cracked”.

The <code>AutoHotkey</code> script first launches the original setup of the targeted software, providing the illusion of a benign installation process. However, a PowerShell script concealed in <code>PowerPoint.xml</code> runs simultaneously, aiming to weaken system security, specifically by:<ol type="1"><li>Disabling the Consent Admin, enabling operations requiring elevation to be performed without consent or credentials.</li><li>Uninstalling Avira AV.</li><li>Altering Windows Defender settings.</li></ol>More detailed information on these system security modifications can be found in the <a href="https://decoded.avast.io/martinchlumecky/hotrat-the-risks-of-illegal-software-downloads-and-hidden-autohotkey-script-within/#Anti-Detection_and_Bypass">Anti-Detection and Bypass System Security</a> section. Lastly, an <a href="https://decoded.avast.io/martinchlumecky/hotrat-the-risks-of-illegal-software-downloads-and-hidden-autohotkey-script-within/#power-shell">Embedded PowerShell script</a> is executed to ensure the persistence of the malware on the system.<h6 id="power-shell">Embedded PowerShell Script</h6>The Task Scheduler is used to maintain the malware’s persistence on the infected system. The embedded script creates a new task with a deliberate typo in its name (“administartor”) that executes a <a href="https://decoded.avast.io/martinchlumecky/hotrat-the-risks-of-illegal-software-downloads-and-hidden-autohotkey-script-within/#vbs-loader">VBS Loader</a> every two minutes. An example of this scheduled task is:<code>schtasks.exe /create /tn administartor /SC minute /MO 2 /tr C:\ProgramData\Microsoft\IObitUnlocker\Loader.vbs /RL HIGHEST</code>Additionally, the embedded script adds the process name <code>RegAsm.exe</code> to the Windows Defender Exclusion list because this process is exploited for injecting the payload, as <a href="https://decoded.avast.io/martinchlumecky/hotrat-the-risks-of-illegal-software-downloads-and-hidden-autohotkey-script-within/#deployment">described later</a>.The final operation within the embedded script processing involves the activation of a .NET Extractor. This extractor unpacks malicious files – including the final <code>HotRat</code> payload and support files – into a persistence folder. The script utilizes the <code>Reflection.Assembly</code> method to trigger a <code>UAC</code> method, as exemplified here:<code>$bytes = [System.IO.File]::ReadAllBytes("'%A_WorkingDir%\Data\Library.dll'")</code> <code>[Reflection.Assembly]::'Load'($bytes).GetType('Library.Class1').GetMethod('UAC').Invoke($null,$null)</code>The .NET Extractor has another crucial function beyond just unpacking malicious files. The malware authors detect the most frequently used antivirus software and attempt to deactivate them using IObit Unlocker. The persistence folder also contains IObit files capable of deleting system and protected files via the IObit driver. Finally, the extractor uses a straightforward command to remove folders of the detected antivirus software, as demonstrated here:<code>IObitUnlocker.exe /Delete &lt;av_folder&gt;</code>Once the embedded script is successfully executed, all necessary files are prepared for deploying the final <code>HotRat</code> payload. This is accomplished using the <a href="https://decoded.avast.io/martinchlumecky/hotrat-the-risks-of-illegal-software-downloads-and-hidden-autohotkey-script-within/#vbs-loader">VBS Loader</a>, which is run by the previously scheduled task.<h4>HotRat Deployment</h4>Once the scheduled task is set up and eventual AVs deactivated, the scheduled task periodically runs the <a href="https://decoded.avast.io/martinchlumecky/hotrat-the-risks-of-illegal-software-downloads-and-hidden-autohotkey-script-within/#vbs-loader">VBS Loader</a>, which gradually deobfuscates and injects the final <code>HotRat</code> payload, as Figure 2 demonstrates.

<h6 id="vbs-loader">VBS Loader</h6>The persistence folder usually contains a VBS script file enrolled in the scheduled task, an entry point for the deployment process. The folder has a few other files used to obfuscate the final payload. To cover every aspect, we include paths found so far list of the persistence folder:<ul><li><code>C:\ProgramData\Microsoft\IObitUnlocker</code></li><li><code>$env:USERPROFILE\AppData\Roaming\IObitUnlocker</code></li><li><code>$env:USERPROFILE\AppData\Roaming\PerfLogs</code></li><li><code>C:\ProgramData\PerfLogs</code></li><li><code>C:\ProgramData\Data</code></li></ul>The <a href="https://decoded.avast.io/martinchlumecky/hotrat-the-risks-of-illegal-software-downloads-and-hidden-autohotkey-script-within/#vbs-loader">VBS Loader</a> script only executes a PS1 script located in the same persistence folder; typically, with name <code>Report.ps1</code>. The PS1 script, called <code>PS Loader</code>, extracts two .NET executable files from PNG files located in the same persistence folder using the PNG Steganography. The PNG files do not contain any exciting content, and there is only a single pixel line with pixels in different shades of red.

The current steganography implements a simple method of extracting useful bytes from each red pixel as follows:<code>foreach ($x in 1..$img.Width ) { $File.Add(($img.GetPixel($x - 1, 0).R)) }</code>The first <code>Image.png</code> file contains the final HotRat payload injected into the host process (<code>RegAsm.exe</code>) via a .NET Injector hidden in the second <code>pe.png</code> file. The injector is a simple .NET application with a simple method:<code>void Execute(string processPath, byte[] payload)</code>and the host process path is hardcoded in <code>PS Loader</code> as follows:<code>C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe</code>Once the process is successfully injected, the <code>HotRat</code> is active, identified AVs are turned off, and persistence is established in the infected system.<h4>HotRat Malware</h4>The final payload that we call <code>HotRat</code> derives from the open-source implementation of <a href="https://github.com/NYAN-x-CAT/AsyncRAT-C-Sharp">AsyncRAT</a>. The malware authors extended the <a href="https://github.com/NYAN-x-CAT/AsyncRAT-C-Sharp">AsyncRAT</a> implementation with new functions to steal various personal information and credentials; it can deploy other malware. So, <code>HotRat</code> is a comprehensive RAT malware. We have identified around 20 newly implemented commands. Most of the commands are realized as a payload service. Specifically, the attackers send a command and zipped <code>.NET payload</code>, which is executed, and the results are sent back to C2. The entry point for each command is a method called <code>PL</code>, as Figure 3 shows.

We have captured no .NET payloads yet, so we just assess functions for each command by its name. On the other hand, there are direct implementations for other commands where we can describe the original functionality of the commands. The table below shows the identified commands and their purpose.

<h6>C2 Servers</h6>There are several samples with hardcoded C2 servers and ports. However, most C2 servers are provided through free DNS servers. Moreover, the clients’ ports are different for each DNS record. So, it is sometimes impossible to track the final IP addresses.We have identified two IP addresses and ports as follows:<ul><li><code>185.205.209.206:1114</code></li><li><code>108.143.240.80:112</code></li></ul>The list of captured DNS records is following:<ul><li><code>fon1[.]sells-it.net</code></li><li><code>foxn1[.]sells-it.net</code></li><li><code>srxy123[.]is-a-geek.com</code></li><li><code>websites[.]theworkpc.com</code></li><li><code>dynsys[.]is-a-guru.com</code></li><li><code>rec[.]casacam.net</code></li><li><code>samaerx[.]ddnsfree.com</code></li></ul>The communication protocol between clients and C2s is the same as the implementation of the <a href="https://github.com/NYAN-x-CAT/AsyncRAT-C-Sharp">AsyncRAT</a> original one.<h4 id="Anti-Detection_and_Bypass">Anti-Detection and Bypass System Security</h4>Since <code>HotRat</code> is run with admin privileges, it is very easy for attackers to make changes in security. As we noted before, the <code>HotRat</code> Installation process includes specific actions to evade security software for most antivirus software and weaken system security.There are a few methods to remove antivirus software. The Avira AV is deactivated using a simple command to uninstall the Endpoint Protection SDK, as follows:<code>C:\"Program Files"\Avira\"Endpoint Protection SDK"\endpointprotection.exe uninstallSdk</code>Even when the Windows Defender is not deactivated, the installation process adds the whole <code>C:\</code> path into the exclusion paths.The rest of the AVs (Malwarebytes, Avast, AVG, and McAfee) detected by <code>HotRat</code> are deactivated through the IObit Unlocker tool that implements a kernel proxy driver to remove system-protected files. Therefore, <code>HotRat</code> can also delete AV files that are identified by a simple test of folder existence in these paths:<ul><li><code>C:\Program Files\Avast Software</code></li><li><code>C:\Program Files\AVG</code></li><li><code>C:\Program Files\Common Files\McAfee</code></li><li><code>C:\Program Files\Malwarebytes\Anti-Malware</code></li></ul>The <code>HotRat</code> malware also switches off the Consent Admin to perform an operation that requires elevation without consent or credentials because the AutoHotkey script executes other supporting executables that require higher permissions. Hence, the following registry update turns off the Consent Prompt:<code>Set-ItemProperty -Path REGISTRY::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System -Name ConsentPromptBehaviorAdmin -Value 0</code><h4>Prevalence</h4>The incidence of <code>HotRat</code> malware first started to rise significantly in mid-October 2022. Since then, we have been observing a stable trend of occurrence in the wild.The most affected regions are Africa, south Asia, central and East Europa, and North America. The map below illustrates the detailed distribution and risk ration of <code>HotRat</code> malware in the wild.

<h4>Abused Software</h4>The list of abused software is varied. As we mentioned above, the attackers focus on the most wanted software in the field of video games, image and sound editing, office applications, and system tools.Unfortunately, due to its popularity, the brand name of one of our products, CCleaner, was also misused to spread <code>HotRat</code> via an illegal copy of the product. We encourage our users to ensure that CCleaner is downloaded directly from our server (<a href="https://www.ccleaner.com/">ccleaner.com</a>) to ensure they are installing an official (and thus secure) and copy of the software.The list below summarizes the most frequently cracked software misused by the attackers utilizing <code>HotRat</code> malware.<ul><li>Adobe Illustrator 2023 v27.1.0.189 (x64) Pre-Multilingual Pre-Activated</li><li>Adobe Master Collection CC 2022 v25.08.2022 (x64) Multilingual Pre-Activated</li><li>Adobe Photoshop 2021 v22.0.0.35 (x64) Multilingual (Pre-Activated)</li><li>Advanced System Care 16.1.0.106</li><li>Age of Empires IV Digital Deluxe Edition</li><li>Allavsoft Video Downloader Converter 3.25.3.8409 + keygen</li><li>Battlefield 3 Premium Edition + all DLC</li><li>CCleaner (All Editions) 6.08.10255 (x64) + Patch</li><li>Command &amp; Conquer Red Alert 2 [ 3.3.1 direct play portable]</li><li>CyberLink Screen Recorder Deluxe 4.3.1.25422</li><li>Disk Drill Enterprise v50734</li><li>EaseUS Data Recovery Wizard Technician v15.8.1.0 Build 20221128 + Fix {Cracks}</li><li>Far Cry 4 gold edition – v1.10 + all dlcs</li><li>IDM 6.41 build 4 incl Patch 3.12.2022 [CrackingPatching]</li><li>IObit Driver Booster Pro v10.2.0.110 + Fix {Crack</li><li>IObit Uninstaller Pro v12.3.0.8 + Fix {CracksHash}</li><li>KMSpico 10.1.8 FINAL + Portable (Office and Windows 10 Activator)</li><li>Microsoft Office 2022 LTSC v3109(x64) Pre-Cracked [CrackingPatching]</li><li>Microsoft Office Professional Plus 2021 v2108 Build 14326.20144 (x86+x64) Incl. Activator</li><li>Nitro Pro Enterprise v13.70.2.40 (x64) + Fix {Crack}</li><li>PlayerFab v7.0.3.1 (x64) + Fix Crack</li><li>Proxima Photo Manager Pro 4.0 Release 7 Multilingual</li><li>ResumeMaker Professional Deluxe v20.2.0.4060 Pre-Cracked Crack</li><li>Revo Uninstaller Pro 5.0.8 Multilanguage</li><li>ScreenRecorder_4.3.1.25422_Deluxe</li><li>SkylumLuminarNeo1.6.1(10826)x64Sky</li><li>Sniper Elite 4 Deluxe Edition v1.5.0 All DLCs Multiplayer Dedicated Server</li><li>The Sims 4 (v1.94.147.1030 &amp; ALL DLC’s)</li><li>Tiktok 18+ Plus PC Download (Latest Version) V1.3.5 For Pc</li><li>Topaz Video AI v3.0.5 (x64) + Fix {Crack}</li><li>Vmware Workstation pro v17.0.1 build 21139696 (x64) + fix {crackshash}</li><li>Wondershare Filmora X 3.0.6.3 (x64) Multilingual</li><li>Wondershare UniConverter v14.1.9.124 (x64) + Fix Crack</li></ul>&nbsp;<h4>Malicious File Repositories</h4>Infected files are usually stored on public repositories. Specifically, the most seen public share websites are <code>krakenfiles[.]com</code>, <code>send[.]cm</code>, <code>easybytez[.]com</code>, <code>easyupload[.]io</code>, <code>wetransfer[.]com</code>, and <code>www.mediafire[.]com</code>. On the other hand, some samples are located on dedicated servers; for example, <code>51-83-136-132[.]xyz, s1-filecr[.]xyz</code>. So, there is no central C2 server hosting the malicious files.When the malicious files are stored on various hosting serves, URLs leading to the files are distributed to the victim’s machines through multiple platforms such as social networks, torrents, forums, or public repositories with the possibility of searching. Figure 4 illustrates the example of Facebook and one forum posts.

Attackers commonly employ a deceptive tactic of actively participating in online forums. Often, victims are searching these forums for assistance in downloading unauthorized software. However, the attackers mislead them by redirecting to alternative URLs where the <code>HotRat</code> malware is already waiting, as demonstrated in Figure&nbsp;4.ConclusionDespite the known dangers, a persistent trend of software piracy exposes users to potential malware infections. In mid-October, we observed a spike in malware activity, wherein illegal software was bundled with a malicious AutoHotkey script that launched the <code>HotRat</code> malware on victims’ computers. The spread of this malware happens through public repositories, with links being disseminated on social networks and forums.<code>HotRat</code> malware is an advanced version of AsyncRAT, armed with a multitude of spying and personal data theft capabilities. We examined the malware’s deployment process, which is straightforward and utilizes a basic form of encryption, PNG Steganography, for delivering the final payload. Furthermore, the malware exhibits persistence by leveraging scheduled tasks, enabling it to maintain a foothold on infected systems. It also can eliminate antivirus programs, thus endangering the system’s overall security. The blend of uncomplicated deployment and antivirus removal underscores the potential threats posed by this malware.It is critical to re-emphasize the caution against downloading dubious software from unverified sources, especially those demanding the deactivation of antivirus programs, as it can help curb the risk of malware infections and data breaches.

Advanced HotRat Malware: Stealth Deployment

HotRat: The Risks of Illegal Software Downloads and Hidden AutoHotkey Script Within

Through their DDosia project, pro-Russia hacktivist group NoName057(16) is still conducting DDoS attacks, mostly with the goal to take offline websites of institutions and companies in European countries. On its Telegram channels, the group openly communicates the fact that they perform their actions in support of Russia in the war against Ukraine, and it’s apparent that their activities will further continue during the war. The group has been offering payments in cryptocurrencies to people who install their DDosia tool in order to participate in their attacks. We want to create awareness that people who have NoName057(16)’s DDoS tool installed on their computer not only participate in cybercrime, but also support the groups’ warfare activities.We detect and block DDosia to make the internet a safer place, and we continue to track DDoS victims and configurations of the DDosia botnet because such information helps to mitigate the impact of DDoS attacks.Since the first Python version needed to be more efficient, the group released a new Go variant of bots in late 2022. <a href="https://www.sentinelone.com/labs/noname05716-the-pro-russian-hacktivist-group-targeting-nato">SentinelLabs</a> has described the first variant of the Go implementation, including the C2 servers at that time active. A few days later, <a href="https://www.team-cymru.com/post/a-blog-with-noname">Team Cymru</a> published an investigation about the botnet architecture describing the DDoS attacks as a largely static infrastructure.Given the above findings, it is apparent that the C2 structure is still evolving. The primary purpose of the following analysis is to explore the C2 architecture and current communication process between the botnet and C2 servers. Therefore, we have been actively monitoring the DDosia botnet and have found several innovations in the bot implementation and the botnet infrastructure. The C2 infrastructure is composed of one central server and two proxies forwarding bot requests. This, combined with an update mechanism, makes the botnet rather resilient to disruptions. The latest versions also include a bot authentication mechanism for all the C2 communication along with IP address blocklisting, presumably to hinder tracking of the project.<h2>Implementation Overview</h2>The first implementation of DDosia came into the world around July 2022. Being authored by the NoName057(16) group, there was interestingly a brief coexistence with the Bobik botnet before the botnet was dismantled, presumably in favor of DDosia. It was written in Python using threads as a means of parallelism; nevertheless, it was still lacking in terms of efficacy. Since the first version, DDosia relied on HTTP protocol for C2 communication, with JSON configs distributed by the servers.The lack of efficacy presumably motivated changes in DDosia, namely the move from Python to Go that we saw in late 2022, with <a href="https://www.sentinelone.com/labs/noname05716-the-pro-russian-hacktivist-group-targeting-nato">SentinelLabs</a> describing the first Go variants. The main advantage of Go in comparison to Python is direct compilation into native code along with the absence of Python’s GIL that may severely affect the performance of threaded code in Python. Interestingly, these new versions are also multi-platform, as we’ve seen variants for all major operating systems (Windows, macOS, Linux, Android). Evidently, the bot development is still in progress, as we see new functionalities, such as HTTP authentication, being added to DDosia along with slight changes in the configuration file.

<h2>Go Implementation</h2>Let’s take a closer look at the second variant of DDosia bot from March 6, 2023, that came up with the authentication mechanism, presumably to combat researchers snooping for lists of targets.

<h6>Build Package</h6>The aforementioned variant has support for multiple architecture as well as multiple platforms; unsurprisingly, it is also written in Go. The builds are distributed via the Telegram channel “Project DDosia” in the form of a zip file with the builds as follows:<ul><li>Windows x64 and arm64</li><li>Linux x64 and arm64</li><li>macOS x64 and arm64</li></ul>The names of the executable are changed sometimes; there is a list of the captured names:<ul><li>dosia_app_(windows|macos|linux)_(x64|arm64)</li><li>d_(win|mac|linux)_(x64|arm64)</li><li>pd_(win|mac|linux)_(x64|arm64)</li><li>dosia_(win|mac|linux)_(x64|arm64)</li></ul><h6>Execution Workflow</h6>A working dir of the bot executable must contain a text file <code>client_id.txt</code> with the <code>User-Hash</code> of the registered user. The form of the <code>User-Hash</code> is a BCrypt hash with these parameters <code>$2a$16$</code>.The first outcome communication is to use <code>nordvpn.com</code> to get detailed information about the bot IP address that is sent to the C2 server. The second outcome is to use C2 as a <code>POST</code> method to <code>/login</code> URL with data representing information about the bot IP, user ID, and bot identification.

The <code>Client-Hash</code> is the result of a library that returns the OS native machine UUID/GUID. It is an open-source implementation of <a href="https://github.com/denisbrodbeck/machineid#unique-key-reliability">Go MachineID</a> by Denis Brodbeck. The <code>Client-hash</code> has a suffix representing the current PID (5481 in this case).

If the authentication is successful, C2 returns <code>HTTP/1.1 200 OK</code> with a token in the form of epoch/Unix timestamp, and the target configuration can then be downloaded via <code>GET /client/get_targets</code>. The first variant of the DDosia bot does not implement any authentication mechanism, but the valid token is necessary to get the target configuration successfully in the current C2 architecture; otherwise, <code>401 Unauthorized</code> is returned.

The returned JSON file is similar to the first variant, with the difference that the original JSON configuration is wrapped up in a <code>data</code> key. Additionally, the new key <code>token</code> is included in each response of <code>GET /client/get_targets</code>. The <code>token</code> is a fresh token for further communication.

The new configuration supports four attack types: http, http2, nginx_loris, and tcp. The rest of the items are the same as SentinelLabs, and we described previously; see <a href="https://decoded.avast.io/martinchlumecky/ddosia-project/">C&amp;C Communication</a> and <a href="https://www.sentinelone.com/labs/noname05716-the-pro-russian-hacktivist-group-targeting-nato">SentinelLabs</a>.When the login and get targets operation are successful, the bot creates approximately 20 working threads that perform the DDoS attack using a synchronized method since the bot counts the number of successful connections. Therefore, the bot waits for an attacked server response; if the response is <code>200</code>, the attempt is counted as a successful attack. Subsequently, the newest bot implementation is eight times faster than the initial implementation in Python.Continuous statistics are sent each ~four minutes back to the C2 server through <code>POST /set_attack_count</code>.

These statistics help the attacker track the target configuration’s effectiveness and respond in time with a new configuration. If everything goes as expected, a new target configuration is requested every ~10 minutes. However, sometimes the C2 server is unable to handle requests, and a connection cannot be established. In this case, the bot continues on the latest target configuration and tries to contact C2 later. Figure 1 provides an overview of the communication between the C2 server and a bot.

<h2>Bot Updater</h2>One of the unknowns remains the question of the bot updates. Our investigations into this area are still in progress, and we are trying to confirm our hypothesis that there is an automatic bot updater.We’ve observed a few takedowns of C2 servers and new build releases in the last months. We expected a delay of several days between the bot updates and further DDoS attacks. However, the time between the C2 takedown and the new DDoS attacks was several hours. Therefore, our hypothesis is that there is an automatic updater since it is improbable to manually update approximately 7,200 independent clients within several hours.The count of new bot releases was considerable in the last four months, as Figure 2 illustrates. So, there should be some automatic updater.

<h3>C2 Protection</h3>All C2 servers have used HTTP protocol to communicate, which was unencrypted. So, it was only a matter of time before the DDosia authors tried to implement a mechanism to protect the target configurations.<h6>Temporary DNS Records</h6>The first attempt to implement the protection mechanism was around January 28, 2023. The main idea was to use temporary DNS records, which are rotated every midnight. The DNS record is then reconfigured to a non-existent record. As a result of the 24-hour period, the initial DNS record is not captured by any online monitoring services, so the history of DNS records includes only the non-existent or invalid records. Consequently, the valid IP address of C2 severe is not recorded anywhere, and it would not be easy to find them.This mechanism has been seen in the cases on January 28-29, 2023. Two builds with hardcoded DNS records were set to non-existent IPs after midnight. The next day, the new builds with new DNS records were released.For example, <code>deac48f968269bb5e75ceb9417f6680d8787a03ba0768e25d8716f189a079574</code> build has two DNS records (<code>pkcds2cas7.ignorelist.com</code>, <code>pqw2vsi21mx74.twilightparadox.com</code>) that led to <code>212.73.134.208</code>. However, the DNS records were reconfigured to <code>127.0.0.2</code> from midnight on January 27-28, 2023. So, if you resolve the DNS records today, you cannot resolve the initial IP since the address is already untraceable.The same case was seen from midnight on January 28-29, 2023, on the <code>5c1be24a5fa75b70c50515a061d2d3ce911b785188328408edc0a79dfc5e3173</code> build. The other two DNS records (<code>trafficsearch.ddns.net</code>, <code>trafficanalyzer.bounceme.net</code>) led to <code>94.140.115.129</code>. The DNS records were also reconfigured to invalid IP addresses; namely <code>0.0.0.0</code>.Implementing this mechanism was probably not successful because the count of reported targets on the group telegram was lower on January 28, as Figure 3 demonstrates. Moreover, there were reported taken-down domains from the previous target configuration. Finally, the build that was released on January 30 contained hard-coded IP addresses of the C2 server (<code>94.140.114.239</code>).

<h6>Request Authentication</h6>The second attempt to implement the protection mechanism was on March 7, 2023. The communication with the C2 server is also via HTTP, but a token mechanism was designed and realized. Therefore, anybody cannot download the target configuration (list of attacked domains) freely without authentication as before.

The first communication with the C2 server is the login request, as described above in Figure 4. First, the request must include the header <code>User-Hash</code>, which users obtain during the registration process in the DDosia Project Telegram channel. The other necessary condition is data about the GeoIP of the bot. If the IP address or ISP of the given bot is on the blocklist (e.g. Avast), the authentication process ends with <code>401 Unauthorized</code>. However, if the authentication is successful, the login request reruns the token in the string form.The token is valid for approximately 15 minutes, and the constant <code>0xF</code> must be added each time the token is used for the following requests to the C2 servers. The adjusted token is included in the HTTP header as a <code>Time</code> entry, and each response then consists of a new fresh token value.<h2>C2 Architecture</h2>The C2 architecture is dynamically changing. We noticed four IP addresses related to the DDosia project since the beginning of 2023. Three addresses are active web servers run on Ubuntu using <code>nginx/1.18.0</code>. More importantly, these web servers return the same target configurations and provide the services like logging into the botnet as well as reporting statistics to the attackers. The currently discovered C2 architecture of the DDosia project is shown in Figure 5.

Using HTTP, the central C2 server (M) is contacted by proxy C2 servers P1 and P2 throughout port <code>5001</code>. The DDosia bots reach the proxy servers also using HTTP via port <code>80</code>, where requests are forwarded to the central server. Any suspicious outcome from the primary server has not been detected yet. However, one suspicious server or client communicates, especially with the primary and P2 servers. We recorded the most network activity of a suspicious IP (<code>161.35.199.2</code>) around February 14, 2023. The purpose of this suspicious machine is still unknown, but it can be a testing or monitoring service.Besides the bots’ communication over port <code>80</code>, we detected connections on port <code>22</code> for both proxy servers. The transmission on port <code>22</code> is not implemented in the bot executables we analyze, but our telemetry indicates a higher communication volume. However, most captured IPs contacting port <code>22</code> are suspicious due to port scans or SSH brute force attacks.In addition, the C2 infrastructure relies heavily on proxy servers which contributes to the resilience of DDosia’s infrastructure. Nevertheless, our monitoring revealed that outages indicated by <code>502 Bad Gateway</code> error responses from the proxy servers. The first significant disruption occurred during the deployment of the authentication mechanism. The outage lasted for several hours – the duration and the timing indicates that development issues may have been responsible. The root of the problem seems to be partially fixed as recent outages were resolved within one hour.<h2>DDosia Tracking</h2>We still continue to monitor the DDosia project targets and the count of users that have joined the project. We will publish detailed information about the targets, configurations, and volunteers in a subsequent post. Figure 6 illustrates a quick overview.

We’ve also observed that DDosia’s community is steadily growing, though there can be doubts about the capacity new members can contribute. Nevertheless, it seems that in this specific case, a volunteer-based model is rather efficient and easier to manage than a malware-based botnet; however, its availability is probably enabled by the political circumstances.ConclusionIt is evident that the project is still in development, and NoName057(16) is trying to improve the efficiency of the DDoS attacks. They are trying to move to a more efficient Go platform because the pilot variant written in Python was lacking in performance.Many of the changes seem to be motivated by protecting the target configuration and C2 architecture secrecy. Hence, the latest version of DDosia bots has realized the authentication mechanism for C2 communication.Our most interesting observation was probably the implementation of an update mechanism in the client since previous updates caused only short-term disruptions to the project’s effectiveness. This has also increased the resilience of the C2 mechanism, as it is no longer necessary to do a manual update after a server takedown. The update mechanism is still under our investigation. In a future blog post, we plan to release a more detailed analysis of the tracker’s historical data.

Enhanced DDoS Efficiency with Go

DDosia Project: How NoName057(16) is trying to improve the efficiency of DDoS attacks

A few months ago, we published a blog post about a <a href="https://decoded.avast.io/martinchlumecky/bobik/">pro-Russian hacker group called NoName057(16)</a>. The group carried out DDoS attacks using a botnet consisting of devices infected with malware called Bobik. NoName057(16)’s success rate using the Bobik botnet to attack selected targets was around 40%. However, the success rate rapidly dropped when the botnet was taken down – as was reported&nbsp;in the group’s Telegram channel early September.&nbsp;When we analyzed the Bobik malware in the summer, we discovered another Command and Control (“C&amp;C”) server, outside of the Bobik botnet, used for DDoSing. The server’s configuration included similar DDoS targets to the Bobik botnet’s target list. The newer C&amp;C server commanded clients written in Python, and we detected a command on August 1, 2022. Later, on September 15, 2022, NoName057(16) announced the launch of the DDosia project, which matched the sample we found before their announcement on Telegram. The group entices people to join their efforts by offering prizes for the best performers, paying rewards out in cryptocurrencies.&nbsp;&nbsp;On December 5, 2022 the original DDosia C&amp;C server we discovered was taken down. The group, however, continues to post about their attacks, and promote the project, indicating a new C&amp;C server was set up.&nbsp;By launching the DDosia project, NoName057(16) tried to create a new parallel botnet to facilitate DDoS attacks. The group publicly announced the DDosia project, while the Bobik botnet deployment was secretive. The NoName(057)16 attracts project members by offering cash rewards to members carrying out the most successful DDoS attacks. After the takedown of the Bobik botnet, we monitored the newly created DDosia botnet through the aforementioned C&amp;C server.&nbsp;The DDosia client consisted of a Python script created and controlled by NoName057(16). The DDosia tool is only available for verified/invited users via a semi-closed Telegram group, unlike the Bobik malware which was deployed on victims’ devices without their knowledge. The success rate of the original DDosia project we tracked was lower than the Bobik botnet, but has the potential to be a nuisance when targeted correctly.<h2>Project Philosophy&nbsp;</h2>Maintaining a botnet consisting of involuntary clients is expensive. The evidence from our previous research showed that NoName057(16) did not own a botnet which they could use as a distribution channel. The group instead used the Bobik botnet, which was, in fact, a sub-botnet of the RedLine Stealer bot that was rented as a botnet-as-a-service. Clearly, the group had the financial resources to afford renting out the botnet, and now to pay best performers of the DDosia project.&nbsp;The DDosia project consists of a closed community of volunteers, so-called “heroes”. Project members register using a Telegram bot. After registering, the bot sends a download URL with DDosia executables and a text file with a unique ID identifying the registered user.&nbsp;DDosia project members have the option to register a crypto-wallet using their ID number. If a member carries out a sufficiently high number of attacks, they can be awarded up to 80,000 Russian rubles in cryptocurrencies such as Ethereum, BitCoin, and Tether. Members can also check information about their overall statistics in the DDosia Telegram channel.&nbsp;In short, NoName057(16) is building a closed community of users who make their computing time available for DDoS attacks. There are&nbsp;approximately 1,000 “heroes”, according to the project’s closed Telegram channel.&nbsp;<h2>Technical Details&nbsp;</h2>To become a DDosia member you have to go through a registration process facilitated by the <code>@DDosiabot</code> in the dedicated DDosia project Telegram channel. After registering, members receive a <code>DDosia.zip</code> archive, which includes an executable. NoName057(16) strongly recommends using a VPN client, connecting through servers outside of Russia or Belarus, as traffic from the two countries is often blocked in the countries the group targets.The structure of the ZIP archive is as follows:<code>DDosia.zip</code><ul><li>Linux and macOS folder<ul><li>The Linux and macOS folders contain a Python script with the DDosia application – <code>Dosia.py</code>. The script uses simple obfuscation – the source code is stored as a text file with escaped hex digits corresponding to ASCII characters of the Python script.</li></ul></li></ul>

<ul><li>Windows <ul><li>The Windows folder includes one Dosia.exe file which is the DDosia Python script packaged as a PyInstaller executable – nothing less, nothing more. </li></ul></li><li>Each folder of the ZIP archive also contains <code>client_id.txt</code> storing a unique ID of the registered user.&nbsp;</li></ul><h3>DDosia Application&nbsp;</h3>The workflow of the DDosia application is straightforward and does not contain any interesting techniques or methods. So, we just summarized the basic aspects of its implementation.&nbsp;At the beginning, DDosia reads the <code>client_id.txt</code> file storing the ClientId of the registered user. The first C&amp;C communication sends a list of DDoS targets managed by NoName057(16). DDosia creates worker threads which are used to perform DDoS attacks. The number of threads corresponds to five times the number of logical cores. Similarly, to Bobiks’ attacks, DDoS attacks can be conducted using HTTP, but also on a lower layer via the TCP protocol; the <code>HttpTarget</code> and <code>TcpTarget</code> classes are designed for these attacks.&nbsp;Statistical information of each DDosia bot is sent back to the C&amp;C server every minute. The information is identified by the <code>ClientId</code>, and the data contains a list of attacked domains and the number of successful and attempted attacks. A successful attack means that DDosia sends a request to the defined server and receives a response from the server. The communication with the C&amp;C server is unencrypted and unauthenticated, so anyone can easily fake the statistical data and thus win the payout of the day.&nbsp;<h3>C&amp;C Server&nbsp;</h3>We found one DDosia C&amp;C located in Russia ⎼ <code>109.107.181.130</code>. Our Nmap scan discovered three open ports with the following services:&nbsp;<h6>4200/tcp&nbsp;</h6>This port was controlled by the Nginx 1.23.1 web server. There was a web page with the title <code>DosiaBotFront</code>; its design is illustrated in Figure 1. It was the administrator console for the configuration of DDosia bots.

<h6>5001/tcp&nbsp;</h6>The next open port was <code>5001</code>, classified as the commplex-link. A few other scans identified an HTTP service on this port. The Nmap scan detected that the C&amp;C communication is unencrypted on the HTTPS layer.&nbsp;<h6>Other ports&nbsp;</h6>The new results uncovered one thousand opened ports when we repeated the port scan. The attackers want to make the port scan more difficult and time-consuming.&nbsp;<h3>C&amp;C Server Discussion&nbsp;</h3>The main DDosia C&amp;C server (<code>109.107.181.130</code>) was taken down on December 5, 2022, at 9 AM UTC. However, the group continues to actively post on their Telegram channel, so the group must have another botnet.&nbsp;<h3>C&amp;C Communication&nbsp;</h3>The DDosia application has two hard-coded URLs that are used to download and upload data to the C&amp;C server. The first one is used to download a list of domains (targets) that will be attacked, the second one is used for statistical reporting.&nbsp;<ul><li>Get targets: <code>hxxp://109.107.181[.]130:5001/client/get_targets </code></li><li>Send statistical information: <code>hxxp://109.107.181[.]130:5001/set_attack_count</code>&nbsp;</li></ul>The list of targets is sent as an uncompressed and unencrypted JSON file. There are two items: targets and randoms. The former contains approximately 20 properties that define DDoS targets; each target is described via several attributes: id, type, method, host, path, body, and more. The latter describes how random strings will look via fields such as: digit, upper, lower, and min/max integer values; see Figure 2.&nbsp;DDosia generates random values at runtime for each attack. The reason is straightforward; the attackers want to randomize HTTP requests and make each HTTP request unique for a better success rate. The randoms replace placeholders in the path or body of the target definition, and their positions are located using this definition <code>$_{number}</code>, as Figure 2 demonstrates.&nbsp;

<h3>Detections&nbsp;</h3>The DDosia project is not classified as common malware, as people execute the application voluntarily. Nevertheless, we actively detect the DDosia application, but the number of hits approaches zero in the limit.&nbsp;Our telemetry shows only a handful of detections related to DDosia. However, we registered many exceptions that our users added to their Avast Antivirus. The most notable exceptions are from Russia, namely St. Petersburg, Moscow, Seversk, Tyumen, Pudomyagi, and Rostov-on-Don. Other countries we observed using adding the project to their exceptions are Canada (Toronto), and Germany (Berlin).&nbsp;<h3>Performance&nbsp;</h3>One DDosia “hero” can generate approximately 1,800 requests per minute using four cores and 20 threads. Naturally, the speed of request generation depends on the attacker’s internet connection quality. The project currently has approximately 1,000 members. Let’s assume at least half of the users are active, then the total count of requests to defined targets can be up to 900,000 req/min. This can be enough to take down web services that do not expect heavier network traffic.&nbsp;<h2>Dosia Targets&nbsp;</h2>The targets of the DDosia project are very similar to <a href="https://github.com/avast/ioc/blob/master/Bobik/targets.xlsx">Bobik’s targets</a>. The group focuses on private as well as public sectors such as courts, banks, education, public media, government, and transport services (airport, railway). For example, the District Court in Słupsk (PL), West Kredit (LV), Cherkasy National University (UA), Maaleht (EE), or Central Finance and Contracts Agency (LV) were targets.&nbsp;Another aspect of DDosia’s targets is the distribution of attacked countries. Although NoName057(16) was founded to support the “special military operation” in Ukraine, the most attacked domains are from Poland, Latvia, Lithuania, followed by Ukraine.&nbsp;<h3>Dosia Success Rate&nbsp;</h3>We have been monitoring the DDosia project configurations since August 1, 2022 up until the original server was taken down on December 5, 2022. More than 2,200 DDoS targets were captured within four observed months. The NoName057(16) Telegram channel boasted about 390 successful attacks, so the success rate was approx. 17% with approximately 1,000 DDosia “heroes”.&nbsp;The green line of Figure 3 illustrates a trend of successful attacks in the observed period. However, it should be noted that the higher rate of successful attacks is affected by the activity of the Bobik’s botnet, which performed DDoS attacks in parallel. Therefore, the real success rate of DDosia should be counted from approximately September 7, 2022, when the Bobik botnet was taken down. So, if we consider the take-down of the Bobik botnet, the DDosia statistics are 1,400 DDoS targets and 190 successful attacks. Therefore, the current success rate of the DDosia project is approximately 13%.&nbsp;The graph also shows a peak on September 2, 2022. NoName057(16) vehemently tried to attack Ukrainian schools and educational institutions at the beginning of the new school year. Similarly, the same targets we observed on the former Bobik server. The institutes under attack were, for instance, the School of Athens, Ukrainian Medical Journal, School Management and Learning Systems, First Cambridge Education Center, and Libera School. Fortunately, none of the targets were taken down on September 2, 2022, although there were disproportionate numbers of configuration changes and attacked domains.&nbsp;

In November the success rate started to increase significantly. There is also a correlation between the number of attacked domains and the number of successful attacks. The attacked domains (blue line) and successful attacks (green line) trends are approaching each other, which can announce upward trends.&nbsp;A possible explanation for this upward trend is that the selected targets for the attacks are more homogenous than in the previous periods where the group attacked various targets. In comparison, a list of November’s selected targets included targets mostly within one primary domain. Therefore, if an attack on any subdomain of the main domain was successful, the probability that most subdomains will also be taken down is high because they use a similar platform, security, and network. The group boasted about their “successful” attacks on their Telegram channel. The strategy is a logical step to increase the NoName057(16)’s prestige. Right after the Bobik server went offline on September 5, 2022 the group mostly just posted&nbsp;bizarre pictures of bears and cartoons, rather than boasting about successful attacks.&nbsp;<h3>DDosia Attacks on Poland’s Government&nbsp;</h3>

The attack on the Polish government domain is a prime example of the new selection strategy. The attackers focused on most subdomains of the .gov.pl domain since November 5, 2022; see the list of selected subdomains:&nbsp;<ul><li>sanok.sr.gov.pl </li><li>belchatow.sr.gov.pl </li><li>siemianowice.sr.gov.pl</li><li>aleksandrowkuj.sr.gov.pl </li><li>trzcianka.sr.gov.pl </li><li>gdansk-poludnie.sr.gov.pl </li><li>zywiec.sr.gov.pl </li><li>prudnik.sr.gov.pl </li><li>katowice-wschod.sr.gov.pl </li><li>brodnica.ug.gov.pl </li><li>radom.ap.gov.pl </li><li>opolska.policja.gov.pl </li><li>aplikacja.ceidg.gov.pl </li><li>powietrze.gios.gov.pl </li><li>exp.lobi.nencki.gov.pl </li><li>cpsdialog.gov.pl </li><li>puesc.gov.pl </li><li>nawa.gov.pl </li><li>kssip.gov.pl </li><li>ezamowienia.gov.pl&nbsp;</li></ul>Most sr.gov.pl web servers run on the same platform (Nginx v1.16.1). If the attackers pick up subdomains running on the same platform, they have a high chance of taking down the selected servers. More importantly, most subdomains (web pages) only have informational characters and do not provide any online services critical to the government. So, these attacks have no value from a cyber attack perspective, except for propaganda on the group’s Telegram channel.&nbsp;Another essential point is the attack on the Central Register and Information on Economic Activity (<code>aplikacja.ceidg.gov.pl</code>). The website expects a higher page load because there are electronic services for entrepreneurs. Therefore, the website was more resilient to DDosia attacks.&nbsp;An example of an attack without any value is the attack on Poland’s municipality Gmina Brodnica. Their website does not include anti-Russian and Russophobic content; however, it was also under attack despite the NoName057(16) declaration to attack sites with anti-Russian and Russophobic content; see the Telegram post below. Therefore, it is evident that NoName057(16) is not after operational impact in the war in Ukraine but rather uses the conflict as an opportunity to establish itself in the community.&nbsp;

<h3>DDosia Configurations&nbsp;</h3>Our telemetry has been recording the DDosia configurations from&nbsp;August 1, 2022 – December 5, 2022. Firstly, Figure 3 above illustrates that the configurations are changed four times per day on average; see the red line. Secondly, the average number of attacked domains per day is seventeen.&nbsp;<h2>Rewards&nbsp;</h2>NoName057(16) promises a cryptocurrency reward for the most productive members. Suppose the participants link their crypto-wallet during the registration; NoName057(16) posted a few messages announcing the most active members, as shown in the posts below.&nbsp;

The prize for the winners is in the order of thousands of rubles (hundreds of dollars). We cannot verify whether the crypto money was really sent to the said clients and thereby verify that the group has enough financial resources at their disposal.&nbsp;Individual participants send statistics about their progress and achievements periodically to the C&amp;C server; however, in plain text without any protection. A body of statistical information is a simple JSON file with <code>ClientId</code> and IDs of attacked servers. Therefore, anyone can counterfeit their own statistics because each client can obtain their <code>ClientId</code> from <code>client_id.txt</code>. A simple Python script below can fake the statistics, and anyone can be the most active client on any given day. The script also contains a list of the targets’ IDs that can be downloaded from the C&amp;C server in plain text.&nbsp;

<h2>Conclusion&nbsp;</h2>Based on the aim of our <a href="https://decoded.avast.io/martinchlumecky/bobik/">previous study</a>, which was monitoring the activity of the NoName057(16) group, we have captured another method used for DDoSing against Ukraine and the countries surrounding it and siding with Ukraine.&nbsp;NoName057(16) has changed their philosophy and built a new botnet using a publicly available tool compared to the Bobik malware that was used previously. The tool is a simple Python script called DDosia. The depth analysis confirms that DDosia is only a tool for DDoSing and does not contain any backdoor functionality.&nbsp;The success rate of the DDosia attacks is ~ 13% percent of all of their attack attempts. DDosia is available via a closed community on Telegram, and the number of members is approximately 1,000. If the community is on the rise, we expect the success rate to be higher. Therefore, the successful attack depends on the motivation that NoName057(16) provides to volunteers. At this moment, 1,000 registered heroes may actually mean 500 active instances of DDosia, so servers that expect a high network activity load are more resilient to attacks.&nbsp;The targets selected for DDoS attacks are the same as in our <a href="https://decoded.avast.io/martinchlumecky/bobik/">previous study</a>. In short, NoName057(16) focuses on companies and organizations that support Ukraine or are “anti-Russian”. At the beginning of November, the target selection was shifted and oriented on subdomains of previously successfully attacked domains, which increased the success rate.&nbsp;The new aspect of DDoS attacks is the possibility of being rewarded. The group collects statistical information about performed attacks and successful attempts. Subsequently, the best “heroes” are paid out in cryptocurrencies. However, the statistics can be easily manipulated.&nbsp;The NoName057(16) has introduced the DDosia project so they can carry out more DDoS attacks when the previous botnet has been taken down. The power of the attacks is much less than with the previous Bobik botnet. Consequently, time will tell how successful DDosia will be.&nbsp;Their DDoS attacks are basically unsophisticated, do not have large impacts, and do not aim to cause significant damage. They want to draw attention to themselves in the media, similar to the Killnet group. Nonetheless, NoName057(16) activities are still more of a nuisance than dangerous.&nbsp;

Martin a Milánek

Posts by Martin a Milánek

HotRat: The Risks of Illegal Software Downloads and Hidden AutoHotkey Script Within

DDosia Project: How NoName057(16) is trying to improve the efficiency of DDoS attacks

DDosia project: Volunteers carrying out NoName(057)16’s dirty work