Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1071.005: Publish/Subscribe Protocols

Adversaries may communicate using publish/subscribe (pub/sub) application layer protocols to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server.

Protocols such as MQTT, XMPP, AMQP, and STOMP use a publish/subscribe design, with message distribution managed by a centralized broker.[1][2] Publishers categorize their messages by topics, while subscribers receive messages according to their subscribed topics.[1] An adversary may abuse publish/subscribe protocols to communicate with systems under their control from behind a message broker while also mimicking normal, expected traffic.

EnterpriseT1071.005Sub-techniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Publish/Subscribe Protocols matter because command-and-control traffic can hide inside messaging patterns that may look normal in modern enterprise, cloud, IoT, or operations environments. Protocols such as MQTT, XMPP, AMQP, and STOMP are designed to route messages through brokers, which can make direct client-to-controller visibility harder. For leaders, the key issue is whether the organization can distinguish legitimate brokered messaging from unauthorized command traffic before it affects incident containment decisions.

Executive priority

Prioritize this where pub/sub protocols are allowed across user networks, server environments, network devices, or business-critical operational systems. The business decision is not simply whether these protocols exist, but whether their use is approved, segmented, logged, and filterable. This technique should drive questions about egress control, broker governance, network boundary inspection, SOC visibility, and incident response playbooks for suspicious application-layer command-and-control.

Technical view

This is a command-and-control sub-technique of Application Layer Protocol covering macOS, Linux, Windows, and Network Devices. ATT&CK does not provide official detection text for this object, but the related detection strategy is behavioral detection of pub/sub protocol misuse for C2. SOC and detection teams should validate whether MQTT, XMPP, AMQP, and STOMP traffic is visible, whether broker destinations and topics are baselined where available, and whether unusual client-to-broker patterns can be investigated. Relationship context includes GLOOXMAIL, a Windows malware entry that mimics legitimate Jabber/XMPP traffic, reinforcing the need to distinguish expected protocol use from lookalike traffic.

Likely telemetry

  • Network flow records showing internal and external broker connections
  • Firewall, proxy, and network boundary logs for allowed or blocked pub/sub protocol traffic
  • IDS/IPS alerts and signatures related to MQTT, XMPP, AMQP, STOMP, or anomalous application-layer traffic
  • Endpoint network connection telemetry from Windows, macOS, and Linux systems
  • Broker logs where the organization operates MQTT, XMPP, AMQP, or STOMP infrastructure

Detection direction

  • Inventory where pub/sub protocols are expected, then alert on use from systems or segments with no business need.
  • Tune detections around unusual broker destinations, unexpected ports or protocols, new client populations, abnormal connection timing, or topic/subscription patterns where broker logs are available.
  • Correlate network alerts with endpoint process and user context to reduce false positives from legitimate messaging clients or approved middleware.
  • Treat encrypted or broker-mediated traffic as a visibility challenge: flow metadata, destination allowlists, and endpoint context may be more reliable than payload inspection alone.
  • Use the related DET0002 strategy as a validation target, but do not assume coverage because ATT&CK provides no official detection logic in this object.

Mitigation priorities

  • Start with network traffic filtering: restrict ingress, egress, and lateral pub/sub protocol use to approved systems, brokers, and destinations.
  • Use network intrusion prevention at boundaries where signatures or policy rules can identify unauthorized or suspicious pub/sub traffic.
  • Segment approved brokers and middleware so general user systems or unmanaged devices cannot freely communicate with them unless required.
  • Maintain allowlists and firewall rules for authorized broker infrastructure, and review exceptions as part of change management and compliance evidence.
  • Ensure incident response teams can quickly identify whether observed pub/sub traffic is approved business messaging or suspicious command-and-control behavior.
Analyst notes and limits

The strongest defensive value is in governance and visibility: know where pub/sub protocols are legitimate, monitor deviations, and preserve enough network and endpoint evidence to support containment decisions. This object is especially relevant to environments that permit messaging middleware, Jabber/XMPP-style communication, MQTT-based systems, or brokered application traffic.

The supplied ATT&CK object has no official detection text and provides limited procedure context beyond the GLOOXMAIL software relationship and cited examples. Local protocol usage, broker ownership, encryption, logging depth, and network architecture are required to determine actual risk and detection coverage.

Official MITRE ATT&CK definition

Publish/Subscribe Protocols

Adversaries may communicate using publish/subscribe (pub/sub) application layer protocols to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server.

Protocols such as MQTT, XMPP, AMQP, and STOMP use a publish/subscribe design, with message distribution managed by a centralized broker.[1][2] Publishers categorize their messages by topics, while subscribers receive messages according to their subscribed topics.[1] An adversary may abuse publish/subscribe protocols to communicate with systems under their control from behind a message broker while also mimicking normal, expected traffic.

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1071 Application Layer Protocol This object subtechnique of Application Layer Protocol.
Associated objects

Groups, software, and campaigns

Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0002: Behavioral Detection of Publish/Subscribe Protocol Misuse for C2 Enterprise subtechnique of · Technique T1071: Application Layer Protocol Enterprise mitigates · Mitigation M1037: Filter Network Traffic Enterprise uses · Malware S0026: GLOOXMAIL Enterprise mitigates · Mitigation M1031: Network Intrusion Prevention Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1037: Filter Network Traffic

Employ network appliances and endpoint software to filter ingress, egress, and lateral network traffic. This includes protocol-based filtering, enforcing firewall rules, and blocking or restricting traffic based on predefined conditions to limit adversary movement and data exfiltration. This mitigation can be implemented through the following measures:

Ingress Traffic Filtering:

- Use Case: Configure network firewalls to allow traffic only from authorized IP addresses to public-facing servers. - Implementation: Limit SSH (port 22) and RDP (port 3389) traffic to specific IP ranges.

Egress Traffic Filtering:

- Use Case: Use firewalls or endpoint security software to block unauthorized outbound traffic to prevent data exfiltration and command-and-control (C2) communications. - Implementation: Block outbound traffic to known malicious IPs or regions where communication is unexpected.

Protocol-Based Filtering:

- Use Case: Restrict the use of specific protocols that are commonly abused by adversaries, such as SMB, RPC, or Telnet, based on business needs. - Implementation: Disable SMBv1 on endpoints to prevent exploits like EternalBlue.

Network Segmentation:

- Use Case: Create network segments for critical systems and restrict communication between segments unless explicitly authorized. - Implementation: Implement VLANs to isolate IoT devices or guest networks from core business systems.

Application Layer Filtering:

- Use Case: Use proxy servers or Web Application Firewalls (WAFs) to inspect and block malicious HTTP/S traffic. - Implementation: Configure a WAF to block SQL injection attempts or other web application exploitation techniques.

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.1
Created
Modified
Raw hash
e61518b9fd826b75...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle e61518b9fd82…
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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    wailing crab sub/pub

    Hammond, Charlotte. Villadsen, Ole. Metrick, Kat.. (2023, November 21). Stealthy WailingCrab Malware misuses MQTT Messaging Protocol. Retrieved August 28, 2024.

    Open source URL
  2. [2]
    Mandiant APT1 Appendix

    Mandiant. (n.d.). Appendix C (Digital) - The Malware Arsenal. Retrieved July 18, 2016.

    Open source URL
  3. [3]
    mitre-attack T1071.005
    Open source URL
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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use