Toy Ghouls — "Angry Birds" MQTT / Matrix Backdoor Hunt

Toy Ghouls — a financially motivated group tracked since 2025 under the aliases Bearlyfy, Laboo.boo, and Feral Wolf, and previously observed deploying the custom GenieLocker ransomware against Russian manufacturing organizations — has added a custom backdoor family to its toolkit for the first time. Kaspersky's 4 September 2026 Securelist post ("Angry Birds: Toy Ghouls' new toys") documents two backdoor variants, mqtt-bird-agent (shipped as cplsupport.exe) and matrix-bird-agent (shipped as wtass.exe), delivered over Windows Remote Management using Evil-WinRM and WinRM-fs and installed as persistent Windows services. The attacker's objective is durable, low-noise remote control of compromised Windows hosts: both variants encrypt their configuration with ChaCha20-Poly1305 keyed to the machine's own MachineGuid, execute operator commands via PowerShell or cmd.exe, and — most notably — route their command-and-control traffic through two legitimate, widely used public services: the free-tier HiveMQ MQTT broker (broker.hivemq.com) and an attacker-run Matrix/Element homeserver (meet.element.tw).

The highest-value defensive angle is that, despite the novel C2 channel, the backdoor's footprint on disk and in the registry is small, specific, and vendor-attributed: two literal binary names and MD5 hashes, two literal Windows service names that masquerade as built-in components, and two non-standard registry keys. None of these collide with legitimate software, so hunting them (queries Q1–Q5 below) carries essentially zero false-positive risk. The C2 channel itself is the hard part — broker.hivemq.com and ip-api.com are legitimate infrastructure used by countless benign applications, so those signals must be hunted as anomalous-context indicators, never as blocklist entries.

Four sources were fetched and saved verbatim as plain-text snapshots in ToyGhouls-MQTT-Matrix-C2-Hunt-sources/ before any indicator was carried into this pack. A fifth candidate source (hackread.com's coverage of the same story) returned HTTP 403 on every fetch attempt and was dropped — it is cited nowhere in this pack and no indicator is sourced from it. No fetched content attempted to issue instructions, redirect research, or claim operator authority; all four snapshots are ordinary vendor/security-journalism prose.

Dropped source: hackread.com ("Toy Ghouls Targets Russian Organizations With New Windows Backdoors") — returned HTTP 403 on every fetch attempt (direct fetch and tool-mediated fetch). Not cited, no indicator sourced from it.

Hostile-content check: none of the four saved snapshots contained embedded instructions, prompt-injection attempts, or claims of operator/user authority. All fetched text was treated as intelligence data, never as directives.

Hunt hypotheses

1. (High) The backdoor binaries execute under their vendor-attributed names cplsupport.exe / wtass.exe — a filename + hash hunt with near-zero collision risk. → Q1
2. (High) Persistence is installed as a Windows service under one of exactly two literal names, cplsupport or wtas — a service-creation hunt with near-zero collision risk. → Q2
3. (High) The sealed configuration lands in two non-standard registry locations (...\synapse\Config\SealedConfig, ...\SynapseAgent\metrics_interval) that no legitimate software is known to use. → Q3
4. (High) The Element variant's C2 homeserver is a specific attacker-registered hostname, meet.element.tw, distinct from the legitimate element.io/matrix.org services. → Q4
5. (High) Both variants execute operator commands via PowerShell or cmd.exe launched directly as a child of the backdoor process/service. → Q5
6. (Medium) The -NonInteractive -NoProfile -Command PowerShell flag combination, broadened beyond the specific backdoor parent, is a general hidden-automation signal worth an environment-wide hunt — at the cost of high false-positive volume from legitimate RMM/DevOps tooling. → Q6
7. (Medium) WinRM-delivered payloads spawn child processes under wsmprovhost.exe — a broad Evil-WinRM/legitimate-remoting signal that needs heavy scoping. → Q7
8. (Medium) An unexpected process making contact with the public HiveMQ broker (broker.hivemq.com, port 8883) is anomalous-context, never a blocklist signal, and needs correlation with Q1–Q3 to be actionable. → Q8
9. (Low-Medium) An unexpected process querying ip-api.com for geolocation is a weak recon signal on its own (legitimate services use it constantly) but useful as an enrichment pivot once another Toy Ghouls indicator has fired. → Q9
10. (Medium) Any new Windows service whose image path resolves under %PROGRAMDATA% is a broader, noisier companion to hypothesis 2 that catches variants using different service names. → Q10

Attack chain

Use these when Falcon coverage is incomplete or as a second, independent data source to corroborate a Falcon hit.

• Windows Security Event ID 4697 ("A service was installed in the system") or System log Event ID 7045 (Service Control Manager) — filter ServiceName for cplsupport or wtas, or ServiceFileName for a path under %PROGRAMDATA%.
• Microsoft-Windows-WinRM/Operational event log — inbound WinRM session establishment events, correlated against your known jump-host/admin-subnet allowlist; anything outside it warrants review.
• Sysmon Event ID 13 (registry value set), if Sysmon is deployed alongside Falcon — filter TargetObject for ...\synapse\Config\SealedConfig or ...\SynapseAgent\metrics_interval as an independent corroboration of Q3.
• Third-party AV/EDR console verdicts — in mixed-vendor environments running Kaspersky alongside Falcon, search AV console history for the verdict names HEUR:Backdoor.Win64.Suptoml.gen, HEUR:Trojan.Script.Zapchast.conf, Backdoor.Win64.Agent.smgdvy, Trojan.Script.Zapchast.abwm, Trojan.Win64.Agent.smgsfo, or Trojan.Script.Zapchast.abwo (all from the Kaspersky Securelist advisory).
• PowerShell Microsoft-Windows-PowerShell/Operational Event ID 4104 (ScriptBlock logging, if enabled per Section 12) — search block text for the literal flag combination -NonInteractive -NoProfile -Command paired with an unusual parent process, to corroborate Q5/Q6 without Falcon.

Promote the five high-confidence, low-FP queries to Custom IOA rules (Falcon console: Configuration → Custom IOA Rule Groups) or Next-Gen SIEM Scheduled Searches. Keep Q6-Q10 as Investigate-only hunt queries — their false-positive rate is too high for automated response without environment-specific tuning.

IOA / Scheduled Search candidates

Alert package summary (for the five IOA candidates above)

Subject: [HIGH] Detection: Toy Ghouls Angry Birds Backdoor — Binary/Service/Registry/C2 Match

Body guidance: State which specific indicator fired (binary name, service name, registry key, or C2 domain), the host and user context, and note that this backdoor family grants full remote command execution — treat any hit as a confirmed compromise, not a suspicious anomaly, given the near-zero false-positive rate of Q1-Q5.

Triage checklist:

1. Confirm the event type — ProcessRollup2/CreateService/RegGenericValueUpdate means it executed/persisted; a corresponding ProcessBlocked means Falcon prevention already stopped it.
2. Pull the host's full process tree around the hit — identify how the binary arrived (look for a wsmprovhost.exe ancestor, per Q7).
3. Check for the companion service (Q2/Q10) and registry keys (Q3) on the same host — Toy Ghouls installs all three together.
4. Pivot to Q8/Q9 on the same host and timeframe to identify which C2 channel (HiveMQ or Matrix/Element) is in use.
5. Check authentication logs for the WinRM session that likely delivered the binary — identify the source account and source host.
6. Isolate the host via Falcon RTR once C2 contact is confirmed (see Containment Runbook, Section 14).
7. Hunt fleet-wide for the same MD5/service/registry key — Toy Ghouls has historically moved laterally before this stage.

Pivot queries: host-scoped variants of Q1/Q3/Q4/Q8/Q9 filtered to the affected ComputerName, plus an environment-wide re-run of Q1-Q4 to check for additional infected hosts.

Playbook 1 — Restrict and log WinRM

1. Inventory hosts with WinRM enabled:
   Get-CimInstance -ClassName Win32_Service -Filter "Name='WinRM'" | Select PSComputerName, State, StartMode
   Prerequisites: domain admin or delegated read access to run a fleet-wide CIM query.
   Reboot required: no.
   Rollback: none required (read-only inventory step).

2. On hosts where WinRM is not required for management, disable it:
   Stop-Service WinRM -Force
   Set-Service WinRM -StartupType Disabled
   Prerequisites: confirm the host is not a designated management/jump box first (step 1's inventory).
   Reboot required: no.
   Rollback: Set-Service WinRM -StartupType Manual ; Start-Service WinRM

3. On hosts where WinRM must remain enabled, restrict authentication and transport:
   winrm set winrm/config/service/auth '@{Basic="false"}'
   winrm set winrm/config/service '@{AllowUnencrypted="false"}'
   winrm set winrm/config/client '@{TrustedHosts=""}'
   Prerequisites: confirm no legitimate workflow depends on Basic auth or unencrypted WinRM traffic (test in a pilot ring).
   Reboot required: no (WinRM service restart only -- Restart-Service WinRM).
   Rollback: winrm set winrm/config/service/auth '@{Basic="true"}' ; winrm set winrm/config/service '@{AllowUnencrypted="true"}' (only if a documented legacy dependency requires it -- prefer fixing the dependency instead).

Playbook 2 — Enable PowerShell ScriptBlock and Module logging via GPO

1. Open Group Policy Management, edit (or create) a GPO linked to the target OU.
   Prerequisites: Group Policy Management permissions on the target OU.
   Reboot required: no.
   Rollback: none required (no state changed yet -- GPO not yet linked/enabled).

2. Computer Configuration -> Administrative Templates -> Windows Components ->
   Windows PowerShell -> "Turn on PowerShell Script Block Logging" = Enabled
   Windows PowerShell -> "Turn on Module Logging" = Enabled, Module Names = *
   Prerequisites: none beyond GPO edit rights.
   Reboot required: no (takes effect on next gpupdate /force + PowerShell session).
   Rollback: set both policies back to "Not Configured" and run gpupdate /force on affected hosts.

3. Verify on a test host:
   gpupdate /force
   Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" -MaxEvents 5
   Prerequisites: local admin on the test host to read the Operational log.
   Reboot required: no.
   Rollback: none required (verification step only).

Playbook 3 — AppLocker rule: deny unsigned EXE launch from ProgramData

1. In a PILOT ring first, create an AppLocker Executable Rule:
   Action: Deny
   User/Group: Everyone
   Condition: Path -> %PROGRAMDATA%\*
   Exceptions: add a path exception for every legitimate vendor already
   installing into ProgramData in your environment (identify these with
   Q10 in Audit mode for at least one full patch cycle before enforcing).
   Prerequisites: AppLocker (or WDAC) policy infrastructure already in place; a
   completed Q10 baseline of legitimate ProgramData services/executables.
   Reboot required: no (Application Identity service restart may be needed:
   Restart-Service AppIDSvc).
   Rollback: set the rule's enforcement mode back to "Audit only" or delete the
   rule from the GPO; re-run gpupdate /force.

2. Deploy in Audit-only enforcement mode for 14 days; review the AppLocker
   event log (Microsoft-Windows-AppLocker/EXE and DLL) for unexpected denials.
   Prerequisites: step 1 rule created in Audit mode.
   Reboot required: no.
   Rollback: none required (audit mode makes no enforcement change).

3. Switch enforcement mode to "Enforce" only after the audit period shows zero
   unexpected legitimate blocks.
   Prerequisites: clean 14-day audit period from step 2.
   Reboot required: no.
   Rollback: set enforcement mode back to "Audit only" immediately if legitimate
   software is blocked; add the specific path as an exception, then re-enforce.

This pack does not catch: (1) the initial file transfer of the backdoor binary/config over WinRM-fs, since generic file-write telemetry on a filename as common as config.toml would be unusably noisy; (2) any full decode of MQTT/Matrix application-layer message content, since Falcon's network telemetry is connection-metadata only; (3) the Element client-side SQLite artifacts that reveal the panel-bot operator account, which require manual host forensics; and (4) the separately reported GenieLocker ransomware chain this actor deploys after establishing a foothold — that chain has its own TTP set and deserves its own dedicated hunt pack. Validation gates for the queries that do ship are in Section 11.

Attempted but not used: hackread.com's coverage of the same story returned HTTP 403 on every fetch attempt and is not cited anywhere in this pack.