How can security teams detect Publish/Subscribe Protocols?

What security teams should look for first

Detection starts with the infrastructure pattern, not the content of the messages. Look for message brokers, topic namespaces, publish and subscribe relationships, and sudden growth in producer or consumer activity that does not match the normal application map. In practice, the quickest signal is a new broker, a new topic hierarchy, or a workload that begins publishing or consuming without a clear business owner.

It also helps to separate legitimate event-driven systems from opportunistic abuse. Publish/subscribe is often used by application platforms, integration middleware, and automation services, so the detection question is whether the broker, topic, and subscriber set were expected and approved. A baseline of known brokers, known topics, and normal access paths makes anomalies stand out much faster than payload inspection alone.

For broader protocol and transport discovery, Network Ports and Protocols Security Guide helps analysts think about exposed services and protocol activity as an inventory problem rather than a single-alert problem.

How to spot suspicious publish/subscribe activity

The most useful indicators are relationship-based. Unauthorised topic creation, repeated topic enumeration, unusual subscriptions from administrative or service accounts, and publishers that suddenly appear on hosts that never handled messaging before are all worth attention. High fan-out from one publisher, or a new subscriber cluster pulling from sensitive topics, can also indicate covert coordination or data staging.

Monitor for broker administration actions as well, because attacker activity often shows up as configuration change before it shows up as overt exfiltration. Broker restart events, ACL changes, queue policy edits, dead-letter routing changes, and cross-environment subscriptions can all indicate someone is reshaping the messaging layer for persistence or stealth. When those events appear without a change ticket or application release, treat them as a detection lead.

If the same infrastructure is used for command delivery or staged abuse, the patterns will resemble other control-channel behaviour. The Command and Control (C2) Guide is useful because it shows how beaconing, protocol tunnelling, and egress abuse can hide inside ordinary-looking communications.

Why access control and inventory matter

Publish/subscribe systems are easy to miss when teams only watch north-south traffic or classic client-server logs. A broker can become a hidden coordination hub if it is not inventoried, and a topic can become a covert handoff point if any host can publish to it. That is why detection and prevention are tightly linked: if you do not know which brokers, topics, and subscribers should exist, anomaly detection becomes noisy and slow.

Access control needs to cover both who may create topics and who may publish or subscribe to them. Weak broker permissions, shared credentials, and overbroad application identities make it hard to distinguish a legitimate integration from abuse. Strong allowlists, environment separation, and monitored administrative access reduce the chance that an attacker can turn the messaging layer into a low-visibility transport.

At the protocol level, the IANA registries are a useful reference point when you are validating whether a service, port, or identifier is expected in your environment rather than newly introduced by an adversary.

Practitioner Guidance

What to prioritise: Build a broker and topic inventory first, then compare it to approved application ownership and expected producer or consumer relationships. If a subscriber relationship cannot be tied to a known workload, treat it as a detection gap before treating it as a tuning problem.

What to verify: Check whether topic creation, subscription changes, and broker administration are logged with enough detail to reconstruct who changed what, when, and from where. Without that evidence, you can detect only the symptom, not the actor or the path.

Decision rule: If a messaging path appears in an environment that should not host it, or if a legitimate broker suddenly carries new cross-service traffic, investigate for misuse before you assume it is harmless application drift.

Practitioner takeaway: Publish/subscribe detection works best when teams treat brokers, topics, and subscriber relationships as governed assets, not just traffic flows.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?