Internal Network Penetration Test · PCI DSS v4.0 · Assumed Breach · Active Directory
Engagement at a glance
- Type: Internal network penetration test (assumed breach)
- Client: Organization operating a PCI Cardholder Data Environment (anonymized)
- Frameworks: PCI DSS v4.0, industry-standard penetration testing methodology
- Findings: 5 total (1 Critical, 1 High, 2 Medium, 1 Low)
- Headline issue: Unconstrained Kerberos Delegation on domain controllers (Critical), a realistic path to full Active Directory domain compromise
- Outcome: Overall risk rated Moderate; critical Active Directory, endpoint-detection, and authentication gaps identified with prioritized, PCI-mapped remediation
For any organization that stores or processes payment card data, the internal network is where a contained incident becomes a business-ending one. An attacker who lands on a single workstation should not be able to walk that foothold into the systems that support the Cardholder Data Environment (CDE). This is the story of how one organization asked Bluefire Redteam to test exactly that assumption, what our team found inside its Active Directory infrastructure, and why network segmentation alone was not enough to keep the PCI environment safe.
The client is not named at their request. Identifying details have been removed and technical specifics generalized in line with our confidentiality commitments. What follows is an accurate account of the engagement.
The client, in brief
Our client operates an environment that includes a PCI Cardholder Data Environment alongside its broader corporate network. Like most organizations subject to PCI DSS, they had invested in separating the systems that touch card data from the rest of the business, and they wanted independent proof that the separation held under pressure.
That responsibility shaped the engagement. For a business bound by PCI DSS, an internal weakness is not just an IT problem, it is a compliance and customer-trust problem. The client understood this, which is why they commissioned an independent internal network penetration test rather than relying on internal review alone.
The challenge
The client wanted a realistic answer to a specific question: if an attacker already had a foothold inside the corporate network, could they escalate privileges, move laterally, and reach the systems that support the PCI environment?
To answer it honestly, the test needed to start where real incidents often do, from inside. The brief was direct: assess the true security posture of the internal environment, prove which attack paths are actually reachable rather than list theoretical risks, and give the engineering and security teams a prioritized fix path mapped to PCI DSS.
Our approach
Bluefire Redteam ran the assessment as an assumed breach exercise. Testers were given controlled remote access, via AnyDesk, to two internal workstations that represented two very different starting points:
- A non-PCI workstation that was not domain joined and had no Endpoint Detection and Response (EDR) or managed detection monitoring.
- A PCI workstation that was domain joined and protected by EDR and managed detection controls.
Starting from both allowed the team to evaluate attack paths originating in the corporate network as well as inside the PCI segment, and to test the segmentation controls between one PCI network segment and three non-PCI segments.
Rather than run a checklist scan, the team worked the environment the way an internal attacker would. The methodology covered:
- Active Directory security configuration, including delegation, privileged accounts, and authentication services.
- Privilege escalation opportunities across internal systems.
- Lateral movement risks, including credential reuse and authentication relay conditions.
- Endpoint detection capabilities, including whether in-memory tooling and script execution triggered alerts.
- Network authentication security controls such as SMB signing.
- Segmentation controls between the PCI and non-PCI network segments.
- A data exfiltration simulation using commonly permitted outbound channels.
What the PCI DSS penetration test found
The PCI DSS penetration test surfaced five findings: one Critical, one High, two Medium, and one Low. A full domain compromise was not achieved within the testing window, but the combination of weaknesses identified created a realistic path an attacker could follow to escalate and expand access. The most consequential issue sat at the center of the environment’s trust model, in Active Directory itself.
The headline issue: Unconstrained Kerberos Delegation on domain controllers (Critical)
Unconstrained Kerberos Delegation was configured on domain controllers. This is one of the most dangerous configurations in an Active Directory environment. It allows Kerberos Ticket Granting Tickets (TGTs) to be cached in memory on the delegated system. If an attacker gains administrative access to such a system, those tickets can be extracted and reused to impersonate privileged users.
In practice, that means a single well-placed compromise could be walked into full administrative control of the Active Directory domain. Because the same Active Directory backs both corporate and PCI systems, domain-level control is not an abstract risk, it is a direct route toward the environment that supports card data. This is a textbook example of why manual penetration testing matters: the misconfiguration is invisible to a vulnerability scanner, and only an operator who understands Kerberos internals recognizes how a legitimate delegation setting becomes a domain-takeover primitive.
The supporting cast
The remaining findings each expanded the attack surface on their own, and, more importantly, made the critical finding easier to reach and weaponize when chained:
- Endpoint detection failed to detect AMSI bypass and in-memory PowerShell execution (High). Testers were able to run reconnaissance and tooling in memory without triggering endpoint alerts, meaning the activity that precedes privilege escalation could happen quietly.
- SMB signing not enforced (Medium). Without SMB signing, NTLM relay attacks become possible under certain network conditions, giving an attacker a practical lateral-movement technique.
- No Local Administrator Password Solution, LAPS (Medium). Shared or reused local administrator credentials increase the risk of credential reuse and lateral movement between systems.
- PowerShell security restrictions not enforced (Low). Unrestricted script execution does not enable compromise on its own, but it smooths the path for post-exploitation once an attacker has a foothold.
As part of the engagement, the team also simulated data exfiltration from both the non-PCI and PCI segments. Internal systems were able to transmit data to external systems over commonly permitted channels, including HTTP and DNS, and the DNS-based exfiltration attempt succeeded. That confirms that without adequate egress monitoring, an attacker with internal access could move data out quietly.
The risk to the PCI environment
Network segmentation did its job in one important respect: it restricted direct connectivity between non-PCI systems and the PCI network segment, which limits the exposure of systems inside the Cardholder Data Environment.
But segmentation of the network is not the same as isolation of identity. The PCI environment relies on the same Active Directory authentication infrastructure as the rest of the business. A compromise of domain-level or privileged credentials could therefore let an attacker authenticate across multiple segments using legitimate credentials, including toward systems that support the CDE. Combined with the endpoint-detection gaps and the internal authentication weaknesses, an attacker could execute tooling and move laterally without immediate detection.
The PCI segment does benefit from stronger controls than the corporate network, including EDR and managed detection monitoring, which give defenders more visibility inside the CDE. That difference matters, and it is worth extending.
Outcomes
- 5 findings identified across Active Directory configuration, endpoint detection, internal authentication, and system hardening, each with prioritized remediation guidance.
- A Critical domain-takeover path (Unconstrained Kerberos Delegation) surfaced and explained before an attacker could find it.
- Findings mapped to PCI DSS v4.0 control requirements, so the security and compliance teams could act from one shared picture.
- An assumed-breach attack-path analysis showing exactly how initial access could progress to privilege escalation, lateral movement, and potential impact on the PCI environment.
- A validated data-exfiltration path over DNS, giving the client concrete evidence to justify tighter egress monitoring.
- Overall internal risk rated Moderate, with a clear, sequenced path to reduce it.
The recommended next step is straightforward: remediate the Active Directory, endpoint-detection, and authentication findings, then re-test to confirm the fixes hold. Bluefire Redteam performs independent patch-verification testing so that a finding marked resolved is proven resolved, not assumed.
Why this matters for PCI and enterprise security teams
Two lessons travel well beyond this one environment:
- Segmentation is not isolation if identity is shared. Separating networks limits direct connectivity, but a single Active Directory that spans PCI and non-PCI systems means one privileged-credential compromise can cross the boundary using legitimate authentication. Harden and monitor the identity plane, not just the network.
- A dangerous configuration plus weak detection equals silent compromise. Unconstrained delegation is serious on its own. Paired with endpoint controls that miss in-memory tooling and AMSI bypass, an attacker can escalate quietly. Configuration hardening and detection engineering have to advance together, not one without the other.
For any organization bound by PCI DSS, an internal network penetration test that starts from an assumed breach, plus re-testing after remediation, is not a compliance checkbox. It is how you find out whether your segmentation actually protects the data it is meant to protect.
Work with Bluefire Redteam
Bluefire Redteam is an AI-augmented offensive security consultancy. We deliver internal and external network penetration testing, red team operations, PCI DSS-aligned assessments, cloud and AI/LLM security testing, and remediation validation for BFSI, enterprise, and government clients worldwide. Every engagement is built to prove impact, not just list issues, and to confirm the fix actually holds.
Considering an internal network penetration test for your PCI or enterprise environment?
Frequently Asked Questions (FAQ) - Internal Network Pentest Case Study
- What is an internal network penetration test?An internal network penetration test evaluates what an attacker could do from inside your network, typically starting from a compromised workstation or a set of internal credentials. It focuses on privilege escalation, lateral movement, Active Directory security, and the controls that should stop an intruder from reaching critical systems.
- What is an assumed breach penetration test?An assumed breach test begins from the position an attacker reaches after initial access, for example a foothold on an internal workstation. Instead of spending the engagement getting in, testers focus on what happens next: how far the foothold can be expanded and whether defenders detect it.
- What is Unconstrained Kerberos Delegation, and why is it dangerous?It is an Active Directory setting that lets a system cache users' Kerberos tickets in memory. If an attacker gains administrative access to that system, those tickets can be extracted and reused to impersonate privileged users, which can lead to full domain compromise. It should be replaced with constrained or resource-based delegation wherever possible.
- Does an internal network penetration test help with PCI DSS?Yes. Internal testing helps validate segmentation and access controls around the Cardholder Data Environment, and findings can be mapped to PCI DSS v4.0 requirements to support compliance and remediation planning.
- Do you re-test after fixes are applied?Yes. Bluefire Redteam performs independent patch-verification testing to confirm that each finding is genuinely resolved before an engagement is considered closed.
- How often should we run an internal network penetration test?At minimum annually, and after significant infrastructure changes, Active Directory changes, or major releases. Regulated environments often benefit from more frequent testing.