How do attackers use publish/subscribe protocols?

How publish/subscribe changes the attack surface

Publish/subscribe systems change the attack surface because messages are brokered rather than delivered point to point. That gives attackers room to blend malicious traffic into legitimate topics, hide command traffic in normal-looking events, or keep a foothold by maintaining subscriptions after the original sender is gone. The protocol design is not inherently unsafe, but trust shifts to the broker, topic model, and access controls.

In practice, that means defenders need to think about who can publish, who can subscribe, and what a compromised client can infer or influence once it joins the message flow. The security question is less about whether a single packet looks suspicious and more about whether the topic itself becomes a durable channel for unauthorized control or data movement.

How attackers use topics, brokers, and subscriptions

Attackers often abuse publish/subscribe protocols for command and control, because the broker can sit between the operator and the compromised host and make the exchange look like routine messaging. They may publish commands into a topic the victim already consumes, read tasking or exfiltrated data from a separate topic, or switch between topics to reduce visibility. Because message delivery is asynchronous, this can also help them survive short outages or intermittent connectivity.

Published messages can also become an exfiltration path when defenders focus only on traditional outbound sessions. If a client is allowed to subscribe broadly, the attacker may not need a direct inbound connection at all, only continued access to the broker and the right topic names. That makes topic governance, not just network perimeter control, central to the defensive model.

Broker abuse is especially effective when topic names are predictable, access is coarse, or authentication is weak. In those environments, a malicious publisher can impersonate a legitimate producer, inject false events, or create noisy traffic that masks a quieter control channel. The same weakness can let an attacker monitor operational data streams and use them to time follow-on actions.

What good defensive handling looks like

Defensive control starts with strong client authentication and explicit authorization for each publish and subscribe action. Topic-level access should be narrow, with separate rights for producers, consumers, and administrative functions, so compromise of one client does not automatically expose the whole message fabric. That is where least privilege matters most, because broad topic access turns a messaging system into a shared trust zone.

Monitoring should focus on broker behavior, topic churn, message volume changes, unusual fan-out, and new or unexpected subscriptions. A sudden appearance of a new broker, an unusual retention pattern, or a client that starts consuming from topics outside its normal function is often more useful than looking for payload content alone. Where possible, pair protocol monitoring with network controls so unauthorized brokers and cross-segment message paths are easier to spot.

For readers who want a deeper attacker perspective on message-broker abuse and command channels, the Command and Control (C2) Guide is the most directly relevant internal resource, because it covers beaconing, protocol tunneling, DNS analytics and egress filtering in the same operational context.

Risk and Threat Considerations

Publish/subscribe protocols can create hidden persistence and data-flow risk when defenders assume the broker is only an infrastructure component. If an attacker controls a publisher or subscriber, the messaging layer can become a durable covert channel that is harder to inspect than a direct connection and harder to scope than a single compromised host.

Failure mechanism: Weak topic authorization, predictable naming, or insufficient broker visibility lets an attacker inject commands, observe operational events, or retain access through subscriptions without needing a classic interactive session.

Impact: The result can be command-and-control persistence, unauthorized data movement, false telemetry, and broader blast radius if multiple systems trust the same brokered channel.

Practitioner Guidance

What to verify: Confirm that every publisher and subscriber is authenticated separately, and that topic-level permissions are explicit rather than inherited from a broad service identity. Treat shared or wildcard topic access as a high-risk condition unless there is a strong operational reason for it.

Decision rule: If a topic can carry both operational telemetry and tasking, separate those flows. If a broker can be reached from multiple zones, assume the broker itself is part of the attack surface and include it in logging, alerting, and containment plans.

Practitioner takeaway: In publish/subscribe systems, the key control point is not the message payload alone, it is whether topic access, broker trust, and subscription scope are tight enough to prevent covert command channels and long-lived unauthorized access.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?