The short version: attackers are starting to throw passwords at login systems that were never meant to work, and that breaks an assumption a lot of defensive tooling is quietly built on.

What a synthetic password is

A synthetic password is a credential that was generated, not leaked and not guessed. It has never appeared in a breach because nobody ever used it. You make it at scale with a script or a model, shaped to look like the kind of password a person would actually choose.

That last part is the point. These are not the 25 character blobs a password manager spits out that look like a bomb went off in the alphabet. They look human. Something like:

Blaire#3863
Elle@2265
jazz!light116
chess&flint152

None of those have ever been typed into anything. They look real enough, and “real enough” is the whole problem.

They are not trying to log in

The instinct is to treat a flood of login attempts as brute force, where the attacker is hoping one of the guesses lands. Synthetic passwords are not really that. The odds of any single generated string matching a real account are tiny, and the attacker knows it. Logging in is not the goal.

The goal is everything that happens around the login attempt:

• Flood the SOC and the SIEM so real credential stuffing hides in the noise.
• Defeat breach matching, because none of these passwords are in any breach corpus.
• Burn analyst time on high volume, high entropy inputs that go nowhere.

In the operational cases that started me down this path, defenders were seeing login traffic that looked like the entire world was trying to get in at once, with passwords that all looked plausible and none of which were known-bad. That is the tell, and it is also the trap.

Making them is trivial

I want to be honest about how low the barrier is. The first generator I wrote was a pile of if-statements I put together quickly with help from ChatGPT. It is a proof of concept, not clever, and I could clearly do better with real effort. It did not matter. You feed it words and numbers, pets, names, drinks, whatever, and it recombines them with separators and digits into human-shaped strings.

I generated 10 million of them and not one was a repeat. The full generator and the analysis scripts are here:

github.com/taffy210/synthetic-passwords-botnet

The experiment

I wanted to put numbers behind the idea rather than just assert it. So I took two corpora and scored both against a breach set of about 10 million known passwords.

• A real corpus: roughly 1 million passwords pulled from recent stealer logs.
• A synthetic corpus: 10 million passwords from my generator.

For each password I computed a per-character Shannon entropy, bucketed it by length and rough pattern, and checked whether it appeared in the breach set. The results are the part worth keeping.

98.66% of the real passwords were already in the breach set. People reuse, and they reuse heavily, which is depressing but not surprising. Out of 10 million synthetic passwords, 18 collided with the breach set. Effectively zero, and the 18 are just birthday-paradox coincidences on common formats.

Someone in the room pushed on exactly this, asking whether it is statistically possible for almost none of 10 million to show up. It is, and that is the finding. The breach corpus is a list of passwords humans have actually used. Synthetic passwords are novel by construction, so they sail straight past it.

They even look right by length

If length were a giveaway, this would be easy. It is not. Real passwords cluster around 8 to 10 characters; the synthetic set sits a little longer, around 9 to 14, well inside the range a human password lives in.

The shapes are not identical, but a synthetic password is not going to stand out in a login stream because it was 41 characters long. It looks like something a person would pick.

Why this breaks defenses

The reason this matters is that a lot of controls lean on the same assumption: if a password has never been seen in a breach, it is probably not part of an attack. Synthetic passwords turn that assumption into an exploit.

• Breach correlation goes blind. Tools that gate on “have I seen this password leak before”, whether that is Have I Been Pwned, a stealer-log feed, or a commercial repository, return a clean result for every synthetic input. Zero match gets read as low threat, and the attempts get waved through.
• Honeywords get harder to trigger. If every attempt is unique and high entropy, decoy credentials and honey accounts are less likely to be tripped, because nothing looks like a targeted guess.
• Behavioral signal gets diluted. When each attempt comes from a different session or IP, with a different plausible password, there is no obvious anchor to pivot on. Not the password, not the source, not the format.

None of these tools are broken. They are answering the question they were designed to answer. The attacker just changed the question.

A detection angle the data handed me

One thing jumped out of the numbers that I did not expect. The synthetic passwords had a tight entropy band, roughly 2.0 to 3.9 per character, while the real corpus ranged from basically 0 up past 6. Human password sets are messy and wide. A generator, unless you work at it, produces something suspiciously uniform.

That uniformity is itself a signal. Real traffic is lumpy. A stream of login attempts whose entropy and format variance are too consistent, too clean, is worth a second look precisely because real users are not that tidy.

What I think defenders should do

Most of this is not exotic. The frustrating part is how often only one method is in place, usually breach correlation on its own.

• Stop treating “not in a breach” as “safe”. It is one weak signal, not a verdict.
• Add entropy scoring and format-variance monitoring, and watch for sudden surges of high-variance inputs.
• Use session and device fingerprinting so the password is not the only thing you are judging.
• Watch for attempts that fail too cleanly. A real person who gets it wrong tries something close to the original next, password then password1. A jump to something completely unrelated every time looks more like a machine.

The bigger shift is from identity-based detection to intent-based detection. Instead of asking only “is this credential known-bad”, ask “does this attempt behave like a human trying to get into their own account”. That is a question a model could reasonably be trained to help with, flagging sessions whose patterns are not human in the same way a CAPTCHA tries to.

Honest caveats

I would rather state the limits than have someone find them for me. The generator is a first pass. Per-character Shannon entropy is a crude measure and not the same as guessing resistance. The breach corpus and the stealer-log corpus overlap by their nature, which is part of why the real match rate is so high. And yes, my conference graph was lopsided enough that the room thought I had lost a fight with PowerPoint. The cleaned-up version is above.

None of that changes the core point. Synthetic passwords are cheap, scalable, and invisible to controls that assume novelty equals safety.

Closing

Synthetic passwords are not on the fringe. Botnets generate them, attack scripts ship them, and they cost almost nothing to produce. The attacker does not care whether the password works, and often does not want it to. The job it is doing is masking and distracting, and it does that job well.

The talk was mostly an awareness piece, because most of the fixes are things this audience already considers obvious. The gap is that obvious and implemented are not the same thing.

Recording is above. Code and data are on GitHub.

Disclaimer: The examples below are anonymised and aggregated across multiple engagements. The goal is to highlight recurring patterns, not embarrass any specific organisation.

Security Theatre: Field Notes from the Inside

The Scene

Most environments I assess are not wide open. They have firewalls, policies, and controls that look sensible on a slide deck.

The same weaknesses keep showing up anyway. Security gets implemented as a compliance checklist rather than an adversarial system.

That is security theatre: controls that exist, but fail under pressure.

It shows up in small things (a forgotten hyperlink), legacy things (Telnet still running), and complex things (multi-tenant routing edge cases that quietly break the idea of “internal”).

Most incidents do not start with a zero-day. They start with an assumption.

The Meaning

Security theatre is security that only works from one angle.

• It satisfies an audit requirement
• It meets a policy statement
• It was set up once and never re-validated
• It relies on “internal trust” as a boundary

It fails the moment an attacker does basic due diligence.

Real Security vs Theatre

A Simple Test

Rate each control against three questions:

1. Is it verified? Not configured, but tested.
2. Is it monitored? Will you know when it fails?
3. Is it owned? Is someone accountable for its health?

Two “no” answers means you do not have a control.

Field Notes

1. “Internal” RFC1918 Space Leaking Other People’s Infrastructure

On one client network, we found a large number of devices in the 172.30.x.x and 172.31.x.x ranges. Normal enough.

The exposed services were not normal:

• Cisco IOS devices presenting known vulnerabilities
• OpenSSH issues flagged, including severe exposure classes
• SNMP responding with default community strings (public)
• Telnet open in cleartext

When we pulled device information over SNMP, the fingerprints did not match the client’s environment. The devices looked like other organisations’ routers, visible from within this client’s own network.

Whether it was a provider-side forwarding mistake, a multi-tenant routing bleed, or a design choice nobody fully understood, the problem is the same:

“Internal” is a routing decision, not a security boundary.

A network can be “private” on paper while being multi-tenant in practice. Technically not the client’s fault. Still their problem.

The pessimistic outlook: unintended trust paths, lateral movement opportunities, messy incident response (“is that ours?” becomes a real question), and reputational fallout if the client network becomes a stepping stone into someone else’s infrastructure.

2. Monitoring Interfaces That Become Management Interfaces

SNMP is often justified as “monitoring only.”

In practice it provides device names, interfaces, routing hints, OS and platform fingerprinting, uptime, load, and depending on configuration, more. When SNMPv2c is exposed with default communities, “monitoring” becomes enumeration on demand.

The control exists (“we have monitoring”), but the threat model is absent (“monitoring endpoints are high-value targets”).

What to do instead:

• SNMPv3 with auth and privacy where possible
• Strict ACLs so only the monitoring system can reach SNMP
• Remove default communities, remove write communities unless there is a hard requirement
• Continuous checks for public/private drift

3. Telnet in 2026

Telnet still appears internally more often than people admit. Rarely a deliberate decision. More often a leftover: legacy device, a “temporary” troubleshooting session, vendor defaults, a project that ended but the port stayed open.

What to do:

• Disable Telnet everywhere, policy plus validation
• If legacy hardware makes that impossible, isolate it and treat it as hostile
• Enforce SSH and modern cipher suites for all management
• Log and alert on any Telnet session as a high-signal event

4. The Easiest Brand Hijack Is a Broken Hyperlink

One of the more sobering findings I have seen had no CVE attached.

A client website linked to their social media profiles. The X and Instagram links pointed to accounts that did not exist. We registered the usernames the website was implicitly endorsing.

Any visitor clicking those links landed on an attacker-controlled profile that looked official by association. I was, briefly, the client’s new social media manager.

The organisation likely had solid perimeter controls. Their public brand identity had an unguarded back door.

What to do:

• Treat web presence as an asset inventory: domains, handles, app store listings
• Reserve key usernames even on platforms you do not actively use
• Run a quarterly external exposure review with marketing and security together
• Add a brand protection checklist to release processes

5. Hidden SSIDs and Other Comforting Myths

I have assessed environments where the guest Wi-Fi was modern and well-configured (WPA3), additional SSIDs existed as “hidden,” and those SSIDs still covered public areas: roads, car parks, the perimeter.

Hidden SSIDs do not stop discovery. The tooling is trivial and takes minutes. They stop casual users from seeing the network in a dropdown list.

What to do:

• Remove unused SSIDs entirely
• Prefer WPA3-Enterprise (EAP) where feasible
• Segment wireless properly: guest is not corporate, corporate is not infrastructure
• Validate coverage from outside the perimeter

6. “Medium” Findings That Do Not Feel Medium

Scanner outputs create a predictable behaviour pattern. Critical gets attention, high gets scheduled, medium gets ignored, info gets laughed off.

Some medium findings describe classes of weakness that become severe with real-world conditions: SSH weaknesses that matter under MITM conditions, management interfaces with brute-force exposure, patch states that are “mostly fine” but leave a few critical paths open.

Severity is a starting hypothesis, not a verdict. Two mediums can combine into a critical.

Prioritise weaknesses that enable credential capture, management access, or trust boundary crossing regardless of how the scanner scored them.

7. Logs Exist, but Meaning Does Not

On the blue side, I often see logging enabled but not operationally useful.

Suricata is a good example. It can generate excellent visibility, but without a workflow it becomes noise. The questions that matter are: what are our top external destinations, which internal hosts talk to unusual places, and what changed since last week.

“We have monitoring” becomes a checkbox, and the logs do not get reviewed.

What to do:

• Build simple, repeatable queries that surface top talkers, new domains, and rare destinations
• Baseline normal behaviour and alert on deviations
• Assign ownership: someone reviews signals and acts on them

The Patterns Underneath

The field notes above are specific. Step back and the same three shapes keep appearing across otherwise unrelated environments. A control is present, it satisfies a diagram or an audit line, and it quietly does nothing under pressure. These are the patterns worth recognising before you find them.

Detection without response

Detection promises visibility. Alerts come in, someone investigates, action is taken. It works for a while. Dashboards get checked, alerts get acknowledged, then the noise builds. False positives pile up. A day goes by without anyone looking, then two, and eventually nobody is sure who owns the dashboard.

At that point the alert that fires and the alert that does not fire produce the same outcome: nothing. An alert nobody investigates is a log entry, not a control. I have watched a Cowrie session persist for minutes on a box that was generating events the whole time, with the events landing in an index nobody queried. The data was perfect. The response was absent.

If you want to test this in your own environment, trigger something that should alert and time how long until a human acts. If the answer is “never,” the detection is theatre.

Authentication with escape hatches

Strong authentication gets undermined at the exceptions, not the front door. Legacy devices that “don’t support it.” Applications that need a compatibility mode. A temporary workaround that quietly becomes permanent. Then the choice problem: several authentication methods enabled at once for convenience, some far weaker than others, with the intention of resilience and the effect of dilution.

Attackers do not attack the strong path. They enumerate the methods on offer and use the weakest one you left enabled “just in case.” A tenant with phishing-resistant MFA on the primary flow and a legacy protocol still accepting a username and password is a tenant with no MFA, for anyone who bothers to ask the right endpoint which methods it supports.

The test: list every way to authenticate to a system, then rate the weakest one. That is your real authentication strength. The strongest path is irrelevant if a weaker one is still reachable.

Segmentation without isolation

Segmentation looks clean in a diagram. Separate zones, tidy rulesets, clear boundaries. In practice the boundaries collapse at shared services. DNS, authentication, file shares, jump hosts, and management interfaces punch holes through supposedly isolated segments because something on one side needs something on the other. Rules get added to make a thing work, the isolation erodes a rule at a time, and nobody re-tests the boundary as a whole.

The network looks compartmentalised. When it matters, it routes like a flat one. This is the same failure as the multi-tenant routing in field note one, seen from the inside: “internal” and “isolated” are both routing decisions wearing a security costume.

The test: from a low-trust segment, see what you can actually reach. Not what the diagram says you should reach. What answers.

Why This Happens

Most security theatre comes from normal organisational pressure:

• Compliance is measurable; security is contextual
• Change control is painful, so legacy stays
• Ownership is fragmented, so controls drift
• Teams are stretched, so verification falls away
• Perimeters look strong, so internal trust grows by default

More tools will not fix this. Verification, ownership, and feedback loops will.

Breaking the Cycle

This week:

• Kill Telnet wherever it exists
• Remove default SNMP communities, lock SNMP behind ACLs
• Inventory and reserve public brand assets
• Delete unused SSIDs, validate coverage beyond the perimeter
• Review private ranges for routing weirdness and unintended reachability

The structural fix: a control is not done when it is configured. It is done when it is verified with adversarial thinking, monitored for failure, and owned with accountability.

If you cannot answer “who owns this control,” it is theatre waiting to fail.

The End

Security is not the number of controls you can list. It is the number that survive contact with an adversary.

If your “internal” network is only secure because everyone agrees to behave, that is not a network. It is a trust exercise.

Appendix: How Screwed Am I?

If any of these are true, you are looking at theatre:

• “It’s fine because it’s internal”
• “We enabled logging” (but nobody reviews it)
• “We use SNMP for monitoring” (but it’s v2c and broadly reachable)
• “It’s hidden” (SSIDs, panels, directories)
• “We patched most of it”
• “That’s only a medium”
• “We don’t know who owns it”

Hunt the assumptions, not just the CVEs.