FamousSparrow / SparroWocky — Latin America Government Espionage

FamousSparrow, a China-aligned cyberespionage group active since at least 2019 (publicly documented in 2021 after exploiting the Microsoft Exchange ProxyLogon vulnerability), has retired its long-standing SparrowDoor backdoor in favor of a new, purpose-built implant named SparroWocky. ESET Research attributes the shift with high confidence — early SparroWocky infections were installed by SparrowDoor itself, and the 2025–2026 victimology matches organizations FamousSparrow previously targeted. Since at least August 2025, the group has concentrated roughly 90% of its observed activity on government and public-sector organizations across eight Latin American countries: Argentina, Ecuador, Guatemala, Honduras, Panama, Peru, Puerto Rico, and Venezuela — a marked pivot from the group's historically global targeting (hotels, trade groups, law firms, engineering firms in the US, Middle East, and Asia).

SparroWocky is a modular, C++ backdoor delivered through a three-part "trident loader" chain: a legitimate signed executable, a side-loaded malicious DLL, and an encrypted .dat payload that is RC4-decrypted and reflectively mapped into memory — never touching disk as a standalone executable. Once resident, it collects host and network information, executes commands and arbitrary files, proxies traffic, exfiltrates files, captures screenshots, creates processes under other user sessions, and can load Beacon Object Files (BOFs) — letting the operators run modules originally built for Cobalt Strike, Metasploit, Sliver, and Brute Ratel directly inside a bespoke implant. Defense evasion is unusually sophisticated for a group of this profile: a custom API-hashing routine resolves Windows APIs at runtime, a SilentMoonwalk-derived technique forges call stacks to hide the true caller of monitored API functions, and the MinHook library is used to hook CreateThread so hooked-thread origins are concealed from analysis tools.

The single richest technical source is ESET's own WeLiveSecurity write-up (saved verbatim in this pack's source snapshots), which publishes the full SparroWocky IOC set: five file hashes, eighteen distinct C&C IP addresses (all under the group's own dedicated VPS infrastructure, active December 2025 – June 2026), the exact persistence artifacts (service name ProcAuditManager, Registry Run-key value SnapCart), and a MITRE ATT&CK v19 mapping covering 30 techniques. This pack builds detections directly against that IOC set and TTP list, and separately preserves — clearly labeled as historical and low current confidence — the older 2024 FamousSparrow/SparrowDoor infrastructure and loader artifacts the user asked to retain for retrospective hunting.

Defender priority: the two highest-value, lowest-noise detections in this pack are the exact-match persistence hunts (Q1: service name ProcAuditManager; Q2: Registry value SnapCart) — both promoted to Custom IOA. Deploy those fleet-wide first, then patch/verify all internet-facing Exchange servers, which remains FamousSparrow's documented initial-access vector.

Seed source not used: a dedicated 2026 TheHackerNews article on SparroWocky could not be located at research time (searches surfaced only an unrelated May-2026 TheHackerNews Exchange story). No indicator or claim in this pack is sourced from TheHackerNews; it is omitted rather than fabricated.

No prompt injection encountered. Every fetched source was screened for text attempting to redirect this agent's instructions (fake authorization claims, embedded commands, alternate output paths, etc.). None was found in any of the six saved snapshots.

Hunt hypotheses

1. (High conf.) SparroWocky establishes persistence via a Windows service literally named ProcAuditManager — an exact, low-noise indicator directly observable via CreateService telemetry.
2. (High conf.) SparroWocky alternatively persists via a Registry Run-key value named SnapCart — an exact, low-noise indicator via AsepValueUpdate/RegGenericValueUpdate telemetry.
3. (High conf.) The compiled SparroWocky loader and in-memory backdoor samples ESET captured carry stable, campaign-specific SHA-1 hashes, directly matchable on process/file-write telemetry.
4. (Medium conf.) The trident-loader DLL side-load reuses the basenames winfsp-x64.dll and DukeQt.dll — real software names chosen for camouflage, so a bare basename hit needs hash or path corroboration.
5. (High conf., perishable) Endpoints beacon to one of eighteen dedicated SparroWocky C2 IPs over TCP/443 or TCP/8080 — precise but infrastructure rotates; this hunt needs periodic refresh.
6. (Low conf., retrospective) 2024-era FamousSparrow/SparrowDoor infrastructure (103.85.25[.]166, 45.131.179[.]24, amelicen[.]com) may still appear in stale logs or unremediated compromises.
7. (Low conf., retrospective) 2021–2024 loader artifacts (libvlc.dll, WINMM.dll, K7AVWScn.dll, taskhosk.exe) may surface in environments never swept for the earlier campaigns.
8. (Low conf., wide net) SparroWocky's TCP-proxy/SOCKS module generates outbound TLS on port 8080 from processes with no legitimate reason to use that port — a broad behavioral net to catch infrastructure not yet captured in the static IOC list.

Attack chain

33 atomic indicators (5 current hashes, 18 current IPs, 4 historical IPs, 1 historical domain, 5 historical hashes) plus 2 distinctive-filename and 2 behavioral-artifact indicators. Every atomic value above traces to 01-eset-welivesecurity-sparrowock.txt (current campaign) or 02-eset-malware-ioc-readme.txt / 06-eset-welivesecurity-2025-campaign.txt (historical) in this pack's source-snapshot folder. Blocking posture: every current-campaign indicator ships at detect, not prevent, because ESET is the sole published technical source for this IOC set. Promote the three loader hashes to prevent only after you have validated them in your own tenant or a second independent source corroborates them. Note also that winfsp-x64.dll is a legitimate WinFsp filename, so act on the hash, never the basename alone.

Sourced verbatim from ESET's SparroWocky writeup (MITRE ATT&CK v19).

Historical (2021/2024) FamousSparrow/SparrowDoor activity additionally maps to T1505.003 (Web Shell), T1003.001 (LSASS Memory), and T1574.002 (DLL Side-Loading) per the eset/malware-ioc GitHub matrix — retained for retrospective hunting in Q6/Q7.

Windows Security Event Log

• Event ID 4697 (a service was installed) — filter ServiceName/ServiceFileName for ProcAuditManager; cross-reference against Q1.
• Event ID 4657 (registry value modified, requires SACL on the Run key) — filter for value name SnapCart under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run or the HKCU equivalent; cross-reference against Q2.
• Sysmon Event ID 7 (image loaded) — flag winfsp-x64.dll or DukeQt.dll loading from a path outside the legitimate WinFsp/Qt install directory.
• Sysmon Event ID 13 (registry value set) — same SnapCart value-name filter as above, useful where Falcon coverage has a gap.

Exchange / perimeter

• Review IIS/HTTP proxy logs on internet-facing Exchange servers for anomalous ASPX/ASHX requests consistent with historical FamousSparrow web-shell staging (T1505.003).
• Confirm current Exchange cumulative-update/security-patch level against Microsoft's latest guidance; FamousSparrow's documented initial-access vector is exploitation of outdated Exchange/Windows Server versions.

Network / proxy

• Review firewall/proxy flow logs for sustained TLS sessions to non-corporate ASNs (LightNode, Kaopu Cloud HK, Cogent, Latitude.sh, The Constant Company/Vultr) on ports 443/8080 originating from server subnets that should not be making direct outbound connections.

Playbook A — Block current SparroWocky C2 IPs at the perimeter firewall

Prerequisites: firewall/proxy change-control window; confirm no legitimate business traffic
  currently depends on the 18 listed IPs (Section 10 CSV) via a 7-day flow-log review.
Reboot required: No.

1. Export the 18 IPv4 addresses from the "Falcon IOC Management CSV" block (Section 10).
2. Create a deny rule (both directions) for TCP/443 and TCP/8080 to each address at the
   perimeter firewall / secure web gateway.
3. Verify:
   - Confirm the rule is active: vendor-specific `show firewall rule <rule-id>` equivalent.
   - Re-run Q5 after 24h; expect 0 further outbound connection attempts (any hit after the
     block is now a blocked-attempt alert, not a successful beacon).

Rollback: Remove the 18 deny-rule entries by rule ID / tag "FamousSparrow-SparroWocky-2026-09".
  No other config is touched; rollback is immediate and has no collateral effect.

Playbook B — AppLocker rule: block DLL execution from user-writable paths (audit-first)

Prerequisites: AppLocker (or WDAC) already enabled in audit mode on target hosts; identify and
  allowlist any legitimate application that intentionally loads DLLs from AppData/Temp/Downloads
  before enforcing.
Reboot required: No (AppLocker policy applies on next Group Policy refresh / gpupdate).

1. Create/extend a DLL rule collection denying execution from:
   %USERPROFILE%\AppData\*, %USERPROFILE%\Downloads\*, %TEMP%\*
2. Deploy in AUDIT mode first via GPO:
   Set-AppLockerPolicy -PolicyObject $auditPolicy -Ldap "LDAP://"
3. Review AppLocker audit events (Event ID 8003/8004, "would have been blocked") for 7 days.
4. Switch the rule collection to Enforce once the audit period shows no legitimate blocks:
   Set-AppLockerPolicy -PolicyObject $enforcePolicy -Ldap "LDAP://"
5. Verify: `Get-AppLockerPolicy -Effective | Select-Object -ExpandProperty RuleCollections`
   confirms Enforce mode; attempt a benign test DLL load from %TEMP% on a test host and confirm
   it is blocked.

Rollback: Revert the GPO's AppLocker rule collection to its prior state (Not Configured or
  Audit) via Group Policy Management Console; run `gpupdate /force` on affected hosts. No
  reboot required.

Playbook C — Verify and remediate Exchange patch level

Prerequisites: maintenance window for Exchange server(s); current backup/snapshot per standard
  change-management policy.
Reboot required: Likely yes — Exchange cumulative/security updates typically require a service
  restart or full reboot; schedule accordingly.

1. Inventory current build: `Get-ExchangeServer | Format-List Name, AdminDisplayVersion`
2. Compare against Microsoft's latest published Exchange Server Security Update / CU.
3. Apply the current CU/SU following Microsoft's documented Exchange update procedure
   (includes prerequisite .NET/PowerShell version checks).
4. Verify: re-run step 1 and confirm the version matches the target build; confirm IIS/OWA
   services restart cleanly and mail flow resumes.

Rollback: Patches are forward-only per Microsoft guidance; recovery path is restoring from the
  pre-change snapshot/backup taken in Prerequisites if the update causes a service-impacting
  regression.

Playbook D — Enable LSA Protection (RunAsPPL)

Prerequisites: confirm all installed security/AV/EDR drivers and any LSA-plugin third-party
  software are compatible with Protected Process Light (PPL) for LSASS; test on a pilot ring
  before fleet-wide deployment — an incompatible driver can prevent LSASS from starting.
Reboot required: Yes.

1. Set the registry value:
   reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f
2. Reboot the host.
3. Verify:
   Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name RunAsPPL
   (expect value 1); confirm LSASS is running as a protected process via Task Manager
   (Details tab → enable "Protection Type" column) or Sysinternals Process Explorer.

Rollback: reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /f
  then reboot to return to the pre-change (unprotected) LSASS state.

Validation gates (Section 11) are folded in here: telemetry-readiness and benign-baseline review must both be confirmed per-tenant before any "Good" or "Partial" row above is treated as production-ready in your environment.

All six source snapshots (fetched page text) are saved under FamousSparrow-SparroWocky-Hunt-sources/ alongside this file for provenance validation. A dedicated TheHackerNews article on SparroWocky was sought per the seed source list but could not be located at research time and is not cited here.