From Misconfigurations to Full Domain Compromise

The Challenge

A US city government engaged their managed security services provider for annual external and internal penetration testing. The MSSP brought us in as the technical delivery partner for the testing work. Municipal networks are not glamorous targets in the public imagination, but they handle constituent data, public safety operations, payment processing for utilities and permits, and the kind of critical day-to-day services residents notice instantly when they fail. A compromise at a municipality has real public impact and very low public tolerance.

The city had made real security investments. They had modern endpoint protection across most of the environment. They had an MSSP monitoring their perimeter. They had policies, documented procedures, and a team that took security seriously. On paper, the posture looked reasonable. That is the exact kind of environment where a pentest either confirms the program is working or reveals that an environment this complex has accumulated misconfigurations nobody noticed because each one, in isolation, looked small.

The MSSP needed a technical partner who could do more than a checklist scan. They needed someone who would actually try to break the environment the way a real adversary would, who could chain findings together into a kill chain rather than list them independently, and who could work inside the MSSP’s partnership with the end client without creating friction. The MSSP’s brand was the brand the city saw. Our job was to make sure the testing work under that brand was as rigorous as anything the city would get from a larger firm, while the MSSP maintained the relationship they’d built.

The Approach

The engagement covered external perimeter testing, internal network testing with an assumed-breach starting point, and targeted testing of the administrative infrastructure that made the environment tick. We followed the PTES methodology we follow on every pentest: intelligence gathering, threat modeling, vulnerability analysis, exploitation, and post-exploitation.

The initial phase surfaced a set of individually modest-looking findings. None of them would have triggered a critical severity on their own. An unprotected NFS share accessible on the internal network. An internal application that authenticated against the domain and kept its data in a PostgreSQL database. Legacy backups of that database sitting, forgotten, on the open share. A handful of these kinds of findings exist in most environments of any real size. Tools flag them. They rarely get fixed because none of them looks urgent.

What mattered was the chain. From an initial internal foothold, we reached the unprotected NFS share and pulled down the legacy PostgreSQL backups it was hosting. Those backups were dumps of an internal application that authenticated users against Active Directory. Buried in that legacy data were domain credentials that, when extracted and tested, turned out to still be valid. Those valid credentials gave us initial authenticated access to the domain.

From that foothold, Active Directory enumeration surfaced unconstrained-delegation misconfigurations on specific systems in the environment. Unconstrained delegation is one of the classic high-impact Active Directory misconfigurations: when abused, it lets an attacker coerce privileged authentications and capture ticket-granting tickets that can be replayed to impersonate those accounts (see MITRE ATT&CK T1558 for the broader Kerberos-abuse family). We chained the initial access into that abuse path, escalated to domain admin, and from there moved laterally to critical systems across the network. By the end of the path, we had proven administrative access to the city’s GIS, Records, and E911 systems — exactly the kinds of systems a municipal adversary would target.

Each individual finding along the way was a story the environment could tell itself. The chain was the story attackers would actually write. We documented the chain as a kill chain, not as a list of findings, so the MSSP and the city could see exactly how a real breach would unfold, exactly where each link sat, and exactly where the chain could be broken.

The Outcomes

We identified a complete attack path demonstrating full organizational takeover and documented it with specificity: the misconfiguration at each link, the technique we used, the control that should have caught it and why it didn’t, and the remediation that would break that specific link of the chain. At the far end of the path sat administrative access to the city’s GIS, Records, and E911 systems — services that residents and responders depend on every day and that a real adversary in this position could have disrupted, exfiltrated from, or held at ransom.

Then we worked with the MSSP and the city’s internal team on remediation. This is the part a lot of pentest firms skip. The report lands, the findings are in the backlog, and the MSSP or internal team is left to figure out the prioritization on their own. We didn’t disappear after the report. We worked through the priority order, answered the technical questions the team had about specific remediations, reviewed the proposed fixes before they went into change windows, and made ourselves available for the calls where the city’s IT leadership needed to explain to non-technical decision-makers why specific remediations mattered.

Each remediation was verified. We went back through the original attack path and confirmed that the specific technique we’d used no longer worked. Where a remediation introduced a new configuration, we tested that configuration. By the time the engagement closed, the kill chain was broken in multiple places. The critical attack path that would have let an attacker walk through the environment unopposed was no longer available.

The MSSP retained the relationship with their end client having delivered demonstrable security improvement. The city closed a critical risk that had existed in the environment for some time without being noticed. The findings were mapped to the CIS Top 18 controls, which made them easy for the city to track against an established framework and easy for the MSSP to reference in their ongoing security conversations with city leadership.

This engagement is the kind of work automated scanning cannot replicate. A scanner would have flagged each misconfiguration as modest. Only a human with access, time, and motivation chains modest findings into a kill chain. Municipal networks need that kind of testing because adversaries run that kind of testing against them every day.