But the headline label needs correcting before defenders put the intelligence into their detections: ESET attributes this activity with high confidence to the China-aligned group it calls FamousSparrow, not Salt Typhoon. The two names have been publicly linked elsewhere, and The Register, BleepingComputer, and The Record have all described the campaign through the Salt Typhoon association. ESET’s own technical report says it continues to track FamousSparrow and Salt Typhoon as separate groups because it lacks technical indicators proving they are the same operation.
That is not a semantic distinction. Threat-group names drive hunting rules, attribution reports, and assumptions about targeting. The useful takeaway is clear enough without overstating the evidence: defenders should treat SparroWocky as an active, China-aligned Windows espionage threat tied to FamousSparrow’s established tooling and victimology.
A regional campaign that began before the new malware
ESET says FamousSparrow’s Latin American focus began no later than July 2025, then became heavily concentrated in the region through the first half of 2026. Ninety percent of the group’s targets recorded in ESET telemetry from mid-2025 onward were in Latin America, an unusual geographic concentration for the China-aligned groups the company tracks.
The new implant appeared in August 2025, replacing the group’s older SparrowDoor backdoor as its primary tool. ESET observed SparroWocky against government organizations in Argentina, Ecuador, Guatemala, Honduras, Panama, Peru, Puerto Rico, and Venezuela. The report does not identify the affected agencies or say how many endpoints were compromised, so the public record supports confirmed targeting and malware deployment — not a claim that each government was broadly breached.
ESET believes the regional concentration likely relates to U.S. pressure on Chinese economic interests in the region under President Donald Trump’s second administration. Its strongest publicly described example is a targeted Panamanian entity involved in the dispute over canal-area ports formerly operated by a China-based company.
That geopolitical explanation remains ESET’s assessment, rather than independently proven tasking from Beijing. Still, the targeting pattern gives it substance: the campaign is aimed at government organizations positioned to hold policy, commercial, diplomatic, or infrastructure information. For enterprises, contractors, law firms, engineering firms, telecom operators, and managed-service providers that work with those institutions, that is the more actionable warning. A campaign does not need to name a private company as its primary target for that company to become a useful route into a target environment.
SparroWocky is built for a Windows foothold
SparroWocky is a modular C++ backdoor, and ESET’s analysis shows a more mature implant than a basic remote-access tool. It profiles the victim host — including computer name, user name, domain, Windows product name, network interface addresses, process information, and remote-session users — before accepting commands from its command-and-control infrastructure.
Its command set enables operators to enumerate drives and directories, transfer files, execute shell commands, run arbitrary programs, establish TCP forwarding, and capture screenshots. The screenshot feature is particularly revealing: after an initial image, the malware can send changed screen blocks every 500 milliseconds. That approach lowers the amount of data sent while giving operators a near-continuous view of activity on a compromised workstation or remote desktop session.
It can also enumerate remote sessions with the Windows Terminal Services API and launch a new instance under another logged-in user’s token. In a shared-server or jump-host environment, that is a meaningful post-compromise capability. A foothold on an administrative system could provide the operator a path to observe or act in another user’s session without needing to deploy an entirely separate malware family.
ESET found that SparroWocky can load Beacon Object Files, or BOFs, directly into memory. BOFs are compact modules popular in red-team tooling because they extend an implant without the operational noise of writing conventional executables to disk. For defenders, this means the backdoor is not frozen at the roughly 30 documented commands. Its operators can add in-memory functionality as their objective changes.
The loader is designed to blend into legitimate software
The initial SparroWocky loader uses a three-part arrangement: a legitimate executable, a malicious DLL substituted for a DLL that program expects to load, and an encrypted payload file, typically using a matching .dat name. When the legitimate program starts, it loads the attacker’s DLL through DLL side-loading; that DLL decrypts and maps the backdoor directly into memory.
The technique deserves more attention than the malware’s whimsical name. The malicious DLL preserves much of the metadata and exported-function structure of the genuine library it imitates, while altering code inside the file and redirecting its entry point. This makes simple filename checks and superficial DLL inspection weak controls. A DLL called winfsp-x64.dll or DukeQt.dll is not automatically suspicious; those are names ESET saw in known samples, but the detection value lies in mismatches between a DLL, its expected signer, its loading executable, and its expected installation path.
The payload itself has its normal Portable Executable markers removed before being reflectively loaded in memory. ESET assesses that this is intended to frustrate security products that use straightforward memory scanning for common PE headers. The loader decrypts the configuration and payload with RC4, while command-and-control communications use TLS and additional RC4 encryption for command data.
The malware’s persistence options are conventional enough to audit: it can create a service called ProcAuditManager, described as tracking process-audit events, or set a SnapCart value in the Windows Run key under either the machine or user hive. Neither name should be treated as a standalone verdict — attackers can change names — but both are valuable pivot points in a scoped hunt.
Windows internals are central to its evasions
The sharper edge of SparroWocky is its use of Windows internals to make telemetry lie or become less useful. It incorporates MinHook to intercept CreateThread and conceal the true start address of newly created threads. ESET found that the malware makes those threads appear to begin at AnimateWindow, a legitimate Windows API, before redirecting execution to the actual malicious address.
That can frustrate EDR products and analysts who trust a thread’s reported start location as a clean indicator of what code initiated it. The malware also uses a version of the SilentMoonwalk technique to forge call stacks around Windows API calls, making activity appear to originate from normal thread-start routines rather than malicious code.
Its in-memory program loader goes further. When executing another PE file, it can imitate ordinary Windows behavior by loading the appropriate English language .mui resource from C:\Windows\System32\en-US\. It also inserts a fabricated loader-data structure into the Process Environment Block’s module lists. In plain terms, SparroWocky is deliberately attempting to make an in-memory program look more like a normally loaded Windows component to both the program itself and security tooling that inspects loaded modules.
Those details narrow the defensive lesson. Organizations should not rely solely on file-based antivirus detections or reputation checks for executables and DLLs. Endpoint monitoring needs to retain process, module-load, thread, service-creation, registry-persistence, and network telemetry long enough to reconstruct suspicious execution chains.
What administrators should hunt now
ESET has published sample hashes, filenames, and 18 known command-and-control IP addresses. Those indicators should be ingested into EDR, proxy, DNS, firewall, and SIEM systems, but IP blocking alone is a short-lived control: the malware connects directly to IP addresses, generally over TCP 443 and occasionally 8080, and its operators can rotate rented infrastructure.
A more durable investigation should look for combinations of behavior:
- Legitimate signed executables loading DLLs from unexpected, user-writable, temporary, or unusual application directories should be reviewed, particularly where an adjacent
.datfile is present. - New or modified services named
ProcAuditManager, or services with generic audit-oriented descriptions that do not align with a known installed product, should be validated against their binary path, signer, parent process, and creation time. - New
SnapCartvalues or unfamiliar entries underHKLMandHKCU\Software\Microsoft\Windows\CurrentVersion\Runshould be investigated alongside the executable and DLL chain they start. - A process that reads a
.datfile, performs in-memory PE loading, then launchescmd.exe, accesses remote-session APIs, or creates processes under another user’s token warrants immediate escalation. - Direct outbound TLS sessions to raw IP addresses on ports 443 or 8080 should be correlated with endpoint processes, especially where the client bypasses normal proxy routing or uses a newly observed self-signed certificate.
ESET’s report also links FamousSparrow historically to exploitation of exposed Microsoft Exchange servers, including the ProxyLogon vulnerability chain in 2021. That history makes internet-facing application exposure a sensible review point, but the current SparroWocky report does not publicly establish the initial-access method for every Latin American intrusion. Administrators should avoid claiming a current Exchange exploit without incident-specific evidence.
The confirmed change is the backdoor and its deployment pattern: FamousSparrow has replaced SparrowDoor with a stealthier Windows implant while concentrating its activity on Latin American government targets. The immediate job for defenders is to hunt the loader-and-persistence chain before the malware’s in-memory execution, session access, and self-deletion options turn a detectable compromise into a difficult reconstruction.