Pen Testing: Trust Me Bro(ker)

Every organisation has that quiet system in the corner - the one doing critical work while nobody talks about it. Web apps get dashboards. Firewalls get attention. Endpoints get antivirus. Message brokers just quietly move data between services, like exhausted office workers carrying coffee between departments. Until security gets forgotten.

During a recent penetration test, one of those quiet systems introduced itself: a NATS server - a fast, lightweight messaging platform common in modern distributed environments. Think of it as the internal postal system for an application ecosystem. Services send messages, other services receive them, automation workflows depend on them. Everything keeps moving.

Until it doesn't.

How the attack unfolded

1. Discovery

Port scan identified an internal NATS server. No authentication banner. A known exploit for this configuration was flagged as potentially applicable.

2. Unauthenticated connection

Connected via the nats CLI with zero credentials. Server accepted the connection immediately.

3. Account enumeration

Queried account information and context list. Default system accounts confirmed.

4. JetStream access

Listed, created, and deleted persistent streams. Full read/write access to the operational data layer.

The first conversation with the server

Once we identified the NATS server on the network, we reached for the nats CLI — the official command-line tool for interacting with NATS. No custom exploit. No special tooling. Just the standard client.

Connecting looked like this:

The server asked for nothing. No credentials, no token, no certificate. It simply accepted the connection and handed over account information. At that point, the interaction had basically gone:

"Hi, can we connect?"

"Yeah, sure bro."

We then listed available contexts and confirmed the server was running with default system accounts - the kind that ship with NATS out of the box and are intended for lab use only.

It gets worse: the JetStream problem

With unauthenticated access confirmed, we moved to JetStream - NATS's persistence and streaming layer. This is where things shifted from embarrassing to genuinely dangerous.

JetStream isn't just a random feature. It's the glue holding distributed systems together - storing operational data, messaging streams, workflows, and application events. Deleting a stream silently removes the foundation that applications depend on.

Imagine someone walking into a warehouse and quietly removing conveyor belts while nobody was watching. Applications stop communicating. Automation breaks. Operational data disappears. Systems start failing in strange ways. And suddenly everyone is on a critical incident call wondering why production exploded at 2 AM.

What we could do with anonymous access

• Connect without any credentials
• View account and server information
• Create new contexts
• List all JetStream streams and their message counts
• Create new streams
• Delete existing streams - including those holding production data

The ancient curse of default configurations

The server was running on default system accounts - shipped with NATS, intended for development, never changed before reaching production. Security professionals have been warning about default credentials since approximately the invention of electricity. And yet here they are, surviving like digital cockroaches.

Attackers know this. It's why default credentials and open anonymous access are among the first things checked in any assessment. Not because it's clever - because it still works far more often than it should.

"It's internal, so it must be safe"

One of the biggest takeaways from this assessment is a belief that still quietly kills organisations: that internal systems are inherently protected.

Internal systems are often less monitored, less hardened, poorly segmented, and blindly trusted by everything around them. Once an attacker gains even minimal access - through phishing, a compromised VPN credential, or another exposed service - these forgotten internal systems become the most valuable targets in the environment.

A message broker sitting in the middle of every application talking to every other application? That's the cybersecurity equivalent of finding the building's master control room unlocked.

Five things this assessment proved, again

🔐 Authentication is not optional

If critical infrastructure allows anonymous access, attackers will eventually notice. Enable authentication, even on internal services.

🗑️ Default accounts belong in labs, not production

Change them. Disable them. Act as if they never existed.

🩹 Patch your infrastructure, including the quiet parts

A known exploit targeting this NATS configuration exists. Outdated internal services are still vulnerable even if nobody talks about them.

🔍 Monitor administrative activity

If streams are being created, modified, or deleted unexpectedly - someone should know immediately, not at the next retrospective.

🧱 "Internal only" is not a security control

Segment your internal network. Apply the same scrutiny to backend services that you'd apply to anything internet-facing.

The most dangerous systems in any environment are often the quietest ones. Not the flashy public websites. Not the fancy dashboards. The forgotten backend services that silently run the business every day - until a penetration tester asks why a production message broker is answering to strangers with no questions asked.

About Liverton Security

At Liverton Security, we help organisations find these gaps before attackers do. If you'd like to talk about what a penetration test could surface in your environment, get in touch.