AN0002: Analytic 0002
Detects non-standard processes (e.g., PowerShell, python.exe, rundll32.exe) making outbound connections using publish/subscribe protocols (e.g., MQTT, AMQP) over non-browser, encrypted channels, often beaconing to message brokers.
Analyst context for executives and security teams
This analytic matters because it looks for Windows processes that do not normally act like browsers or standard application clients making encrypted outbound connections with publish/subscribe protocols such as MQTT or AMQP. For leaders, the value is not in the protocol names themselves; it is in confirming whether the organization can notice unusual command or scripting processes communicating with message-broker style infrastructure before that traffic becomes an incident-response blind spot.
Executive priority
Prioritize this as a validation point for egress visibility, SOC readiness, and incident triage quality on Windows systems. Security leaders should ask whether encrypted outbound traffic from tools such as PowerShell, python.exe, or rundll32.exe is visible, whether publish/subscribe protocol use is expected anywhere in the environment, and whether exceptions are documented for business systems that legitimately use MQTT or AMQP. This can support control prioritization around network monitoring, endpoint visibility, and compliance evidence for outbound traffic governance.
Technical view
The supplied analytic is Windows-focused and describes detection of non-standard processes making outbound encrypted connections using publish/subscribe protocols, often beaconing to message brokers. SOC and detection teams should validate whether endpoint process telemetry can be joined with network connection metadata so analysts can see process name, host, destination, port/protocol indicators, encryption context, and connection frequency. Because no ATT&CK tactic or formal detection logic is supplied, implementation should be treated as a hypothesis-driven analytic requiring local baselining of legitimate MQTT, AMQP, scripting, automation, and application behavior.
Likely telemetry
- Windows endpoint process execution telemetry, including process name and command context where available
- Endpoint network connection telemetry linking outbound connections to initiating processes
- Network metadata for encrypted outbound sessions, including destination, port, timing, and frequency
- Protocol identification or proxy/firewall metadata capable of distinguishing MQTT, AMQP, or message-broker style traffic where available
- Asset and application inventory to identify legitimate systems expected to use publish/subscribe protocols
Detection direction
- Validate process-to-network correlation for PowerShell, python.exe, rundll32.exe, and other locally unusual non-browser processes.
- Baseline legitimate MQTT and AMQP usage before alerting broadly; industrial, IoT, messaging, integration, or application platforms may create expected traffic.
- Tune for repeated or periodic outbound connections to message-broker-like destinations, while avoiding claims of malicious beaconing without supporting local evidence.
- Review blind spots caused by encrypted channels, lack of protocol identification, missing endpoint network telemetry, or inability to associate a connection with the originating process.
- Use allowlists carefully: document approved applications, destinations, and service accounts rather than suppressing by protocol alone.
Mitigation priorities
- Inventory legitimate Windows systems and applications that use MQTT, AMQP, or related publish/subscribe communications.
- Improve endpoint and network logging so outbound encrypted sessions can be tied back to initiating processes.
- Restrict unnecessary outbound connectivity from scripting and utility processes where policy and business operations allow.
- Apply egress controls and proxy/firewall governance for broker-style destinations, with documented exceptions for approved business use.
- Prepare incident-response triage playbooks for alerts involving unusual Windows processes, encrypted outbound traffic, and repeated broker communications.
Analyst notes and limits
The object is a detection analytic, not a technique, and no relationships or official detection logic were supplied. The most defensible use is as a coverage-validation prompt: can the SOC identify unusual Windows processes using encrypted publish/subscribe communications, and can it separate expected business messaging from suspicious activity?
ATT&CK provides only a short description for this analytic. Tactics, relationships, aliases, and official detection details are not supplied. Local environment baselines are required to determine what is unusual, which destinations are approved, and what alert thresholds are appropriate.
Analytic 0002
Detects non-standard processes (e.g., PowerShell, python.exe, rundll32.exe) making outbound connections using publish/subscribe protocols (e.g., MQTT, AMQP) over non-browser, encrypted channels, often beaconing to message brokers.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 529cdfe131db… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0002Open source URL
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.