Inside a Red Team Engagement: How We Breached a Hardened Network
Red TeamActive DirectoryLateral Movement

Inside a Red Team Engagement: How We Breached a Hardened Network

A walk-through of a real-world red team operation — from initial recon to domain compromise — and the misconfigurations that made it possible.

S

Sujith Rasnayaka

April 1, 2026

9 min read

Red team engagements are not penetration tests with extra steps. They are full-scope adversarial simulations designed to test detection and response, not just technical controls. This post walks through a sanitized account of a recent engagement against a Fortune 500 client — every finding was disclosed and remediated.

Scope and Rules of Engagement

The client operated a hybrid environment: on-premises Active Directory synchronized to Azure AD, with a mix of legacy Windows Server 2012 R2 hosts and modern Windows 11 endpoints. Our rules prohibited physical access, social engineering of customers, and any actions impacting production availability.

Everything else was in scope.

Phase 1: External Reconnaissance

We began with passive OSINT — LinkedIn for employee names and technology indicators, Shodan for externally exposed services, and certificate transparency logs for subdomain enumeration. Within four hours we had:

  • 47 valid employee email addresses
  • 12 externally reachable hosts, including a legacy VPN concentrator on an end-of-life firmware version
  • A staging subdomain exposing a Git repository with hardcoded AWS credentials

The AWS credentials were rotated before we could pivot, but the Git exposure demonstrated that secrets management was not enforced in the CI/CD pipeline.

Phase 2: Initial Access

The VPN concentrator ran an unpatched version susceptible to an authentication bypass (CVE details omitted per disclosure policy). Using a public PoC, we obtained an authenticated session within the internal network without valid credentials.

From that foothold, we ran BloodHound to map AD relationships. The results were striking: a service account with unconstrained delegation rights had been left with a weak password. Kerberoasting yielded the hash in eleven seconds. Password cracking took three minutes.

Phase 3: Lateral Movement and Domain Compromise

Armed with the service account, we identified a path from that account to a tier-zero asset — the domain’s backup operator group — via nested group membership. Pass-the-ticket gave us interactive access to the domain backup server, and from there a DCSync attack extracted all domain credential hashes within the engagement window.

Total time from initial access to domain compromise: 14 hours.

What the Client Fixed

  1. VPN patching cadence — moved to a 72-hour SLA for critical CVEs
  2. Unconstrained delegation — removed from all service accounts; migrated to Resource-Based Constrained Delegation
  3. Password policy — enforced 20-character minimum for service accounts with automated rotation via CyberArk
  4. BloodHound continuous monitoring — deployed BloodHound Enterprise for ongoing AD attack path analysis

The hardest part of presenting these findings was not the technical explanation — it was communicating that their controls had worked exactly as designed, and that the design itself needed to change.

Back to Blog