Passive listening, one account, and the whole domain
The client asked us for one thing: test the internal network the way someone who is already inside would. An ordinary employee, an ordinary wall jack, zero special privileges to start.
We used no fresh exploit and no zero-day. It was enough to listen to what the network broadcasts on its own and to answer politely.
In two weeks we held a domain administrator account, the full password database from the controller, and one password that logged us into almost a hundred and sixty accounts at once. Below is the whole path, technique by technique, mapped to MITRE ATT&CK.
Context
Start with something that should work in the client's favor. The domain password policy required fourteen characters. That's more than most companies we visit, and on paper it looks responsible.
The problem is that this rule lived in the domain settings but not in reality. When someone raised the required length, nobody forced a reset of the existing passwords. New accounts picked up the new rule, old ones kept theirs. In the database we later pulled from the controller, passwords shorter than nine characters sat there comfortably, even though the system claimed the minimum was fourteen. Even the domain administrator's password was eleven.
The test itself was simple in principle: an internal network pentest from the position of someone who already has access to the office network. An internal user: an intern with a laptop, someone plugged into a jack in the conference room, a compromised workstation. The scope was a few network segments and one question: how far does such a person get.
Challenge
The environment wasn't built without thought. There was an Active Directory domain, there was segmentation into several subnets, there was a password policy stricter than average. Judged against an audit checklist, plenty of boxes would come out green. We say so honestly, because a test earns credibility by showing both sides, not only the bad parts.
The weak spot was elsewhere, in the parts that don't shout from a compliance report. In how Windows resolves names by default when DNS fails. In the fact that some hosts didn't enforce signing on SMB traffic. And in one account that did far too much at once.
What we did
We started by listening. When a machine on a Windows network can't find a name in DNS, it doesn't give up. It broadcasts a question to the whole local segment along the lines of "hey, does anyone know who this is?" That's an invitation to anyone who happens to be listening. We were listening. We answered "yes, that's me," and the machine trustingly tried to authenticate to us, handing over its login attempt as a NetNTLMv2 hash along the way. Into the same pool we added a second mechanism: on a Windows network IPv6 is on by default and takes priority, and nobody had configured an addressing server for it. We stepped into that void, presented ourselves as the configuration server and the name server, and captured further authentication attempts.
Then came the turn to relay the session. Because some hosts didn't enforce SMB signing, we didn't even have to crack the captured credentials. We relayed them on the fly to other machines and acted on that user's behalf. Here the snowball effect kicked in: one user who fell into our trap had local administrator rights on eighteen machines. From each of them we scooped up the local account database with password hashes.
That same account turned out to be a domain administrator, used for day-to-day work. We cracked its password offline on our cracking rig. Eleven characters, below their own threshold of fourteen, so it went fast. At the domain level, that was the end.
With domain administrator rights we dumped the entire Active Directory password database from the controller. Over three thousand credential sets. Then we cracked them offline, at our leisure, with no pressure from account lockouts. One in five hashes fell, 22 percent exactly. And the punchline we came for: one password repeated across 158 accounts.
The whole path in the language of MITRE ATT&CK looks like this:
The mechanics of the first step are easiest to show as a simplified run. The data is generic, no real names, addresses, or timestamps:
# maszyna nie znajduje nazwy w DNS i pyta cały segment [BROADCAST] kto to jest "fileserv01"? [NASZ HOST] to ja, łącz się ze mną [MASZYNA] ok, uwierzytelniam się... (NetNTLMv2) # host docelowy nie wymusza podpisywania SMB, # więc przechwyconą sesję przekazujemy dalej [NASZ HOST] -> [inny host] loguję się jako przechwycony użytkownik [inny host] dostęp przyznany
Result
Full domain compromise from an ordinary user's position, no zero-day, in two weeks, with the risk rated critical. Once an attacker holds a domain administrator account and the full password database from the controller, they no longer break into individual systems. They move through the organization like a trusted user. Reused passwords turn one crack into access to dozens of accounts. A reused local administrator password means that taking one machine leads to taking the next.
Alongside this identity layer, the environment carried a second debt. Three critical and over a hundred serious vulnerabilities on outdated versions of web servers, cryptographic libraries, and database services, plus weak TLS cipher suites. Each is a separate vector. Together they paint a picture of an environment where patching stopped keeping pace with reality.
What to do about it, in a form you can check off:
- Disable LLMNR and NBT-NS through GPO where they aren't needed, and block DHCPv6 traffic and router advertisements if IPv6 isn't in use. That takes away the attacker's first step, the free credentials from listening.
- Enforce SMB signing on all workstations and servers. Without it, a captured session can be relayed onward and cracking isn't even needed.
- Separate administrative accounts from day-to-day work accounts and roll out local administrator password management, for example LAPS, so that taking one machine doesn't open the next.
- On every password policy change, force a reset of existing passwords. A rule that doesn't reach accounts from before the change protects only on paper.
- Enforce unique passwords across systems and raise the real minimum length to at least fifteen characters. One password on many accounts is a gift to the attacker.
- Get patching in order: a central process for updating systems and applications, and the retirement of outdated protocols and weak ciphers.
- Where possible, add multi-factor authentication and segmentation to limit the reach of a man-in-the-middle attack within a segment.
One more thing
The most interesting thing about this test is that no step was magic. Listening, relaying a session, one over-privileged account, one password reused hundreds of times. Each of these looks innocent until they line up in a row.
So the closing question is simple. If someone plugged into a jack in your conference room today and just started listening, how far would they get?
Book a call with a consultant. We'll walk through the scope, the risks, and what a test like this could look like at your company.
All case studies are anonymized by sector, without names, dates or any data that could identify the client, in line with confidentiality. We never publish real vulnerabilities or client technical data.