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

Security Evangelist at Gen

Malware Researcher

Research

<p>When we published the first part of this research, we said the investigation was still ongoing. That was not a closing line. We were already looking at the infrastructure, the signals behind the attacks, and the scale of the reservation data abuse we were seeing in our telemetry.&nbsp;</p><p>Then something else happened.&nbsp;</p><p>Friends, colleagues, and other contacts started forwarding us messages they had received from Booking.com. The messages warned that unauthorized third parties may have accessed information linked to their reservations. Shortly after, media outlets began reporting the same thing: Booking.com had notified affected customers, reset reservation PINs, and said the accessed information could include names, email addresses, phone numbers, booking details, and information shared with accommodations. Booking.com said financial information was not accessed from its systems.&nbsp;</p><p>The timing mattered, but not because it started our investigation. It mattered because it publicly confirmed the kind of reservation-data exposure our first article had described from the attack side.&nbsp;</p><p><a href="https://us.norton.com/blog/online-scams/reservation-hijacking-scam" target="_blank">Reservation Hijack scams</a> work because criminals do not have to guess. A traveler receives a message about a real booking. The message contains details that make sense: the right accommodation, the right trip context, sometimes the right contact information. The link then opens a fraudulent page built around the same accommodation.&nbsp;</p><p>A generic <a href="https://us.norton.com/blog/online-scams/what-is-phishing " target="_blank">phishing message</a> has to create trust from nothing. This scam steps into a relationship that already exists between the traveler, the booking platform, and the accommodation.&nbsp;</p><p>While those public warnings were appearing, Gen Threat Labs continued canvassing the data we had available: blocked URLs, fraudulent landing pages, SMS messages, emails, WhatsApp messages, in-app message evidence, and other signals connected to attacks we had already stopped. We used AI-assisted analysis to connect pieces that would otherwise remain scattered: messages, landing pages, accommodation names, URLs, templates, and infrastructure patterns. Human analysts reviewed the results and separated what we could prove from what we could only suspect.&nbsp;</p><p>The result is a much clearer picture.&nbsp;</p><p>We identified more than <strong>350 compromised accommodations</strong> linked to the Reservation Hijack scam flows, spread across <strong>50 countries</strong>. These were not abstract indicators or generic travel-themed pages. In the cases we analyzed, victims had already received reservation-specific information before being pushed to a fraudulent page customized around the accommodation tied to that booking.&nbsp;</p><p>That is the difference between ordinary travel phishing and this model. The attackers are not guessing who is traveling. They already have enough reservation context to make the fraud feel normal.&nbsp;</p><p>And they are doing it at scale.&nbsp;</p>

<h3>How we connected the evidence&nbsp;</h3><p>The second phase of our investigation was already underway when Booking.com’s customer notifications started circulating publicly.&nbsp;</p><p>Gen’s view of this activity comes from attacks we blocked before they could complete. No single signal tells the whole story. An SMS or WhatsApp message may show the <a href="https://us.norton.com/blog/emerging-threats/what-is-social-engineering " target="_blank">social engineering</a>. A URL may show the redirect path. A landing page may show the accommodation being impersonated. An in-app message may show where the attacker entered the trusted communication flow. A repeated page structure may link incidents that look separate at first.&nbsp;</p><p>Put together, those pieces show how reservation data moves from compromise to fraud.&nbsp;</p><p>AI helped us work through that evidence at scale. We used it to normalize accommodation names, cluster similar messages, compare landing-page structures, connect URLs with page content, and flag repeated patterns across channels. This was not “AI says these attacks are connected.” It was AI-assisted triage followed by human review.&nbsp;</p><p>From that process, we extracted and cleaned accommodation names from captured fraudulent landing pages and identified <strong>350 compromised accommodations</strong>.&nbsp;</p><p>We use “compromised accommodations” carefully here. It means reservation context tied to those accommodations was compromised and used in an attack flow we intercepted. The source of compromise may vary: a hotel account, a booking platform partner account, an email inbox, a property management system, a guest messaging workflow, or a third-party service provider.&nbsp;</p><p>The end result for the traveler is the same. Criminals had access to information that should have stayed inside the booking relationship.&nbsp;</p><p>This is also a conservative number. It only includes attacks where we had enough evidence to connect the flow to a specific accommodation. It does not include people who received a message and never clicked, attacks outside our telemetry, landing pages we did not capture, or cases where the accommodation name could not be reliably extracted.&nbsp;</p><p>So 350 is not the size of the problem. It is the part we could see clearly.&nbsp;</p><h3>From scam pattern to repeatable operation&nbsp;</h3><p>A single compromised hotel account can explain a few victims. A copied phishing kit can explain a short campaign. Hundreds of accommodation-specific scam flows across 50 countries point to something more organized.&nbsp;</p><p>The model we see is consistent.&nbsp;</p><p>Reservation context enters the fraud chain, sometimes through compromised accommodation-side accounts, inboxes, partner tools, or data obtained from other criminal actors. That context is then used to contact travelers with details that make the message feel legitimate.&nbsp;</p><p>The wording, the property, the country change. The logic does not.&nbsp;</p><p>That is why this follow-up is not simply “we found more cases.” The first article explained <a href="https://www.gendigital.com/blog/insights/research/reservation-hijack-scam">how Reservation Hijack scams work</a>. This one shows how far the model has spread.&nbsp;</p><h3>A worldwide footprint, led by Europe&nbsp;</h3><p>The highest number of compromised accommodations in our dataset were linked to <strong>Germany</strong>, followed by <strong>France</strong>, the <strong>United Kingdom</strong>, <strong>Italy</strong>, <strong>Spain</strong>, and the <strong>United States</strong>.&nbsp;</p><p>Germany accounted for 49 compromised accommodations in the dataset. France followed with 35, the United Kingdom with 31, Italy with 24, Spain with 20, and the United States with 19.&nbsp;</p><p>Together, the top five European countries, Germany, France, the United Kingdom, Italy, and Spain, accounted for <strong>159 compromised accommodations</strong>, about <strong>45%</strong> of the full dataset.&nbsp;</p>

<p>The European concentration makes sense. Europe has a dense travel market, a high volume of cross-border bookings, many independent and mid-sized accommodation providers, and a strong dependency on online booking platforms and pre-arrival guest messaging.&nbsp;</p><p>Those conditions give criminals useful cover. Travelers expect messages before arrival. They expect payment questions, check-in instructions, policy reminders, and booking updates. A well-timed fake message does not feel unusual.&nbsp;</p><p>But the country distribution also shows that this is not a single-region problem. The activity spreads across <strong>50 countries</strong>, with a long tail of destinations beyond the largest clusters.&nbsp;</p>

<p>That long tail matters. It suggests the model is not limited to a few obvious tourist destinations or a handful of famous hotel brands. Once criminals have access to reservation data and a working scam flow, the same approach can be adapted to different countries, languages, property types, and booking habits.&nbsp;</p><p>The property does not need to be famous. It only needs to be real, tied to a real reservation, and recognizable to the victim.&nbsp;</p><h3>Not just hotels&nbsp;</h3><p>Hotels make up the largest share of the dataset, but they are not the whole story.&nbsp;</p><p>We identified compromised accommodations across several property types: hotels, aparthotels, apartments, inns, motels, lodges, resorts, guesthouses, B&amp;Bs, hostels, villas, bungalows, and capsule hotels.&nbsp;</p>

<p>This is a useful reminder of how fragmented the travel ecosystem really is. A traveler may book a large hotel chain, a family-run guesthouse, a serviced apartment, a hostel, or a villa through similar platforms and messaging flows.&nbsp;</p><p>From the traveler’s point of view, the trust model is almost the same. They made a booking. They expect communication. They may not know whether the message came from the property, the platform, a channel manager, a property management system, or a compromised account sitting somewhere in between.&nbsp;</p><p>That is exactly the gap criminals are abusing.&nbsp;</p><h3>How big could this problem be?&nbsp;</h3><p>To understand the potential scale of Reservation Hijack scams, we looked at the accommodation properties appearing in our research dataset.&nbsp;</p><p>In total, we identified <strong>350 accommodation entries</strong> linked to reservation hijack scam activity. These were not all the same kind of business. The dataset included hotels, aparthotels, resorts, hostels, guesthouses, villas, apartments and other accommodation types. For each one, we estimated the number of rooms, units, beds or capsules, depending on the property type, and used that to calculate the likely maximum guest capacity.&nbsp;</p><p>Across the deduplicated dataset, these properties represented an estimated maximum capacity of around <strong>82,000 guests at any given time</strong>. Using a conservative occupancy rate of <strong>50%</strong> and an average length of stay of <strong>2.5 nights</strong>, this translates into approximately <strong>6 million guest stays per year</strong>.&nbsp;</p><p>That does not mean 6 million people were scammed. It does not mean 6 million people had their data exposed. What it shows is the size of the opportunity criminals may be looking at when they compromise accommodation or booking communication channels.&nbsp;</p><p>A single compromised workflow can give scammers something much more valuable than a random phone number or email address. It can give them context: the name of the accommodation, the dates of the stay, the booking amount, the channel the guest expects to be contacted through, and the right moment to create urgency.&nbsp;</p><p>That is why Reservation Hijack scams are so convincing. The scam does not feel like spam. It feels like part of the trip.&nbsp;</p>

<h3>The activity does not look random&nbsp;</h3><p>We are still investigating the infrastructure behind these attacks, so we are not attributing the activity to a named group.&nbsp;</p><p>But the evidence does not look like hundreds of unrelated actors randomly copying one another.&nbsp;</p><p>Across the dataset we analyzed, the same fingerprints kept appearing. Many pages used the same internal paths for scripts, images and styles. Several included the same unusual overlay component, repeated internal asset paths, and the same card-validation language, including claims that funds would be reserved and refunded within 10 minutes.&nbsp;</p><p>The pages were also built to look specific to the victim. Hotel names appeared in page titles and visible content. Prices varied from one case to another. Check-in and check-out dates were inserted into the page. In some cases, page metadata and images were synchronized with the accommodation being impersonated. The evidence points to a repeatable process for turning reservation context into property-specific phishing pages. Taken together, those patterns are consistent with a phishing kit designed to generate accommodation-specific pages at scale, rather than pages built manually for each victim.&nbsp;</p><p>The phishing pages also included a fake live support chat. To the victim, it looked like part of the booking or payment process, but it was controlled from the phishing infrastructure. The payment step could therefore become a live interaction: someone behind the page could react to the victim’s input, ask for another card, explain away a failed “validation”, push the victim to continue, or try to capture a one-time code while the victim still believed they were talking to booking support.&nbsp;</p><p>Some of the infrastructure also uses legitimate internet services, including services such as Cloudflare, to place a layer between the visible scam page and the systems behind it. That does not make those services malicious. It means criminals are abusing the same infrastructure that normal websites use, including protective layers that can obscure hosting details, traffic paths, and backend systems.&nbsp;</p><p>For investigators, this kind of setup makes the infrastructure harder to trace. For travelers, it removes many of the usual warning signs. They see a page that loads normally, shows the right accommodation, includes a support chat, and refers to the trip they actually booked. At that point, many people will treat the request as part of the reservation process, even when it is not.&nbsp;</p><h3>Correct information is not proof of legitimacy&nbsp;</h3><p>For years, people have been told to watch for bad spelling, odd sender names, generic greetings, and suspicious links. That advice still helps, but it does not solve this problem.&nbsp;</p><p>A message can include the right accommodation, the right destination, and details from a real stay, and still be malicious. A page can show the correct hotel name, dates, and a plausible payment amount, and still be fake. A request can arrive at the moment when a traveler expects a check-in or payment message, and still be fraud.&nbsp;</p><p>Page behavior can create false confidence too. In some of the phishing pages we analyzed, the fake support chat looked like part of the booking or payment process. If the victim had a question, or if the card “validation” failed, the page could keep the interaction going instead of simply collecting data and stopping there.&nbsp;</p><p>That is what makes Reservation Hijack scams difficult for travelers to judge. The victim is not being tricked only by a fake brand or a fake website. They are being pushed through a process built around real context, at the moment when that context feels normal.&nbsp;</p><p>Travelers expect hotels and booking platforms to contact them. They expect last-minute requests, check-in instructions, payment checks, ID forms, and confirmation messages. Criminals are not fighting that expectation. They are using it.&nbsp;</p><h3>What travelers should do&nbsp;</h3><p>The safest rule is simple: <strong>do not treat correct booking information as proof that a message is legitimate.</strong>&nbsp;</p><p>If a message asks you to verify payment details, confirm a reservation, re-enter card information, pay a balance, reset a PIN, or avoid cancellation, do not use the <a href="https://us.norton.com/blog/online-scams/i-clicked-on-a-phishing-link" target="_blank">link in the message</a>.&nbsp;</p><p>Open the booking platform or hotel app directly. Go to the official website yourself. Use contact details from the original booking confirmation. If needed, call the property using a verified number. Check whether the same request appears inside your official booking account.&nbsp;</p><p>This applies even if the message mentions the right hotel, the right destination, or details from your stay.&nbsp;</p><p>Booking.com has told customers that it will not ask guests to share credit card details by email, phone, WhatsApp, or text, or ask for a bank transfer that differs from the payment policy in the booking confirmation.&nbsp;</p><p>If you already entered payment details into a suspicious page, contact your bank immediately, freeze or cancel the card, and monitor for follow-on fraud. Criminals may reuse the card data later, or sell it to others.&nbsp;</p><h3>What accommodations should take from this&nbsp;</h3><p>For hotels and other accommodation providers, this is not only a guest-awareness issue. Guest communication has become part of the attack surface.&nbsp;</p><p>The systems and workflows between the property and the guest are now valuable targets. That can include hotel staff accounts, booking platform partner accounts, email inboxes, property management systems, guest messaging tools, channel managers, and third-party service providers.&nbsp;</p><p>The lures we have seen on the accommodation side are not exotic. They look like normal hotel work. Some impersonate Booking.com and claim there is a guest complaint waiting for a response. Others say that a paid reservation needs urgent verification, or that the property’s visibility or ranking may be affected if staff do not act quickly. We have also seen payment and invoice-themed messages designed to make staff open attachments or documents that can lead to credential theft or <a href="https://us.norton.com/blog/malware/signs-of-malware" target="_blank">malware infection</a>.&nbsp;</p>

<p>That is why the first visible sign of a Reservation Hijack scam may not be the message sent to the guest. It may start earlier, with an email to a shared hotel inbox, a fake partner-support notice, a malicious attachment, or a document that looks like part of normal accounting or reservation handling. Once reservation context is obtained, whether directly or through another actor in the criminal ecosystem, it can be used later to make guest-facing scams much more convincing.&nbsp;</p><p>For accommodation providers, staff training needs to cover the workflows criminals are actually abusing. Urgent complaints, reservation-verification requests, payment advice emails, invoice notifications, security-update prompts, and any message asking staff to open an attachment, enable content, sign in again, or act under time pressure should all be treated as possible entry points into the same fraud chain.&nbsp;</p><p>The defensive work starts with account protection, but it should not stop there. Accommodation providers need strong <a href="https://us.norton.com/blog/account-safety/multi-factor-authentication" target="_blank">multi-factor authentication</a>, tight control over who can access guest data, monitoring for unusual logins or message patterns, and a clear process for responding when an account may have been abused. The devices used to manage reservations, guest messages, invoices and payment-related emails should also be protected with reliable security protection. Some of the lures we observed were designed to make staff open attachments or documents that could install malware or steal credentials. In those cases, <a href="https://us.norton.com/antivirus" target="_blank">antivirus</a> or endpoint protection may be the last barrier before a compromised inbox becomes a compromised booking workflow.&nbsp;</p><p>Payment-related communication deserves special attention. If a guest receives a payment or verification request, there should be a reliable way to confirm whether it is real. If an account is suspected of being compromised, guests need to be warned quickly and clearly.&nbsp;</p><p>The reputational damage can be painful. Even when the property is also a victim, the traveler may remember the incident as “the hotel message that stole my card details.” That makes workflow security part of customer trust.&nbsp;</p><h3>What the wider travel ecosystem should learn&nbsp;</h3><p>Reservation Hijack scams sit between several parts of the travel industry. The booking platform may see unusual partner activity. The hotel may see confused guests. The traveler sees a convincing message. The bank sees card fraud. A security company sees the landing page.&nbsp;</p><p>Each view is partial, and that delay helps the scam continue.&nbsp;</p><p>The useful signals are often scattered: unusual partner logins, repeated payment-verification language, guest-message spikes, reused templates, fake landing pages, redirects, and infrastructure overlaps. Sharing those signals faster would make it easier to see when separate complaints are really part of the same operation.&nbsp;</p><p>One compromised accommodation can look like a local incident. Hundreds of compromised accommodations across 50 countries point to a repeatable abuse model.&nbsp;</p><h3>The next phase of travel fraud&nbsp;</h3><p>Reservation Hijack scams exploit a simple mistake in how we judge trust online.&nbsp;</p><p>Travelers think: “This message knows my booking, so it must be real.”&nbsp;</p><p>Criminals know: “If we have the booking context, the victim will do much of the trust work for us.”&nbsp;</p><p>The message does not have to be perfect. The website does not have to be flawless. The attacker does not need to convince the victim from zero. They only need to appear inside a relationship that already exists.&nbsp;</p><p>Our latest data shows that this model has spread well beyond isolated cases. We identified <strong>350 compromised accommodations across 50 countries</strong>, covering hotels, apartments, hostels, resorts, guesthouses, villas, and other accommodation types. Together, those properties represent a large travel footprint and millions of estimated annual guest interactions.&nbsp;</p><p>The investigation is still ongoing. We are continuing to analyze infrastructure, campaign overlaps, and the clues suggesting connected activity behind parts of the operation.&nbsp;</p><p>For travelers, the lesson is simple.&nbsp;</p><p>Trust your booking. Do not automatically trust the message.&nbsp;</p>

After our first report, Booking.com began warning customers that reservation data had been accessed. Our continuing investigation shows how criminals are using that data at scale. 

When Hotel Scams Know Your Booking: 350 Compromised Accommodations Across 50 Countries 

Threat Research Team

<p>Attackers replaced selected official download links with malicious installers that deployed a Python bot, r77 rootkit components, and Windows policy-based defense evasion.</p><p>On May 6, 2026, attackers compromised the official JDownloader website and swapped download links to serve trojanized installers. The JDownloader developers <a href="https://www.reddit.com/r/jdownloader/comments/1t6goqe/is_the_website_hacked/">confirmed the breach</a> within hours, restored clean files, and disclosed a timeline, but acknowledged they didn't know what the malicious installers actually do. We took the malware apart to answer that question.</p><p>&nbsp;</p><p>What we found goes well beyond a typical trojanized installer. The payload is a multi-component attack framework: a Python bot protected by PyArmor v9, an r77 rootkit stager with AMSI bypass, and a Windows Defender Application Control (WDAC) policy that blocks 50 security executables from running, including Avast, AVG, Avira, Windows Defender, HitmanPro, and Kaspersky Virus Removal Tool. We reversed the full C2 protocol from the obfuscated Python bytecode and recovered the campaign configuration from the dropper's encrypted strings.</p><p>&nbsp;</p><h2>The infection chain</h2><p>The trojanized installer is unsigned. Windows SmartScreen blocks it, and users who ran it had to manually bypass the warning. Inside, it wraps the legitimate JDownloader installer alongside an XOR-encrypted second-stage PE:</p>

<p>Stage 2 acts as the campaign's quartermaster. It deploys five components from XOR-encrypted resources embedded in its PE (key: <code>fywo</code>):</p><table class="table"><thead><tr><th>Component</th><th>Purpose</th></tr></thead><tbody><tr><td><strong>PyArmor bot</strong></td><td>The main payload, a Python script with obfuscated bytecode</td></tr><tr><td><strong>PyArmor runtime</strong></td><td>DLL that decrypts the bot's bytecode at execution time</td></tr><tr><td><strong>r77 rootkit stager</strong></td><td>Native x86 PE that hides the bot's process, files, and registry keys</td></tr><tr><td><strong>WDAC Code Integrity policy</strong></td><td>Blocks 50 AV/EDR executables from running after reboot</td></tr><tr><td><strong>Python 3.14.3 installer</strong></td><td>The legitimate Python runtime (needed to run the bot)</td></tr></tbody></table><p>Before doing any of this, Stage 2 calls <code>WaitForSingleObject</code> with a 300-second timeout — three times in sequence. This 5-minute-per-call delay is designed to outlast automated sandboxes, which typically give samples 2-5 minutes of execution time. One sandbox vendor recorded an 8-minute total wait before any malicious behavior appeared.</p><p>&nbsp;</p><h2>Killing your antivirus before it can fight back</h2><p>The most operationally significant component is the WDAC Code Integrity policy.</p><p>Windows Defender Application Control (WDAC) policies tell the operating system which executables are allowed to run. The attackers deploy a deny-list policy to <code>%WINDIR%\System32\CodeIntegrity\SIPolicy.p7b</code> that blocks 50 executable paths across six security vendors plus core Windows security services:</p><table class="table"><thead><tr><th>Target</th><th>Blocked executables</th></tr></thead><tbody><tr><td><strong>Avast</strong></td><td>AvastSvc.exe, AvastUI.exe, afwServ.exe, aswEngSrv.exe, aswidsagent.exe, aswToolsSvc.exe, wsc_proxy.exe, Icarus components, Overseer</td></tr><tr><td><strong>AVG</strong></td><td>All executables under Program Files\AVG\Antivirus</td></tr><tr><td><strong>Avira</strong></td><td>Security, VPN, Fallback Updater, Optimizer Host, Endpoint Protection SDK</td></tr><tr><td><strong>Windows Defender</strong></td><td>MsMpEng.exe, MpCmdRun.exe, MpDefenderCoreService.exe</td></tr><tr><td><strong>Windows Security</strong></td><td>SecurityHealthHost.exe, SecurityHealthService.exe, SecurityHealthSystray.exe</td></tr><tr><td><strong>Windows Update</strong></td><td>MoUsoCoreWorker.exe, wuauclt.exe, wusa.exe</td></tr><tr><td><strong>Others</strong></td><td>HitmanPro, Kaspersky Virus Removal Tool, Farbar Recovery Scan Tool</td></tr></tbody></table><p>After the next reboot, none of these executables can start. The AV service is effectively dead. It won't run, it can't scan, and Windows Update can't push signature updates. One victim in the Reddit thread reported that Windows Defender disappeared entirely after running the trojanized installer.</p><p>This is a known but uncommon TTP (MITRE T1562.001). It requires the installer to run elevated, which the SmartScreen bypass dialog would have prompted for. Users who clicked through both warnings — SmartScreen and UAC — gave the malware everything it needed.</p><h2>&nbsp;</h2><h2>How the dropper provisions the bot</h2><p>Stage 2's strings are all XOR-obfuscated with the same <code>fywo</code> key used for its resources. After deobfuscation, we recovered 122 strings including registry paths, API names, and encrypted configuration values.</p><p>The dropper writes the bot's initial configuration to <code>HKCU\SOFTWARE\Python</code>. Both the registry value names and data are RC4-encrypted and hex-encoded — making the registry entries look like random hex strings to casual inspection. We recovered two configuration values:</p><ul><li data-list-item-id="e15e9100cccadef17d91598e244b0b038"><strong>CampaignID</strong> a unique identifier for this campaign, used during bot registration with the C2 server.</li><li data-list-item-id="e7a2666057614636498fba93e483028cf"><strong>DDRList</strong> six dead-drop resolver URLs that the bot uses to discover its C2 servers (detailed in the next section).</li></ul><p>Notably, the dropper does not write a C2 server list directly. The bot discovers its command-and-control addresses exclusively through the dead-drop resolver mechanism — a design choice that makes the infrastructure resilient to takedowns.</p><p>&nbsp;</p><h2>Dead-drop resolvers: how the bot finds its C2</h2><p>A dead-drop resolver (DDR) is an intermediary, a legitimate web page where the operator publishes encrypted C2 addresses. The bot fetches the page, extracts and decrypts the content, and connects to whatever C2 servers it finds. If the operator needs to rotate infrastructure, they update the DDR page and every infected machine follows automatically.</p><p>The bot reads its DDR list from the registry, fetches each URL, and RC4-decrypts the page content. Valid payloads start with the prefix <code>VAL:</code> followed by a semicolon-separated list of C2 URLs.</p><p>We extracted all six dead-drop resolver URLs from the dropper and probed them:</p><table class="table"><thead><tr><th>URL</th><th>Status</th><th>Decrypted content</th></tr></thead><tbody><tr><td><code>telegra[.]ph/tr02-05-02</code></td><td>Live</td><td>C2 list: parkspringshotel[.]com + auraguest[.]lk</td></tr><tr><td><code>telegra[.]ph/ki06-05-02</code></td><td>Live</td><td><code>VAL:XX</code> — placeholder for future C2 rotation</td></tr><tr><td><code>rentry[.]co/zzk7opdu</code></td><td>Live</td><td>Same C2 list</td></tr><tr><td><code>rentry[.]org/wayc2qqz</code></td><td>Live</td><td><code>VAL:XX</code> — placeholder</td></tr><tr><td><code>codeberg[.]org/etienne74/guix/...</code></td><td>404</td><td>Removed or never created</td></tr><tr><td>`2wxjoz6lkdxkniksujbdknkugweemx7uvxdr4ejgyipce4tnvktvbvqd.onion/t`</td><td>Not probed</td><td>Tor hidden service DDR</td></tr></tbody></table><p>The operator has two live C2 servers and four reserve dead-drop pages — two stubs ready for C2 rotation and one Tor fallback. If the current C2 infrastructure gets burned, the operator updates a Telegraph or Rentry page and every infected machine picks up the new address on its next poll cycle.</p><p>Beyond the dead-drop mechanism, the bot has a domain generation algorithm (DGA) as a last-resort fallback. It combines four seeds (<code>XNerWs4I</code>, <code>e55gegnW</code>, <code>RjWN0Y9m</code>, <code>AemOU1co</code>) with 14 TLDs and an ISO-week-based rotation to produce 56 candidate domains per week. We probed all current DGA domains — none are registered. The operator is running purely on dead-drop infrastructure for now, but the DGA ensures the botnet can survive even if all resolver pages and C2 servers are taken down simultaneously.</p><p>&nbsp;</p><h2>The C2 protocol: RSA-OAEP wrapping AES-GCM</h2><p>We reversed the bot's full communication protocol from the PyArmor-protected bytecode. It uses a layered encryption scheme designed to prevent passive interception and session tampering:</p>

<p>The bot wraps a fresh AES-256 key with the hardcoded RSA-2048 public key (OAEP, SHA-256) and sends it to the C2. The server proves possession of the private key by returning <code>"ok"</code> encrypted with AES-GCM. From that point, every message in both directions is AES-256-GCM encrypted with a per-direction sequence counter as authenticated associated data — preventing replay and reordering.</p><p>After the handshake, the bot registers with the campaign ID provisioned by the dropper. The server returns a <code>bot_id</code> and <code>bot_pass</code> that the bot stores in the registry for subsequent polling. The bot's primary capability is arbitrary Python code execution — the attacker can ship any Python code and the bot will run it and return the output.</p><p>All identified C2 and staging servers are compromised <a href="https://qloapps.com/">QloApps</a> hotel reservation websites:</p><table class="table"><thead><tr><th>Domain</th><th>Role</th><th>IP</th><th>PHP</th><th>Location</th></tr></thead><tbody><tr><td><code>parkspringshotel[.]com</code></td><td>C2 panel</td><td>172.96.172[.]91</td><td>8.3.30</td><td>Ghana</td></tr><tr><td><code>auraguest[.]lk</code></td><td>C2 panel</td><td>209.133.215[.]178</td><td>8.3.30</td><td>Sri Lanka</td></tr><tr><td><code>checkinnhotels[.]com</code></td><td>Linux payload staging</td><td>66.29.137[.]25</td><td>7.4.33</td><td>—</td></tr></tbody></table><p>The two C2 servers share identical JARM fingerprints and run the same PHP version, confirming the same C2 panel software is deployed on both. The third domain, <code>checkinnhotels[.]com</code>, was used to host the Linux payload disguised as an SVG file (<a href="https://www.bleepingcomputer.com/news/security/jdownloader-site-hacked-to-replace-installers-with-python-rat-malware/">BleepingComputer</a>). All three run QloApps — an open-source hotel booking CMS — suggesting the attacker specifically targets this software to build their infrastructure. None of the domains had malicious detections on VirusTotal at the time of discovery. We confirmed both C2 servers remain operationally live as of May 11.</p><h2>&nbsp;</h2><h2>The r77 rootkit stager</h2><p>The rootkit stager is a 176 KB native x86 PE based on the open-source <a href="https://github.com/bytecode77/r77-rootkit">r77 rootkit</a>. It contains an embedded .NET assembly that performs four operations:</p><ol><li data-list-item-id="e9ca3772c2bd6052d86931268e23d036a"><strong>AMSI bypass</strong> — a PowerShell cradle patches <code>AmsiScanBuffer</code> in memory, disabling Windows' Antimalware Scan Interface before any script payload runs.</li><li data-list-item-id="e01c27cd4c721b2dabe18b819d05c84fe"><strong>Reflective DLL injection</strong> — injects the r77 hooking DLLs (32-bit and 64-bit variants) into <code>winlogon.exe</code>. These DLLs hook Windows API functions to hide any process, file, or registry key whose name starts with the <code>$77</code> prefix.</li><li data-list-item-id="e254d7da7ebd6dfd7d57f7c5f67760ba3"><strong>Registry persistence</strong> — stores the stager assembly as a binary blob in <code>HKLM\SOFTWARE\$77stager</code> and reloads it at every boot via .NET reflection.</li><li data-list-item-id="ef200c38559748bd535edaf6a0d5aa3d5"><strong>Service creation</strong> — installs a Windows service (<code>$77svc</code>) to ensure the rootkit survives reboots independently of the registry mechanism.</li></ol><p>Once r77 is active, the <code>$77</code> prefix acts as an invisibility cloak. The Python bot calls <code>r77_hide_self()</code> and <code>r77_hide_registry_path()</code> to rename its own process and registry hive with this prefix, making them invisible to Task Manager, <code>regedit</code>, and most security tools.</p><h2>&nbsp;</h2><h2>The Python bot under PyArmor v9</h2><p>The final payload is a Python script protected by <a href="https://pyarmor.dashingsoft.com/">PyArmor</a> v9, a commercial bytecode obfuscation tool. PyArmor encrypts each function's bytecode individually and decrypts it at runtime through a native DLL — making static analysis significantly harder than standard Python malware.</p><p>We built a custom tool to decrypt and disassemble the protected bytecode, recovering 30 functions totaling 7,326 lines of disassembly. The bot is cross-platform (Windows and Linux), uses gevent for asynchronous I/O, and handles the full lifecycle: configuration management, C2 discovery via dead-drop resolvers and DGA, encrypted communication, task execution, and rootkit integration.</p><p>The bot's primary capability is executing arbitrary Python code received from the C2 server. Combined with the Python 3.14 runtime installed by the dropper, this gives the operator the ability to deploy any follow-on payload — keyloggers, credential stealers, lateral movement tools — without needing to push new binaries to the victim.</p><h2>&nbsp;</h2><h2>Impact and recommendations</h2><p>Users who downloaded JDownloader from the official website between May 6 and May 7, 2026, using the "Download Alternative Installer" links (Windows) or the Linux shell installer link are potentially compromised. The <a href="https://jdownloader.org/incident_8.5.2026.html">official incident report</a> lists eight malicious installer hashes across x86/amd64 and multiple JRE versions. The attackers exploited an unpatched CMS vulnerability to swap download links — the actual installer files hosted externally were never modified. In-app updates, macOS downloads, and package manager installs (Flatpak, Winget, Snap) were not affected.</p><p>The Linux attack chain, [first reported by BleepingComputer](https://www.bleepingcomputer.com/news/security/jdownloader-site-hacked-to-replace-installers-with-python-rat-malware/), follows a different delivery path. We downloaded the trojanized shell installer and its payload to verify the claims and dig deeper.d. The modified install4j script requires root, checks for x86_64 architecture, and downloads a 20 MB tar.gz from <code>checkinnhotels[.]com/img/logo1.svg</code> (disguised with <code>Content-Type: image/svg+xml</code> — still live as of May 11). The archive contains two files: a 3 KB SUID-root helper (<code>systemd-exec</code>) and a 21 MB PyInstaller bundle (<code>pkg</code>). The helper is a minimal ELF that calls <code>setuid(0)</code>, <code>setgid(0)</code>, and <code>execvp()</code> — installed to <code>/usr/bin/systemd-exec</code> with <code>chmod 4755</code>. Persistence is created via <code>/etc/profile.d/systemd.sh</code>, which launches the payload masquerading as <code>/usr/libexec/upowerd</code>.</p><p>We decrypted the PyArmor-protected Python bytecode from the Linux payload and confirmed it is <strong>the same bot source code</strong> as the Windows variant — identical RSA public key, DGA seeds, RC4 keys, C2 protocol, and DDR handler logic. The same campaign ID (<code>NdcHsJPM</code>) and all six DDR URLs are written to <code>~/.local/share/</code> as RC4-encrypted files (mirroring the Windows registry approach). The only difference is the Python runtime: the Linux bundle uses Python 3.12 (packaged via PyInstaller) versus Python 3.14 on Windows.</p><p>The JDownloader developers restored clean downloads on May 9 and published a detailed incident timeline. Users who already had JDownloader installed and received updates through the application's built-in updater were not affected — only fresh downloads from the website during the compromise window were trojanized.</p><p><strong>If you ran the trojanized installer:</strong></p><ul><li data-list-item-id="e78c8637f87f47adb2a6c0e9e37ff1466">The WDAC policy may have disabled your antivirus. Check <code>%WINDIR%\System32\CodeIntegrity\SIPolicy.p7b</code> — if it exists and you didn't create it, delete it and reboot.</li><li data-list-item-id="e5a9344602452a9e77dfe81e30c45fd8c">The registry keys <code>HKCU\SOFTWARE\Python</code> (bot config) and <code>HKLM\SOFTWARE\$77stager</code> (rootkit) are strong indicators of compromise — but if r77 is active, its API hooks hide all <code>$77</code>-prefixed registry keys and the bot's own hive from standard tools like <code>regedit</code>. To inspect these, boot from a Windows recovery environment or mount the registry hives offline.</li><li data-list-item-id="edcbc2f271c7b2885893f8f995fe252eb">A clean OS reinstall is the safest remediation. The r77 rootkit's reflective injection into <code>winlogon.exe</code> and AMSI bypass make partial cleanup unreliable.</li></ul><p><strong>For defenders:</strong></p><ul><li data-list-item-id="efcd7ce434d65f159da0dbff097d5fb44">The bot uses the default Python User-Agent <code>Python-urllib/3.14</code>. While not unique on its own, it can help correlate connections to the C2 URLs and DDR pages listed below.</li><li data-list-item-id="e35fe4757c01a79131defbd71e6762bfb">Monitor for DNS queries to the DGA pattern: 15-character lowercase alphanumeric hostnames on TLDs including <code>.top</code>, <code>.cfd</code>, <code>.sbs</code>, <code>.cyou</code>, <code>.icu</code>, <code>.casa</code>.</li><li data-list-item-id="e41ab2df0dd210b9e338012701bdf4398">The mutex name <code>Global\0C3C1D37</code> can serve as a host-based indicator.</li><li data-list-item-id="e68e99d7961368cd02568989f8e767d08">Block the dead-drop resolver pages: <code>telegra[.]ph/tr02-05-02</code>, <code>telegra[.]ph/ki06-05-02</code>, <code>rentry[.]co/zzk7opdu</code>, <code>rentry[.]org/wayc2qqz</code>.</li></ul><h2>&nbsp;</h2><h2>Indicators of Compromise</h2><p>Full IOC list available on <a href="https://github.com/avast/ioc">GitHub</a>.</p><h3>Hashes (SHA-256)</h3><table class="table"><thead><tr><th>Artifact</th><th>Hash</th></tr></thead><tbody><tr><td>Stage 1 — Windows (analyzed variant)</td><td><code>5a6636ce490789d7f26aaa86e50bd65c7330f8e6a7c32418740c1d009fb12ef3</code></td></tr><tr><td>Stage 1 — Linux shell installer</td><td><code>6d975c05ef7a164707fa359284a31bfe0b1681fe0319819cb9e2c4eec2a1a8af</code></td></tr><tr><td>Stage 2 (C++ dropper)</td><td><code>77a60b5c443f011dc67ace877f5b2ad7773501f3d82481db7f4a5238cf895f80</code></td></tr><tr><td>Stage 3 — Windows (PyArmor bot)</td><td><code>5fdbee7aa7ba6a5026855a35a9fe075967341017d3cb932e736a12dd00ed590a</code></td></tr><tr><td>PyArmor runtime DLL</td><td><code>33318499489cdb82543c0bfea699b98f5928c7a360966df6e958a9cbc2eab3fe</code></td></tr><tr><td>r77 rootkit stager</td><td><code>5c887054cb1dce077943afa955db43306f66795f7cbda8233d8ba25230a23d41</code></td></tr><tr><td>WDAC CI policy</td><td><code>5ee86c177dc5bdba05e3bdc67b07115c66097f825fff257bf0d4a999bbb8a1ea</code></td></tr><tr><td>Linux payload archive (logo1.svg)</td><td><code>6550672cac21e036882921dd934ee06552dc74d3b0a9e1ddc26f952855e11371</code></td></tr><tr><td>Linux SUID helper (systemd-exec)</td><td><code>25744e90bfa44cbcbf1f3d3c3cb90dd79dd32a6e359df9d2660ff251d6d03b46</code></td></tr><tr><td>Linux PyInstaller bot (pkg)</td><td><code>bf47585bd0b39f0731f044b37a95eb7e311ad31b23b50306a113a3aa777dbfab</code></td></tr></tbody></table><p>Six additional Windows installer variants are listed in the <a href="https://jdownloader.org/incident_8.5.2026.html">official incident report</a>. Full hash list on <a href="https://github.com/avast/ioc/tree/master/JDownloaderRAT">GitHub</a>.</p><h3>Network indicators</h3><table class="table"><thead><tr><th>Type</th><th>Value</th><th>Context</th></tr></thead><tbody><tr><td>C2 URL</td><td><code>parkspringshotel[.]com/m/Lu6aeloo.php</code></td><td>Active C2</td></tr><tr><td>C2 URL</td><td><code>auraguest[.]lk/m/douV2quu.php</code></td><td>Active C2</td></tr><tr><td>Staging</td><td><code>checkinnhotels[.]com/img/logo1.svg</code></td><td>Linux payload (still live)</td></tr><tr><td>C2 IP</td><td><code>172.96.172[.]91</code></td><td>parkspringshotel.com</td></tr><tr><td>C2 IP</td><td><code>209.133.215[.]178</code></td><td>auraguest[.]lk</td></tr><tr><td>Staging IP</td><td><code>66.29.137[.]25</code></td><td>checkinnhotels.com</td></tr><tr><td>Dead-drop resolver</td><td><code>telegra[.]ph/tr02-05-02</code></td><td>Live, serves encrypted C2 list</td></tr><tr><td>Dead-drop resolver</td><td><code>rentry[.]co/zzk7opdu</code></td><td>Live, serves encrypted C2 list</td></tr><tr><td>Dead-drop resolver</td><td><code>telegra[.]ph/ki06-05-02</code></td><td>Stub, reserved for C2 rotation</td></tr><tr><td>Dead-drop resolver</td><td><code>rentry[.]org/wayc2qqz</code></td><td>Stub, reserved for C2 rotation</td></tr></tbody></table><h3>Host indicators</h3><table class="table"><thead><tr><th>Type</th><th>Value</th></tr></thead><tbody><tr><td>Mutex</td><td><code>Global\0C3C1D37</code></td></tr><tr><td>Registry (bot config)</td><td><code>HKCU\SOFTWARE\Python\*</code> (hex-encoded RC4-encrypted value names)</td></tr><tr><td>Registry (r77)</td><td><code>HKLM\SOFTWARE\$77stager</code>, <code>$77dll32</code>, <code>$77dll64</code>, <code>$77svc</code></td></tr><tr><td>WDAC policy</td><td><code>%WINDIR%\System32\CodeIntegrity\SIPolicy.p7b</code> (GUID <code>{31351756-3F24-4963-8380-4E7602335AAE}</code>)</td></tr><tr><td>Bot process</td><td><code>pythonw.exe</code> (Python 3.14, User-Agent <code>Python-urllib/3.14</code>)</td></tr><tr><td>Tor drop path</td><td><code>C:\ProgramData\tor\tor\tor.exe</code></td></tr><tr><td>Linux SUID binary</td><td><code>/usr/bin/systemd-exec</code></td></tr><tr><td>Linux payload</td><td><code>/root/.local/share/.pkg</code></td></tr><tr><td>Linux persistence</td><td><code>/etc/profile.d/systemd.sh</code></td></tr><tr><td>Linux masquerade</td><td><code>/usr/libexec/upowerd</code></td></tr></tbody></table><h3>MITRE ATT&amp;CK</h3><table class="table"><thead><tr><th>Technique</th><th>ID</th></tr></thead><tbody><tr><td>Supply Chain Compromise: Compromise Software Supply Chain</td><td>T1195.002</td></tr><tr><td>Obfuscated Files or Information</td><td>T1027</td></tr><tr><td>Impair Defenses: Disable or Modify Tools</td><td>T1562.001</td></tr><tr><td>Process Injection: Dynamic-link Library Injection</td><td>T1055.001</td></tr><tr><td>Web Service: Dead Drop Resolver</td><td>T1102.001</td></tr><tr><td>Dynamic Resolution: Domain Generation Algorithms</td><td>T1568.002</td></tr><tr><td>Encrypted Channel: Asymmetric Cryptography</td><td>T1573.002</td></tr><tr><td>Rootkit</td><td>T1014</td></tr><tr><td>Create or Modify System Process: Windows Service</td><td>T1543.003</td></tr><tr><td>Modify Registry</td><td>T1112</td></tr></tbody></table><p>For customers using Norton, Avast, AVG, Avira or any other security product, the most important question is whether the malicious installer was executed. If you downloaded an affected installer but did not run it, delete the file, download a fresh installer from the official JDownloader site, and run a full scan with up-to-date protection. If you ran the installer, or cannot rule out that you ran it, treat the system as compromised. JDownloader recommends a clean operating system reinstall in this situation, and we agree that this is the safest baseline. The Windows payload includes rootkit behavior, persistence, encrypted configuration and policy-based defense evasion, so a normal scan may reduce risk but cannot guarantee that every persistence mechanism has been removed. Until the system has been rebuilt or inspected from a trusted recovery environment, avoid using it for sensitive activity. Do not log in to email, banking, work accounts, password managers or other important services from that machine. Change important passwords from another trusted device, and monitor accounts for unusual activity.</p><p>&nbsp;</p>

Malware that hid itself on infected systems and disabled antivirus protection.

Inside the JDownloader Supply-Chain Attack: An r77 Rootkit Bot That Kills Your Antivirus

<p><strong>TLDR: </strong>Bedep was a malware family active mainly in 2014 and 2015 that used an unusually sophisticated domain generation algorithm, or DGA, to hide its command-and-control infrastructure. Instead of relying only on the date, it used real foreign exchange rates published by the <em>European Central Bank</em>, making its future domains much harder to predict in advance. Under the hood, the malware used ideas from group theory to generate a fixed set of unique domains without collisions, a rare example of advanced mathematics being applied directly in real-world malware.</p><p>Most domain generation algorithms are boring. A linear congruential generator, a date seed, some modular arithmetic, a character table -- <code>seed = (seed * 0x41C64E6D + 0x3039) % 2^31</code>, rinse, repeat. You reverse them in an afternoon, pre-compute next month's domains over lunch, and move on.</p><p>Bedep author implemented a number theory textbook inside a 32-bit DLL, and the result is one of the most mathematically elegant pieces of malware ever shipped.</p><p>This post is a deep dive into this unique engineering.</p><h2>What is Bedep?</h2><p>Bedep is an ad-fraud botnet that was active from late 2014 through 2015, delivered exclusively through the Angler exploit kit. When a Flash zero-day (CVE-2015-0311) was burning, Angler was dropping Bedep. The malware itself was a modular downloader focused on click fraud, but its infrastructure is what made it interesting. In early 2015, new variants appeared with a DGA for C2 resolution. A three-day sinkhole by Arbor Networks (ASERT) caught phone-homes from roughly 82,000 unique IPs, spread across every continent except -- notably -- Russia.</p><p>Dennis Schwarz originally reversed the DGA at ASERT, who published a proof-of-concept Python reimplementation and a detailed write-up titled <em>"Bedep's DGA: Trading Foreign Exchange for Malware Domains."</em> The original blog post has since been taken down from NETSCOUT's site, but survives on the <a href="https://web.archive.org/web/20160311083109/http://www.arbornetworks.com:80/blog/asert/bedeps-dga-trading-foreign-exchange-for-malware-domains/">Wayback Machine</a>. The PoC lived at <code>github.com/arbor/bedep_dga</code>. Dennis got the algorithm working but noted that parts of it were opaque -- he called the core transform a "blackbox" and flagged the embedded table as "likely something Fermat number related." He was right. Let's open that box.</p><p>&nbsp;</p><h2>The ECB trick: Seeding a DGA from the financial markets</h2><p>Before the math starts, Bedep needs a seed that both the bot and the botmaster can independently derive without communicating. Most DGAs use the date. Bedep uses the date <em>and</em> the global foreign exchange market.</p><p>The algorithm fetches two XML files from legitimate public services:</p><ol><li data-list-item-id="ec5890edf5187711796f804fae7ad8577"><strong>UTC time</strong> from <code>earthtools.org/timezone/0/0</code> -- the current timestamp, converted to "days since year zero."</li><li data-list-item-id="ead6313dc967de96442575ff50339b412"><strong>Euro foreign exchange reference rates</strong> from <code>www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d.xml</code> -- the European Central Bank's daily publication of EUR conversion rates against 31+ world currencies, updated every business day.</li></ol><p>The time is used to select which day's rates to use. Specifically, Bedep picks "last Tuesday's" exchange rates -- meaning the preceding week's Tuesday until Thursday, after which it rolls forward to the current week's Tuesday. Only rates falling on a Monday boundary (in the algorithm's day-counting scheme) are considered. This gives a roughly weekly rotation with a deterministic selection rule.</p><p>From the chosen date, Bedep extracts up to 48 currency rates -- USD, JPY, GBP, CZK, BGN, HUF, and so on. Each rate is parsed through a slightly broken custom <code>atof()</code> implementation (off by a bit in the least significant digits -- a quirk, not a feature), packed into a 64-bit IEEE double, and its low 32-bit dword is extracted for use in the algorithm.</p><p>Here is what a single run looks like, from the PoC output for April 7, 2015:</p><p><code>parsed 31 currencies from 2015-04-07 (currency date): &nbsp; &nbsp;USD: 1.0847 &nbsp; &nbsp; &nbsp;JPY: 130.33 &nbsp; &nbsp; BGN: 1.9558 &nbsp; &nbsp;CZK: 27.455 &nbsp; &nbsp; &nbsp;DKK: 7.4714 &nbsp; &nbsp;GBP: 0.7286 &nbsp; &nbsp;HUF: 299.08 &nbsp; &nbsp; &nbsp;PLN: 4.0578 &nbsp; &nbsp;RON: 4.4165 &nbsp; &nbsp;SEK: 9.374 &nbsp; &nbsp; &nbsp; CHF: 1.0438 &nbsp; &nbsp;NOK: 8.73 &nbsp; &nbsp;HRK: 7.619 &nbsp; &nbsp; &nbsp; RUB: 59.8265 &nbsp; TRY: 2.8079 &nbsp; &nbsp;AUD: 1.4192 &nbsp; &nbsp; &nbsp;BRL: 3.3979 &nbsp; &nbsp;CAD: 1.3563 &nbsp; &nbsp;CNY: 6.7241 &nbsp; &nbsp; &nbsp;HKD: 8.4086 &nbsp; &nbsp;IDR: 14091.77 &nbsp; &nbsp;ILS: 4.267 &nbsp; &nbsp; &nbsp; INR: 67.598 &nbsp; &nbsp;KRW: 1183.28 &nbsp; &nbsp;MXN: 16.1919 &nbsp; &nbsp; MYR: 3.9527 &nbsp; &nbsp;NZD: 1.4423 &nbsp; &nbsp;PHP: 48.3 &nbsp; &nbsp; &nbsp; &nbsp;SGD: 1.4724 &nbsp; &nbsp;THB: 35.335 &nbsp; &nbsp;ZAR: 12.8345</code></p><p>&nbsp;</p>

<p>Why is this clever? Because the ECB rates are:</p><ul><li data-list-item-id="e5f3c952abb440c715bcfa626ac9bd4c0"><strong>Publicly available</strong> -- anyone can fetch the same XML</li><li data-list-item-id="e7730a0d72c71be00a0c3d3feebc10618"><strong>Globally consistent</strong> -- every bot on every continent gets the same data</li><li data-list-item-id="e1667d4c4edd48ffbda05118e24153bf0"><strong>Unpredictable in advance</strong> -- nobody can predict next Tuesday's EUR/USD rate</li><li data-list-item-id="e80b9125dab13aae37cb9ed8b88656475"><strong>Historically verifiable</strong> -- the ECB publishes archives going back years</li><li data-list-item-id="e0d9bf0abba3c6cb7703705ce6203f707"><strong>Impossible to tamper with</strong> -- the ECB is not going to modify their reference rates to help you sinkhole a botnet</li></ul><p>And because the malware fetches this from <code>ecb.europa.eu</code>, the request looks like legitimate traffic. A Snort signature (SID 33188) was written to detect it, but it fired constantly on real users checking exchange rates.</p><h2>The mathematical core</h2><p>This is where Bedep stops being a clever botnet and starts being a discrete mathematics exercise.</p><h3>Precomputed subgroup parameters</h3><p>The DLL embeds a lookup table -- 102 entries of 8 dwords each, stored as JSON in the PoC (<code>transform2_table_varN.json</code>, one per config variant). At first glance it looks like random constants. It is not.</p><p>The <code>transform2</code> function takes a hash derived from the exchange rates and days-since value, then uses it as an index into this table. Each table entry, after being decoded through config-specific XOR and multiply constants (<code>0x663d81 * entry[0] ^ value3</code> and <code>0x281 * entry[1] ^ value2</code>), yields two critical values:</p><ul><li data-list-item-id="ee4084ac1a9ee922a9a2585119d02acb9"><strong>p</strong> -- a prime number</li><li data-list-item-id="e7d298adce011a8fe31f7d5db7f1685ee"><strong>q</strong> -- an integer such that q divides p - 1</li></ul><p>This is the subgroup structure. The table stores primes whose group orders (p - 1) have known factorizations with small prime factors. The malware doesn't need to factor p - 1 at runtime -- that hard work was done offline by the author and baked into the DLL. Dennis Schwarz noted these were "likely something Fermat number related," and he was onto something: the primes are chosen so that their totient has a smooth factorization, making generator-finding tractable.</p><p>The number of domains to generate comes directly from q - 1. For the first config, this works out to 22 domains; for the second, 28 -- totaling 50 domains per weekly rotation.</p><h3>Finding generators: A textbook primitive root search</h3><p>With p and the prime factorization of p - 1 in hand, Bedep needs a generator of the multiplicative group ((\mathbb{Z}/p\mathbb{Z})^*) -- or more precisely, of a specific subgroup of order q.</p><p>The <code>transform8</code> function does this in two stages. First, it runs a <strong>trial-division prime sieve</strong>: starting from 3, stepping by 2 (skipping evens), it tests each candidate against all previously found primes. It collects up to 37 small primes, then filters for those that actually divide q (the subgroup order). This gives the prime factorization of q.</p><p>Then <code>transform3</code> finds the <strong>primitive root</strong> itself. This is the standard algorithm straight from a number theory textbook:</p><p><code>def find_primitive_root(p, prime_factors_of_order): &nbsp; &nbsp;for g in range(2, p // 2): &nbsp; &nbsp; &nbsp; &nbsp;is_generator = True &nbsp; &nbsp; &nbsp; &nbsp;for q_i in prime_factors_of_order: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# If g^((p-1)/q_i) ≡ 1 (mod p), then g generates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# a proper subgroup, not the full group. Reject it. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if pow(g, (p - 1) // q_i, p) == 1: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;is_generator = False &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break &nbsp; &nbsp; &nbsp; &nbsp;if is_generator: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return g &nbsp; &nbsp;return None</code></p>

<p>The actual code in <code>transform3</code> is this logic rendered in C-style loop structure with manual index tracking, but the mathematics is identical. For each candidate g starting from 2, it checks:</p><p>[ g^{(p-1)/q_i} \not\equiv 1 \pmod{p} \quad \text{for all prime factors } q_i \text{ of } p-1 ]</p><p>If g passes all checks, it generates the full group. This is literally the algorithm from Section 11.1 of Shoup's <em>A Computational Introduction to Number Theory and Algebra</em>, implemented in a malware DLL.</p><h3>Walking the cyclic group</h3><p>Now comes the payoff. With a prime p, a generator g, and a subgroup order q, the <code>transform7</code> function sets up the DGA's iteration state:</p><p><code>modulus &nbsp; &nbsp;= p &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# field_c seed &nbsp; &nbsp; &nbsp; = pow(g, random_e, p) &nbsp; &nbsp; &nbsp; &nbsp;# field_4 -- starting element step &nbsp; &nbsp; &nbsp; = pow(g2, random_f, q) &nbsp; &nbsp; &nbsp; # field_8 -- step exponent</code></p>

<p>The starting position <code>seed</code> is g raised to a random exponent (derived from <code>rdtsc</code>, the CPU timestamp counter). The step is similarly randomized from a second generator. Both are computed via modular exponentiation.</p><p>Then, for each domain, the iteration is simply:</p><p><code>seed = pow(seed, step, modulus) &nbsp; &nbsp; # one step through the cyclic group domain = seed_to_domain(seed, currencies)</code></p>

<p>That single line -- <code>pow(seed, step, modulus)</code> -- is the entire DGA engine. Each call advances the state to the next element of the cyclic subgroup.</p><p>Because the subgroup has order q, and step is coprime to q (guaranteed by the generator construction), this walk visits every non-identity element of the subgroup exactly once before cycling. The number of domains generated equals q - 1, which is precisely the number of non-identity elements. No collisions. No wasted iterations. No off-by-one hoping you hit enough domains.</p><p><strong>The key insight:</strong> the set of group elements visited is deterministic (fixed by p, g, and the exchange rates), but the <em>order</em> of visitation depends on the random exponents from <code>rdtsc</code>. Every infected machine walks through the same set of q - 1 elements, generating the same q - 1 domain names, but potentially in a different order. Same destinations, different paths.</p><p><code>flowchart TB &nbsp; &nbsp;subgraph cyclic_group ["Cyclic Subgroup of (Z/pZ)*"] &nbsp; &nbsp; &nbsp; &nbsp;E1["g^1 mod p"] --&gt; E2["g^2 mod p"] &nbsp; &nbsp; &nbsp; &nbsp;E2 --&gt; E3["g^3 mod p"] &nbsp; &nbsp; &nbsp; &nbsp;E3 --&gt; E4["..."] &nbsp; &nbsp; &nbsp; &nbsp;E4 --&gt; Eq["g^(q-1) mod p"] &nbsp; &nbsp; &nbsp; &nbsp;Eq --&gt; E1 &nbsp; &nbsp;end &nbsp; &nbsp;subgraph walk ["DGA Walk (order depends on rdtsc)"] &nbsp; &nbsp; &nbsp; &nbsp;S1["seed_0"] --&gt;|"pow(s, step, p)"| S2["seed_1"] &nbsp; &nbsp; &nbsp; &nbsp;S2 --&gt;|"pow(s, step, p)"| S3["seed_2"] &nbsp; &nbsp; &nbsp; &nbsp;S3 --&gt;|"pow(s, step, p)"| S4["..."] &nbsp; &nbsp; &nbsp; &nbsp;S4 --&gt;|"pow(s, step, p)"| SN["seed_(q-2)"] &nbsp; &nbsp;end &nbsp; &nbsp;S1 -.-&gt;|"= g^e mod p\n(random start)"| cyclic_group &nbsp; &nbsp;S2 -.-&gt;|maps to| E3 &nbsp; &nbsp;S3 -.-&gt;|maps to| Eq</code></p>

<h2>From Group Elements to Domain Names</h2><p>Each group element is a 32-bit integer. Turning it into a domain name is the final step, handled by <code>transform11</code>. This is less mathematically elegant and more of a traditional mixing function, but it has a nice property: every character position in the domain uses a <em>different</em> currency rate.</p><p>The algorithm cycles through the full list of parsed currencies (31 in the example above). For a domain of length 18, that means character 0 is influenced by USD, character 1 by HRK, character 2 by MXN, character 3 by GBP, and so on. Each character is computed by:</p><ol><li data-list-item-id="e1b4d60fdb8fc1f153baf8a99855a0b35">Multiplying the currency's 3-letter name (packed as a 32-bit int) and its 64-bit floating-point rate by large constants</li><li data-list-item-id="ec05b47f97cd63ed0295b790fd5474c85">XORing and shifting the result with the current seed and the days-since value</li><li data-list-item-id="e2f1e2c5d769b5e8978ca12f1d05cf791">Taking the result modulo 26 (for positions 2+) or modulo 36 (for the last two positions, allowing digits)</li><li data-list-item-id="e589b38ae5aa632fba755388fc26bd71c">Adding the ASCII offset for 'a'</li></ol><p>The domain length itself is derived from the seed XORed with a rate-dependent value, bounded between 12 and 18 characters. All domains use the <code>.com</code> TLD.</p><p>A trace from the PoC output shows the mixing in action:</p><p><code>seed: 0xa13c9652 &nbsp; &nbsp;mixing in USD's rate &nbsp; &nbsp;mixing in HRK's rate &nbsp; &nbsp;mixing in MXN's rate &nbsp; &nbsp;mixing in GBP's rate &nbsp; &nbsp;... &nbsp; &nbsp;mixing in ZAR's rate &nbsp; &nbsp;domain: rrpohktjlscncqxvt3.com seed: 0x558af439 &nbsp; &nbsp;mixing in USD's rate &nbsp; &nbsp;... &nbsp; &nbsp;domain: wjavcjhazzxyxotkbi.com</code></p>

<p>Each domain is a fingerprint of the entire exchange rate vector, filtered through one specific element of the cyclic group.</p><h2>The Full Pipeline</h2><p>Putting it all together:</p><p><code>flowchart LR &nbsp; &nbsp;ECB["ECB XML\n31+ currency rates"] --&gt; DateSelect["Select last\nTuesday's rates"] &nbsp; &nbsp;Earth["earthtools.org\nUTC timestamp"] --&gt; DateSelect &nbsp; &nbsp;DateSelect --&gt; Mix["XOR/multiply\nrates + days_since"] &nbsp; &nbsp;Mix --&gt; TableLookup["Lookup table\n→ prime p, order q"] &nbsp; &nbsp;TableLookup --&gt; GenFind["Sieve primes,\nfind generator g"] &nbsp; &nbsp;GenFind --&gt; GroupSetup["seed = g^rand mod p\nstep = g2^rand mod q"] &nbsp; &nbsp;GroupSetup --&gt; Walk["Iterate:\nseed = seed^step mod p"] &nbsp; &nbsp;Walk --&gt; CharMix["Mix seed with\ncurrency rates"] &nbsp; &nbsp;CharMix --&gt; Domains["22-28 domains\nper config"]</code></p>

<p>Seven configs were observed in the wild, each with its own embedded table, XOR constants, and currency count (36 or 48). Each malware variant embedded two configs that ran per rotation -- the first generating 22 domains, the second 28, yielding 50 domains total. Across the observed campaign, domains were registered 2-5 days ahead of use through "Domain Context" registrar with Regway nameservers, all resolving to infrastructure at 5.196.181.244 and 46.105.251.1.</p><h2>Why this matters</h2><p>Compare Bedep's approach with its contemporaries:</p><table class="table"><thead><tr><th>Family</th><th>DGA Technique</th><th>Seed</th></tr></thead><tbody><tr><td>Conficker.C</td><td>Date + simple arithmetic</td><td>Current date</td></tr><tr><td>Gamaredon</td><td>Nested character-range loops</td><td>Hardcoded ranges</td></tr><tr><td>Necurs</td><td>CRC32 hash of date components</td><td>Date + constant</td></tr><tr><td>Matsnu</td><td>Dictionary word concatenation</td><td>Days since epoch</td></tr><tr><td><strong>Bedep</strong></td><td><strong>Cyclic group walk mod p</strong></td><td><strong>ECB exchange rates</strong></td></tr></tbody></table><p>Every other DGA on this list can be pre-computed arbitrarily far into the future. Bedep cannot -- because Tuesday's exchange rates don't exist until Tuesday. You can sinkhole Conficker's domains for next year during your coffee break. For Bedep, you have to wait for the ECB to publish, then race the botmaster to register the domains.</p><p>The mathematical guarantee is real: the cyclic group structure ensures exactly q - 1 distinct domains per rotation with no collisions and no wasted iterations. The primitive root construction ensures the generator produces every element. The precomputed tables avoid expensive factorization at runtime. The exchange rate seed provides unpredictable entropy from a trusted, globally-consistent, publicly-verifiable source.</p><p>This is not someone who copy-pasted a DGA from a forum. The author understood multiplicative groups modulo primes, knew how to find primitive roots, precomputed smooth-order primes offline, and wired the whole thing to the European Central Bank's daily publications. Whether they learned this from a university course, a textbook, or a cryptography library's source code, the result is unmistakable: this is applied algebra, deployed in production, at scale.</p><p>The original ASERT analysis is preserved on the <a href="https://web.archive.org/web/20160311083109/http://www.arbornetworks.com:80/blog/asert/bedeps-dga-trading-foreign-exchange-for-malware-domains/">Wayback Machine</a>. The proof-of-concept implementation was published on <a href="https://github.com/arbor/bedep_dga">ASERT's GitHub</a>. The sample analyzed here is <code>e5e72baff4fab6ea6a1fcac467dc4351</code> (MD5) /&nbsp;</p><p><code>d0fb1b66b6e4da395892327be9f39adb4533e7759ace39f67bdde0bb1cdaef35</code> (SHA256).</p><p>&nbsp;</p><p><em>Credits: The DGA was originally reversed by Dennis Schwarz at Arbor Networks / ASERT. This post builds on his work, focusing on the mathematical structure he identified but didn't fully unpack.</em></p>

A closer look at how Bedep used foreign exchange data and advanced math to generate hard-to-predict domains, making its command-and-control infrastructure more difficult for defenders to block and disrupt

When Malware Authors Study Algebra: The Group Theory Inside Bedep's DGA

A VM-obfuscated backdoor observed on a single machine in the UK, operated for one year, and vanished without a trace. 

Chasing an Angry Spark

SR. MALWARE ANALYST

Mgr, Threat Analysis Engineering

<p>Malicious software is often designed to hide its true behavior, wrapping its underlying logic in layers that make it difficult to analyze. “Unpacking” is the process researchers use to peel back those layers and reveal what the software is actually doing. But when standard tools run into unfamiliar or custom protections, this process can quickly become slow and highly manual. This project explores whether AI can help bridge that gap, assisting with the more repetitive parts of analysis so researchers can focus on validation, reasoning, and the parts of reverse engineering that still require human judgment.&nbsp;</p><p>Automated static binary unpacking is hard, and it tends to stop being hard in a useful way only when the packer is familiar. There are good unpackers out there, including some internal ones, but once you get out of their comfort zone, unsupported packers, custom routines, or slightly unusual logic can bring the whole process to a halt.&nbsp;</p><p>That makes unpacking a good example of where&nbsp;<a href="https://www.gendigital.com/blog/insights/research/engineering-the-future-of-agentic-threat-hunting">AI may genuinely help</a>. Across our broader work at Gen, we are increasingly using&nbsp;<a href="https://www.gendigital.com/blog/insights/research/engineering-the-future-of-agentic-threat-hunting">AI-assisted workflows</a> to accelerate parts of reverse engineering, technical correlation, and evidence organization, not as a substitute for expert analysis, but as a way to reduce friction in the slower, more repetitive parts of the job. The responsibility for verification and final conclusions still stays with the researcher.</p><p>From that perspective, the idea behind what we call the Last-Resort Unpacker is fairly simple: if AI is good at spotting patterns and translating logic across representations, could it help us recover payloads in cases where traditional static unpacking pipelines fail? We are not trying to solve the hardest forms of protection here. The goal is more pragmatic, to cover more real-world cases, reduce manual effort, and potentially extract logic that can later feed back into our regular unpacking workflows.</p><p>We came up with two approaches.</p><h2>High level design – Variant 1</h2><p>Given a sample to unpack, this simple premise has a few steps. Since we’ll go the most direct but also the riskiest way, let us call it <em>a carpe diem</em> variant.</p><p><strong>Identification:</strong>The first step is to identify which functions might be responsible for the unpacking and which buffers they are targeting. We have decided to use Gemini 2.5 Pro for our workload and complemented it with <em>radare2&nbsp;</em>reverse engineering framework to provide structured access to the disassembly. Once we identify the suspected decryption routine and the corresponding buffers, we may proceed to the translation.</p><p><strong>Translation:</strong> The next step relies on Gemini’s capabilities to rewrite the identified functions into their pythonic representation with prescribed function signatures.</p><p><strong>Verification:</strong> Now we have a Python code that hopefully faithfully represents the machine code identified in the first step. Now comes up the time to admit that we will be cheating on the initial assignment and we have to ensure that we will not be caught. We can easily statically check whether the source code is a valid source code. Now comes the tricky part – we have to verify that the product Python code does not have undesirable side-effects, be it from simple hallucinations or worse – due to hypothetical prompt injection. We have decided to do a strict abstract syntax tree (AST) verification which permits only certain keywords, operations, imports, and calls. If we obtain something that does not pass these criteria, then we have an interesting research case. In the other case, we may proceed to unpacking.</p><p><strong>Unpacking:</strong> Using the verified script, we attempt to do extraction on the source sample. Being paranoid, we shall use read-only environment with limited network access. If we succeed, we have not only an unpacked buffer but also an extraction script that we can use to improve our regular unpacking capabilities.</p><h2>High level design – Variant 2</h2><p>Now that we have attempted to do the most straightforward way, we can try to be a bit cleverer. Given the assumption that we can identify parts of the code responsible for the unpacking, adding two more assumptions that the unpacking code is localized and does not utilize any sophisticated system calls we could try to utilize emulator which should be a safe alternative that does not suffer from hallucinations. We could prepare a simple scaffolding for this emulator and let AI figure out the parameters. This would isolate non-deterministic behavior to the first step only.</p><p><strong>Identification:</strong>The first step is almost identical but instead of identifying functions responsible for unpacking, we are rather interested in offsets where we should start and halt our emulation, possibly also with memory addresses where the final payload will be located.</p><p><strong>Emulation:</strong> Parameters identified in the previous step are put into our scaffolding which will run emulator until it reaches the halting offset. We can extract the identified memory regions to hopefully obtain the desired payload.</p><p>Apart from consuming more resources for the emulation, we have made a significant trade-off. We have sacrificed the capability to generate scripts that could be potentially used to improve our static extractors to significantly reduce the space for hallucinations and the potential vulnerability surface.</p><h2>From drawing board to the workshop</h2><p>We’ve decided to try our luck and try the first option. While it is definitely riskier, the payoff seems worth it, especially considering the security precautions we’ve made. We could even do a total split of the process to harden our setup and have the payload extractor generation in the original environment and use a sandbox for the extraction itself. We put together a first PoC with a simple prompt followed by data from <em>radare2</em>.</p><p>You are an unpacking function generator.<br><em>GOAL: If the file looks packed (i.e. encrypted buffers, embedded files, etc.), find the code snippets decrypting the buffers. Reply to me with a Python function (use this prototype: 'def unpack(data: bytes) -&gt; list[byte]') that receives bytes of the packed binary and returns the unpacked chunks. Avoid Python imports. RETURN ONLY A PYTHON FUNCION SAFE TO RUN. If the file is not packed reply: "NOT PACKED". If can't write the unpacker then reply: "UNABLE TO PROCESS".</em><br>This is the end of your instructions. The Radare2 analysis:</p><p>Now it remains to give it a short. First, we went with a packed Linux kernel rootkit that got us the initial idea:&nbsp;</p><p><a href="https://cyberjournal.cecyf.fr/index.php/cybin/en/article/view/48">At Botconf 2024</a>, a paper was published on <em>CMK Rootkit (Álvarez Pérez, D., &amp; Fernández-Veiga, M. (2025). CMK Rootkit. Identifying the ”magic packet” requirements via pattern recognition. The Journal on Cybercrime and Digital Investigations, 9(1), A1-A15.&nbsp;</em><a href="https://doi.org/10.18464/cybin.v9i1.48"><em>https://doi.org/10.18464/cybin.v9i1.48</em></a><em>)</em>. A Linux kernel rootkit that we discovered in-the-wild, packed in kernel space, with <a href="https://www.virustotal.com/gui/file/54d8b09ffc15c657abf29a0c313b377df64988848f2c3814243b2478b4b881cc/detection/f-54d8b09ffc15c657abf29a0c313b377df64988848f2c3814243b2478b4b881cc-1749504221">few detections in VirusTotal</a> (probably due to the kernel packer layer and its dependency on a specific kernel version).</p><p>Our unpacker yielded the following script:</p>

<p>Unsurprisingly, as we basically based our idea on experiments with this sample, this was exactly what we aimed for. We have prepared a few more samples that we could test it on:</p><ul type="disc"><li data-list-item-id="ec7335952dd9f0c78d6b986b609e617d0">54525d25019d3ea2d40fe006ecc305ebb1ac5663b380019346de43c4886e8685<ul type="circle"><li data-list-item-id="e878959fe541e0581ac2d93f53d7915dc">This PE packed binary uses a key table located at offset 0xe5c1 containing 500 elements. The packed data is located at offset 0x200.</li></ul></li><li data-list-item-id="e24c112bbcdface33504cd11fd00c60a7">1fcf4da2fac671a2f3a07007e9963d3e1063dcfb0b1a0934c66082e8233d7686<ul type="circle"><li data-list-item-id="e999fd8e60c992d59154f20daef223bd0">This PE file contains a payload encoded as a word-based substitution cipher. It implements anti-sandbox protection that checks the available memory (via GlobalMemoryStatusEx) and the system ticks (via GetTickCount64) to determine if the underlying system is a sandbox.</li></ul></li></ul><h2>Closing thoughts</h2><p>This experiment fits into a broader shift in how we are using AI in technical research. The value is not in handing over reverse engineering to a model and hoping for the best. It is in identifying narrow, high-friction parts of the workflow where pattern recognition and code translation can save analysts time, while validation, judgment, and final conclusions remain firmly in human hands.</p><p>A last-resort unpacker will not solve the hardest cases, and it is not a replacement for established tooling or expert analysis. Advanced multi-layer protections, virtualization, and heavily environment-dependent logic still remain difficult territory. But even within those limits, the approach already shows practical value. If it helps recover payloads from unsupported packers, reduces manual effort in repetitive cases, or produces reusable logic that can later improve our existing unpacking pipelines, then it is worth pursuing.</p><p>Seen from that perspective, the point is not that AI is replacing reverse engineers. It is that it can make experienced researchers faster when conventional automation runs out of road.</p>

Exploring how AI can assist in unpacking protected binaries, recovering payloads from unsupported packers, while reducing repetitive analysis

Building a last-resort unpacker with AI

Threat Researcher at Gen

Threat Research Team Lead

<h2>Key points</h2><ul type="disc"><li data-list-item-id="e4b810198ac9891110da1771c3f2d0397">Gen Threat Labs has identified Remus, a new 64-bit infostealer we attribute to the infamous Lumma Stealer family – emerging in the wake of Lumma’s takedown and the doxxing of its alleged core members.</li><li data-list-item-id="ede8006689bbfaba0d6fa856478b3ea79">In this technical blog post, we detail the compelling evidence tying Remus to Lumma across multiple dimensions.</li><li data-list-item-id="ef3f0d531ccf019ab00b98a38b3c43c17">We also describe a previously undocumented Application-Bound Encryption bypass employed specifically by Remus and Lumma.</li><li data-list-item-id="ee0040d0e9463ac082d24fcdbfd7af133">The first Remus campaigns date back to February 2026, with the malware switching from Steam/Telegram dead drop resolvers to EtherHiding and employing new anti-analysis checks.&nbsp;</li></ul><h2>Introduction</h2><p>When the security industry talks about information stealers, Lumma Stealer, without a doubt, has become the notorious icon of this landscape. Not only could it count itself among the most sophisticated, technically advanced, and widespread stealers-as-a-service in the world, but it was also described in a variety of blog posts from basically everyone in the industry, including us.</p><p>In this analysis, we describe a new variant of Lumma Stealer that we call Remus, a new x64 build which we suspected might occur in the foreseeable future after the doxxing of Lumma authors from late August to October 2025. And the future is here.</p><p>Remus brings the same stealing arsenal to the table as we already know from Lumma, capable of stealing stored browser passwords, cookies, cryptocurrency, and much more. However, rather than revisiting Lumma's well-documented capabilities, we focus on the remarkable resemblance between Remus and Lumma, as well as the new techniques Remus introduces, including the use of EtherHiding to resolve C2s, replacing the traditional use of Steam and Telegram dead drop resolvers, and additional anti-analysis checks.&nbsp;</p><p>The attribution of Remus to Lumma is many-fold and described thoroughly throughout the blog post. The main indicators, to name a few, are the use of the same string obfuscation technique, AntiVM checks, direct syscall/sysenter handling, indirect control flow obfuscation, and, most importantly, an almost identical approach to bypassing AppBound Encryption, which we’ve only seen used explicitly by Lumma to date.</p><p>With that said, we can still see active Lumma campaigns all around the world, which makes Remus not a replacement, but a continuous evolution.</p><h2>Development timeline</h2><p>Before diving into the technical details, it is worth noting that during our hunting efforts, we came across several test samples, which even carry a <code>testbuild</code> label embedded directly in the binaries (see Figure 1). We are internally referencing these builds as Tenzor (based on encrypted strings). These test builds are already 64-bit and structurally very close to Remus, suggesting they represent a transitional step, or perhaps even a testing ground, between Lumma and Remus.</p>

<p>This also brings us to the name itself. Both Tenzor and Remus have left a string artifact in the same part of the code, referencing the <code># TENZOR LOG</code> and <code># REMUS LOG</code> strings. Since we have been tracking only test builds with the Tenzor string and Remus is the variant that is being actively distributed in live campaigns, we took the liberty of naming the new x64 Lumma variant after the latter string – Remus.</p>

<p>Notably, all the Tenzor samples carry a build date of September 16, 2025, in their stack-encrypted strings, which is months before the first Remus samples began appearing in the wild at the turn of January and February 2026. The build timing closely coincides with a period when Lumma Stealer suffered a major blow through a doxxing campaign that exposed alleged core members and severely disrupted its operations. This may suggest that some of Lumma’s authors split off, or that Lumma decided to rebrand under a new name in the midst of the doxxing fallout. Nevertheless, at Gen Threat Labs, we track both Remus and Tenzor as variants of Lumma Stealer. That said, the only samples bearing the Tenzor name are the ones that also carry the <code>testbuild</code> label. All others are identified as Remus.</p>

<h2>Similarities between Remus and Lumma</h2><p>When we first started analyzing Remus, something felt familiar, and for good reason. Many of the techniques and design patterns we encountered in Remus closely mirrored those we had already seen in Lumma Stealer. The main difference is that Lumma was 32-bit while Remus is 64-bit, which naturally introduced some variations. Yet, when we looked past the 32-bit versus 64-bit differences and stripped away the obfuscation layers, what remained was strikingly familiar.</p><p>In the following subsections, we highlight the most compelling evidence of a direct connection between Remus and Lumma. Note that this is not an exhaustive list. The overlaps are far more numerous, but we selected just a few that we believe speak for themselves.</p><h3>Forgotten dead drop resolver and string obfuscation&nbsp;</h3><p>For a malware researcher, strings are among the most valuable resources during reverse engineering, and in the case of attributing Remus to Lumma, they proved no different.&nbsp;</p><p>Both Remus and Lumma use a virtually identical mechanism for string obfuscation. The encrypted string is first assembled on the stack using a series of various forms of the <code>mov</code> instruction, followed by a decryption loop that transforms the data byte by byte. The transformation is often further obscured by MBA (Mixed Boolean-Arithmetic) obfuscation and is either inlined or placed in a standalone function. In any case, each string is protected using a unique transformation, making it very difficult to build a universal static decryptor. As a result, emulating the decryption loops is likely the most effective approach for dealing with encrypted strings in both Remus and Lumma.&nbsp;</p>

<p>Notably, the decryption loops are often preceded by several <code>nop</code> instructions (Lumma) or a single <code>nop</code> instruction encoded using multiple bytes (Remus), likely inserted as padding during a custom compilation pass. We are aware that the compilers themselves can emit <code>nop</code> paddings. Still, in both Remus and Lumma, these sequences go beyond the typical, making it yet another indicator linking the two together.</p><p>After decrypting all strings in both Remus and Lumma and comparing them side by side, we found roughly 100 completely identical strings. Most of these, however, could be attributed to virtually any information stealer. The more telling discovery came when we looked at the strings that were not identical – most of them turned out to be semantically the same, just slightly refactored. This alone would already be a strong indicator.&nbsp;</p><p>However, what ultimately confirmed our theory was shifting the string comparison from Lumma vs. Remus to Lumma vs. Tenzor, as Tenzor effectively acts as a bridge between the other two – many of the strings we had previously matched only semantically between Remus and Lumma were still present in Tenzor in their original, unmodified form, directly matching Lumma’s. At the same time, Tenzor also contained very specific strings found exclusively in Remus but not in Lumma, such as <code>B9%????4rnO/@NQe?Nx*</code>, used as a wildcard mask in the ABE-bypass (which we will discuss later), firmly linking it to both sides.</p>

<p>On top of that, among the decrypted Tenzor strings, we also found a Steam dead drop resolver <code>hxxps[://]steamcommunity[.]com/profiles/76561199861614181</code>, which turned out to be the exact same resolver present in multiple confirmed Lumma samples, namely:</p><ul><li data-list-item-id="e7c7ac2aae55af0df2c596fe8463f5a97">002f714f93bed53f165129a820c2d5b72227f1cafac43be19e5e223ce219a5e1 (Lumma)</li><li data-list-item-id="ea0c5ca160e92372f6b8b681415725a00">066c4ab954fc1270ee62c0d7c582c4c691e58e0ffef0c654bc204a46e440d16d (Lumma)</li><li data-list-item-id="e2eae0f6619eb5e4ffb9d1e84b3e057d6">0683f353cf3e101f721f1658e2a554ff7888ff9f2c32e23ceb3d23876864a264 (Lumma)</li><li data-list-item-id="efe40dcac54b87ce148882d49b97105a6">0580ebf601989457f0708799b431fd4d9f5e59d98838282d72936099aa6636da (Tenzor)</li></ul>

<h3>Application-bound encryption bypass</h3><p>Another very strong indicator tying Remus and Lumma together is the way they bypass Application-Bound Encryption (ABE), as both employ a highly specific technique that, until now, we have only observed and have been actively tracking in Lumma Stealer.</p><p>The technique involves injecting a very short shellcode (less than 100 bytes) into the browser process to decrypt the <code>v20_master_key</code>. However, unlike most techniques relying on injection, Lumma as well as Remus do not use this shellcode to call <code>IElevator::Decrypt</code> with the key obtained from the <code>Local State</code> file (the <code>[“os_crypt”][“app_bound_encrypted_key”]</code> JSON field). Instead, it locates the <code>v20_master_key</code> directly in the browser’s process memory, where it is stored in an encrypted form protected by <code>CryptProtectMemory</code> with the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag. It then calls the complementary <code>CryptUnprotectMemory</code> with the same flag from within the browser’s context to decrypt it.</p><p>It is important to note that this in-memory encrypted form of the <code>v20_master_key</code> is protected with a <strong>different key</strong> than the one used to protect the key on disk – it is a separate protection layer that Chromium browsers use to safeguard the key while it resides in memory at runtime. However, since the key is protected with the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag, decryption can only be performed by the same process that encrypted it, which is precisely why injection into the browser process is necessary in this specific bypass. For the curious, we discussed this topic in more detail in our recent&nbsp;<a href="https://www.gendigital.com/blog/insights/research/voidstealer-abe-bypass" target="_blank">VoidStealer blog post</a>.</p><p>From this point on, we will walk through the ABE bypass as implemented in Remus, noting any differences from Lumma’s implementation where applicable. Where no differences are explicitly mentioned, the two implementations work either identically or very similarly.&nbsp;</p><p>So how does Remus find the protected <code>v20_master_key</code>? It begins by walking the browser’s PEB module list, looking for two modules in a single pass: <code>dpapi.dll</code> and the browser DLL (e.g., <code>chrome.dll</code>).&nbsp;</p><p>When <code>dpapi.dll</code> is found, Remus manually parses its PE export directory, reading the DOS header, PE header, and export table through repeated <code>NtReadVirtualMemory</code> syscalls. For each exported function name, it computes a seeded CRC32 hash and compares it against the pre-computed hash&nbsp;corresponding to&nbsp;<code>CryptUnprotectMemory</code>. Essentially, a typical API-hashing, but in a remote process. Once a match is found, it&nbsp;resolves the function’s RVA to obtain its absolute address in the browser’s address space.</p><p>When the browser DLL is found during the same pass, Remus decrypts a hex pattern <code>488d058bcc8d02488901488b024889415b488d41</code>, which was encrypted by the same string obfuscation technique described earlier and stores the value <code>0xEFF87</code> (which corresponds to <code>11101111111110000111</code> in binary) into a variable we labeled as <code>wildcard_mask</code> (see&nbsp;Figure&nbsp;8).&nbsp;</p>

<p>The hex pattern corresponds to a sequence of opcodes that Remus searches for within the browser DLL (e.g., <code>chrome.dll</code>), while the wildcard mask, read from the least significant bit, indicates which bytes must match exactly and which should be treated as wildcards. Lumma does the same but takes a different approach to wildcarding. Instead of a hex mask, it uses a 20-character string <code>B9%????4rnO/@NQe?Nx*</code>, where ? denotes a wildcard and any other character means the byte must match exactly. Notably, this exact string also appears in Tenzor builds, which directly ties Tenzor to the Lumma codebase.</p>

<p>Looking into <code>chrome.dll</code>, we can see that the pattern is designed to locate a <code>LEA</code> (Load Effective Address) instruction that loads a 32-bit displacement pointing to the <code>os_crypt_async::Encryptor</code> virtual function table (vftable). The reason for specifically targeting the <code>os_crypt_async::Encryptor</code> class is that it holds the protected <code>v20_master_key</code>.</p>

<p>Once the pattern is found, Remus reads the 32-bit displacement at <code>pattern_address + 3</code> and computes the absolute address of the <code>os_crypt_async::Encryptor</code> vftable using the formula: <code>target_addr = pattern_addr + disp32 + 7</code> (since the <code>LEA</code> instruction is 7 bytes long and the displacement is relative to the next instruction).&nbsp;It then scans the browser’s memory for this 8-byte vftable pointer by enumerating committed, readable memory regions via <code>NtQueryVirtualMemory</code> and reading each one into a local buffer via <code>NtReadVirtualMemory</code>. Wherever a match is found, it marks the start of an <code>os_crypt_async::Encryptor</code> instance in memory, as the vftable pointer sits at the very beginning of the object. From there, extracting the protected <code>v20_master_key</code> is just a matter of walking the structure at known offsets.&nbsp;</p>

<p>After resolving all the necessary&nbsp;addresses, Remus allocates&nbsp;a buffer&nbsp;in the browser process via <code>NtAllocateVirtualMemory</code>, which serves as both the copy destination and the in-place decryption target.&nbsp;It then constructs&nbsp;a 51-byte&nbsp;shellcode (shown in Figure 12), allocates a second buffer with the <code>PAGE_EXECUTE_READWRITE</code> protection constant for the shellcode itself, and&nbsp;writes it into the browser process via <code>NtWriteVirtualMemory</code>. The shellcode is then executed via <code>NtCreateThreadEx</code>, and Remus waits for its completion using <code>NtWaitForSingleObject</code>.&nbsp;Once the <code>v20_master_key</code> is decrypted, Remus simply reads it from the buffer it previously allocated (and, therefore, already knows its&nbsp;address) via <code>NtReadVirtualMemory</code>.</p>

<p>The injected shellcode differs slightly between Remus and Lumma, but both fundamentally do the same thing – copy the protected <code>v20_master_key</code> into a pre-allocated buffer and jump to <code>CryptUnprotectMemory</code> to decrypt it in place. Both construct the shellcode on the stack, patching in the resolved addresses before writing it into the browser process. The only real difference is that Remus produces a more compact variant (51 vs 62 bytes) by reusing registers. Concrete examples of the injected shellcodes are shown in Figure 13 (Remus) and Figure 14 (Lumma).</p>

<p>Another detail linking the two is that when no browser process is already running, or when injection into an existing one fails, both Remus and Lumma spawn a new one on a separate, hidden desktop, preventing any visible windows from appearing on the user’s screen. They first attempt to open an existing desktop using <code>OpenDesktopW</code> and fall back to creating a new one via <code>CreateDesktopW</code> if it does not yet exist. A new browser instance is then launched via <code>CreateProcessW</code> with <code>STARTUPINFOW.lpDesktop</code> set to this desktop. The only difference is that Lumma uses a hardcoded desktop name&nbsp;<code>ChromiumDev</code> (or previously also <code>ChromeBuildTools</code>), while Remus generates a random 16-character alphanumeric string using a Mersenne Twister PRNG, a natural evolution rather than a change in approach.</p><p>Furthermore, both Remus and Lumma also employ SYSTEM token impersonation as an alternative method to bypass ABE. Interestingly, the two families differ in which method they prefer: Remus attempts SYSTEM elevation first and falls back to shellcode injection, while Lumma tries injection first and resorts to SYSTEM elevation only if it fails. That said, SYSTEM token impersonation for ABE bypass is a well-known technique widely used across many stealer families. What, however, is highly distinctive is the injection-based bypass described above, which to our knowledge has only been used by Lumma and now also Remus.&nbsp;</p><h3>AntiVM CPUID checks</h3><p>Another identical technique shared by Remus and Lumma is their anti-VM check based on the&nbsp;<code>cpuid</code>&nbsp;instruction with&nbsp;<code>EAX</code>&nbsp;set to&nbsp;<code>0x40000000</code> – the hypervisor vendor identification leaf. When executed inside a virtual machine, the processor returns the hypervisor’s vendor signature in <code>EBX:ECX:EDX</code>. Both Remus and Lumma specifically check the&nbsp;<code>ECX</code>&nbsp;portion (4 bytes) against five known hypervisor signatures: KVM (<code>KVMKVMKVM</code>), QEMU/TCG (<code>TCGTCGTCGTCG</code>), VMware (<code>VMwareVMware</code>), VirtualBox (<code>VBoxVBoxVBox</code>), and Xen (<code>XenVMMXenVMM</code>). Notably, both check <strong>the same substrings</strong> of hypervisor names <strong>in the same order</strong>, and the checked substrings are obfuscated.&nbsp;</p><p>The decompiled code performing the check can be seen in Figure 15 (Remus) and Figure 16 (Lumma). For clarity, we omitted the decryption loops from the Lumma listing, but they are the same decryption loops we described earlier.</p>

<h3>Crypter check</h3><p>When executed without a protective layer, both Remus and Lumma display a warning dialog before proceeding with their malicious payloads (see Figures 17 and 18). The purpose of this mechanism is twofold: to discourage distributors from spreading the raw, unprotected executables, which are more easily detected by security products, and to prevent less skilled affiliates from accidentally infecting their own machines.</p>

<p>This type of check is relatively rare. So far, only a handful of families have been observed employing it – namely, <a href="https://outpost24.com/blog/lummac2-anti-sandbox-technique-trigonometry-human-detection/">Lumma</a>, <a href="https://research.checkpoint.com/2025/rhadamanthys-0-9-x-walk-through-the-updates/" target="_blank">Rhadamanthys</a>, Remus, and <a href="https://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation">more recently also AuraStealer</a>, albeit AuraStealer takes a slightly different approach (rather than simply displaying a warning and waiting for the user to click <code>Yes</code> or <code>OK</code>, it additionally requires the user to enter a randomly generated code shown in the dialog).&nbsp;</p><p>However, despite the surface-level similarity, the underlying implementations differ. <a href="https://research.checkpoint.com/2025/rhadamanthys-0-9-x-walk-through-the-updates/">Rhadamanthys displays its warning dialog</a> using <code>MessageBoxW</code>, whereas both Remus and Lumma invoke it through a direct <code>NtRaiseHardError</code> syscall.&nbsp;</p><h3>Direct syscalls/sysenters</h3><p>Both Remus and Lumma make use of direct syscalls/sysenters. While their implementations differ in some details, mostly as a natural consequence of the 32-bit vs 64-bit architecture, the overall design is strikingly similar.</p><p>One of the first things both do upon execution is that they enumerate all <code>Nt</code>-prefixed exports from <code>ntdll.dll</code> and build a lookup table mapping their name hashes to the corresponding Syscall Service Numbers (SSNs). The process is the same in both cases: they walk the <code>ntdll.dll</code> export directory, hash each matching export name, and scan the first 32&nbsp;bytes of each function’s prologue to extract the SSN from the <code>mov eax, &lt;SSN&gt;</code> instruction. The extracted SSN is then stored alongside the export’s name hash in a hash-to-SSN lookup table.&nbsp;</p>

<p>To invoke a specific syscall/sysenter, both perform a linear scan of the lookup table until they find an entry whose hash matches the requested function. The SSN from the matching entry is then passed to a central dispatcher, which we refer to as <code>lumma_sysenter</code> and <code>remus_syscall</code>. The calling conventions of those dispatcher functions are nearly identical: the first argument is the SSN, followed by the argument count and the variadic arguments themselves. The only difference is that Lumma expresses the argument count in bytes (<code>number_of_arguments × 4</code>), whereas Remus passes the actual count directly.</p>

<p>The dispatchers themselves look different at first glance, but this is mostly a consequence of ABI differences between 32-bit and 64-bit code. The core logic is the same: arrange the syscall/sysenter arguments and invoke the kernel. Remus does so directly via the&nbsp;<code>syscall</code>&nbsp;instruction. Lumma, on the other hand, resolves a dispatcher address during the hash-to-SSN initialization through a fallback chain: it first attempts to resolve the <code>Wow64Transition</code> export from <code>ntdll.dll</code> using API-hashing, then tries the <code>TEB-&gt;WOW32Reserved</code>, and finally, if that value is <code>NULL</code>, falls back to a hardcoded <code>sysenter</code>stub. Each of these fallback mechanisms ultimately achieves the same outcome – a transition from user-mode 32-bit code into the kernel.</p>

<p>Separately from the 32-bit <code>sysenter</code> dispatch, Lumma also employs Heaven’s Gate, a&nbsp;technique that allows 64-bit code to be executed from within a 32-bit process on a 64-bit operating system. Lumma uses it specifically when interacting with 64-bit browsers (during the ABE bypass) to call native 64-bit <code>ntdll.dll</code> functions that have no NtWow64 equivalents – namely <code>NtCreateThreadEx</code> to start the injected thread, <code>NtFreeVirtualMemory</code> for clean up, and <code>NtQueryVirtualMemory</code> to query the browser’s memory layout. The remaining cross-process operations, such as memory reads, memory allocations, and shellcode writes, are handled through standard NtWow64 sysenter calls (<code>NtWow64ReadVirtualMemory64</code>, <code>NtWow64AllocateVirtualMemory64</code>, and <code>NtWow64WriteVirtualMemory64</code>). Since Heaven’s Gate is inherently a WoW64 technique applicable only to 32-bit processes running on 64-bit systems, and Remus is a 64-bit binary, it has no equivalent. Remus simply uses direct syscalls for all these operations.</p><h3>Shared code patterns</h3><p>Another striking similarity is the layout of many functions, which shows a remarkable resemblance and, in some cases, is nearly identical (if we disregard the obfuscation and differences caused by 32-bit vs 64-bit code). While there are many such functions, we highlight two concrete examples. The first is the heap allocation wrapper, which Remus and Lumma implement in a virtually identical manner, as illustrated in Figures&nbsp;24 and 25. Furthermore, the same holds for other memory helpers, such as the reallocation and deallocation wrappers.&nbsp;</p>

<p>The second example is the clipboard-stealing routine (Figures 26 and 27). Both implementations follow the same sequence: they open the clipboard, retrieve its contents, convert it from UTF-16 to UTF-8, decrypt the output filename <code>Clipboard.txt</code> using a stack-based decryption loop, and finally append the result to the exfiltration archive. The only difference is that Remus wraps each API call in a thin stub, which, however, might just be a result of different compiler optimization.</p>

<p>Notably, although the vast majority of API calls are obfuscated through API hashing, the clipboard functions <code>OpenClipboard</code>, <code>GetClipboardData</code>, and <code>CloseClipboard</code> are among the very few unobfuscated imports in both binaries.</p><p>Equally notable is the entry point structure. Both Remus and Lumma begin executing their malicious logic directly from the PE entry point (the&nbsp;<code>start</code>&nbsp;function), with no runtime initialization whatsoever. In a typical C/C++ binary, the entry point calls the CRT startup routine, which sets up the heap, initializes global variables, registers exception handlers, processes the command line, and invokes static constructors before eventually calling&nbsp;<code>main</code>. However, neither Remus nor Lumma follows this pattern. Instead, both jump directly from the entry point into their core logic: resolving modules and APIs, performing anti-analysis checks, initializing C2 communication, and exfiltrating data, ending with a direct call to <code>ExitProcess(0)</code>. This suggests both were compiled without linking to the standard C runtime, likely a deliberate choice to minimize the binary size and reduce unnecessary dependencies.</p><p>The structural similarities extend further. Both binaries share the same section layout, with each section serving an identical semantic role. Even the C2 configuration follows the same pattern: in both cases, the encrypted blob, key, and nonce are statically embedded in the <code>.rdata</code> section and decrypted at runtime using ChaCha20.</p><p>To summarize, we strongly believe the degree of similarity between the two codebases is too deliberate to be a coincidence, pointing to a single, shared origin.</p><h3>Indirect control flow obfuscation</h3><p>Finally, both Remus and Lumma make use of control flow obfuscation by replacing direct jumps with indirect ones, where the target is read from an offset stored in the <code>.data</code> section. As shown in Figure 28, this technique takes several forms. In its simplest case, the target address is resolved by a single pointer dereference (highlighted in yellow). In more complex cases, it extends to a full jump table, where a computed index selects among several target addresses stored consecutively in the <code>.data</code> section (highlighted in orange). Lastly, in some cases, the target address is first loaded into a register (highlighted in blue) and then jumped to via a register-based indirect jump (highlighted in pink).</p>

<p>Although functionally equivalent to normal jumps, the indirection&nbsp;complicates the control flow analysis in two ways. First,&nbsp;some of the indirect jump targets cannot be statically determined (for example, when the register holding the target address can be set in multiple different preceding basic blocks, each potentially loading a different target), leaving the control flow graph incomplete as the connections between basic blocks are lost. Second, some of these orphaned blocks end up being misidentified as standalone functions, further disrupting function boundary detection and leading to a broken, incomplete decompiler output. Notably, Figure 28 also provides another glimpse of the <code>nop</code> paddings discussed earlier.</p>

<p>Both binaries contain hundreds of these indirect dispatch points, and once again, if we set aside the minor differences arising from the 32-bit vs. 64-bit differences, the obfuscation is virtually identical. Although removing the obfuscation entirely requires more effort, the IDA’s decompiler output can be significantly improved by marking the referenced offsets as constants. For those interested, we covered this trick in our <a href="https://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation">AuraStealer blog post</a>, along with other approaches for tackling control flow obfuscation.</p><h2>What’s new in Remus</h2><p>Having covered the key similarities between Remus and Lumma, let’s now focus on what is new in Remus. The core architecture is clearly inherited from Lumma. Still, several changes go beyond a straightforward 32-bit-to-64-bit port. These range from refactored strings and more thorough device fingerprinting to a different exfiltration archive format, a switch from FNV-1a to CRC32 for API hashing, and an overhauled C2 communication that has been restructured to deliver dynamic configurations incrementally rather than in a single large blob. &nbsp;</p><p>The most significant changes, however, are the replacement of traditional Steam/Telegram dead drop resolvers with blockchain-based C2 resolution using EtherHiding, a persistence technique allowing attackers to store malware-related data (such as domains, payloads, encryption keys, among others) on blockchain as a smart contract, and the introduction of additional anti-analysis checks.</p><h3>Dead drop resolvers via EtherHiding</h3><p>Both Remus and Lumma employ dead drop resolvers, a mechanism in which the malware does not contact its C2 server directly but instead retrieves the C2 address at runtime from an intermediary hosted on a legitimate platform. This makes the infrastructure significantly more resilient, as if a C2 domain is taken down, the dead drop can be adjusted to point to a new server without the need to distribute an updated binary. Moreover, the dead drop URLs typically reside on well-known, high-reputation services, making them more difficult for security vendors to block without collateral damage.</p><p>Where the two differ is in the choice of platform. Lumma relies on Steam profiles and Telegram channels, typically encoding C2 URLs using ROT-15, while Remus goes a step further, replacing these with Ethereum smart contracts. At runtime, it sends an <code>eth_call</code> JSON-RPC request to a hardcoded contract address via a public RPC endpoint and extracts the C2 URL from the hex-encoded response. Because blockchain data is decentralized and immutable, there is no platform operator to report abuse to, making the dead-drop effectively immune to takedowns.</p><p>Just like Lumma’s Steam profile URL, Remus stores the smart contract address separately from the static C2 configuration, as a stack-encrypted string. Notably, after the JSON response is retrieved, the C2 address is, at least for now, merely hex-encoded in the <code>result</code> field (no other obfuscation, such as ROT-15 in case of Lumma, is applied).</p>

<h3>Additional anti-analysis checks</h3><p>Remus introduces two additional anti-analysis mechanisms, both evaluated early during startup (before connecting to its C2). If either check fails, the malware silently terminates via <code>ExitProcess(0)</code>.&nbsp;</p><p>The first check targets sandbox and analysis tool DLLs. Remus walks the PEB's <code>InLoadOrderModuleList</code>, hashes the name of every loaded module using a CRC32 variant with a custom initialization constant, and compares the result against 11 pre-computed hashes stored in its <code>.rdata</code> section, each corresponding to a module commonly injected by analysis environments, including Avast sandbox (<code>snxhk.dll</code>), Sandboxie (<code>sbiedll.dll</code>), Comodo sandbox (<code>cmdvrt32.dll</code>, <code>cmdvrt64.dll</code>), and several others.&nbsp;</p>

<p>If no sandbox DLLs are detected, Remus proceeds by expanding the path&nbsp;<code>%UserProfile%\Documents\Outlook Files</code>, enumerating all&nbsp;<code>*.pst</code>&nbsp;files in that directory, and checking for the presence of&nbsp;<code>honey@pot.com.pst</code>, which would be treated as a sandbox environment.&nbsp;</p><h2>Summary</h2><p>In this analysis, we described our findings regarding a new x64 variant of Lumma Stealer, which we call Remus. We focused on various similarities and differences between Lumma and Remus, thoroughly describing the technical aspects of both. We also provided a timeline, referencing the very first test builds of Remus (historically called Tenzor), which correlate with the extensive doxxing of Lumma authors from late August to October 2025.</p><p>The key aspects that allowed us to attribute Remus as a new x64 version of Lumma are the use of the same string obfuscation technique, AntiVM checks, direct syscall/sysenter handling, indirect control flow obfuscation, and, most importantly, an almost identical approach to bypassing AppBound Encryption, which we’ve only seen used by Lumma to date.</p><p>Remus, however, is not merely an x64 port of Lumma. It also introduces a couple of novel techniques in how it operates, including the use of EtherHiding instead of a traditional approach of using Steam/Telegram as dead drop resolvers, as well as additional anti-analysis checks to evade a wider range of security vendors.</p><h2>Indicators of Compromise (IoCs)</h2><p>A complete IoC list is available on our <a href="https://github.com/gendigitalinc/ioc/tree/master/Remus">GitHub</a>.</p><h3>C2 domains</h3><p>hxxp[://]217[.]156[.]122[.]12:80<br>hxxp[://]217[.]156[.]122[.]57:80<br>hxxp[://]217[.]156[.]122[.]75:1378<br>hxxp[://]45[.]151[.]106[.]110:80<br>hxxp[://]80[.]97[.]160[.]155:80<br>hxxp[://]86[.]107[.]168[.]103:80<br>hxxp[://]94[.]231[.]205[.]229:28313<br>hxxp[://]adveryx[.]biz:6573<br>hxxp[://]backbou[.]biz:5902<br>hxxp[://]baxe[.]pics<br>hxxp[://]baxe[.]pics:48261<br>hxxp[://]borscer[.]biz:9592<br>hxxp[://]buccstanor[.]pics<br>hxxp[://]buccstanor[.]pics:28313<br>hxxp[://]buccstanor[.]pics:48261<br>hxxp[://]chalx[.]live:5902<br>hxxp[://]chromap[.]biz:4219<br>hxxp[://]coox[.]live:28313<br>hxxp[://]drymoge[.]biz:4192<br>hxxp[://]forestoaker[.]com:6290<br>hxxp[://]gluckcreek[.]online:48261<br>hxxp[://]intem[.]lat:9592<br>hxxp[://]interxo[.]biz:7481<br>hxxp[://]josegza[.]biz:8521<br>hxxp[://]krondez[.]com:28982<br>hxxp[://]lazzo[.]bet:3989<br>hxxp[://]managew[.]biz:5902<br>hxxp[://]navelum[.]biz:3201<br>hxxp[://]nitroca[.]biz:6782<br>hxxp[://]outcrol[.]biz:4895<br>hxxp[://]padaz[.]pics:4219<br>hxxp[://]parky[.]pics:3989<br>hxxp[://]prickaz[.]biz:2039<br>hxxp[://]remnane[.]biz:5692<br>hxxp[://]ropea[.]top:28313<br>hxxp[://]siltsoh[.]biz:7481<br>hxxp[://]texakgi[.]cloud:3849<br>hxxp[://]vinte[.]online<br>hxxp[://]vinte[.]online:28313<br>hxxp[://]woodena[.]biz:7821<br>hxxp[://]zadno[.]run:4219<br>hxxps[://]cheekiez[.]biz<br>hxxps[://]nobleckly[.]biz</p><p>&nbsp;</p><h3>Remus SHA-256 (Non-exhaustive)</h3><p>0a8f734f10400f7ae8fef591147e78dab6350089683be84c1cb6c82113cb1319<br>25e74a76f2f3601abcb20fd743a7e3cf3befd5a3838c7501af5d87d293233809<br>4428c3ffe2532f162f31d7573bbc1cca2299195421da3d8e8a3e535e9fc42b08<br>484e3ab5d425a97819f01dcc330e005dc444c51625bfdcd7ea9a3954018d1fc9<br>64db10e76b46be8db36e02993d36559bc3f86606c9ea955731872b716c8f0c69<br>788b56e9be2f1dd6a977dce0265f293ab42d3e8ffb287ab584e169fbf115da1f<br>8653d7158486aa10fc0078c3ca9318cd7ace05d4b3e6f3b1fb84ffb7a6a339ec<br>a4f111e5425690fcd384c62ecb5b57b0f645925572af3541748e01d810cd2b40<br>ab2e47720388fa201e242552f8d8b82363c6c52f6c63fa3fec9dce027cb12e77<br>bc11d036fe59abb3915f736307c56d2fd43e8127e46c31f926eeda864f4d66dc<br>c3f7cea80dbafaa90a88b28a6dfb1227caaf5c2a29f0ce06bf663d6ed2cfc079</p><p>&nbsp;</p><h3>Tenzor SHA-256&nbsp;</h3><p>0580ebf601989457f0708799b431fd4d9f5e59d98838282d72936099aa6636da<br>7a25253e6d8d9ccf62a67f8014cacb301daf9e40f1b68ecc7f354d6896d16960<br>cab7855ccfca19a06eea76e0e170f592dcc95906ecfa5436f5a11947e04e63d5<br>dfbeab30d14df9104a95de83ab4690308c653eb0c3706554687c45a77adc1385</p>

The Lumma Rebrand We’ve Been Waiting For?

Remus: Unmasking The 64-bit Variant of the Infamous Lumma Stealer

Senior Malware Analyst

<p>You need Photoshop for a side project. The subscription is expensive. You search for a free Mac download, land on a site that looks good enough, and within an hour, the app is running. A few weeks later, your Mac is hot even when you're not doing much. The fans stay loud. The battery drains fast. Activity Monitor shows a process with a name you do not recognize, chewing through CPU in the background. That "free" app may have cost you your machine's processing power, your saved passwords, your browser sessions or access to the files on your disk. That trade is more common than many Mac users think.&nbsp;</p><p><strong>In the first 48 hours after we began tracking one recent cracked software distribution wave, our protections blocked about 108,000 attempts to launch these applications on macOS systems.</strong> This is a count of blocked launch attempts recorded by one of our shields, not unique devices. Of those detections, 58% came from Macs still supported by Apple, while 42% came from systems that no longer receive Apple's current support. The pattern is already clear: even for MacOS, cracked apps are still a practical delivery channel for cryptominers, infostealers, adware and long-term persistence.&nbsp;</p><h2>The signature that keeps showing up&nbsp;</h2><p>Open enough cracked Mac apps and you start to see recurring patterns. One of the patterns we see quite often is a string left by the TNT group:&nbsp;</p><p><code>.TNT - why join the navy if you can be a pirate&nbsp;</code></p><p>Still, this story will not be about them but rather the whole distribution pipeline around them.&nbsp;</p><p>A crack may start as a modified version of a legitimate app with license checks removed. After that, it often moves through mirror sites, torrent uploads, forum reposts, Telegram channels and re-packed archives. Every handoff is another chance to add something extra to the file. That is the real problem. Users rarely download a package from a trusted source. They are downloading whatever the last person in the chain decided to upload.&nbsp;</p><h2>Why people still download cracked Mac apps&nbsp;</h2><p>Cost is one of the obvious reasons. A subscription can feel absurd when you need an app for one class, one freelance project or one weekend task. There is another reason too: old hardware. Plenty of people still use older Macs that work well enough for everyday tasks, but no longer run the latest macOS release. Once that happens, the legitimate software market starts shrinking around them. New versions no longer support old releases; official downloads for old versions get harder to find and compatibility drops. The machine still works, but the software ecosystem has moved on.&nbsp;</p><p>That is exactly when cracked software starts to look practical. It promises a version that runs on old hardware, costs nothing and solves the problem immediately. What it does not say is that older Macs are often already at a disadvantage. They may miss newer security features and recent patches. If the installation also tells the user to weaken built-in protections, the system becomes much easier to abuse.&nbsp;</p><h2>How cracked apps reach users&nbsp;</h2><p>Cracked macOS software spreads through a loose supply chain. Some files come from dedicated download sites that look almost like real app stores. Others spread through torrent trackers, warez forums, Telegram channels, Discord communities and file-sharing links posted on SEO-driven "download" pages. The packaging changes, the mirrors change and the hostnames change. The model stays the same.&nbsp;</p><p>The important point is not which site was involved. It is that every re-upload, re-zip and re-pack creates another opportunity to insert a payload. The original crack may be clean, but the version on a mirror site may already tell a different story; the torrent may include an extra installer, the archive posted to a chat channel may have been modified again. There is usually no reliable way for a typical user to tell the difference before running it.&nbsp;</p>

<h2>The installation guide often tells users to defeat macOS security&nbsp;</h2><p>This is where the risk becomes very concrete. MacOS includes several protections that are meant to stop exactly this kind of software from running freely. Gatekeeper helps block apps from unidentified developers. Notarization checks software distributed outside the App Store for known malicious content. System Integrity Protection, or SIP, helps prevent changes to critical parts of the system. Permission controls limit what apps can read and modify. And cracked software install guides often tell users to work around those protections step by step.&nbsp;</p><p>Typical instructions often include:&nbsp;</p><ol type="1"><li data-list-item-id="eae2da4be03f3a2b670f4a813338399f9">Disable Gatekeeper so unsigned apps can run.&nbsp;</li><li data-list-item-id="eb606b7c024052b2cb4a67f27b385f2ce">Boot into Recovery Mode and disable SIP.&nbsp;</li><li data-list-item-id="ef4a9d11e409c539f6414805c6023c5d8">Launch the crack tool with administrator privileges.&nbsp;</li><li data-list-item-id="e10349530c6710071bdfe76740183e59c">Grant Full Disk Access when prompted.&nbsp;</li></ol>

<p>This matters because an attacker does not need to discover an advanced exploit if the user has already done the hard part for them. If an unsigned binary gets root privileges and Full Disk Access on a system with weakened protections, it has significantly more room to do real damage. On older Macs, the risk is even worse. When the OS is already behind on security updates, turning off the protections that remain can leave the system exposed for months.&nbsp;</p><h2>What actually gets bundled with these downloads&nbsp;</h2><p>Unfortunately, these payloads are a bit like a box of chocolates; you never know what you're gonna get. We tried to go through stats to identify some main types of these unwanted payloads.&nbsp;</p><ul type="disc"><li data-list-item-id="ed1f60a74a2f7183221b82c6518f4a758"><strong>Cryptominers</strong>, such as XMRig, aim to use computer resources to mine cryptocurrency. Thus, besides the original app, the Mac will also do a second job in the background, usually resulting in high CPU usage, loud fans and significantly reduced battery life.&nbsp;</li><li data-list-item-id="ee96f909440c5a529a92515c4c36aebfc"><strong>InfoStealers</strong>, on the other hand, are trying to stay under the radar, collect various data on the device and send it to the control server. Usually, they are after saved passwords, cookies, session tokens, wallet data or documents as these can be monetized quickly. Remember that full disk access in step 4? That one made it a whole lot easier.&nbsp;</li><li data-list-item-id="ecff0fdd0b1b2cd2b26f1850f4425166b"><strong>Backdoors</strong> are usually trying to stay low and provide persistent access to the computer, be it to deploy further malware or use the computer as a staging point for future actions (e.g., email campaign). On macOS, this usually means LaunchAgents or Launch Daemons that run automatically after rebooting.&nbsp;</li><li data-list-item-id="efc64564b7278b592130a283c2184891b"><strong>Adware and Browser Hijackers</strong> are less dramatic than previous categories but still annoying, nonetheless. They may redirect your search, inject ads, change browser settings and commit affiliate fraud (e.g., injecting their affiliate links) - as the monetization relies on abuse of (semi-)legitimate internet infrastructure; these are the easiest ways to monetize. To be clear, the point is not that every cracked app is booby-trapped with these payloads. Unfortunately, obtaining cracked software may require you to trust an anonymous supply chain with system-level access to your systems, with limited options to verify what you got.&nbsp;</li></ul><h2>The Mac myth still helps to keep this pipeline alive&nbsp;</h2><p>A lot of people still carry some version of the old belief that Macs do not really get malware. That idea was always overstated, as this usually relied on Macs being a smaller market for malware authors than the Windows ecosystem. Today, with many threats going multi-platform, this idea is actively dangerous.&nbsp;</p><p>While macOS has its own built-in protections that manage to provide some level of protection, they still rely on the user installing the software from trusted sources and crucially (but unsurprisingly), the user must not turn them off to have any effect. The moment a user starts disabling Gatekeeper, turning off SIP and granting broad permissions to unsigned binaries, the system is left exposed.&nbsp;</p><p>This combination makes cracked software on macOS quite an attractive delivery method. Leading the user to disable their AV is one of the oldest tricks in the book, but this one takes it a step further by implicitly banking on a still-popular myth to avoid raising suspicion.&nbsp;</p><h2>Is there a way back?&nbsp;</h2><ol type="1"><li data-list-item-id="e36f761d5067b1f3b97fcb41250f533d3">Re-enable SIP in Recovery Mode:&nbsp;</li></ol><p><code>csrutil enable&nbsp;</code></p><ol type="1"><li data-list-item-id="e13ce9ed1846fa4c90cd5595cc3c40d05">Then re-enable Gatekeeper in Terminal:&nbsp;</li></ol><p><code>sudo spctl --master-enable&nbsp;</code></p><ol type="1"><li data-list-item-id="e3f587d06dd59561a968a5024f26dcf20">Check common persistence locations. Unfamiliar .plist files or oddly named helper items are worth investigating.&nbsp;</li></ol><p><code>~/Library/LaunchAgents/&nbsp;</code><br><code>/Library/LaunchAgents/&nbsp;</code><br><code>/Library/LaunchDaemons/&nbsp;</code><br><code>~/Library/Application Support/&nbsp;</code></p><ol type="1"><li data-list-item-id="e844d0ecf4d5c86132be363b690f9a29c">Run a full system scan using e.g., Avast for Mac or Norton Security for Mac. Running it on the <em>Downloads</em> folder might not be enough.&nbsp;</li><li data-list-item-id="ead808099598a77195a50d27149505dc1">Consider changing important passwords. Start with email, banking, work accounts, cloud storage, and any password manager. This is especially crucial if the full system scan identified malware.&nbsp;</li><li data-list-item-id="eb0715b9167c2c31908d76fb610c0f80e">Watch for follow-on activity. Look for login alerts, suspicious financial activity and unusual browser behavior that continue after removing the cracked app. Consider a clean install if the system was compromised for an extended period. The safest approach is a full macOS reinstall from Recovery Mode. Back up personal files (documents, photos — not applications), wipe the drive, reinstall macOS and restore only verified clean data.&nbsp;</li></ol><h2>The real price of "free"&nbsp;</h2><p>Cracked software might sound attractive because it solves an immediate problem. It saves money. It keeps an old Mac useful for a little longer. It avoids a subscription that people don't want to pay. But the actual deal may look different once you include the hidden terms. Even when the original crack is benign, things may get tangled once you consider distribution, potentially including other middleman in the transaction, with each possibly vying for their share.&nbsp;</p><p>If the goal is simply to get work done, the safer alternatives are boring but real: official older installers when vendors provide them, open-source alternatives, lower-cost one-time-purchase tools, student licensing or used hardware that can still run a supported macOS release.&nbsp;</p><h2>Our role: Protection, not judgment&nbsp;</h2><p>As a company behind reputable antivirus solutions such as Avast, AVG and Norton, we want to be clear: we don't judge users by the software choices they make. We understand that people might turn to cracked software to solve their problems, be it tight budgets, old hardware that still works or needing an app for a short-term project. We get it.&nbsp;</p><p>Our job is not to be the software police.&nbsp;</p><p>Our job is to protect you from threats that hide in the places where you might be looking for solutions.&nbsp;</p><p>When our detection systems flag a cracked app, it is not because we disapprove of your choice to use it. It is because we found something genuinely malicious bundled with it - a cryptominer, an infostealer, a backdoor or other malware that puts your system and data at risk.&nbsp;</p><p>If we block a cracked app, you can be confident that we detected something nasty lurking inside. Our goal is to let you make informed decisions about the software you install, with full knowledge of what risks come with it.&nbsp;</p><h2>Final thought&nbsp;</h2><p>The quote that TNT and other groups stamp on cracked software, "Why join the Navy if you can be a pirate?", was about thinking differently. About building something new instead of following the established path. About creativity and independence. Using it to brand cracked software misses the point entirely. The real pirates in this story are usually not the users trying to save money or keep an old Mac useful for a little longer. They are the actors further up the chain: repackagers, mirror operators, uploaders and malware distributors who turned cracked software into a monetization engine.&nbsp;</p><p>That is what makes this ecosystem work so well. The person downloading the app thinks they are taking a shortcut. They might be stepping into a supply chain built to extract value from them, whether that means mining cryptocurrency in the background, stealing credentials, hijacking browser traffic or keeping a foothold on the machine for later.&nbsp;</p><p>Still, the end decision is not ours to make.&nbsp;</p><p>If you make your decision, step with care.&nbsp;</p><p>As you might eventually realize that you did not join the Navy. You did not become a pirate. You just ended up as cargo.</p>

Though you might sometimes become cargo. Inside the macOS Cracked Software Pipeline 

Why Join the Navy if You Can Be a Pirate? 

Staff Scientist, AI

<p><strong>The deepfake story you think you know is incomplete.</strong>&nbsp;</p><p>When most people hear “deepfake,” they picture a fake face.&nbsp;</p><p>One important nuance: <strong>a deepfake face does not automatically mean a scam</strong>, and a scam does not even require a deepfake face at all. Visuals can be a useful clue, but <strong>identifying synthetic media is getting more complex</strong>, and simplistic “looks fake” judgments are increasingly unreliable. That is why we lean on <strong>multiple signals</strong>, including audio analysis and transcript, to reason about intent and behavior.&nbsp;</p><p>Connecting the term deepfake with deceit makes sense, it is the most visual part of the problem, and it has become a cultural shorthand for deception. But in real-world scam campaigns, the face is often just packaging. The engine is usually the message, including the script, the call to action, the pressure, and the promise.&nbsp;</p><p>That's why our detection starts where the persuasion lives: the content, especially the audio. Scam videos often reuse the same pitches, again and again, such as “guaranteed returns,” “limited-time access,” “you’ve been selected,” “act before it’s too late.” Even when the visuals look polished, even when the footage looks familiar, the audio can give away the intent.&nbsp;</p><p>As we continued our research on what makes a deepfake a scam, we started asking another question that changed what we looked for:&nbsp;</p><p><strong>Once a video is already labeled as scam content by our audio and content analysis, which faces keep showing up across those scam videos?</strong>&nbsp;</p><p>The answer was not only “famous people.”&nbsp;</p><p>It was actually a set of VIPs that do not exist.&nbsp;</p><h2>Why we looked for “VIPs” in scam video&nbsp;</h2><p>In scam ecosystems, repetition is rarely an accident. Criminals optimize what works, then scale it.&nbsp;</p><p>So instead of asking “who is this person?” we asked “how often does this face appear across scam-labeled videos, and where does it show up?” If the same presenter is repeatedly used as a delivery vehicle for scam scripts, that recurrence becomes a signal of reuse, coordination, and industrialization.&nbsp;</p><p>To do that, our proof of concept takes scam-labeled videos, extracts faces, generates compact visual descriptors, then groups them by similarity. The most prevalent identities in that scam-labeled set become “VIPs,” meaning faces that appear unusually often across scam content. We use faces here as an additional <strong>signal </strong>for grouping and speed, to connect related scam videos and spot scale. It complements audio and transcript analysis, it is not the primary factor deciding whether a video is a scam.&nbsp;</p><p>We expected the usual outcome: a list dominated by high-profile public figures that scammers frequently impersonate.&nbsp;</p><p>And yes, those faces are there. Public figures like Elon Musk have become recurring bait in investment-themed scams, giveaways, and “exclusive opportunity” narratives.&nbsp;</p><p>But the most important finding was what appeared alongside the celebrity targets.&nbsp;</p><h2>VIPs that don’t exist&nbsp;</h2><p>Some of the most prevalent “presenters” in scam video are not real people.&nbsp;</p><p>They look like ordinary talking-head hosts: friendly expression, neutral styling, camera-ready delivery. They speak clearly, they project confidence, and they often appear in exactly the kind of format people have learned to trust: a calm explainer, a “news-style” segment, a professional endorsement, a casual recommendation.&nbsp;</p><p>But they are AI avatars, synthetic presenters generated to be reused. To be clear, an AI avatar is not automatically a scam; what makes these specific presenters relevant is that we found them recurring inside videos already labeled as scams based on the message and behavior.&nbsp;</p><p>In general, proving that a person on screen is synthetic can require detailed and expensive analysis, things like lip-sync consistency, motion artifacts, and other forensic techniques. Our approach is different: we identify and aggregate recurring avatar identities from scam-labeled videos using lightweight visual descriptors and similarity grouping. That gives us a faster, cheaper way to recognize AI avatar presenters that are not yet “known,” but are already showing up frequently in the wild.&nbsp;</p><p>We are confident about this classification. These are not ambiguous “maybe enhanced” clips. They are AI avatar outputs, and we have also seen the supply chain behind them, including avatar creation services marketed openly on freelance marketplaces like Fiverr.&nbsp;</p><p>This matters because it changes the threat model.&nbsp;</p><p>If you only think about deepfakes as “someone impersonating a celebrity,” you miss the bigger shift: scammers are increasingly manufacturing credibility without impersonating anyone at all.&nbsp;</p><p>That might sound like a minor distinction, but it changes the incentives.&nbsp;</p><ul type="disc"><li data-list-item-id="e908326041bf0d633ca65ffb02170a711">A celebrity deepfake creates obvious controversy and is easier for platforms and victims to challenge.&nbsp;</li><li data-list-item-id="e3d8efe40c9161bf5c06bb597444c608c">A synthetic presenter has no “real person” attached, no victim to complain, and no public figure to debunk the content.&nbsp;</li><li data-list-item-id="efe3688ea8aebb1aa6c655308f6223fda">The same synthetic presenter can be reused endlessly, across topics and languages, with minimal cost.&nbsp;</li></ul><p>In short, these “VIPs” are not famous because they are recognized, they are VIPs because they are operational assets in scam production.&nbsp;</p><h2>From celebrity deepfakes to avatar farm&nbsp;</h2><p>Celebrity impersonation is still here, and it will remain attractive. Reputation is a powerful shortcut to trust.&nbsp;</p><p>But impersonation has trade-offs. It is high-profile, easier to report, and riskier for scammers. It can also be brittle, a single debunk can collapse a campaign.&nbsp;</p><p>Synthetic presenters reduce that risk. You do not have to mimic a specific person, you just have to look credible enough to keep someone listening for 20 seconds.&nbsp;</p><p>This is why the “avatar farms” mental model fits.&nbsp;</p><p>Instead of crafting a one-off forgery, scammers can run a production line:&nbsp;</p><ol type="1"><li data-list-item-id="ebb598c8a5f36ed5bf22c58a25cf5137d">Create or acquire a synthetic presenter that looks broadly trustworthy&nbsp;</li><li data-list-item-id="e037f34075f6fe1c6b325444d26aec9ad">Generate scripts at volume, tailored to whatever is trending&nbsp;</li><li data-list-item-id="e9830311305c72262b00d5e0ed4706f87">Swap voiceovers, captions, and visual overlays&nbsp;</li><li data-list-item-id="e1829309715a175d81fbb484eaf94b1e0">Publish, measure engagement, then publish again with minor variations&nbsp;</li></ol><p>That production line scales. It is designed for experimentation, iteration, and reach.&nbsp;</p><p>And it works because most scams do not require cinematic realism. They require momentum.&nbsp;</p><h2>Synthetic trust, the new social engineering&nbsp;</h2><p>Humans are wired to treat faces and voices as social proof. A confident presenter can make a claim feel less risky, even when the claim is outrageous. A calm delivery can make urgency feel “reasonable.” A familiar format can make a stranger’s instructions feel like a normal next step.&nbsp;</p><p>That is the core idea behind synthetic trust.&nbsp;</p><p>AI avatars are not trying to be memorable. They are trying to be acceptable. They are engineered to pass a quick gut-check, “this seems legitimate,” long enough to drive a click, a download, a payment, or a message.&nbsp;</p><p>For scammers, that is an upgrade. A synthetic presenter does not get tired. It does not demand a fee. It does not have a moral objection. It can be generated in many languages, in endless variations, and deployed in parallel across platforms.&nbsp;</p><p>You may still see celebrity bait at the top of the funnel. But underneath it, a lot of scam content is shifting toward manufactured presenters that are easier to scale.&nbsp;</p><h2>The twist: sometimes the video is real and only the audio is weaponized&nbsp;</h2><p>There is another reason audio-first detection matters: not every scam video relies on a fake face.&nbsp;</p><p>Sometimes criminals take legitimate footage, a real interview, a real tutorial, a real product explainer, and overlay a scam pitch on top. The visuals can be authentic. The deception sits in the narration, the instructions, and the call to action.&nbsp;</p><p>This technique does two things for scammers:&nbsp;</p><ul type="disc"><li data-list-item-id="ee6d78ff507a6dd63751daeb5224bcc60">It reduces production cost, because they can recycle existing footage&nbsp;</li><li data-list-item-id="eae4e6dba3c1d54936aa4100bfd420af0">It reduces suspicion, because the visuals look “normal” at a glance&nbsp;</li></ul><p>If defenses focus only on “does the face look fake?”, this kind of repurposed content can slip through. That is why we treat the message as primary. Then, once content is labeled as scam, we look for the repeated visual infrastructure that carries those messages, including recurring AI avatar presenters.&nbsp;</p><h2>A note on hired actors&nbsp;</h2><p>Not every recurring presenter in scam content is synthetic. We have also seen scams that use hired actors or commissioned videos. Sometimes it is a human reading a script, sometimes it is a human clip later repurposed with different narration or overlays.&nbsp;</p><p>In other words: the “avatar farm” trend does not replace all old techniques. It sits alongside them.&nbsp;</p><p>That is also why we avoid simplistic rules like “this face is fake therefore it is a scam.” What matters is intent and behavior. Faces help us connect the dots faster as a signal, they are not the verdict.&nbsp;</p><h2>Practical tips: how to protect yourself from scam videos&nbsp;</h2><p>If a video is pushing you toward money, logins, downloads, or urgent verification, treat the presenter as part of the packaging, not proof.&nbsp;</p><ol type="1"><li data-list-item-id="eb375588bdd69b963a569da0423a5860d"><strong>Follow the action, not the face.</strong>&nbsp;<br>If the video is urging urgency, secrecy, or immediate payment, pause. That pressure is often the scam.&nbsp;</li><li data-list-item-id="ecf36de53c2869ca44dd7de68b8dd6a10"><strong>Verify outside the platform.</strong>&nbsp;<br>Search for the claim from independent sources, not links in the description or comments.&nbsp;</li><li data-list-item-id="ea8e5ddb75021374558a5553272959836"><strong>Be suspicious of “too smooth” certainty.</strong>&nbsp;<br>Scam scripts often sound confident, generic, and strangely frictionless, as if risk does not exist.&nbsp;</li><li data-list-item-id="ee5e84990c119d747dd4cb8566a61b415"><strong>Watch for mismatch.</strong>&nbsp;<br>If the visuals feel unrelated to the pitch, or the audio feels pasted-on, treat it as a warning sign.&nbsp;</li><li data-list-item-id="ecd31fbfea4a6ecebbceff95dfbcc3458"><strong>Avoid installs prompted by videos.</strong>&nbsp;<br>“Install this to verify,” “download this viewer,” “run this command,” these are common routes into malware and credential theft.&nbsp;</li><li data-list-item-id="e190568cd7906f183381254eeea433387"><strong>Use protection tools.</strong><br>Tools like Norton’s AI-powered Scam Protection and Avast Deepfake Guard can help spot what’s easy to miss, including deepfake audio in videos and scam signals across web, SMS and more.&nbsp;</li></ol><h2>The bottom line&nbsp;</h2><p lang="EN-US">Deepfakes may get the headlines, but they are only part of the story. From impersonating real people to manufacturing trust at scale, faces, voices, scripts, formats, all of it can be generated, reused and optimized.&nbsp;</p><p lang="EN-US">Which means the real skill is not spotting what looks fake; it is recognizing how scams behave.&nbsp;</p><p lang="EN-US">Follow the pressure. Question the promise. Verify outside the moment.&nbsp;</p>

When the face is familiar but the person isn’t real 

From Celebrity Deepfakes to Avatar Farms, How Scammers Industrialize Trust

<p>It starts with a message that does not feel wrong.</p><p>You have a family trip coming up. You made the booking days or weeks ago, saved the confirmation and moved on with your life. Then WhatsApp pings.</p><p>The message says it is from the hotel’s Guest Relations team. It references the same property you booked. It mentions details that match your stay. It sounds like the kind of practical note you might expect before a trip, a small inconsistency, a quick verification, a routine check before arrival.</p><p>And that is exactly why it works.</p><p>When a scam contains real details, it stops feeling like spam and starts feeling like customer service. The attacker does not need perfect writing. They do not need malware. They do not even need a particularly clever pretext. They just need enough truth to make the lie feel safe.</p><p>That is the pattern at the heart of what we are calling the <a href="https://us.norton.com/blog/online-scams/reservation-hijacking-scam" target="_blank"><strong>Reservation Hijack Scam</strong></a>.</p><p>We call it a <strong>Reservation Hijack Scam</strong> because the attacker is not just spoofing a hotel or sending a generic phishing lure. They are hijacking the context around a real reservation and using it to make fraud feel like routine customer service.&nbsp;</p><p>In the stronger versions of the attack, that goes further. Once hotel staff credentials are phished, the attacker may gain access to real hotel or partner accounts and contact guests from within legitimate workflows, for example through a booking platform account or hotel messaging environment. At that point, the scam is no longer only borrowing the hotel’s identity, it is actively impersonating the hotel through systems the guest already trusts.</p><p>That is the shift that matters most. This is not just a travel-themed phishing lure dressed up with better wording. In the strongest cases, criminals can move from impersonating the hotel to operating through compromised hotel-side or partner workflows, contacting real travelers in the context of real reservations.</p><h2>A scam category built on stolen and relayed trust</h2><p>Most phishing is generic. It arrives with no context, so your brain treats it with suspicion.</p><p>Reservation Hijack scams work differently. They reflect real context back at the victim, the hotel name, the destination, the fact that there is a genuine booking, sometimes the stay window, sometimes even the exact amount due. That reflected truth becomes the bypass.</p><p>Add a short fuse, usually 24 or 48 hours, and the attacker gets what they want most, fast compliance before the victim pauses, verifies or calls the property.</p><p>This is not just a nicer phishing template. It is a different quality of deception.</p>

<h2>What we found</h2><p>Our investigation points to two visible fronts in the same scam pattern.</p><p>The first is the booking-platform lure. Victims receive WhatsApp messages or similar contact from what appears to be a hotel or guest relations team, then get pushed into a fake guest portal or payment verification page. We have seen this most clearly in Booking.com-linked cases, with additional signs of similar abuse around other travel and hospitality workflows. These messages feel unusually convincing because they contain real booking context.</p><p>The highest observed activity is concentrated across parts of Western Europe, notably the United Kingdom, France, and Germany, alongside the United States, Brazil and Australia.</p>

<p>We have also seen this scam pattern surface across multiple channels, including Booking.com messaging, WhatsApp, SMS and email. That matters because it shows this is not tied to a single delivery trick. It is a flexible fraud workflow that can move wherever guests are most likely to trust and respond.</p><p>The second is the <strong>hotel software abuse path</strong>, where the attacker does not just imitate a hotel from the outside, but appears to operate from inside the hotel’s workflow. For example, Cloudbeds is a hospitality management platform used by hotels to handle reservations, guest communications, and other day-to-day operations. In the Cloudbeds-related cases we reviewed, the attack chain begins with phishing hotel staff, not guests. Once the attacker steals staff credentials, they can log into real hotel management tooling, access reservation data and use guest communication features to target upcoming travelers. Depending on the systems tied to that hotel workflow, that may also let the attacker operate through legitimate booking or messaging accounts associated with the property, effectively communicating with real customers as if they were the hotel itself.</p><p>That shift matters.</p><p>At that point, the hotel is no longer just the theme of the scam. Its real accounts, workflows and communication channels can become the delivery mechanism.</p><p>That hotel-side compromise path is not theoretical. In partner-targeted examples we uncovered, attackers impersonated Booking.com security communications and pushed accommodation partners to install what was presented as a mandatory security update. In reality, the attached material led the victim to run a malicious command (<a href="https://www.gendigital.com/blog/insights/reports/threat-report-q3-2025" target="_blank">Scam-Yourself Attack Tactic</a>) that deployed a remote access trojan, giving the attacker a foothold that could then be used to steal credentials and abuse the partner account.</p>

<h2>How the scam works, from start to finish</h2>

<p>At its core, this scam follows a simple pattern, even if the entry point can vary.</p><p>First, the attacker gains access to trust, typically by phishing hotel staff and stealing credentials to a real hospitality platform or connected hotel account. That gives them visibility into genuine reservations, the contact details of real travelers, and in some cases the ability to communicate through legitimate hotel-linked workflows.</p><p>Next, the attacker identifies real travelers. That is what makes the scam feel different from ordinary phishing. The victim is not chosen at random. They are contacted in the context of a real trip, with details that match an actual booking.</p><p>The level of personalization depends on how much information the attacker has. When they can access rich reservation data, such as the property name, stay dates, guest name, payment context or booking details, they can build a highly tailored spear phishing message that feels almost indistinguishable from routine customer service. When they only have limited data, such as an email address or phone number, the scam may look more generic, but it can still exploit hotel branding, urgency and the expectation of pre-trip communication.</p><p>That difference is visible in the lures themselves. In high-context variants, the message may name the guest, reference a specific stay date and amount, or lead to a payment page already populated with reservation details. In lower-context variants, the flow is far more generic and relies on the victim to fill in the missing details themselves.</p>

<p>That difference is visible in the lures themselves. In high-context variants, the message may name the guest, reference a specific stay date and amount, or lead to a payment page already populated with reservation details. In lower-context variants, the flow is far more generic and relies on the victim to fill in the missing details themselves.</p><p>In the weaker version of the scam, the attacker uses that information to craft convincing messages from the outside, through WhatsApp, SMS or email lookalikes. In the stronger version, the attacker may message the guest from a real hotel or booking-related account they have taken over. The difference is important. The victim may not just see a plausible hotel message, they may see what looks like a legitimate continuation of their existing booking conversation.</p><p>In one case we reviewed, the phishing message was delivered through a legitimate Booking.com partner communication thread after the accommodation partner account had been compromised. The malicious request was injected into an otherwise normal conversation, making the attack especially difficult to detect because it arrived from a trusted source rather than a spoofed sender. The follow-up warning from the hotel highlights the confusion and damage that can occur once a real partner account is abused:</p>

<p>Then comes the message. It usually arrives over a fast, informal channel such as WhatsApp or SMS, and it is written to feel administrative rather than alarming. The goal is not to scare the victim, but to make the request feel routine, a payment issue, a booking confirmation, a verification step or an urgent action before arrival.</p><p>In the examples we reviewed, the exact wording and format varied by platform, but the underlying pattern stayed consistent: the message borrowed hotel context, introduced a practical problem, and pushed the guest toward a verification or payment step that benefited the attacker.</p><p>From there, the victim is pushed into a controlled flow. That may be a fake guest portal, a spoofed payment page, or even a branded PDF that adds one more layer of credibility before the victim reaches the real theft stage.</p><p>The theft happens when the traveler enters payment details, approves a transfer or otherwise complies with the fake verification process. At that point, the attacker has turned stolen trust into financial fraud.</p><p>And the damage may not stop there. Payment details can be reused, tested with small charges, sold or leveraged in follow-on scams. What begins as a believable hotel message can end in broader financial compromise.</p><p>That is what makes this scam different. It is not just phishing with a travel theme. It is a workflow attack built on stolen context and relayed trust.</p><h2>The Cloudbeds path, step by step</h2><p>Cloudbeds has publicly warned of an industry-wide phishing campaign targeting hospitality providers and described credential-phishing attacks impersonating Cloudbeds login pages as the root cause rather than a Cloudbeds platform breach.</p><p>That point matters especially for small and medium-sized hospitality businesses. Large travel brands usually have bigger security teams, more formalized controls and more mature fraud processes. Smaller properties often rely on lean teams, fast guest communication and a handful of operational platforms to keep everything moving. That makes them particularly vulnerable when attackers target employees directly with credential phishing.</p><p>The attack chain we mapped is brutally efficient.</p><p>First, hotel staff are lured to fake login pages and their credentials are stolen. Then the attacker logs into the real management environment. From there, they can see future reservations, guest names, contact details, stay information and sometimes payment context. In some scenarios, that access may also extend beyond visibility. If the compromised hotel workflow is connected to guest-facing messaging on booking or hospitality platforms, the attacker may be able to contact customers from the property’s legitimate account presence. That makes the fraud especially dangerous, because the message may arrive inside a channel the traveler already associates with their real reservation.</p><p>In the cases documented in our working material, some victims received SMS messages containing detailed reservation information and links that led to professionally styled PDFs impersonating hotel groups. Those PDFs pushed “payment verification” within 48 hours, using generic branding, urgency, and a prominent call to action to move the victim toward the real theft stage. The PDF step appears to function as a buffer, one more layer of legitimacy for the victim, and one more layer of indirection for scanners and filters to deal with. In some cases, the PDF itself was hosted on legitimate partner storage that had been hijacked, giving the lure another borrowed layer of trust before redirecting the victim onward.</p>

<p>From there, the victim is redirected again, typically to typo-squatted domains designed to harvest card details, bank transfers or other payment information. Example domains documented in the shared material include frontdesk-reservation[.]com, frontdesk-online[.]biz, and hotel.form842987[.]digital.</p><h2>One scam, multiple surfaces</h2><p>This is the part many people miss.</p><p>The WhatsApp message, the SMS, the fake PDF, the lookalike payment page, the stolen card, these are not separate incidents. They are one pipeline. And that pipeline can include direct impersonation of the hotel itself. Sometimes the attacker stands outside the workflow and imitates the property. Sometimes the attacker steps inside a compromised hotel or booking-related account and speaks from a position the guest already trusts. Different surface, same scam family.</p><p>First, the attacker gets context. Next, they use that context to deliver a believable message through a channel people act on quickly. Then they move the victim into a verification flow that feels administrative, not dangerous. If payment details are entered, the harm does not stop at one fraudulent charge. Cards can be tested with small transactions, then used for larger purchases, then resold or retried later.</p><p>This is what makes the scam so dangerous. The same fraud logic can be adapted to different platforms, different levels of stolen context, and different points in the guest journey.</p><h2>Why this matters now</h2><p>Hospitality has become an unusually attractive environment for this kind of fraud.</p><p>Hotels run on urgency, constant guest communication and high-trust operational workflows. Travelers expect messages about check-in, balances, room preferences, arrival timing, and identity verification. That makes it easier for attackers to hide malicious intent inside language that would look normal in almost any other context.</p><p>And when the attacker is working with real reservation data, or worse, using compromised hotel or booking-linked accounts to contact guests directly, the old consumer advice starts to bend. Checking the link still matters, but it is no longer enough on its own. The victim is not just being tricked by branding. They are being tricked by context.</p><h2>What travelers should do</h2><p>If a hotel contacts you via Booking.com messaging, Airbnb, WhatsApp, SMS or email and asks you to verify payment details, do not tap the link. The same caution applies if the message appears to come from an existing reservation thread or from what looks like the hotel’s real account on a booking platform. Trust the booking, not the message.&nbsp;</p><p>Go to the booking site, hotel site, or official app yourself. If you need to call the property, use a trusted contact route from the original booking or the verified website, not the number or link inside the message.</p><p>If you already entered payment details, assume compromise. Contact your bank, cancel the card, enable transaction alerts and watch for follow-on attempts.</p><h2>What hotels should learn from this</h2><p>The lesson for hospitality is not just “train staff better,” although that matters. It is that hotel software, messaging workflows, and guest communication tools now sit directly on the fraud path.</p><p>The hotel is no longer only a victim. In the eyes of the guest, it can become the face of the scam. In the worst cases, it can also become the voice of the scam, when attackers use compromised hotel or partner accounts to message guests as if they were legitimate staff.</p><p>That means account protection, phishing-resistant authentication, tighter controls around exports and guest messaging, anomaly detection and faster incident response are no longer nice-to-haves. They are part of brand protection.</p><p>Because once attackers learn how to turn operational systems into trust amplifiers, they do not need to break in loudly. They can simply log in, relay stolen trust to the guest, and let the workflow do the rest.</p><h2>One final thought</h2><p>For years, the best advice on travel scams was simple: watch for bad grammar, generic messages, and suspicious links.</p><p>That advice still matters. But it belongs to an earlier phase of the problem.</p><p>The next phase looks like this: the message knows your booking, sounds plausible, and may arrive through a channel or account the traveler already trusts. That is the point where customer service and fraud begin to overlap.</p><p>That is the Reservation Hijack Scam.&nbsp;</p><p>In the next part of this series, we will look more closely at the infrastructure, indicators and investigative signals behind it.</p>

From Booking-themed lures to compromised hospitality software, criminals are using reservation data and trusted workflows to make fraud feel like customer service. 

The Reservation Hijack Scam: How attackers hijack hotel accounts to target guests

<h2><strong>TL;DR&nbsp;</strong></h2><p>It started with a lie. A sample walked into the lab wearing a Vidar label like a cheap suit two sizes too small. We pulled the threads, and the whole thing came apart. What fell out was a previously unknown information stealer we named <strong>Torg Grabber</strong> – 334 samples compiled over three months, a rapid evolution from Telegram dead drops through an encrypted TCP protocol nobody asked for, all the way to a production-grade REST API that worked like a Swiss watch dipped in poison. Over 40 operator tags pulled from the binaries – a mix of nicknames, date-encoded batch IDs, and confirmed Telegram user IDs – fingerprinted individual MaaS customers and confirmed what we already suspected: this was a builder-and-panel operation, crime as a service, infrastructure included. OSINT resolution of the numeric tags peeled back the curtain on eight operators as Telegram accounts buried up to their necks in the Russian cybercrime ecosystem. The bot tokens gave us the developer accounts behind the whole show. Nobody said crime doesn’t pay, but nobody said it doesn’t leave fingerprints either.&nbsp;</p><p><strong>The misclassification that started It all&nbsp;</strong></p><p>The sample came in on a Tuesday in early February, wearing the name Vidar Stealer the way a pickpocket wears a priest’s collar. It didn’t fit. A 747 KB PE64 binary compiled with MinGW/GCC – when Vidar v17.9 is a 32-bit MSVC job that, as a colleague put it, “looks significantly different.” That was like saying a Great Dane looks significantly different from a Pekingese. You didn’t need a magnifying glass.&nbsp;</p><p>A deeper look turned up a self-identifying debug string – "<code>grabber v1.0</code>" – sitting in the binary like a monogrammed handkerchief left at a crime scene. The C2 protocol was all wrong for Vidar: REST API endpoints (/api/auth, /api/upload/chunk), ChaCha20 encryption, HMAC-SHA256 authentication. This wasn’t Vidar any more than I was the Queen of England.&nbsp;</p><p>We ran it against StealC v2 for good measure – similar endpoint patterns on the surface, the way all gin joints look alike from the sidewalk. Zero protocol overlap. Different endpoint structure, different communication model, different encryption. This was something new, something nobody had put a name to yet.&nbsp;</p><p>So we named it ourselves. <strong>Torg Grabber</strong> – “Torg” from its most-used C2 domain <code>technologytorg.com</code> (Russian <em>“торг”</em> = trade, marketplace – fitting for a business that trades in other people’s secrets), and “Grabber” from the malware’s own vocabulary (<code>GRABBER_HOST, GRABBER_TAG, "grabber v1.0</code>"). If a thing names itself, you ought to listen.&nbsp;</p><h2><strong>Timeline: Two months of rapid development&nbsp;</strong></h2><p>Three hundred thirty-four samples. Three months. It was like watching a time-lapse film of a weed growing through concrete. The corpus told the story of a malware operation spinning up in real time, stumbling forward with the reckless confidence of a man who knows exactly what he’s doing and doesn’t much care who’s watching.&nbsp;</p>

<p>Three exfiltration mechanisms. Three ways to get the goods out. Each one a little smarter than the last, the way a burglar graduates from smashing windows to picking locks to making copies of the key.</p><h3>Phase 1: Telegram Bot API (Dec 9–11, 2025)</h3><p>The earliest builds were small and nervous, the way a rookie’s hands shake on his first job. Compact little things, 270 to 313 KB, that grabbed credentials, stuffed them into a ZIP archive, and shipped the whole package to a private Telegram channel via&nbsp;sendDocument. No encryption beyond TLS. A&nbsp;User-Agent: TG header about as subtle as a neon sign in a funeral parlor. Five retry attempts, and if the ZIP upload choked, a fallback to plaintext&nbsp;sendMessage – the digital equivalent of shouting your secrets across a crowded room.</p><p>Twenty-five samples, eight bot tokens, eight private channels, each with two or three members. This was the prototype phase: fast to set up, zero infrastructure cost, and about as durable as a paper umbrella in a monsoon. Telegram can revoke tokens on a whim, and the API calls stick out in traffic logs like a tall man in a short crowd.</p><h3>Phase 2: GRAB Binary TCP Protocol (Dec 17–20, 2025)</h3><p>Four samples. A narrow four-day window. This was the experimental phase – somebody had an idea, and they were going to see if it could walk before they taught it to run.</p><p>Instead of HTTP, the malware opened a raw TCP socket to&nbsp;<code>*.tara.net.bd</code> on port 50443 and spoke a custom binary protocol that had all the charm of a coded knock on a speakeasy door:</p><ul><li data-list-item-id="e3d01df3606010b531fb2e83821bb7f96">A 9-byte frame: 4-byte&nbsp;<code>GRAB</code> magic, 1-byte type, 4-byte length</li><li data-list-item-id="e0aa34faadca69a4d6fcee2220c2a3415">ChaCha20-Poly1305 AEAD encryption with HMAC-SHA256 key derivation</li><li data-list-item-id="eec12b3e52f329ead2daead35c83d690c">SHA-256 hash of the payload sent before the encrypted data</li><li data-list-item-id="e0500a32b5824c04717745665cb222a44">64 KB chunks with 5-second retry intervals</li></ul><p>The C2 hostnames were&nbsp;<code>bk.tara.net.bd and&nbsp;raketa.tara.net.bd</code> – “raketa” being Russian for “rocket,” because even criminals have a sense of poetry. Both under a Bangladesh TLD but geolocated to Turkey, which made about as much geographic sense as a polar bear in Havana. The encryption key was hardcoded:&nbsp;<code>0123456789abcdef</code> repeated. A test key. Development builds, still warm from the compiler.</p><p><em>See Appendix A, Figure A1</em></p><p>Technically sophisticated – proper AEAD, authenticated handshakes, chunked transfer. The kind of work that said the developer knew cryptography the way a safecracker knows tumblers. But it was abandoned after four builds. Running a custom TCP protocol at scale turned out to be harder than hiding behind Cloudflare, which is to say, harder than letting somebody else do the heavy lifting. Some lessons you only need to learn once.</p><h3>Phase 3: REST API over HTTPS (Dec 18 onward)</h3><p>This was the production rig. The real thing. No more rehearsals.</p><p>The malware performs a JSON registration at&nbsp;<code>/api/auth</code>, sending along a machine fingerprint – GPU, wallpaper hash, hardware ID, antivirus product – like a new inmate checking into prison with his personal effects. In return, it gets configuration, a session token, and sometimes shellcode, because some operators like to bring their own party favors. Then comes the upload: stolen data, chunked over HTTPS, ChaCha20-encrypted, routed through Cloudflare. Each request carries an HMAC-SHA256&nbsp;<code>X-Auth-Token</code> header, because even thieves want to know they’re talking to the right fence.</p><p><em>See Appendix A, Figure A2</em></p><p>Over two months, the binary fattened up from ~410 KB to ~747 KB, the way a confidence man’s wallet thickens over a good season. The additions were considerable: a 20 KB ChaCha20-encrypted Reflective DLL for bypassing Chrome 127+ App-Bound Encryption across 7 Chromium browsers via their IElevator COM interfaces; 20 direct NT syscall wrappers with PRNG-obfuscated tables; and an ever-growing shopping list of collection targets – 850 browser extensions alone consuming ~213 KB of binary space, like a burglar’s toolkit that takes up half the trunk. Two size epochs are visible – a ~160 KB jump around January 21 that marks a major feature release as clearly as a new coat of paint on an old building. The newest builds kept rolling off the line daily through February 2026, each one a little bigger, a little meaner, a little hungrier.</p><h2>The loader chain: From dropper to stealer</h2><p>Torg Grabber doesn’t show up at the party alone. It arrives wrapped in layers, the way a bad idea shows up wrapped in good intentions — three skins of encryption and obfuscation to peel away before the stealer ever touches memory. Each skin has a job. The outer one: crypter-level polymorphism, the kind that makes every sample look like a different animal. The middle: reflective PE loading, never leaving fingerprints on disk. The innermost: the stealer itself, finally naked and ready to work.</p><h3>Stage 0: The Dropper</h3><p>The outermost layer changes its face depending on who’s handing it out. Telemetry from our userbase paints the picture – several lure families, all funneling into the same loader chain like tributaries feeding a dirty river:</p><ul><li data-list-item-id="ef20558cd69ad2240467faf8b907f23c7"><strong>Fake game cheats</strong>:&nbsp;<code>CrimsonLoader.exe,&nbsp;RivalMods.exe</code></li><li data-list-item-id="ecfc5a9772478bacf10752d88d8626f41"><strong>Cracked software</strong>:&nbsp;R<code>elease-app-x64.rar</code> →&nbsp;<code>Set-up.exe</code>,&nbsp;<code>Aerovora.zip</code>,&nbsp;<code>Terraria_1.4.5.zip</code></li><li data-list-item-id="eb92e8d896c8fe97501e98a43c55aa26a"><strong>ClickFix clipboard</strong>: PowerShell one-liner via Google Apps Script (see&nbsp;<a href="//F7CA28BA-0D78-43F6-82F3-AD55EE8C3098#in-the-wild-observed-infection-chain">full chain below</a>)</li></ul><p>Regardless of the lure, the final dropper drops a randomly-named executable into&nbsp;<code>C:\Windows\ –&nbsp;v4jkqh.exe</code>,&nbsp;<code>hkjpy08.exe</code>,&nbsp;<code>ln3dkgz.exe</code>,&nbsp;<code>en3v4ior.exe</code> – names that look like someone fell asleep on the keyboard. This pattern is consistent across 78 distinct samples in our telemetry. The crypter stage. The thing that gets you in the door.</p><p>Before it spawns the next stage, the dropper does something clever. Configuration propagation. It sets environment variables that carry the operator’s whole setup across process boundaries — the way a con man memorizes his cover story before he walks into the bank:</p>

<p>One compiled stealer, a hundred operators. The dropper injects identity at runtime. Crime as a service, served by environment variables.</p><h3>Stage 1: Self-Extracting Loader</h3><p>The first code stage is a MinGW-compiled PE64 with an encrypted overlay pasted on the end — beyond the section data, like a secret message written on the back of a photograph. The overlay structure lives in the file’s last 8 bytes. You have to read backwards to find the beginning:</p><p><em>See Appendix B, Listing B1&nbsp;</em></p><p>The extraction pipeline runs like a three-card monte:</p><ol><li data-list-item-id="e5b92ce18abe492c50ce87bded031e432"><strong>Hex decode</strong> — Custom hex encoding: 3 bytes per output byte, two hex digits plus a separator. Lower entropy than raw ciphertext. The kind of detail that evades entropy detection the way a whisper evades a crowded room.</li><li data-list-item-id="eea648425fcc7b67250a494bd3dc405ea"><strong>AES-256-CBC decrypt</strong> — Key and IV pulled from the overlay. Every build gets its own key material. The builder doesn’t recycle.</li><li data-list-item-id="e472ee13b2b0ba690024aa2694c9aaf77"><strong>Parse decrypted buffer</strong> — A&nbsp;uint32 skip count, then null-terminated API name strings (<code>NtWriteVirtualMemory</code>, <code>NtProtectVirtualMemor</code>y), then the shellcode. The loader resolves those NT APIs at runtime and injects the shellcode into memory using direct syscalls. No imports. Clean hands.</li></ol><h3>Stage 2: Reflective PE Loader</h3><p>The shellcode from Stage 1 is a PE in disguise. A reflective loader carrying the final Torg Grabber payload as an encrypted blob in <code>.rdata</code> — about 793 KB of trouble. This stage runs entirely in memory. It never touches disk. The kind of ghost that leaves no footprints.</p><h4><em>Dynamic API Resolution</em></h4><p>The loader finds every Windows API it needs by walking the PEB — Process Environment Block — and parsing export tables. No&nbsp;<code>GetProcAddress</code> in the import table. Static analysis looks at the binary and sees nothing. It’s the malware equivalent of paying cash.</p><h4><em>AES-256-CBC Decryption</em></h4><p>The blob gets decrypted first. AES-256-CBC, hardcoded 256-bit key, 128-bit IV. Each build carries different constants. Fingerprints:</p><p><em>See Appendix B, Listing B2&nbsp;</em></p><h4><em>Four Cascaded Byte Transforms</em></h4><p>After AES comes the garnish. Four byte-level transforms in sequence. Reversible arithmetic over GF(2^8). The constants vary by build; the structure never does:</p>

<table class="table"><tbody><tr><td>Step</td><td>Operation</td><td>Constant</td><td>Purpose</td></tr><tr><td>1</td><td>byte = (byte + K₁) &amp; 0xFF</td><td>0x7C / 0xAC</td><td>Additive shift</td></tr><tr><td>2</td><td>byte = byte ^ K₂</td><td>0x68 / 0x58</td><td>XOR mask</td></tr><tr><td>3</td><td>byte = ROR(byte, 2) / ROL(byte, 2)</td><td>2 bits</td><td>Bit rotation</td></tr><tr><td>4</td><td>byte = (byte * K₃) &amp; 0xFF</td><td>0xC5 / 0xCD</td><td>Modular multiply</td></tr></tbody></table>

<p>Five layers total with AES. Simple XOR-key recovery goes home empty. Automated decryption without the right constants hits a wall.</p><h4><em>Anti-Analysis: NOP-Equivalent Functions</em></h4><p>Between decryption stages, the loader calls functions that look busy. Multi-register shuffles. Conditional branches. Memory loads. Complex enough to make a decompiler sweat. Net effect: zero. They’re NOPs dressed up for the opera:</p>

<p>Several of these stubs get called between each decryption stage and before the memmove. Dead code padding the call graph like sawdust in a cheap sausage.</p><h4><em>The Hidden memmove: PE Reassembly from Non-Contiguous Chunks</em></h4><p>The operation that matters most — and the one you’re most likely to miss. After the byte transforms, a single&nbsp;<code>memmove</code> stitches the final PE together from two pieces that weren’t sitting next to each other:</p><p><em>See Appendix B, Listing B3</em></p><p>Skip the memmove and you get a PE with a poisoned&nbsp;<code>.idata</code> section and 110 KB of overlay garbage. It loads into IDA. It crashes when you run it. The encryption stuffed junk between the two halves — any automated extractor has to know exactly where to cut and paste. Final size:&nbsp;<code>0xA6E00</code> = 683,520 bytes. Hardcoded in the loader as a&nbsp;<code>VirtualAlloc</code> parameter.</p><h4><em>Manual PE Mapping</em></h4><p>After reassembly, the loader maps the PE the old-fashioned way. Reflective loading 101:</p><ol><li data-list-item-id="e1b056298a8894ae089d3da9a8901b3aa"><strong>Allocate</strong> —&nbsp;<code>VirtualAlloc(PAGE_READWRITE)</code> for&nbsp;<code>SizeOfImage</code> bytes</li><li data-list-item-id="eb2193d53562357b767ce7b7fa01d3116"><strong>Copy headers</strong> — first&nbsp;<code>SizeOfHeaders</code> bytes</li><li data-list-item-id="eef41778348fbeeefd913c08313ff305b"><strong>Map sections</strong> — to their virtual addresses (<code>VirtualAddress + base</code>)</li><li data-list-item-id="e2dfba01eaa5a533e27b2001492ba03c6"><strong>Process relocations</strong> — apply delta from preferred&nbsp;<code>ImageBase</code> to actual allocation</li><li data-list-item-id="e84e05b522b4a583feeb4671f81391808"><strong>Resolve imports</strong> — walk the Import Directory,&nbsp;<code>LoadLibraryA</code> and&nbsp;<code>GetProcAddress</code> for each DLL/function</li><li data-list-item-id="e0bd9f61592132d5e5cd730bf4b857dff"><strong>Set section permissions</strong> —&nbsp;<code>VirtualProtect</code> with&nbsp;<code>PAGE_EXECUTE_READ</code>,&nbsp;<code>PAGE_READONLY</code>,&nbsp;<code>PAGE_READWRITE</code></li><li data-list-item-id="e34ebad8f173a493e0d3668315a6921b1"><strong>Call entry point</strong> —&nbsp;<code>AddressOfEntryPoint + base</code></li></ol><p>The stealer PE never hits disk. It lives only in memory, mapped inside the loader’s process. A ghost inside a ghost.</p><h3>Stage 3: Torg Grabber</h3><p>The final payload. 683 KB PE64. MinGW/GCC. Seven hundred thirty-seven functions in fifteen categories, organized like a filing cabinet in a detective’s office — everything in its place:</p><p><em>See Appendix B, Listing B4 (Stage 3: Torg Grabber).]</em></p><p>Execution starts at&nbsp;<code>main_data_collection_and_exfil</code>. The orchestrator. The one running the show:</p><ol start="8"><li data-list-item-id="e7e97057020ca972f16d99cd2de4c9d58"><strong>Reads configuration</strong> —&nbsp;<code>GRABBER_*</code> environment variables, set by the dropper, with hardcoded fallbacks for the forgetful</li><li data-list-item-id="e59d21024124feb483ed7084b75283ebe"><strong>Profiles the system</strong> — MachineGuid, GPU, process list, antivirus (46 signatures across 24 products), VM/sandbox detection, CIS locale check</li><li data-list-item-id="e6dd228fde01ef32dd9634540729fde71"><strong>Creates a mutex</strong> —&nbsp;<code>Local\&lt;MachineGuid&gt;</code> so only one instance runs at a time</li><li data-list-item-id="e003a12fb4575621eb9150a6dd12e7f56"><strong>Registers with C2</strong> — POST to&nbsp;<code>/api/auth</code> with ChaCha20-encrypted JSON, gets a session ID and maybe streaming config</li><li data-list-item-id="e8caea529cba09bd0a405a330b9f1500e"><strong>Resolves NT syscalls</strong> — parses&nbsp;<code>ntdll.dll exports</code>, builds PRNG-obfuscated syscall table</li><li data-list-item-id="e30e1ff27be21c754814b9cbad9b3f89e"><strong>Collects data</strong> — 25 Chromium browsers, 8 Firefox, 850 extensions, Discord, Steam, Telegram, VPN, FTP, email, password managers, wallets, screenshot, installed software, Desktop/Documents files</li><li data-list-item-id="ee0c091fe9e7fafc3479d6316df833505"><strong>Exfiltrates</strong> — archives to in-memory ZIP or streams chunks, uploads via chunked HTTPS with ChaCha20 and HMAC-SHA256</li></ol><p>The stealer can also take shellcode from the C2 at registration.&nbsp;<code>decrypt_and_execute_shellcode</code> handles ChaCha20-decrypted, zlib-compressed payloads — allocates executable memory via&nbsp;<code>NtAllocateVirtualMemory</code>, runs it. Arbitrary post-exploitation without a new binary. Before execution,&nbsp;<code>export_config_to_env</code> writes the config back to environment variables so any child process inherits the operator’s settings.</p><h3>Configuration propagation: The environment variable chain</h3><p>One pattern runs through the whole chain: <strong>configuration travels by environment variable</strong>. The dropper sets&nbsp;<code>GRABBER_*</code>. The stealer reads it at startup (<code>init_grabber_config_from_env</code>). Before process injection — ABE bypass, shellcode — the stealer writes the config <em>back</em> to env vars (<code>export_config_to_env</code>). Child processes inherit. No recompilation. One payload, many operators:</p><p><em>See Appendix B, Listing B5&nbsp;</em></p><p>The stealer binary is operator-agnostic. The builder customizes the dropper. The dropper does the rest.</p><h3>In the Wild: Observed infection chain</h3><p>Static analysis gives you the stages. Behavioral telemetry gives you the story. We captured the <strong>full delivery chain</strong> on a real victim machine — January 30, 2026 — from initial social engineering through PowerShell stages to stealer execution. The whole show, start to finish.</p><h4><em>The ClickFix Initial Access</em></h4><p>Before the InnoSetup dropper. Before the PowerShell. A <strong>clipboard hijack</strong>. The victim hits a malicious Google Apps Script page:</p><p><code>https://n-3t7yxs7pcq6bihciyqway6qnhvhrol2fgy2tdaa-0lu-script.googleusercontent.com/blank</code></p><p>The page drops a PowerShell command into the clipboard and tells the victim to paste. Classic ClickFix. The 309-byte payload (SHA256:&nbsp;<code>07b96e5c...e6c26edebf, detected as&nbsp;HTML:Clipboard-A</code>) triggers the base64-encoded stager download from&nbsp;<code>j0o.pw/core2</code>. The clipboard payload was captured along with the dropped stager — the missing link between the social engineering and the PowerShell chain.</p><h4><em>Full Process Tree</em></h4><p><em>See Appendix B, Listing B6&nbsp;</em></p><h4><em>Stage by Stage</em></h4><p><strong>0. ClickFix clipboard attack</strong> — The victim visits a Google Apps Script page (<code>n-3t7yxs7pcq6bihciyqway6qnhvhrol2fgy2tdaa-0lu-script.googleusercontent.com</code>) with a fake verification or update prompt. The page silently copies a PowerShell command to the clipboard and tells the user to hit Win+R and paste. That 309-byte payload (<code>HTML:Clipboard-A</code>) kicks off everything — the Chrome InnoSetup download and the hidden PowerShell downloader both trace back to that paste. Google Apps Script: trusted domain, free hosting, URLs you can’t blocklist without catching the whole neighborhood in the net.</p><p><strong>1. Dropper download</strong> — Chrome pulls <code>GAPI_Update.exe</code> from Dropbox (<code>uc0be8c69...dl.dropboxusercontent.com</code>). 60 MB InnoSetup. Extracts benign DLLs (<code>msvcp140.dll, vcruntime140.dll, WebView2Loader.dll</code>) to <code>%LOCALAPPDATA%\Connector\</code>. Looks like a real install. Looks like a lot of things that aren’t.</p><p><strong>2. Hidden PowerShell BITS downloader</strong> — A PowerShell process with <code>-W Hidden -E &lt;base64&gt;</code>. The decoded command uses <strong>BITS Transfer</strong> — Windows’ Background Intelligent Transfer Service — to grab the next script:</p>

<p>BITS runs through <code>svchost.exe</code>, not PowerShell. Legitimate Windows service. Many endpoint tools never look. The script runs, then deletes itself. <strong>Fileless</strong> delivery. No artifact left behind but the memory of the thing.</p><p><strong>The&nbsp;</strong><code><strong>sys.ps1</strong></code><strong> stager — decoded content:</strong></p><p>Live payloads downloaded from both endpoints (infrastructure still serving as of February 8, 2026): <code>/core</code> is 6,944 bytes (SHA256: <code>a7fafc75...079fa3e2</code>, <a href="https://www.virustotal.com/gui/file/a7fafc75426a3b31dc89915cc79c014ad094bfcb98d69c39af4a0847079fa3e2">VT</a>); <code>/core2</code> is 6,972 bytes (<code>94c964eb...cd800fd</code>). Same structure: base64-wrapped payload, <code>$e</code> = <code>[System.Convert]::FromBase64String('...'); Invoke-Expression [System.Text.Encoding]::UTF8.GetString($e)</code>.</p><p><strong>3. Fake “Windows Security Update” progress bar</strong> — The script brings the console to the foreground with Add-TypeP/Invoke:</p><p><em>See Appendix B, Listing B7&nbsp;</em></p><p><code>Add-</code>Type compiles via <code>csc.exe</code> — producing <code>pvxhy3qg.cmdline</code> and <code>bz2ytolk.cmdline</code> invocations in the process tree. Not AMSI bypass. Just bringing the window forward and resizing to 80x20. Then an animated ASCII progress bar. <strong>420 seconds</strong>. Seven minutes. 24 milestones. The victim watches. The real work happens in the background.</p><p><em>See Appendix B, Listing B8&nbsp;</em></p><p><strong>4. XOR-encrypted triple loader download</strong> — While the progress bar ticks, a background <code>Start-Job</code> downloads <strong>three loaders</strong> via BITS Transfer, <code>Invoke-RestMethod</code> as fallback. Each file: base64 blob decrypted with a <strong>256-byte repeating XOR key</strong>:</p><p><em>See Appendix B, Listing B9&nbsp;</em></p><p>Base64 decode. XOR each byte against the key, cycling every 256. We verified: both <code>t4e.pw/res1.php</code> (2.6 MB) and <code>t4e.pw/res4.php</code> (2.7 MB) decrypt to valid PE64 with <code>MZ</code> headers. Three loaders, executed <strong>sequentially</strong> with 30–41 second delays. Hidden.</p><p>Endpoint versioning: <code>/core uses</code> res{1–3}, <code>/core2</code> uses res{4–6}. Domains split: <code>j0o.pw</code> = stagers, <code>t4e.pw/re3.pw</code> = loaders.</p><table class="table"><tbody><tr><td>Stager version</td><td>Loader 1</td><td>Loader 2</td><td>Loader 3</td></tr><tr><td>/core (6,944 B)</td><td>t4e.pw/res1.php</td><td>t4e.pw/res2.php</td><td>re3.pw/res3.php</td></tr><tr><td>/core2 (6,972 B)</td><td>t4e.pw/res4.php</td><td>t4e.pw/res5.php</td><td>re3.pw/res6.php</td></tr></tbody></table>

<p><strong>5. Loader execution and unpacking chain</strong> — Decrypted loaders land in <code>%LOCALAPPDATA%\Microsoft\Windows\UpdateCache\</code> as <code>updateWeb_Microsoft_v7028111.exe</code> and kin. Fake version strings: “Breathtaking Output 383” / “Global Channel Port Limited”. Server-side polymorphism. Fresh build per download.</p><p>Complete unpacking chain: <strong>seven layers</strong> — base64 → XOR → AES-CBC overlay → hex-encoding → CTR cipher → LZNT1 → AES-CBC + byte transforms. Both chains deliver the same 683 KB stealer, compiled 19 minutes apart:</p><p><em>See Appendix B, Listing B10</em></p><p>Binary comparison: .<code>data</code> section byte-for-byte identical. <code>.text</code> differs by 48 bytes. Campaign IDs: “meow” vs “gapi”.</p><p><strong>6. Detection</strong> — The captured instance (<code>eee3f818</code>..., 13 MB) spawned twice. First instance proceeded with extraction. Second spawned dllhost.exe. Behavioral detection terminated the second instance as the loader tried to disable Event Tracing for Windows before execution.</p><h4><em>New Infrastructure: The PowerShell C2 Layer</em></h4><p>Four domains. Delivery and exfiltration split like a good heist crew:</p>

<table class="table"><tbody><tr><td>Domain</td><td>Role</td><td>Endpoints</td><td>IP</td><td>Protocol</td></tr><tr><td>j0o.pw</td><td>Stager only</td><td>/core, /core2</td><td>84.200.125.231</td><td>HTTPS</td></tr><tr><td>t4e.pw</td><td>Loader only</td><td>/res1.php–/res5.php</td><td>84.200.125.231</td><td>HTTPS</td></tr><tr><td>re3.pw</td><td>Loader only</td><td>/res3.php, /res6.php</td><td>84.200.125.231</td><td>HTTPS</td></tr><tr><td>si-dodgei.digital</td><td>Stealer C2</td><td>/api/auth, /api/upload/*</td><td>104.21.50.122 (Cloudflare)</td><td>HTTPS</td></tr></tbody></table>

<p>All three <code>.pw</code> domains hit the same IP (84.200.125.231). <code>j0o.pw</code> and <code>t4e.pw</code> registered January 28, 2026 — same day, PublicDomainRegistry.com, <code>orderbox-dns.com</code> DNS, Let’s Encrypt certs issued together. Palau TLD. Short names. Disposable. SOA emails: <code>ellisdtum@gmx.com</code>, <code>jameyjswoeste@gmx.com</code>. GMX. Throwaway.</p><p>Infrastructure still live as of February 8, 2026. Server-side polymorphism confirmed. <code>si-dodgei.digital</code> = new stealer C2 — registered December 24, PDR, Cloudflare. Separate delivery and exfiltration. Bad burns on the loader side don’t touch active stealers. Burns on the stealer C2 don’t touch the delivery pipeline. Operational resilience. The kind of planning that keeps you in business.</p><h2>Technical highlights</h2><h3>Direct syscalls with PRNG obfuscation</h3><p>The malware resolves NT syscall numbers the hard way – parsing&nbsp;<code>ntdll.dll</code>’s export table straight from the PEB, scanning for&nbsp;<code>syscall;</code> ret byte patterns, and storing the results in a table encrypted with a custom PRNG. The seed comes from&nbsp;<code>QueryPerformanceCounter</code>, PID, TID, and stack ASLR – four sources of randomness stirred together like a bartender making a cocktail that nobody ordered. Twenty syscalls wrapped, covering process injection for ABE key extraction, file I/O for prying open locked browser databases, and process termination for killing browsers that have the bad manners to hold file locks while someone’s trying to rob them.</p><h3>App-Bound Encryption bypass: A 20 KB reflective DLL</h3><p>Starting with Chrome 127 in July 2024, Google introduced <strong>Application Bound Encryption (ABE)</strong> – the browser’s master encryption key chained to the browser’s own process identity via a Windows Elevation Service COM interface. A neat trick. Credentials could only be decrypted from within a trusted browser process. It was the kind of lock that made honest people feel safe and dishonest people feel challenged.</p><p>Torg Grabber solved it with a lockpick that weighed exactly 19,968 bytes. A <strong>ChaCha20-encrypted Reflective DLL</strong>buried in the .rdata section like a razor blade in an apple.</p><p><em>See Appendix A, Figure A3</em></p><h4><em>The Encrypted Payload</em></h4><p>The DLL sits at a fixed offset in <code>.rdata</code> as an undifferentiated byte blob – no PE headers showing, nothing to catch the eye in static analysis. It might as well have been a patch of wallpaper. The parent function decrypts it in-place with a custom ChaCha20 implementation: hardcoded 256-bit key, 96-bit nonce, 312 blocks of 64 bytes. After decryption, the MZ and PE signatures emerge like a face surfacing in dark water, and the code walks the export directory looking for one specific string: ReflectiveLoader.</p><p>We extracted and decrypted the payload. It had the following particulars:</p>

<table class="table"><tbody><tr><td>Property</td><td>Value</td></tr><tr><td>Size</td><td>19,968 bytes (0x4E00)</td></tr><tr><td>Architecture</td><td>x64 PE32+</td></tr><tr><td>Compiler</td><td>GCC 15.2.0 (MSYS2 MinGW-w64)</td></tr><tr><td>Exports</td><td>ReflectiveLoader, GetIp</td></tr><tr><td>Sections</td><td>10 (.text, .data, .rdata, .pdata, .xdata, .bss, .edata, .idata, .tls, .reloc)</td></tr></tbody></table>

<p>The <code>ReflectiveLoader</code> export is textbook reflective injection: it walks backwards from <code>GetIp()</code> to find its own MZ header, resolves <code>LoadLibraryA</code>, <code>GetProcAddress</code>, and <code>VirtualAlloc</code> from kernel32.dll via PEB walking and ROR13 export name hashing, maps sections, processes relocations, resolves imports, flushes the instruction cache, and calls <code>DllMain</code>. Standard procedure. The kind of thing they’d teach in school if schools taught this sort of thing.</p><h4><em>Browser Detection and COM Elevation</em></h4><p>Once loaded, the DLL spawns a worker thread that reaches back to the parent through a named pipe and collects the ABE-encrypted key material. Then it figures out where it’s living. A call to <code>GetModuleFileNameW</code>, the path lowercased and matched against a list of known executables and installation directories – like a kidnapping victim recognizing the room by the wallpaper:</p>

<table class="table"><tbody><tr><td>Browser</td><td>Process / Path Match</td><td>Own CLSID</td><td>IID Variants</td><td>Vtable Offset</td></tr><tr><td><strong>Edge</strong></td><td>msedge.exe, \microsoft\edge\</td><td>{1FCBE96C-...}</td><td>2</td><td>+64</td></tr><tr><td><strong>Chrome</strong></td><td>chrome.exe, \google\chrome\</td><td>{708860E0-...}</td><td>3</td><td>+40</td></tr><tr><td><strong>Brave</strong></td><td>brave.exe, \brave-browser\</td><td>{576B31AF-...}</td><td>2</td><td>+40</td></tr><tr><td><strong>Avast</strong></td><td>avastbrowser.exe, \avast software\browser\</td><td>{EAD34EE8-...}</td><td>1</td><td>+40</td></tr><tr><td><strong>AVG</strong></td><td>avgbrowser.exe, \avg\browser\</td><td>{EDC3300F-...}</td><td>1</td><td>+40</td></tr><tr><td><strong>Vivaldi</strong></td><td>vivaldi.exe, \vivaldi\</td><td>Chrome’s CLSID</td><td>3</td><td>+40</td></tr><tr><td><strong>Opera</strong></td><td>opera.exe, \opera software\</td><td>Chrome’s CLSID</td><td>3</td><td>+40</td></tr></tbody></table>

<p>Each Chromium-based browser that implements ABE registers its own Elevation Service COM class with a browser-specific CLSID. The DLL carries five of these like a skeleton key ring: Chrome, Edge, Brave, Avast, AVG. For Vivaldi, Opera, and any unknown Chromium fork that wanders into the crosshairs, it falls back to Chrome’s CLSID and hopes for the best.</p><p>There’s a wrinkle, though, and it matters: <strong>Edge uses a different vtable layout</strong>. Extra methods in the interface push DecryptData to vtable offset +64 – method index 8 – instead of the standard +40, method index 5. Everyone else lines up neatly. Edge has to be different. The DLL handles this with a branch on browser type ID, because in this line of work, the details are what keep you out of trouble or put you in it.</p><p>After creating the COM object with CoCreateInstance(CLSCTX_LOCAL_SERVER), the DLL calls CoSetProxyBlanket with RPC_C_AUTHN_LEVEL_PKT_PRIVACY and EOAC_DYNAMIC_CLOAKING to set the security context, then invokes IElevator::DecryptData with the encrypted key wrapped in a BSTR. When it works – and it works more often than Google would like – the method hands back a 32-byte BSTR: the AES-256 master key. The keys to the kingdom, delivered through the kingdom’s own front door.</p><h4><em>The Response</em></h4><p>The decrypted master key is packed into a 44-byte response and written back through the named pipe, neat as a coroner’s report:</p>

<p>The DLL carries debug logging <code>– [DLL] Detected: Chrome, [DLL] Elevator object created with IID variant 2, [DLL] Master key extracted successfully! </code>– that gets buffered and sent back with the key. Development artifacts left in the production code, like a carpenter’s pencil marks under the paint. Sloppy, maybe, but also human. After the response goes through, the parent process terminates the suspended browser and uses the recovered master key to decrypt the Chromium <code>encrypted_key</code> from <code>Local State</code>, which unlocks the credential entries in <code>Login Data</code>, <code>Cookies</code>, and <code>Web Data</code>. The vault door swings open. Everything inside belongs to someone else.</p><h4><em>Corpus-Wide ABE Timeline</em></h4><p>The encrypted DLL blob runs hot with entropy in the PE’s&nbsp;.rdata section, and the parent binary always carries the string&nbsp;"<code>ReflectiveLoader</code>" – both traits as distinctive as a scar. We didn’t need to decrypt anything to spot ABE capability across all 139 samples. Automated triage told the story:</p><table class="table"><tbody><tr><td>Phase</td><td>Samples</td><td>ABE Bypass</td><td>Blob Size</td></tr><tr><td>Telegram Bot API (Dec 9–11)</td><td>25</td><td>None</td><td>–</td></tr><tr><td>GRAB TCP Protocol (Dec 17–20)</td><td>4</td><td>None</td><td>–</td></tr><tr><td>REST API, first build (Dec 18)</td><td>1</td><td>None</td><td>–</td></tr><tr><td>REST API, production (Dec 22+)</td><td>109</td><td><strong>All</strong></td><td>18–20 KB</td></tr><tr><td>GRABBER variant w/o ABE (Feb 3)</td><td>1</td><td>None</td><td>–</td></tr></tbody></table><p>The ABE bypass shipped with the very first dedicated C2 domain build – <code>attackzombie.com</code>, December 22, 2025 – and rode along in every REST API sample since. Not a later addition. A launch feature. The developers considered it essential equipment, the way a safecracker considers a stethoscope. The lone exception was a 122 KB <code>safeguss.com</code> sample from February 3 that looked more like a stripped loader than the full stealer – a scout, not the army.</p><p>The encrypted blob grew over time, the way a pickpocket’s ambition grows:</p><p><em>See Appendix A, Figure A4</em></p><p>The 18-to-19 KB growth around December 29 lines up with the addition of Avast and AVG Secure Browser CLSIDs. Two 20 KB blobs flickered into existence on January 26–27 and then vanished – an experimental build that got trimmed back, like a line of dialogue that didn’t make the final cut.</p><h3>Operator tags: Fingerprinting the MaaS customers</h3><p>Every REST API build carries an <strong>operator tag</strong> – a short string identifying the customer, sent as the first field in the C2 registration. A calling card. A signature on the dotted line. The tag is resolved through a two-tier mechanism: the malware checks the <code>GRABBER_TAG</code> environment variable first, and only falls back to a hardcoded default if the env var comes up empty:</p>

<p>In older builds, the fallback tag sits in .rdata between the mutex format string "<code>Local\%s</code>" and the C2 domain – as conspicuous as a name tag at a criminal convention. In newer builds, the compiler inlines short tags as <code>mov</code> immediates (e.g., <code>mov dword ptr [rip+disp], 73756564h</code> for “deus”), and the longest tags use <code>mov rax</code>, <code>imm64</code>. Even the machine code has an opinion about how to keep a secret.</p><p>At runtime, the resolved tag gets copied into a 640-byte registration structure and shipped off to <code>/api/auth</code> along with the machine’s vital statistics:</p>

<p>A brief experiment – five samples across three days in early February – pushed the idea further: the payload read <strong>everything</strong> from environment variables. <code>GRABBER_HOST</code>, <code>GRABBER_TAG</code>, <code>GRABBER_ANTI_SNG</code>,<code>GRABBER_ANTI_VM</code>, <code>GRABBER_STREAMING</code>. One binary to serve them all. A universal key. At first it looked like the experiment died after three days – subsequent builds went back to hardcoded domains and tags. But starting Feb 10, the env-var mechanism came back for good: <strong>every build from Feb 10 onward</strong> includes <code>GRABBER_*</code> env var support alongside hardcoded defaults, and the builder simultaneously switched all operators from plaintext <code>.rdata</code> strings to compiler-inlined <code>mov</code> immediates. A unified builder update. The stealer became truly operator-agnostic – the way a gun doesn’t care whose hand it’s in.</p><p>Across the corpus, we extracted over <strong>40 distinct operator tags</strong>. The most active:</p><table class="table"><tbody><tr><td>Count</td><td>Tag</td><td>Type</td><td>Domains Used With</td></tr><tr><td>42x</td><td>5197705037</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc, technologytorg.com, bbcplay.top, playbergs.info</td></tr><tr><td>24x</td><td>8172045377</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc, bbcplay.top, playbergs.info</td></tr><tr><td>24x</td><td>main1402_2</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>19x</td><td>0902</td><td>Numeric (build ID?)</td><td>evasivestars.com</td></tr><tr><td>16x</td><td>5362456016</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc, bbcplay.top, playbergs.info</td></tr><tr><td>15x</td><td>main1402</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>14x</td><td>5551690712</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc, bbcplay.top</td></tr><tr><td>9x</td><td>Main</td><td>Nickname</td><td>sinixproduction.com, startbuldingship.com, technologytorg.com</td></tr><tr><td>9x</td><td>578510323</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc</td></tr><tr><td>7x</td><td>Den</td><td>Nickname</td><td>technologytorg.com, attackzombie.com</td></tr><tr><td>7x</td><td>7612929707</td><td>Numeric (unresolved)</td><td>gogenbydet.cc, bbcplay.top, playbergs.info</td></tr><tr><td>6x</td><td>Deus</td><td>Nickname</td><td>attackzombie.com, technologytorg.com, safeguss.com</td></tr><tr><td>5x</td><td>main2402_1</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>4x</td><td>Gapi</td><td>Nickname</td><td>si-dodgei.digital, avanpost-fi.digital</td></tr><tr><td>3x</td><td>Gd</td><td>Initials</td><td>technologytorg.com, attackzombie.com</td></tr><tr><td>3x</td><td>7287445517</td><td><strong>Telegram ID</strong> (confirmed)</td><td>gogenbydet.cc</td></tr><tr><td>3x</td><td>main_new</td><td>Nickname</td><td>evasivestars.com, wulingyuanparkzone.com</td></tr><tr><td>3x</td><td>main2002_2</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>3x</td><td>Meow</td><td>Nickname</td><td>si-dodgei.digital</td></tr><tr><td>2x</td><td>7488523544</td><td><strong>Telegram ID</strong> (confirmed)</td><td>playbergs.info</td></tr><tr><td>2x</td><td>8251115314</td><td>Numeric (unresolved)</td><td>playbergs.info</td></tr><tr><td>2x</td><td>7694683550</td><td>Numeric (unresolved)</td><td>gogenbydet.cc, playbergs.info</td></tr><tr><td>2x</td><td>main2</td><td>Nickname</td><td>technologytorg.com</td></tr><tr><td>2x</td><td>BB1</td><td>Nickname</td><td>safeguss.com</td></tr><tr><td>2x</td><td>main7</td><td>Nickname</td><td>evasivestars.com</td></tr><tr><td>2x</td><td>main2302_1</td><td>Date-encoded batch</td><td>evasivestars.com</td></tr><tr><td>2x</td><td>pb2</td><td>Nickname</td><td>safeguss.com</td></tr><tr><td>2x</td><td>deus_auto</td><td>Nickname</td><td>wulingyuanparkzone.com</td></tr><tr><td>2x</td><td>capha2</td><td>Nickname</td><td>safeguss.com</td></tr></tbody></table>

<p>Three kinds of tags now: <strong>nicknames</strong> (<code>den, deus, gd, tf, main, BB1, BattleBuild, capha2, pb2</code>) – the kind of names men give themselves when they think nobody’s looking. <strong>Date-encoded batch IDs</strong> (<code>main1402, main1402_2, main2002_2, main2302_1,main2402_1</code> – where the digits encode the build date as DDMM) – <code>evasivestars.com</code> alone received 74 samples through this mechanism, each tag a timestamp on a factory floor. And <strong>numeric Telegram user IDs</strong> that we confirmed by running eight of twelve through the TelegramDB OSINT database. The C2 panel uses the IDs to route stolen-goods notifications to the operator’s Telegram. The <code>main/main2/main5/main7/main_new/main10</code> progression suggests a developer tag, while the date-encoded variants (<code>main1402</code> = Feb 14 batch) indicate automated nightly builds. The deus lineage evolved through <code>deus_new3</code>, <code>deus_new4</code>, and <code>deus_auto</code> on <code>wulingyuanparkzone.com</code> – iterative testing, like a man trying on aliases until one fits.</p><h4><em>Unmasking the Operators</em></h4><p>Running the numeric tags through TelegramDB was like pulling masks off at a costume party. Underneath, the faces were about what you’d expect:</p><table class="table"><tbody><tr><td>Tag</td><td>Telegram Name</td><td>Username</td><td>Previous Usernames</td><td>Notable</td></tr><tr><td>5197705037</td><td><strong>F̲a̲s̲o̲L̲’</strong></td><td>@Pi55_0ff</td><td>@SCAMHERE1</td><td>Top operator, 42 samples. Previous username is a confession</td></tr><tr><td>8172045377</td><td><strong>финфанфун</strong></td><td>@ytcel</td><td>@zxcnork, @jxnxdxsxxm</td><td>24 samples. Russian display name</td></tr><tr><td>578510323</td><td><em>(hidden)</em></td><td>@mamontovv</td><td>@reportmamont, @mamont0w, @rukoeb_3000</td><td>9 samples. “Мамонт” = Russian for a scam victim. Premium</td></tr><tr><td>5551690712</td><td><strong>L1man</strong></td><td>@ezbonus22</td><td>@hydrosh0t, @lox3526tyrk</td><td>14 samples. “лох” = Russian for sucker</td></tr><tr><td>7287445517</td><td><strong>ANRILOV | PAYPAL</strong></td><td>@anrilovfck</td><td>@cryptowoma, @ebalvseh11</td><td>3 samples. Bio: “PAYPAL WORK | MALWARE MONSTER”. Premium</td></tr><tr><td>5362456016</td><td><strong>Tony Montana</strong></td><td>@scarface_logs</td><td>@G5zvkr</td><td>16 samples. Bio links @NoMetaRu (logs marketplace). Profile pic: Scarface still with “SCARFACE LOGS” overlay. Premium, DC4</td></tr><tr><td>7488523544</td><td><strong>123 1</strong></td><td>@scamsomebody</td><td>@declineeeeed, @dennnied1</td><td>2 samples. Username literally @scamsomebody. Previous names reference declining/denying – chargebacks? Premium</td></tr><tr><td>1527633244</td><td><em>(hidden)</em></td><td>@wordpress20</td><td>@teamphoenixs, @sneqixolod</td><td>1 sample. “teamphoenix” – possibly group-affiliated</td></tr><tr><td>7694683550</td><td><em>(not indexed)</em></td><td>–</td><td>–</td><td>2 samples. A ghost</td></tr><tr><td>8598114766</td><td><em>(not indexed)</em></td><td>–</td><td>–</td><td>1 sample</td></tr><tr><td>8251115314</td><td><em>(not indexed)</em></td><td>–</td><td>–</td><td>2 samples</td></tr><tr><td>8402108450</td><td><em>(not indexed)</em></td><td>–</td><td>–</td><td>1 sample</td></tr></tbody></table>

<p>The username histories read like a glossary of Russian cybercrime slang. “Мамонт” – mammoth – is what they call a scam victim, from the expression “мамонт пришел,” the mammoth has arrived. “Лох” – sucker, mark, the one holding the short end. @SCAMHERE1 needs no translation in any language. One operator’s public bio announces “PAYPAL WORK | MALWARE MONSTER” with the quiet pride of a man who put his occupation on his tax return. <code>@scarface_logs</code>– “Tony Montana” – links to <code>@NoMetaRu</code>, a logs marketplace, and uses a Scarface movie still with “SCARFACE LOGS” branding as a profile picture. Subtle as a brick through a window. The newest arrival, <code>@scamsomebody</code>, leaves even less to interpretation, with previous usernames <code>@declineeeeed</code> and <code>@dennnied1</code> suggesting chargeback fraud experience – the kind of resume you don’t put on LinkedIn. Four carry Telegram Premium – these aren’t burner accounts tossed after a single job. These are established identities, permanent residents in the Russian cybercrime neighborhood, the kind of people who pay rent and expect the landlord to fix the plumbing.</p><p>All eight resolved accounts were still publicly accessible at the time of writing (Mar 2026). Nobody had bothered to draw the curtains.</p><p>Several tags appear across multiple C2 domains. den shows up on builds for both <code>technologytorg.com</code> and <code>attackzombie.com.deus</code> spans three domains. Most strikingly, we observed a full <strong>domain rotation chain</strong> for the numeric-ID operators: <code>gogenbydet.cc</code> (Dec 22 – Feb 12) → <code>bbcplay.top</code> (Feb 12 – Feb 22) → <code>playbergs.info</code> (Feb 22 – present). Operators <code>5197705037</code>, <code>8172045377</code>, <code>5362456016</code>, <code>7612929707</code>, and <code>7694683550</code> all followed this migration path, like a parade of regulars moving to a new bar every ten days. New operators (<code>7488523544, 8251115314, 8402108450</code>) appeared directly on playbergs.info – fresh faces who never knew the old place. The tags identify <strong>operators</strong>, not infrastructure, and the seamless migration suggests the panel backend can redirect operators to new domains without breaking stride. The early Telegram and GRAB TCP builds predate the mechanism entirely – no tags, no calling cards, just the raw proto-malware feeling its way in the dark.</p><p>The env-var mechanism combined with hardcoded fallbacks is the smoking gun for the MaaS model. The builder can bake operator-specific values into the binary or delegate everything to the dropper, letting a single compiled payload serve any customer who walks through the door. It’s the franchise model, applied to crime.</p><h2>C2 infrastructure</h2><p>Eighteen C2 domains identified over twelve weeks, most tucked behind Cloudflare like witnesses in a protection program:</p><table class="table"><tbody><tr><td>Domain</td><td>Registered</td><td>Samples</td><td>Notes</td></tr><tr><td>gogenbydet.cc</td><td>Dec 22</td><td>74</td><td>Dominant Jan–Feb; operators migrated out</td></tr><tr><td>evasivestars.com</td><td>~Feb 2</td><td>74</td><td>Exploded via date-encoded batch builds</td></tr><tr><td>bbcplay.top</td><td>Feb 11</td><td>33</td><td>Active Feb 12–22; PDR registrar; fake Chrome installer delivery</td></tr><tr><td>technologytorg.com</td><td>Dec 24</td><td>33</td><td>Contains “torg” – where the name came from</td></tr><tr><td>playbergs.info</td><td>Feb 22</td><td>18</td><td>Current primary for numeric-ID operators; NiceNic registrar</td></tr><tr><td>attackzombie.com</td><td>Dec 16</td><td>10</td><td>First dedicated C2, the one that started it</td></tr><tr><td>safeguss.com</td><td>~Feb 3</td><td>7</td><td>Growing; operators pb2, capha2, BB1, deus</td></tr><tr><td>si-dodgei.digital</td><td>Dec 24</td><td>5</td><td>Stealer C2 for delivery chain; PDR registrar</td></tr><tr><td>wulingyuanparkzone.com</td><td>Feb 3</td><td>5</td><td>deus lineage operators; 22-char domain spans 3 mov immediates</td></tr><tr><td>sinixproduction.com</td><td>2021 (!)</td><td>3</td><td>An old domain with a new purpose</td></tr><tr><td>avanpost-fi.digital</td><td>~Feb 19</td><td>2</td><td>gapi operator (same as si-dodgei.digital); PDR registrar</td></tr><tr><td>50elk.com</td><td>Jun 2024 (!)</td><td>2</td><td><strong>Different C2 backend</strong> (/api/machine/set-files-r); NiceNic registrar; VT 10/93</td></tr><tr><td>new-app-techno.com</td><td>Feb 3</td><td>1</td><td>Operator File_23; Realtime Register (PDR reseller); Cloudflare</td></tr><tr><td>findyour-dreams.com</td><td>Dec 28</td><td>1</td><td>&nbsp;</td></tr><tr><td>startbuldingship.com</td><td>Jan 5</td><td>1</td><td>Typo: “bulding” – even criminals can’t spell</td></tr><tr><td>quick-neo.com</td><td>Oct 2025</td><td>1</td><td>/api/machine/set-files-r backend (earliest sample); pre-staged domain</td></tr></tbody></table>

<p>The C2 infrastructure tells a story of <strong>domain rotation</strong> – organized, deliberate, like a crew that knows when to move. gogenbydet.cc dominated from late January through early February, then operators migrated to <code>bbcplay.top</code> (Feb 12–22), which was in turn replaced by <code>playbergs.info</code> (Feb 22 – present). Meanwhile, evasivestars.com quietly became the highest-volume domain through automated batch builds with date-encoded operator tags, now tied with <code>gogenbydet.cc</code> at 74 samples each – a factory nobody noticed because it didn’t make noise. A separate infrastructure cluster uses <code>.digital</code> TLD domains (<code>si-dodgei.digital, avanpost-fi.digital</code>) registered through the same PDR registrar, both serving the <code>gapi/meow</code> operator. Combined with the operator tags and the <code>GRABBER_HOST</code> environment variable, the picture is clear enough to read without glasses: <strong>Malware-as-a-Service</strong>, a builder model where each customer gets a binary with their name and C2 address baked in. The twelve numeric operator tags – eight confirmed as live Telegram accounts – prove the panel routes stolen data notifications straight to the operator’s phone. The Telegram-only exfiltration model didn’t die; it evolved into a notification layer sitting on top of the REST API architecture. Old habits don’t die. They get promoted.</p><h3>Registrar clustering and WHOIS overlap</h3><p>Three major registrar clusters emerged, and the WHOIS data gave us a gift – direct registrant identity links across multiple domains, wrapped up with a bow:</p>

<table class="table"><tbody><tr><td>Registrar</td><td>Domains</td><td>WHOIS Registrant</td><td>VT Detections</td></tr><tr><td><strong>Global Domain Group</strong>#3956</td><td>technologytorg.com, safeguss.com, evasivestars.com</td><td>Redacted; all three registered within 6 weeks (Dec 24 – Feb 2)</td><td>11/93, 0/93, 0/93</td></tr><tr><td><strong>NiceNIC (HK)</strong> #3765</td><td>gogenbydet.cc, findyour-dreams.com, playbergs.info,50elk.com</td><td><strong>Same registrant name hash</strong> 1f8f4166599d23ee across all four; two email clusters: 9253e579452ffad5s@(gogenbydet/findyour-dreams) and 6eb609d996e182a6s@ (playbergs/50elk). 50elk.comregistered <strong>Jun 2024</strong> (pre-staged); Peru registrant.</td><td>1/93, 8/93, 2/93, 10/93</td></tr><tr><td><strong>Registrar.eu (NL)</strong>#1647</td><td>attackzombie.com</td><td>Whois Privacy Protection Foundation (NL)</td><td>8/93</td></tr><tr><td><strong>Dynadot</strong> #472</td><td>sinixproduction.com</td><td>Super Privacy Service LTD; domain from <strong>2021</strong>, repurposed Jan 2026</td><td>0/93</td></tr><tr><td><strong>Realtime Register (NL)</strong> #839</td><td>startbuldingship.com, new-app-techno.com</td><td>Finland / Germany (Thüringen); PDR reseller for new-app-techno.com; startbuldingship.com <strong>suspended</strong></td><td>0/93, 1/93</td></tr><tr><td><strong>PDR / PublicDomainRegistry</strong>#303</td><td>si-dodgei.digital,&nbsp;bbcplay.top,&nbsp;avanpost-fi.digital</td><td>GDPR-masked (Germany) / “Filip Cooper” (Seychelles); <strong>three C2 domains</strong> through same registrar; si-dodgei.digital and avanpost-fi.digital share .digital TLD and gapi operator</td><td>0/93, 0/93, 0/93</td></tr><tr><td><strong>Hostinger</strong> #1636</td><td>wulingyuanparkzone.com</td><td>Lithuania</td><td>0/93</td></tr><tr><td><strong>Dominet/Aliyun (HK)</strong>#3775</td><td>quick-neo.com</td><td>Malaysia; registered <strong>Oct 2025</strong> – 2 months before first sample</td><td>2/93</td></tr></tbody></table><p>The <strong>NiceNIC cluster</strong> was the strongest find – and it grew. All four domains share the exact same registrant name hash (<code>1f8f4166599d23ee</code>), split into two email-address pairs: <code>gogenbydet.cc/findyour-dreams.com</code> (email <code>9253e579452ffad5s@</code>, Hong Kong/Ohio registrants) and <code>playbergs.info/50elk.com</code> (email <code>6eb609d996e182a6s@</code>, Hong Kong/Peru registrants). The shared name hash proves all four were registered by the same individual despite claiming different countries. Same hand, same pen, four different post offices. Notably, <code>50elk.com</code> was registered in <strong>June 2024</strong> – eight months before the first Torg Grabber sample – and carries 10/93 VT detections with 2,000–4,000 daily malware hits, suggesting it was already in the business before being repurposed as a Torg Grabber C2. The Global Domain Group cluster includes three domains, all registered within a six-week window. The <strong>PDR cluster</strong> now holds three domains: <code>si-dodgei.digital</code> (Dec 24), <code>bbcplay.top</code>(Feb 11), and <code>avanpost-fi.digital</code> (Feb 19). The <code>.digital</code> pair is particularly telling – both serve the same <code>gapi/meow</code> operator and share the same TLD, confirming they’re managed by the same infrastructure operator. The <strong>Realtime Register </strong>cluster now includes two domains: <code>startbuldingship.com</code> (Jan 5, Finland, suspended) and <code>new-app-techno.com</code> (Feb 3, Germany/Thüringen), the latter sold through PDR as reseller – creating a cross-link to the PDR cluster, the way one lie always connects to another. The operation used eight registrars across Hong Kong, the US, the Netherlands, Germany, the Seychelles, Peru, Finland, and Lithuania – diversifying against takedowns the way a smart investor diversifies against market crashes.</p><p>Three domains stuck out like sore thumbs in a velvet glove:</p><ul><li data-list-item-id="ee891671d04e4d6332b6927e95f08c327"><code><strong>sinixproduction.com</strong></code> was registered in January 2021 – five years before Torg Grabber drew its first breath. Its nameservers were switched to Cloudflare on January 13, 2026. An acquired domain, or a compromised one. Either way, it had a past, and its past wasn’t in malware.</li><li data-list-item-id="e131fd0d8f98bd4f1e3ca771a168a134d"><code><strong>50elk.com</strong></code>, registered June 17, 2024 via NiceNic, carried 2,000–4,000 daily malware hits in our domain reputation data before Torg Grabber even existed. Deep analysis in IDA Pro reveals these builds use a <strong>completely different C2 backend</strong> – <code>POST /api/machine/set-files-r</code> with multipart form-data uploads – rather than Torg Grabber’s native REST API. Despite the different exfiltration protocol, the binaries share the full <code>GRABBER_*</code> environment variable framework, anti-VM/anti-CIS checks, and mutex pattern. They self-identify as "<code>grabber v1.0</code>" with plaintext debug messages in <code>.rdata</code>. See <em>A Parallel Backend:&nbsp;</em><code><em>/api/machine/set-files-r</em></code> for details.</li><li data-list-item-id="e364e8168c3762cb784cdc65306447ebf"><code><strong>quick-neo.com</strong></code>, registered October 30, 2025, pre-dates all known samples by six weeks and carries a Cloudflare Radar rank of 10,000 and a Cisco Umbrella rank of ~242,000. IDA Pro analysis confirms its December 18 sample uses the same <code><strong>/api/machine/set-files-r</strong></code><strong> backend</strong> as the <code>50elk.com</code> builds – making it the earliest known sample with this protocol, from the same week the REST API transition began. See <em>A Parallel Backend:&nbsp;</em><code><em>/api/machine/set-files-r</em></code><em> </em>for details.</li></ul><h3>The GRAB TCP server</h3><p>The two experimental GRAB protocol domains –&nbsp;<code>bk.tara.net.bd</code> and&nbsp;<code>raketa.tara.net.bd</code> – resolve to&nbsp;<code>190.92.174.248</code>, hosted by <strong>WHG Hosting Services Ltd</strong> (AS199404, UK company, IP geolocated to India). Unlike the REST API domains, this one isn’t hiding behind Cloudflare. It uses a Let’s Encrypt wildcard for&nbsp;<code>*.tara.net.bd</code> and shares the server with&nbsp;<code>potshilpo.shop</code>, a Bangladesh-based domain. Shared hosting. The developer phase, where you don’t yet have the budget or the paranoia for dedicated infrastructure. BitDefender and G-Data flag&nbsp;tara.net.bd as malware. Someone noticed, even if not everyone.</p><h3>What VT sees: Distribution and delivery</h3><p>VirusTotal’s communicating files for the three busiest C2 domains tell the story of how Torg Grabber reaches its victims. The delivery mechanism is the oldest trick in the book, dressed up with a fresh coat of paint: trojanized installers, ZIP-packaged lures, digital candy left on the doorstep.</p><p><strong>Fantasy-themed lures</strong> (<code>technologytorg.com</code>): The ten most recent communicating files are 87–113 MB ZIP installers wearing auto-generated fantasy names like costumes at a masquerade:&nbsp;<code>Aerovora.zip</code>,&nbsp;<code>Nebulax.zip</code>,&nbsp;<code>Pyroxis.zip</code>,&nbsp;<code>Ignisyn.zip, Aetherion.zip</code>,&nbsp;<code>Zephyrion.zip</code>,&nbsp;<code>Aquathea.zip</code>,&nbsp;<code>Nebulynx.zip</code>,&nbsp;<code>Luminavora.zip</code>. The naming convention had the mechanical creativity of a builder script that read too many sci-fi paperbacks.</p><p><strong>Pirated software lures</strong> (<code>gogenbydet.cc</code>): Multiple 166 MB ZIPs labeled&nbsp;<code>Terraria_1.4.5.zip</code> and&nbsp;<code>Setup.zip</code> – bait for people who want something for nothing, which is most people. A smaller&nbsp;loader <code>.zip</code> at 31 MB suggested a more targeted delivery chain, something with a shorter fuse.</p><p><strong>Numeric-ID lures</strong> (<code>attackzombie.com</code>): Smaller 3 MB ZIPs with numeric filenames –&nbsp;<code>24323350</code>,&nbsp;<code>24353240</code>,&nbsp;<code>24427545</code> – plus&nbsp;installer <code>.zip</code>. A simpler naming scheme from the earliest REST API domain, back when the operation was still figuring out its wardrobe.</p><p><strong>Droppers on disk</strong> turn up as randomly-named executables in&nbsp;<code>C:\Windows\:&nbsp;v4jkqh.exe</code>,&nbsp;<code>hkjpy08.exe</code>,&nbsp;<code>we4osct.exe</code>, <code>bfp2w6.exe</code>. The naming pattern of a crypter or loader that doesn’t want to be remembered – digital aliases, disposable as matchbook covers.</p><p><strong>VT label noise</strong>: The communicating files are variously tagged&nbsp;<code>Trojan.dacic/vidar</code>,&nbsp;<code>trojan.aotera</code>,&nbsp;<code>trojan. cryptagen</code>t, and even&nbsp;<code>trojan.aotera/rhadamanthys</code> – a mess of misattribution that brought Torg Grabber to our attention in the first place. None of these labels fit. They reflect the industry’s reflex of pinning unknown stealers to familiar family names, the way a police sketch ends up looking like everybody and nobody.</p><p>All dedicated C2 domains share the same Cloudflare JARM fingerprint (<code>27d40d40d00...525c</code>) and use Google Trust Services TLS certificates. Matching suits. Same tailor.</p><h2>Attribution: Following the Telegram trail</h2><p>The 19 early Telegram-exfiltrating samples came with hardcoded bot tokens and channel IDs, carried openly in the binary like monogrammed luggage at an airport. By querying the Telegram Bot API, we obtained bot metadata, channel information, and – the prize – the <strong>Telegram accounts of the channel creators</strong>. The people who set up the drops. The hands behind the curtain.</p><p><em>See Appendix A, Figure A5</em></p><h3><em>The Bots</em></h3><table class="table"><tbody><tr><td>Bot</td><td>Username</td><td>Status</td></tr><tr><td>8247426625</td><td>@trtest12bot</td><td>Live</td></tr><tr><td>8284437818</td><td>@gr_bot_life_bot</td><td>Live</td></tr><tr><td>8456437646</td><td>@lalllaland_bot</td><td>Live</td></tr><tr><td>8471726820</td><td>@palayodd_bot</td><td>Live</td></tr><tr><td>4 others</td><td><em>(unknown)</em></td><td>Revoked</td></tr></tbody></table><p>Four bots still alive and ticking, tokens unrevoked, as of February 8, 2026. All eight channels private, two to three members each – the bot and one or two humans. Small operations. Tight circles. The kind of crew where everyone knows everyone and nobody knows anyone outside.</p><h3>The Operators</h3><p>Each exfiltration channel has a creator – the Telegram account that set up the room and invited the bot. We found four:</p><table class="table"><tbody><tr><td>Username</td><td>Display Name</td><td>User ID</td><td>Channel</td><td>Notable</td></tr><tr><td><strong>@ChaChaGuru</strong></td><td>Pope Robinson</td><td>7863185848</td><td>“BkChannel”</td><td><strong>ChaCha20 in the username</strong></td></tr><tr><td><strong>@OneCC_team</strong></td><td>OneCC</td><td>7983438838</td><td>“playodd”</td><td>Bio: “Selling CC&gt;First hand&gt;Sniffed”</td></tr><tr><td><strong>@the_01G</strong></td><td>X I</td><td>7960359642</td><td>“land”</td><td>&nbsp;</td></tr><tr><td><em>(none)</em></td><td>Lauriev Hontisorknnd</td><td>8214631236</td><td>“1 kanal”</td><td>“1 kanal” = “channel 1” – the test run</td></tr></tbody></table>

<p><strong>@ChaChaGuru</strong> was the lead we couldn’t ignore. The username is a direct reference to <strong>ChaCha20</strong> – the stream cipher that runs through Torg Grabber’s veins like blood type. It encrypts the C2 payloads. It protects the GRAB protocol. It wraps the shellcode. And the “Bk” in “BkChannel” matches <code>bk.tara.net.bd</code>, the GRAB TCP domain. Two connections. Both pointing the same direction. This wasn’t circumstantial evidence; it was a man leaving his business card at the scene.</p><p><strong>@OneCC_team</strong> presented as a group identity, and their public bio – “Selling CC&gt;First hand&gt;Sniffed” – was an open advertisement for stolen credit card sales. Not even coded. Just stated, plainly, the way a butcher advertises pork chops. Their profile photo history traced a career arc from an Amazon delivery truck through “OMG” and Bitcoin/AML imagery to a Guy Fawkes mask – a trajectory from e-commerce fraud through cryptocurrency crime to the anonymous hacking persona, documented in selfies.</p><p>All four creator accounts carry user IDs in the 7.8–8.2 billion range – created in the same timeframe, shortly before the bots themselves. The channel called “1 kanal” (Russian for “channel 1”) by “Lauriev Hontisorknnd” – a name as fabricated as a three-dollar bill – was the test channel. The first attempt. The rough draft.</p><h2>What Torg Grabber steals</h2><p>The stealer’s appetite is broad, and it’s getting broader. It wants everything, and it’s not shy about asking.</p><p>Here’s the rap sheet:</p><ul><li data-list-item-id="e6c94f8f1812a2022dd1d2f3d7da713fc"><strong>Browser credentials</strong>: 25 Chromium-based browsers (Chrome, Edge, Brave, Opera, Vivaldi, Yandex, CocCoc, CryptoTab, and 17 others that never thought they’d end up on a list like this) and 8 Firefox-family browsers, with AES-GCM, DPAPI, and ABE support. Plus harvesting of credentials previously extracted by the <strong>“Underground” tool</strong> – a standalone credential extraction tool whose output Torg Grabber scavenges like a jackal following a lion (see below)</li><li data-list-item-id="e189ced2b07dbbe824fef40f0391ad7f0"><strong>Browser extensions – 850 total</strong>: Three hardcoded lists. <strong>728 wallet extensions</strong> covering every crypto wallet from MetaMask and Phantom down to ShibaWallet and xMetaCene. <strong>103 password/2FA extensions</strong> – LastPass, 1Password, Bitwarden, and every authenticator app that ever tried to keep someone safe. <strong>19 notes extensions</strong>, because sometimes people write their passwords on sticky notes, even digital ones. Full lists in the&nbsp;<a href="https://github.com/gendigitalinc/ioc" target="_blank">IOC repository</a></li><li data-list-item-id="e902a0534ddd9db1b31ca1626e07310a9"><strong>Desktop wallets</strong>: 30+ standalone applications – Exodus, Atomic, Electrum, Monero, Daedalus. The whole menagerie</li><li data-list-item-id="e8584d6b90fd45056b2e40596641095c2"><strong>Messaging</strong>: Discord tokens (LevelDB scanning), Telegram session data, Steam configs</li><li data-list-item-id="ea137fd09ecd26e88aaf53686e2757bc6"><strong>Credentials</strong>: VPN configs from 8 providers, FTP clients (5), email (Thunderbird, Outlook), password managers (7), gaming platforms (6)</li><li data-list-item-id="ef207f85eab7a553a1507c70c0dd6959d"><strong>System profiling</strong>: Hardware fingerprint, installed software, process list, screenshot, environment variables, and <strong>AV detection</strong> scanning 46 process signatures across 24 products – Kaspersky, Avast, ESET, CrowdStrike, SentinelOne, Windows Defender. It wants to know who’s watching before it starts working, the way a burglar checks for dogs before climbing the fence</li><li data-list-item-id="eaec55d241c9ae2b5988c1e458dd1ac8c"><strong>File grabbing</strong>: Pattern-based collection from Desktop and Documents with C2-configurable rules</li><li data-list-item-id="e5c1348e1d786ad029539f7c229d1606d"><strong>Arbitrary code execution</strong>: The C2 can deliver ChaCha-encrypted, zlib-compressed shellcode at registration. Just in case everything else wasn’t enough</li></ul><h2>850 browser extensions: Casting the widest net</h2><p>Perhaps the most striking thing about Torg Grabber isn’t what it does, but how much of it there is. Eight hundred and fifty extension IDs, hardcoded into the binary, organized into three tidy categories like a catalog for a store that sells things that don’t belong to it:</p><table class="table"><tbody><tr><td>Category</td><td>Count</td><td>Archive Path</td><td>What They Steal</td></tr><tr><td><strong>Wallet</strong></td><td>728</td><td>Wallet/Extension/</td><td>Crypto wallet seeds, keys, session data</td></tr><tr><td><strong>Password/2FA</strong></td><td>103</td><td>Password/</td><td>Password vaults, TOTP secrets, MFA tokens</td></tr><tr><td><strong>Notes</strong></td><td>19</td><td>Notes/</td><td>Saved notes – and the passwords people hide in them</td></tr></tbody></table><p>The <strong>728 wallet extensions</strong> cover essentially every crypto wallet ever conceived by human optimism. The marquee names are all there – MetaMask, Phantom, TrustWallet, Coinbase, Binance, Exodus, TronLink, Ronin, OKX, Keplr, Rabby, Sui, Solflare. But the list doesn’t stop at the big names. It keeps going, deep into the long tail, past projects with install counts you could fit in a phone booth – ShibaWallet, xMetaCene, Elli Sui Wallet. The kind of thoroughness that suggests the list was scraped from the Web Store rather than curated by hand. Nobody sits down and types 728 extension IDs one by one. Not even a criminal.</p><p>The <strong>103 password extensions</strong> are equally comprehensive. The majors – LastPass, 1Password, Bitwarden, KeePass, NordPass, Dashlane, ProtonPass, Enpass – plus niche products like Psono, Pleasant Password Server, and heylogin. And here’s the twist: <strong>31 two-factor authentication extensions</strong> are in the mix. 2FAAuth, GAuth, TOTP Authenticator, Akamai MFA. The stealer doesn’t just want the password. It wants the second factor too. The lock and the key and the deadbolt and the chain. Everything that stands between the victim and complete exposure.</p><p>For each matched extension, the malware vacuums data from three locations: 1. <code>Local Extension Settings/</code> – the extension’s LevelDB storage 2. <code>IndexedDB/</code> – any IndexedDB databases matching the extension ID 3. <code>Sync Extension Settings/</code> – synced data, if the user has Chrome Sync enabled</p><p>The archive paths include a DJB2 hash of the browser name – <code>Wallet/Extension/MetaMask/C-Chrome-a1b2c3d4/</code> – to keep stolen credentials from different browsers filed separately. Organized crime, in the most literal sense.</p><p>The full extension lists are published in the IOC repository. Defenders and extension developers can use them. Everyone else can marvel at the ambition.</p><h2>Harvesting a previous tool: “Underground”</h2><p>Early Torg Grabber builds contained code to harvest credentials from <code>C:\ProgramData\Underground</code> – a path that, at first glance, had the look of an anti-detect browser’s home directory. We spent some time chasing that theory. Turns out we were looking at it wrong. The way you sometimes look at a shadow on the wall and see a man, but when the light shifts it’s just a coat on a hook.</p><h3>What “underground” really is</h3><p>We recovered a number of&nbsp;<code>C:\ProgramData\Underground\logs.txt</code> files from infected machines. The logs told a different story. “Underground” isn’t a browser at all. It’s a <strong>standalone credential extraction tool</strong> with a two-stage architecture that bears a family resemblance to Torg Grabber’s own ABE bypass – the kind of resemblance that makes you check if they had the same father:</p><ol><li data-list-item-id="eaebbd3d4aa7deb4f016350202282ff88"><strong>Host process</strong> (injector) – enumerates installed browsers, creates a suspended browser process, performs reflective DLL injection, and talks to the injected payload through named pipes</li><li data-list-item-id="e0bdeb938b3bb7a840a901fe1addec28c"><strong>Injected DLL</strong> (reflective loader) – runs inside the browser process, decrypts the ABE-protected master key via Chrome’s COM Elevator service, then dumps credentials to JSON files</li></ol><p>The log output documents the full chain: browser enumeration, suspended process creation, ReflectiveLoader injection, named pipe setup (<code>\\.\pipe\chrome.nacl.*,&nbsp;\\.\pipe\mojo.*</code>), ABE key decryption via COM, profile enumeration, and credential extraction. It writes its take as JSON files and plaintext token files to&nbsp;<code>C:\ProgramData\Underground</code>. Neat. Professional. The kind of work that leaves receipts.</p><h3>What Torg Grabber harvests</h3><p>When Torg Grabber finds this directory – and on machines where the operators have been running their toolkit, it will – it parses three types of JSON output files left behind by the Underground tool:</p><ol start="3"><li data-list-item-id="e2607892443ff28f869bd1fa195fa5a42"><strong>Passwords</strong> –&nbsp;{<code>"origin":"..."</code>} objects with URLs, usernames, and passwords</li><li data-list-item-id="e0281f0bdf9f4fa2e26ba0e5c099a8086"><strong>Cookies</strong> –&nbsp;{<code>"domain":"..."</code>} objects with full cookie metadata</li><li data-list-item-id="eb155f96476575ab11879fc30506733c4"><strong>Payment cards</strong> –&nbsp;{<code>"card_number":"..."</code>} objects with card details</li></ol><p>It also collects three token files (<code>gaming_tokens.txt</code>,&nbsp;<code>media_tokens.txt</code>,&nbsp;<code>social_tokens.txt</code>) containing session tokens for various platforms. Double-dipping. Credentials that were already extracted once, stolen again for the archive.</p><h3>The connection</h3><p>The architectural overlap between Underground and Torg Grabber is the kind of thing that makes you sit up in your chair. Both use reflective DLL injection into suspended browser processes. Both use named pipe IPC. Both do COM-based ABE bypass. The blueprints are close enough to be cousins.</p><p>But the DLL-side log strings are completely different – Torg Grabber’s&nbsp;<code>abe_decrypt.dll</code> uses&nbsp;[<code>DLL</code>] prefixed messages that don’t appear anywhere in Underground’s logs, and the host-side injector strings from Underground are absent from&nbsp;<code>abe_decrypt.dll</code>. Different binaries. Same school of thought. This rules out a shared executable but points toward a shared codebase, a common author, or tools from the same ecosystem – bought from the same shelf in the same underground marketplace.</p><p>The working hypothesis: the operators who deploy Torg Grabber also ran the Underground tool on infected machines – either as a precursor or running alongside. Torg Grabber’s JSON parsers then scavenge whatever Underground left behind, like a second shift coming in to clean out what the first shift missed. This is consistent with the MaaS model: operators run multiple tools, and a good stealer picks up everything, even another tool’s leftovers.</p><h3>The CIS cleanup twist</h3><p>When the malware detects a CIS locale – Russia, Ukraine, Belarus, Kazakhstan, and the rest of the old neighborhood – it doesn’t merely skip collection. It actively <strong>deletes the entire Underground directory</strong>:</p>

<p>On CIS machines, this erases the Underground tool’s logs and extracted credentials – destroying evidence of the operators’ own activities. Not protecting fellow criminals’ data. Covering their own tracks. The kind of cleanup you do when you’ve been in someone’s house and you want to make sure nobody knows you were there.</p><h3>Gone in a day: The underground-to-ABE swap</h3><p>Corpus-wide analysis turned up a fact as clean and cold as a knife: Underground harvesting and the ABE bypass are <strong>perfectly mutually exclusive</strong>. Not a single sample in 139 builds contains both.</p><table class="table"><tbody><tr><td>Feature</td><td>Samples</td><td>Date Range</td><td>Binary Size</td></tr><tr><td>Underground harvesting</td><td>30</td><td>Dec 9 – Dec 20</td><td>265 – 525 KB</td></tr><tr><td>ABE bypass</td><td>109</td><td>Dec 22 – Feb 7</td><td>411 – 747 KB</td></tr><tr><td>Both</td><td><strong>0</strong></td><td>–</td><td>–</td></tr></tbody></table><p>The last Underground build compiled on <strong>December 20 at 15:45 UTC</strong>. The first ABE bypass build appeared <strong>38 hours later</strong>, on <strong>December 22 at 06:32 UTC</strong>. Not a gradual transition. Not a slow fade. A clean break. One feature walked out the door and another walked in, and they didn’t even pass each other in the hallway.</p><p>The logic reads like a business decision – and it was one. Once Torg Grabber gained its own built-in ABE bypass, there was no longer any need to scavenge credentials from a separate tool. The developers replaced a dependency on external tooling with native capability, the way a restaurant that used to buy bread from down the street puts in its own oven. The timing lines up with the December 22 pivot to production REST API infrastructure. Everything changed at once, because when you’re going to jump, you might as well jump with both feet.</p><h2>A parallel backend: /api/machine/set-files-r</h2><p>Three samples. Two domains. A completely different C2 protocol than the rest of the corpus, and yet the same malware framework underneath — like finding two different keys in the same man’s pocket, both opening different doors. <code>quick-neo.com</code> in December, <code>50elk.com</code> in February. This wasn’t some late experiment cooked up after the main line had settled. The quick-neo.com sample landed the same week the REST API transition began. The <code>/api/machine/set-files-r</code> backend was running in parallel from day one. Two horses in the same race, and nobody had bothered to tell the program.</p>

<table class="table"><tbody><tr><td>Date</td><td>Domain</td><td>Backend</td><td>Size</td><td>Features</td></tr><tr><td>Dec 18, 2025</td><td>quick-neo.com</td><td>machine_api</td><td>266 KB</td><td>Underground browser, no ABE, plaintext .rdata</td></tr><tr><td>Feb 17, 2026</td><td>50elk.com (×2)</td><td>machine_api</td><td>712 KB</td><td>GRABBER_* env vars, ABE bypass, plaintext .rdata</td></tr></tbody></table><p>The jump from 266 KB to 712 KB — nearly triple — and the feature additions along the way — ABE bypass, env vars, string encryption — mirror the main Torg line’s evolution over the same stretch. Same playbook. Different stage. This wasn’t a dead fork. Somebody was feeding it.</p><h3>What they share with standard Torg Grabber</h3><p>The familiar framework is present across both:</p><ul><li data-list-item-id="ecb3e00d261e86a6cb95c41e9b031c88e">Anti-analysis: GPU-based anti-VM (EnumDisplayDevicesA against vendor blocklist), locale-based anti-CIS (GetLocaleInfoA against blocklist), Local{MachineGuid} mutex.</li><li data-list-item-id="e180593968c5d6e901e25c4c1c5a2b0af">Build tag: “grabber v1.0” – logged at startup alongside a timestamp.</li><li data-list-item-id="ed0b237a6f1f9890c06b46a4f380da80d">GRABBER_* environment variables (Feb 17 builds only): GRABBER_HOST, GRABBER_TAG, GRABBER_ANTI_SNG, GRABBER_ANTI_VM, GRABBER_STREAMING, GRABBER_HWID, GRABBER_GPU, GRABBER_SESSION – same set, same defaults (HWID → c479d3ea-cedd-43ef-af74-dc6163e5dad7, GPU → Radeon RX550/550 Series). The Dec 18 build pre-dates the env var mechanism.</li></ul><h3>What is different: The C2 protocol</h3><table class="table"><tbody><tr><td>&nbsp;</td><td>Standard Torg Grabber</td><td>machine_api builds</td></tr><tr><td><strong>Registration</strong></td><td>POST /api/auth with HWID, operator tag, ChaCha20 key exchange</td><td>Stubbed out – auth function returns 1unconditionally</td></tr><tr><td><strong>Upload endpoint</strong></td><td>/api/upload/chunk (chunked), /api/stream/*</td><td>POST /api/machine/set-files-r</td></tr><tr><td><strong>Content type</strong></td><td>ChaCha20-encrypted + HMAC-SHA256 authenticated chunks</td><td>Multipart form-data (boundary=----UploadBoundary9876543210)</td></tr><tr><td><strong>Upload field</strong></td><td>Encrypted binary stream</td><td>zip_file – raw ZIP bytes</td></tr><tr><td><strong>Port</strong></td><td>443 (HTTPS via Cloudflare)</td><td>443 (HTTPS, direct – no Cloudflare)</td></tr><tr><td><strong>User-Agent</strong></td><td>Custom ("Mozilla/5.0 ... grabber/1.0" variants)</td><td>Plain "Mozilla/5.0"</td></tr><tr><td><strong>Error handling</strong></td><td>Retry with exponential backoff</td><td>HTTP 200 → success; 403/400 → abort immediately</td></tr><tr><td><strong>Archives sent</strong></td><td>Single encrypted stream</td><td>Two separate uploads: main.zip, files.zip</td></tr></tbody></table><p>&nbsp;</p>

<p>The /api/machine/set-files-r endpoint does not match any publicly documented stealer family’s C2 protocol. A ghost in the machine, and the machine wasn’t talking.</p><h3>The Collection pipeline</h3><p>Standard Torg sends single encrypted archive; machine_api builds construct two ZIP archives with distinct folder layout:</p>

<p>files.zip: Additional file grabber results.</p><p>The collection functions produce numbered debug log entries ([1] Creating ZIP buffer…, [2] Generating UserInfo…, etc.) — more structured than standard Torg’s free-form debug strings. The kind of organization that suggests someone was keeping score.</p><h3>Plaintext strings throughout</h3><p>Unlike the main Torg line — which progressively moved from plaintext .rdata to compiler-inlined mov immediates — both machine_api samples keep all strings as plaintext in .rdata. C2 domain, endpoint path, debug messages like “[#] Killed ALL %s processes: %d”. Everything out in the open. This branch never got the string hardening. Either they didn’t care, or they didn’t get the memo.</p><h3>Interpretation</h3><p>The quick-neo.com discovery settles the timeline. The&nbsp;/api/machine/set-files-r backend isn’t a late experiment — it’s contemporary with the earliest REST API builds. December 18 is the same day attackzombie.com samples first appeared. Two backends shipped from the same codebase on the same day. Like a man with two passports, both valid.</p><p>The ten-week gap between quick-neo.com (Dec 18, 266 KB) and 50elk.com (Feb 17, 712 KB) tells the rest of the story. The machine_api line tracked the main Torg evolution: ABE bypass added, env var framework integrated, binary nearly tripled in size. Not a dead fork. Actively maintained. Parallel development, same hands on both levers.</p><p>Two readings remain:</p><ol><li data-list-item-id="ef532baab10f732e03509e783ce1da74d">Operator-specific panel. Under the MaaS model, one customer runs a panel at /api/machine/set-files-r while the majority use the standard REST API panel.</li><li data-list-item-id="e55b3be61fa9f659eea94c15d688dc7fe">Developer’s own backend. The /api/machine/set-files-r panel is the developer’s original infrastructure, while the REST API was built for the MaaS product.</li></ol><p>Either way, the GRABBER_* environment variable framework and anti-analysis suite are the stable identity anchors — they persist across different C2 backends, string protection schemes, and collection pipeline layouts. The backend protocol itself is modular and swappable. The face changes. The fingerprints don’t.</p><h2>Conclusion</h2><p>Torg Grabber is a case study in velocity. Three months from prototype to production. Four exfiltration mechanisms tried – Telegram Bot API, GRAB TCP, REST API, and the parallel <code>/api/machine/set-files-r backend</code> – each one a rung on a ladder that only goes up. Eighteen C2 domains across eight registrars. A binary that nearly tripled in size while its developers were still registering the domains it would phone home to. It was like watching someone build an airplane while it was already taxiing down the runway.</p><p>The Telegram breadcrumbs left behind by the early builds – bot tokens, channel metadata, and an operator whose username literally namedrops the malware’s signature encryption algorithm – provided a window into the human side of the operation. These aren’t ghosts. They’re people, with Telegram Premium subscriptions and public bios that read like job applications for a criminal enterprise.</p><p>By resolving the numeric operator tags through OSINT databases, we put faces to eight of twelve MaaS customers. The faces weren’t pretty. Usernames referencing scamming (@SCAMHERE1, @scamsomebody), victims (<code>@mamontovv</code>, from “мамонт” – the mammoth, the mark, the one who showed up), suckers (<code>@lox3526tyrk</code>, from “лох” – the word speaks for itself), and stolen-credential marketplaces (<code>@scarface_logs</code> linking to <code>@NoMetaRu</code>). Four carry Telegram Premium – established actors, not disposable identities. Combined with the developer accounts recovered from the bot tokens, the picture is unusually complete. Both sides of a MaaS operation, buyer and seller, laid out under the light.</p><p>The observed delivery chain tells its own story – from a ClickFix clipboard attack hosted on Google Apps Script, through a multi-stage PowerShell stager with a fake progress bar and XOR-encrypted BITS transfers, to three polymorphic MinGW loaders served from disposable .pw domains. The delivery infrastructure is as carefully engineered as the stealer itself. Strict role separation between domains – stagers on j0o.pw, encrypted loaders on t4e.pw/re3.pw, exfiltration on the main C2 cluster – provides operational resilience: burning one domain doesn’t touch the others. The use of trusted platforms (Google Apps Script, Dropbox) for initial access and server-side polymorphism for loader generation makes static blocking about as effective as putting up a “No Trespassing” sign at a public park.</p><p>The family remains under active development. New C2 domains registered weekly. Builds compiled daily – 334 samples and counting, each one a fresh fingerprint. The operator base growing, 40+ tags and rising, new customers walking through the door. What initially looked like a three-day experiment with environment-variable configuration has since become the standard: every build from Feb 10 onward ships with <code>GRABBER_*</code> env var support and compiler-inlined string assignments, replacing the earlier plaintext <code>.rdata</code> approach. The most significant operational shift is the <strong>domain rotation chain</strong> (<code>gogenbydet.cc</code> → <code>bbcplay.top</code> → <code>playbergs.info</code>), where entire operator groups migrate to fresh infrastructure roughly every ten days – a cadence that makes domain-based blocking a losing game. Meanwhile, <code>evasivestars.com</code> has become a mass-build factory with date-encoded batch tags, suggesting automated deployment pipelines. We’ll keep watching. These are the kind of people who don’t stop until someone stops them.</p>

A newly identified MaaS credential stealer evolves from Telegram exfiltration to encrypted TCP and full REST API infrastructure

Torg Grabber: Anatomy of a New Credential Stealer 

<p>In the world of cybercrime, the best disguise is often just another criminal. Sometimes, a new threat will wrap itself in the "uniform" of a well-known group to avoid extra scrutiny. That is exactly how our story begins.</p><p>On a quiet Tuesday in February, a routine sample landed in our lab. At first glance, it appeared to be "Vidar," which is a common and widely understood type of malware. However, as our researchers began to look under the hood, the Vidar costume started to fall apart. This was not the work of a known group. It was something entirely new, highly sophisticated, and growing with incredible speed. We named it <strong>Torg Grabber</strong>.</p><h4>The mystery of the misclassification</h4><p>Detecting malware is often like recognizing a person by their gait or their handwriting. Vidar has a very specific "look" in its code. But this new sample was different. It was built with different tools, used different encryption, and spoke a completely different language when communicating with its creators.</p><p>Our team realized that Torg Grabber was essentially a digital pickpocket wearing a priest’s collar. By pretending to be a common threat, it hoped to fly under the radar of automated security systems. By the time we finished our investigation, we had uncovered 334 different versions of this malware, all created in a span of just three months. This was not a hobbyist at work: it was a production line.</p><h4>The evolution of a criminal business</h4><p>One of the most fascinating parts of this story is how the criminals behind Torg Grabber "upgraded" their business. We tracked three distinct phases of their growth.</p><p>In the beginning, they were small and cautious. They used simple Telegram bots to ship stolen data back to private chat channels. This was the digital equivalent of a rookie thief shouting secrets across a crowded room. It worked, but it was noisy and easy to shut down.</p><p>Only a few weeks later, they moved into an experimental phase. They created a custom, high speed communication protocol that used advanced military grade encryption. It was sophisticated, but it was also difficult for them to manage at a large scale.</p><p>Finally, they settled on what we call the "Production Rig." They built a professional grade system that hides its traffic behind legitimate web services like Cloudflare. This makes their malicious activity look like normal web browsing. By the time they reached this stage, Torg Grabber had become a "Malware as a Service" operation, where the developers sell their "product" to dozens of other criminals who want to get into the game.</p>

<h4>The "ClickFix" trap: how they get in</h4><p>Torg Grabber does not just break into your house: it tricks you into opening the door. Our team observed a clever tactic called "ClickFix."</p><p>Imagine visiting a website and seeing a pop up that says your browser needs a security update. It looks official and even includes a progress bar that ticks away for seven minutes. While you wait for this fake "Windows Security Update" to finish, the malware is silently working in the background. It is downloading multiple layers of code, each one designed to hide the next, until the final infostealer is safely tucked away in your computer's memory.</p><p>We have seen this malware hidden in all sorts of digital "candy," including fake game cheats for popular titles and cracked versions of expensive software. The lure changes, but the goal is always the same: social engineering.</p>

<h4>The digital master key</h4><p>Perhaps the most dangerous feature of Torg Grabber is its ability to bypass modern browser security. Major browsers like Google Chrome and Microsoft Edge recently introduced a feature called "App-Bound Encryption." Think of it as a vault door that can only be opened by the browser itself.</p><p>To beat this, the creators of Torg Grabber built a custom "lockpick." It is a tiny piece of code, only 20 KB in size, that sneaks into a legitimate browser process. Once inside, it tricks the browser into using its own "master key" to unlock your saved passwords and credit card details. By the time the malware is done, it has effectively walked through the front door of your digital life using your own keys.</p><h4>A massive appetite for your data</h4><p>Unlike older malware that might just try to crash your computer, an infostealer has one goal: profit. Torg Grabber is programmed to find almost everything of value on your machine. Its "shopping list" is staggering:</p><ul type="disc"><li data-list-item-id="eee754b80a606370a3c6e23613c76bf58"><strong>Your Financial Life:</strong> It specifically looks for 728 different cryptocurrency wallet extensions. It does not just want the big names: it is programmed to recognize even the most obscure digital wallets.</li><li data-list-item-id="eccbe6d26d81a46afe89fb53e6b60bcf6"><strong>Your Security Tools:</strong> It targets 103 different password managers and two factor authentication tools. It knows that if it can steal your "vault," it has everything.</li><li data-list-item-id="e14f5ff1a5f2e77d96d83cede3d096582"><strong>Your Privacy:</strong> It scans your Desktop and Documents folders for notes where you might have jotted down sensitive passwords or recovery phrases.</li><li data-list-item-id="e96da5bcdfc161d32390554e495aebfba"><strong>Your Identity:</strong> It steals "session cookies." These allow a criminal to log into your email or social media accounts as if they were you, often bypassing the need for a password entirely.</li></ul>

<h4>Tracking the human fingerprints</h4><p>Our research went beyond just the code. We followed the digital breadcrumbs all the way back to the people running the show. Each version of Torg Grabber contains a "tag," which is like a signature for the criminal who bought it.</p><p>We extracted over 40 distinct operator tags and used them to unmask several established identities in the Russian cybercrime world. We found individuals with nicknames like "Tony Montana" and "ChaChaGuru" who were openly boasting about their successes in private channels. Some even linked their accounts to marketplaces where they sell the very data they stole from victims.</p><h4>Why technical dissection matters</h4><p>We do not tell this story just to show how complex these threats have become. We tell it because this kind of technical dissection is how better protection is built.</p><p>Unmasking Torg Grabber required careful reverse engineering, threat intelligence work, sample correlation, infrastructure tracking, and repeated hypothesis testing across hundreds of artifacts. That work still depends on human expertise, especially when the goal is not just to describe what malware does, but to understand what changed, why it changed, and what defenders should do next.</p><p>At the same time, investigations like this are also showing us how threat research is changing. At Gen Digital, we are increasingly using agentic AI workflows to help accelerate parts of reverse engineering, threat hunting, technical correlation, and evidence organization, while keeping researchers fully responsible for validation, judgement, and final conclusions. The result is not automated truth. It is a faster and more scalable way for expert analysts to work through complex investigations without lowering the bar for rigor.</p><p>That broader shift is something we explore in more detail in our article, <a href="https://www.gendigital.com/blog/insights/research/engineering-the-future-of-agentic-threat-hunting">Engineering the Future of Agentic Threat Hunting</a>, which explains how we are building AI-assisted investigative workflows to help researchers move faster while keeping every meaningful claim evidence-based and human-owned.</p><p>And for readers who want to go deeper into this specific case, from the malware internals to infrastructure and operator traces, you can read the full technical report here: <a href="https://www.gendigital.com/blog/insights/research/torg-grabber-credential-stealer-analysis" target="_blank" rel="noopener noreferrer">https://www.gendigital.com/blog/insights/research/torg-grabber-credential-stealer-analysis</a></p>

How a “Vidar” look‑alike turned out to be Torg Grabber—a fast‑growing infostealer-as-a-service with ClickFix lures, browser lockpicks and a sprawling criminal customer base

The Malware with a Secret Identity: How We Unmasked Torg Grabber

Senior Principal Research Engineer

Junior Data Scientist

AI Researcher

Research Manager

<p>Scam advertising does not thrive on social platforms because it is invisible. It thrives because it is designed to look legitimate, just long enough to reach victims before detection catches up.</p><p>In our first investigation,&nbsp;<a href="https://www.gendigital.com/blog/insights/research/scam-ad-machine-meta">The Scam Ad Machine</a>, we showed the scale of the problem and how widespread scam ads have become on Meta platforms, with roughly 1 in 3 ads approved for publication in the UK and EU being a scam.&nbsp;This second part builds on that foundation, focusing on how these campaigns actually operate in practice.</p><p>Across our investigation of Meta platforms, we saw the same pattern again and again, scammers combining normal advertising features, deceptive presentation tricks, and short-lived campaign tactics to stay in circulation. This is not a single evasion trick. It is an operating model.</p><p>Below, we break down the techniques we found at scale, and why many of them are difficult to catch through automated moderation, manual review, or public transparency tools.</p><h2>How scammers hide in plain sight</h2><h3>Multi-facet ads, hiding one scam among legitimate links</h3><p>One of the most common techniques we uncovered is what we call <strong>multi-facet advertisements</strong>.</p><p>These ads bundle multiple images, products, and links into a single ad. Most of the links point to legitimate marketplaces or well-known ecommerce platforms such as Amazon, eBay, AliExpress, or Etsy. Hidden among them is a single malicious or scam-related link, often leading to fake ecommerce stores, fraudulent service pages, account scams, or impersonation pages tied to public figures.</p><p>The trick is simple: make the scam look like part of a normal shopping experience.</p><p>By surrounding one malicious destination with a cluster of legitimate brands and products, the ad looks ordinary at first glance. That lowers suspicion for users and can also make review harder if the ad is assessed superficially. It also creates collateral damage, legitimate brands and products end up visually associated with fraudulent campaigns.</p><p>From a detection perspective, this should be a solvable problem. A robust review process could inspect the full set of linked domains and compare what is shown with what is actually being promoted. In practice, however, we identified large volumes of these campaigns running simultaneously from different advertisers on Meta platforms, often linked to newly created advertisers and low-history accounts.</p>

<h3>URL masking, when the ad shows one domain and sends users to another</h3><p>This is one of the most effective deception techniques we observed.</p><p>Scammers make an ad appear to link to a trusted domain, such as a major marketplace or brand, while the click sends the user somewhere else. The ad displays a familiar name, but the landing page belongs to unrelated infrastructure controlled by the attacker.</p><p>For users, especially on mobile, that visible domain cue is often enough. Many people do not inspect the final URL before clicking, and once they land on an attractive page with compelling offers or urgency signals, many will continue browsing.</p><p>In our observations, Meta’s API may expose the domain shown in the ad, not necessarily the final destination the user reaches after clicking. That makes this technique harder to detect programmatically and significantly complicates analysis by transparency researchers, watchdogs, journalists, regulators, and law enforcement.</p><p>In other words, what the ad appears to be, and where it actually leads, can diverge in ways that are difficult to verify at scale.</p>

<p>The actual link leads to the website selling products that are completely unrelated to the advertised ones.</p>

<h3>Typosquatting, deceptive subdomains, and misleading previews</h3><p>Why abandon a tactic that still works?</p><p>A classic technique remains highly effective, registering domains that closely resemble legitimate brands. A small spelling change, an extra character, or a visually similar character can be enough to fool users at a glance. In fast-scrolling environments, these differences are easy to miss.</p><p>Scammers also use deceptive subdomain structures to look more credible. Instead of using a plainly suspicious domain, they may deploy subdomains such as go.[domain], shop.[domain], or offers.[domain]. These can look more legitimate to users and may also create inconsistencies in detection coverage. In some cases, we observed situations where one domain variant was flagged while a related subdomain remained active.</p><p>Another layer of deception appears in the creative itself. In ads using domain impersonation or typosquatting, we also observed mismatches between the ad’s visual preview and its actual content. For example, a video thumbnail may show a legitimate product, a game scene, or unrelated imagery, while the underlying content promotes a scam. If neither an automated system nor a human reviewer clicks through or expands the media, the discrepancy may go unnoticed.</p><p>This combination, deceptive domain naming plus misleading visuals, increases both click-through potential and evasion resilience.</p><p>An example of an advertisement using the prefix “go.”. The link “GO.DATING4SINGLES.COM” does not lead to the website, but “DATING4SINGLES.COM” does.</p>

<h3>Unicode text obfuscation that breaks detection, not readability</h3><p>Sometimes the URL is not the main problem, the text is.</p><p>Many scam ads rely on familiar triggers, high-return investments, miracle products, fake financial services, urgent offers, or celebrity-backed promises. In plain text, these patterns should be relatively easy to flag for additional review.</p><p>Scammers increasingly avoid this by using obfuscated characters and Unicode tricks. To a human reader, the text may look normal. To an automated system, parts of the same string may be transformed into unusual Unicode sequences, invisible joiners, or look-alike characters that break keyword matching and reduce classifier reliability.</p><p>The result is elegant from the scammer’s perspective, readable to people, unreliable for machines.</p><p>We observed this technique at scale in scam ads circulating across Meta platforms, often in combination with other evasive tactics such as domain impersonation and celebrity references.</p>

<h3>Hidden impersonation, names that look real to people but not to machines</h3><p>Impersonation remains one of the fastest ways to manufacture trust in scam advertising.</p><p>Scammers know that names associated with wealth, authority, or credibility can dramatically increase engagement, whether it is a celebrity, a business leader, or a title such as “Dr.” or “PhD.” Those same names should also be obvious candidates for automated scrutiny.</p><p>Scammers work around this by manipulating text so that it looks normal to a user but is encoded differently for machines. One common technique we observed uses special spacing characters or joiners that visually preserve a name while changing its underlying structure. To the naked eye, it may read as a well-known person’s name. To a detection system, it may be processed as a different token entirely.</p><p>This technique was especially common in scam ads designed to manufacture credibility through famous names, credentials, or authority signals.</p><p>This advertisement uses the name of dentist Dr. Margaret Hunt to gain users' trust. At the same time, a special character is used in the name to avoid detection.</p>

<h2>Why scam ads keep coming back</h2><p>The problem is not only that scam ads evade detection. It is that they regenerate faster than enforcement can disrupt the operation behind them.</p><p>This is the Hydra problem of scam advertising. Remove one ad, and several variants can reappear through new accounts, duplicate creatives, and short-lived campaigns built to expire before meaningful intervention happens.</p><p>Our investigation did not only examine what scam ads looked like. It also examined what happened to them over time, how they were removed, how quickly similar variants reappeared, and how easily the underlying operations continued.</p><p>What we observed suggests a recurring pattern, many interventions remove individual ad instances, while the broader scam operation remains fully capable of regeneration.</p><h3>Takedowns that remove ads, but not the operation</h3><p>One of the first patterns we noticed was that removals often appeared to happen on a single ad instance basis.</p><p>We observed cases where the same scam ad, or functionally identical copies of it, continued running even after one instance had been removed. This happened across different advertisers and, in some cases, within the same scam-linked advertiser account. The text, target audience, visuals, and destination could remain effectively the same, while only one instance was taken down.</p><p>Based on these observations, moderation often appears to act on the ad object that was detected, rather than reliably escalating to advertiser-level or campaign-cluster disruption.</p><p>For scammers, this is a gift. If enforcement targets copies one by one, duplication becomes a business advantage.</p><h3>Short-lived campaigns, high volume beats persistence</h3><p>Scammers do not need every ad to survive. They need enough ads to run long enough.</p><p>A common pattern we observed was the use of <strong>many short-lived advertisements</strong>, often with small budgets and short runtimes. Instead of relying on one long campaign, scammers distribute risk across large numbers of disposable ads. If some are removed, others remain active and continue reaching users.</p><p>This strategy fits the takedown pattern above. If moderation is slower than campaign turnover, short-lived scam ads become highly efficient. The ad dies, the operation continues.</p><p>We also repeatedly observed advertiser pages with very limited organic activity, minimal followers, random page names, and behavior patterns consistent with throwaway infrastructure, yet still capable of launching scam ads.</p><p>Permanence is not the business model, throughput is.</p><h3>User reporting is too slow for disposable scam ads</h3><p>We also tested the user reporting path directly by reporting scam ads from platform accounts.</p><p>In multiple cases, we observed the same ads still active after reporting, and in some cases visible again on subsequent checks. This does not necessarily mean reports are ignored, but it does suggest that user reporting alone is too slow or too inconsistent to function as an effective frontline defense against high-volume scam advertising.</p><p>This becomes even more problematic when campaigns are designed to run briefly and aggressively. By the time an ad is reviewed manually, it may already have completed its useful life, reached a large audience, and been replaced by multiple variants.</p><p>At this scale, platform moderation faces a difficult asymmetry. Scammers can generate and rotate ads faster than manual review can reasonably keep up.</p><h3>Advertisers accounts are cheap to replace</h3><p>Another structural issue is the ease of creating or replacing advertiser accounts.</p><p>Even when accounts are blocked, scammers can often resume operations quickly by shifting to new accounts, new pages, or repurposed profiles. During our investigation, we observed large numbers of suspicious advertisers with limited page history, low follower counts, recently created pages, and naming patterns consistent with disposable setups.</p><p>This creates a persistent regeneration advantage. If the cost of losing an advertiser account is low, and the cost of creating a replacement is also low, enforcement becomes a recurring operating expense for the scammer, not a meaningful deterrent.</p><p>That is the Hydra problem in practical terms, remove one head, and the infrastructure behind it keeps producing more.</p><h3>Scam ads are engineered for resilience</h3><p>Scam advertising is not static. It is adaptive, distributed, and engineered for resilience.</p><p>From URL presentation tricks and Unicode obfuscation to disposable ad waves and rapid advertiser regeneration, scammers exploit structural weaknesses in how social advertising ecosystems are built, moderated, and audited.</p><p>Reactive takedowns matter, but they are not enough when enforcement is slower than replication.</p><p>Meaningful progress requires systemic changes, stronger advertiser verification, better destination-level transparency, campaign-level enforcement, and faster cross-platform disruption mechanisms.</p><p>The Hydra metaphor matters here because it captures the real failure mode. Removing individual ads without disrupting the regeneration model does not solve the problem, it manages the symptoms while the system keeps producing new heads.</p>