LiveActive security incident?Get immediate response
MITRE ATT&CK® Malware

S9011: BRUSHFIRE

MITRE ATT&CK S9011: BRUSHFIRE Malware details for Linux, Network Devices, with detection guidance, relationships and mapped CVEs.

EnterpriseS9011MalwareObject v1.0Modified
Glexia's Take · Automated analysis

Security context for executives and security teams

Automation confidenceMedium

BRUSHFIRE matters because it is described as a passive, in-memory C backdoor for Linux and network devices. That combination can reduce the value of ordinary file-based malware controls and can make edge or infrastructure devices a blind spot during an incident. For leaders, the practical question is whether security teams can see unusual signaling and encrypted data movement from systems that often sit at trust boundaries.

Executive priority

Treat this as a resilience and visibility issue for Linux and network-device estates, especially internet-facing or boundary infrastructure. The ATT&CK relationships point to stealth, traffic signaling, reflective in-memory execution, decoding/deobfuscation, and encrypted non-C2 exfiltration. Executives should ask whether these platforms are inventoried, patched according to relevant vendor advisories, logged at a level useful for incident response, and covered by network detection. Where such devices support OT, oil and gas, petrochemical, or other critical operations, the business risk is not just malware cleanup but confidence in segmentation, remote access, and continuity decisions.

Technical view

SOC and IR teams should validate coverage around Linux hosts and network devices rather than relying only on endpoint file detection. Key behaviors to hunt for include unusual inbound packet patterns or traffic signaling, unexpected encrypted egress that is not part of known command-and-control channels, memory-resident code execution inside existing processes, and local decoding or deobfuscation activity. Because the official ATT&CK object provides no detection text, teams should build detections from the related techniques T1205, T1620, T1140, and T1048.002 and test whether telemetry exists on the affected platforms before assuming coverage.

Likely telemetry

  • Network flow records, firewall logs, VPN or edge-device logs, and packet capture where available
  • TLS or other encrypted-session metadata, destination reputation/context, certificate metadata, and egress volume patterns
  • Linux process, module, memory-map, audit, syslog, and EDR telemetry where deployed
  • Network-device operating logs, process/service status, configuration change records, and administrative access logs
  • Alerts or forensic evidence for anomalous in-memory execution, reflective loading, or code running without expected on-disk backing

Detection direction

  • Confirm whether Linux and network-device telemetry is actually collected and retained; these platforms are common blind spots compared with Windows endpoints.
  • Tune network analytics for traffic signaling patterns and unusual inbound probes that precede a change in service behavior, while accounting for legitimate health checks, scanners, and management tools.
  • Baseline encrypted egress from boundary devices and Linux servers; investigate asymmetric encrypted transfers to destinations or protocols inconsistent with normal operations.
  • Use memory-focused triage during incidents because the malware is described as executing in-memory within an existing process.
  • Correlate any suspected BRUSHFIRE behavior with the related ATT&CK techniques rather than relying on static indicators alone.

Mitigation priorities

  • Maintain an accurate inventory of Linux systems and network devices, with ownership, exposure, and logging status clearly defined.
  • Prioritize patch and configuration management for internet-facing and remote-access infrastructure, using applicable vendor advisories and vulnerability-management processes.
  • Restrict and monitor egress from network devices and Linux infrastructure; allow only required destinations, protocols, and administrative paths.
  • Harden management planes with strong authentication, least privilege, network segmentation, and restricted administrative access.
  • Prepare IR playbooks that include memory capture, network-device log preservation, configuration review, and segmentation validation.
Additional notes and limits

The object is a malware entry for BRUSHFIRE, external ID S9011, in ATT&CK Enterprise v19.1. MITRE describes it as a passive in-memory C backdoor observed in activity attributed to PRC state-affiliated threat actors including UNC5221 and SYLVANITE, with external references from Dragos, Google, and Picus. The object has no aliases, no ATT&CK tactics listed directly, and no official detection guidance; the practical defensive framing is therefore derived from the supplied platforms, description, references, and uses relationships.

This take does not assert current exploitation, customer exposure, guaranteed detectability, or complete attribution beyond the supplied ATT&CK description. No indicators, commands, hashes, procedures, or official detection analytics were provided. Local asset inventory, network architecture, logging depth, and vendor-specific device behavior are required to turn this into deployable detections or response decisions.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

BRUSHFIRE

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
ea132a21790b6abe...
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.