What Internal Pentests Miss in Hybrid Identity Environments
Most internal network pentests still run against a scope written when the environment was Active Directory on its own. In organisations that have since federated Okta or Entra ID to AD, that scope leaves a documented path to Domain Admin outside the engagement. An internal network pentest hybrid identity scope, the kind that covers the identity provider alongside the directory it synchronises to, closes that gap. The rest of this piece walks through where AD-only scope falls short, the specific Okta-to-Domain Admin attack path a human tester follows, what hybrid identity testing actually checks, and how to update the next SOW.
Where AD-Only Scope Falls Short
A pentest SOW drafted three years ago, when the environment was AD-only, tends to list Kerberoasting, NTLM relay, Active Directory Certificate Services misconfiguration, and lateral movement across member servers. All of these remain valid. What they no longer cover on their own is the identity provider that now sits upstream of the directory.
Hybrid identity penetration testing exists because the attack surface has moved. The decisions that used to live in Domain Controllers now live partly in Okta, Entra ID, or any SAML or OIDC provider the organisation has stood up for workforce single sign-on. When the engagement does not enumerate the IdP, it does not see the push and provisioning rules that reach back into AD.
The question CTDefense hears from CISOs reviewing their own SOW: does an internal pentest cover Okta authentication? In most cases, no. The scope language names AD, member servers, and workstation egress, and the testers stay inside that boundary. Push rules, SAML assertion trust, and the AD synchronisation service account’s privileges inside sensitive AD groups all go untested unless the SOW asks for them.
Third-party integrations are not a minor part of the breach picture. The Verizon 2026 Data Breach Investigations Report found “breaches involving a third party now accounting for 48% of all breaches.” A cloud identity provider is a third-party integration sitting directly in the authentication path for most workforce logins. An engagement that avoids it is avoiding the vector in nearly one in two incidents.
The team covers this territory in its wider work on the AD attack paths that annual pentests miss; hybrid identity is the next layer out from that same set of gaps.
The Okta-to-Domain Admin Path
The clearest way to explain the gap is to walk a single path from an Okta user to Domain Admin, end to end. This is the Okta to Domain Admin attack path a human tester reproduces when the IdP is in scope.
The anchor finding sits in SpecterOps’ March 2026 research. In Discovering Unexpected Okta Attack Paths with BloodHound, the researchers document that Okta’s own recommended configuration places synchronisation service accounts inside Domain Admins in AD. That is the vendor’s documented default, not a customer misconfiguration. Any organisation that followed the Okta deployment guide has an AD account, used by the Okta AD agent, holding Domain Admin privileges.
The path from there is short. How does the Okta sync account reach Domain Admin? It is already there. The question for the tester is who can write memberships through Okta into AD. If an attacker, or a compromised Okta administrator, or a user with sufficient control over Okta push rules, can add their own account to an AD-side destination that the sync agent writes, that account inherits whatever privilege the destination already carries. The sync account itself does not need to be compromised. The membership path does the work.
The chain in a typical hybrid environment reads: compromise an Okta user with push rights, or chain through an app admin role, push an attacker-controlled AD-mapped identity into sensitive AD groups, let the sync agent write the change, authenticate to a Domain Controller as that identity, and run DCSync. The pentest reproduces each hop and documents where detection stops.
None of this is a zero-day. The configuration is published. The attack graph is simply the one the AD-only test does not draw.
What Hybrid Identity Testing Checks
Identity provider security testing is the category label for the work; the content of the scope is specific. When CTDefense scopes an internal network pentest for a hybrid environment, the engagement examines the following in addition to the traditional AD surface:
- Synchronisation service account privileges. The AD account used by the Okta or Entra Connect agent is read against every security principal it belongs to, with particular attention to Domain Admins, Enterprise Admins, and any custom tiered-admin containers.
- Okta push rules and app-assignment logic. The team maps which Okta groups write into which AD destinations, and who can modify those rules through the Okta admin console or API.
- SAML and OIDC assertion trust configuration. The engagement reviews signing certificates, assertion issuers, and the applications that trust assertions from the IdP; a mis-scoped trust can let a compromised IdP tenant impersonate users into on-prem apps.
- JIT provisioning paths. Just-in-time user creation routes are followed to see what AD attributes an IdP-created user receives and whether any of those routes bypass approval.
- SCIM endpoint permissions. SCIM provisioning endpoints are tested for authentication strength and for which memberships they can set, since a weakly protected SCIM endpoint is a direct write path into the directory.
The reason this list matters at the scoping stage, not at the report stage, is that detection is the hard part. A sync agent writing a membership change looks exactly like a sync agent doing its job. SpecterOps acknowledged this directly in BloodHound Enterprise Expands Beyond Microsoft, announcing the “first three official OpenGraph extensions that expand automated attack path analysis beyond the Microsoft ecosystem” because Okta, GitHub, and macOS are now live enterprise attack surfaces. The team’s thinking on why identity-aware detection is part of this conversation sits alongside the testing checklist; the EDR does not see the attack graph without identity context.
Updating Your Next Internal Pentest SOW
The practical question is what to change in the next SOW. Three edits cover most of the gap.
- Name the identity provider explicitly in the systems-in-scope section. “Okta tenant X” or “Entra ID tenant Y” with the tenant identifier, not just “Active Directory”.
- Add a sub-section listing the five items above: sync account privileges, push rules, assertion trust, JIT provisioning, SCIM endpoints.
- Grant the test enough credentials to enumerate the IdP’s admin surface read-only, so the team can trace push rules without needing a compromised administrator in the chain. Read access, not write.
Upcoming audits sharpen this. For organisations preparing a NIS2 penetration testing scope review, or an ISO 27001 recertification where the control catalogue now reflects federated identity, a pentest report that only names AD looks thin against the auditor’s checklist. A report that walks the Okta-to-AD boundary and documents what was tested there carries more weight with regulators and with the board.
CTDefense includes hybrid identity in the scope of every Internal Network Penetration Testing engagement where the client has a federated IdP alongside on-prem AD. Organisations in Finance, Healthcare, Technology, and Manufacturing that have commissioned AD-focused tests for years, and that have added Okta or Entra ID since the last report, are the ones most likely to be reading a clean pentest result that does not quite reflect the current blast radius. Treating the IdP as part of the internal network, rather than a separate SaaS asset, is the straightforward fix.