Threat Analysis Engineer

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

Threat Researcher at Gen

Research

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

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

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

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

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

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

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

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers

Security Evangelist at Gen

Malware Researcher

<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

<p>Black Friday and the holiday shopping season are the busiest times of the year for online shopping, and unfortunately, for online scams too. In October alone, we observed a <strong>significant spike in blocked fake </strong>shop<strong> (e-shop scams) attacks in the United States</strong>. Blocked attacks were up 185% compared with the January to September average, and the number of users targeted rose by 126% over the same period.&nbsp;&nbsp;</p><p>Throughout most of 2025, the share of users running into fake shop scams stayed relatively low. From late spring, it started to creep up, then shot up sharply in October as holiday campaigns kicked in. The chart below shows this “risk ratio”, that is, the percentage of active users who have been protected from fake shops on any given day.&nbsp;</p>

<p>That is not a coincidence. When people are hunting for bargains, feeling rushed, and bombarded with ads, they are more likely to click before they think. Scammers know this and flood the internet with convincing fake shops that look like the real thing. &nbsp;</p><p>This blog walks through what we are seeing and what you can do to stay safe while you shop.&nbsp;</p><h2>What we are seeing this shopping season&nbsp;</h2><p>When we looked at the domains behind these fake shops, a clear pattern appeared:&nbsp;</p><p>Many scam sites run on<strong> </strong>legitimate platforms such as Shopify, MyShopline, Shoplazza, and Chinese frameworks such as Shopage.org. These services are designed to help small businesses get online quickly, but they also give fraudsters an easy way to launch professional-looking stores at speed.&nbsp;</p><p>Most of the fake shops we saw are wrapped in seasonal themes. Right now, many are covered in festive banners and countdown timers. Some have already switched to <strong>Christmas layouts and “</strong>holiday sale” branding to catch early gift shoppers.&nbsp;</p>

<p>The way victims arrive at these sites is also telling. Rather than relying on spam email, scammers are buying placement in Facebook Ads and TikTok Ads. These ads can be highly targeted, so a fake offer for designer glasses, sneakers or kitchen gadgets can be shown directly to the people most likely to be interested. Fake shops are not a problem just in the United States. In fact, during October and November alone, we blocked almost 260 000 fake e-shop domains worldwide, which is around four times higher than the same shopping season last year. The map below shows the share of users we protected from fake shop scams in each country in 2025. Darker colors mean a higher proportion of people in that country ran into at least one blocked fake shop, with clear hotspots in North America, much of Europe and Australia, but activity almost everywhere.&nbsp;</p>

<h2>Copy-paste shops and the role of AI tools&nbsp;</h2><p>We also saw multiple "single product" fake shops that look almost identical. One example promoted "intelligent reading glasses" with bold claims about advanced optics and a big 50 percent discount. Another pushed a "designer wine glass" using the same layout, the same type of trust badges, and nearly the same urgency-driven messages.&nbsp;</p><p>You can think of these as copy-paste shops. Once a scammer has a template that works, they can quickly clone it and swap in a new product, image and price.&nbsp;</p><p>While we did not confirm AI built stores in this particular dataset, the tools to automate this already exist. AI store builders for Shopify and AI powered marketing tools promise to create product pages, write copy, and generate ad campaigns in a few clicks. In the wrong hands, that makes it easier for fraudsters to launch more fake shops faster and to test which lures work best.&nbsp;</p>

<h2>How fake shops fake trust&nbsp;</h2><p>Modern fake shops are not just about flashy discounts. They are designed to look legitimate at a glance.&nbsp;</p><p>Many use polished templates and SSL certificates, so the little padlock icon appears in the browser. That padlock only means the connection is encrypted, not that the site is honest, but scammers know people trust it.&nbsp;</p><p>Some fake shops seed third party review platforms with positive reviews to boost their scores. In our analysis we saw cases where those reviews were later removed by the platform for breaking guidelines, a strong sign they were fake. In at least one case, the scam site ran on a subdomain of an older, existing site and showed Black Friday deals alongside those disputed reviews. Piggybacking on an established domain is another way to look more credible.&nbsp;</p><p>On social media, scammers run ads that look like any other promotion in your feed. They often target specific demographics, interests or locations, and in some cases even reply to comments or reviews to keep up the illusion of a real business.&nbsp;</p>

<h2>How to Spot a Fake Online Shop&nbsp;</h2><p>There is no single trick that catches every scam, but a few simple habits can dramatically lower the risk:&nbsp;</p><ol><li><strong>Check the address bar, not just the logo. </strong>Look closely at the URL. Watch out for strange spellings, extra words, or domains that do not match the brand name you expect.</li><li><strong>Be skeptical of “too good to be true” discounts</strong>. Genuine retailers do run big Black Friday sales, but if a high demand product is half the usual price, treat it as suspicious.</li><li><strong>Verify reviews</strong>.<strong> </strong>Do not rely only on the testimonials shown on the shop itself. Search the store name together with words like "reviews", "scam" or "complaints". Be wary if you only find a handful of overly positive comments.</li><li><strong>Check contact and return information. </strong>Legitimate shops make it easy to see who they are and how to reach them, for example a physical address, company name, clear return policy, and real customer service options. Vague contact details or only a web form are warning signs.</li><li><strong>Use security tools and safer payment methods. </strong>Enable browser protection and make sure your security solutions are on so known scam domains are blocked before you land on them. When you pay, prefer options that offer buyer protection, such as credit card or trusted payment service, and avoid bank transfers, gift cards or cryptocurrency for online purchases.&nbsp;</li></ol><p>Scammers treat Black Friday, Cyber Monday and the entire holiday shopping season as a business opportunity. They use the same tools, platforms and marketing channels as legitimate stores, just with a very different goal.&nbsp;</p><p>The good news is that you do not need to stop shopping online to stay safe. A bit of skepticism, a habit of checking before you click, and the right security tools in the background will go a long way to keep your money and data out of their hands.&nbsp;</p>

Ľuboš Bever

Posts by Ľuboš Bever

Holiday scams: How fraudsters exploit the shopping season and how to stay safe