Cloud and Active Directory are often assessed as separate environments. An attacker does not respect that boundary. A managed identity can read a domain secret. A cloud VM can reach a domain controller over a private network. An Active Directory certificate or federation key can create a stronger identity. A database link can cross from one network and identity authority into another. The hard problem is not listing each technology. It is proving that one authority actually becomes the next. A reachable domain controller does not prove domain compromise, a readable vault does not prove its secret works, and a trust relationship does not prove the current user can reach a service across it. Pentest Copilot follows those transitions end to end. It identifies the starting authority, validates the bridge into the next identity system, confirms which host or service accepts the new authority, and records the resulting access without exposing authentication material or ticket material.
Consider one Azure VM. Its managed identity can read one scoped Key Vault secret.
The secret authenticates as one Active Directory service account.
That account is allowed to delegate only to one file service.
Kerberos accepts an impersonated user for that exact destination.
The same proof standard applies to five directory families:
Other hybrid routes prove:
Every finding records its starting identity, target service, accepted evidence, and restoration requirements.
The discovery and validation flow keeps cloud scope, private-network targets, directory identities, and permitted attack categories attached to the same assessment. A cloud discovery result cannot create a directory finding by itself, and a directory relationship cannot create a cloud finding until the destination accepts the bridged identity.
Discovery starts on the attached machine. For example, the Azure VM identity, resource scope, and subnet are recorded before Pentest Copilot tests Key Vault access or a private route to a domain controller.
That anchored context limits later discovery to reachable hosts and protocols.
Directory discovery adds only relationships that can continue a path:
Those inventories are joined by relationships. A VM is linked to its managed identity and subnet. A Key Vault secret is linked to the identity allowed to read it. A domain account is linked to the service where the authentication material was accepted. A delegating account is linked to the exact service principal name it may reach. A trust records direction and the domains on both ends. A certificate template records who may enroll, whether the requester may supply a subject, and whether the certificate can authenticate.
Hybrid paths are easy to overstate. For example, finding an Entra Connect setting proves that synchronization exists only if there is an active connector and reachable sync server. It does not prove that connector authentication material can be extracted. Finding a trust proves a relationship between domains, but not that the current user can obtain a service ticket or run a command in the other domain.
The assessment therefore requires three kinds of evidence:
| Evidence layer | Question answered | Example |
|---|---|---|
| Configuration | Does the relationship exist? | A service account is configured for constrained delegation to one file-service principal |
| Authorization | Can the current identity use the relationship? | The machine identity can read the scoped vault authentication material for that service account |
| Functional result | Did the target accept the transition? | Kerberos issued the required tickets and the named file service accepted them |
The first path began with a managed identity attached to an Azure VM. That identity could read one deliberately scoped secret from Key Vault. The secret belonged to a domain service account configured for protocol-transition constrained delegation.
Constrained delegation needs a little unpacking. Kerberos normally issues a service ticket that lets a user authenticate to one service. Protocol transition lets a trusted service obtain a Kerberos identity for a user who did not initially authenticate with Kerberos. Constrained delegation then limits where that service may act for the user. For a valid finding, the delegation target was one named file-service principal, not every host in the domain.
The assessment first used the VM identity to read the vault secret in memory. It authenticated to the domain as the delegating service account, requested the protocol-transition ticket for the selected privileged user, then requested a service ticket for the exact file service. Finally, it accessed a bounded marker in the domain's shared policy area.
| Step | Security boundary crossed | Proof retained |
|---|---|---|
| 1 | Azure VM to Key Vault | Managed identity and selected secret version, with no secret value |
| 2 | Vault authentication material to AD service account | Successful domain authentication as the exact delegator |
| 3 | Delegator to privileged user | Accepted protocol-transition and constrained-delegation tickets |
| 4 | Privileged user to file service | Exact service identity and bounded file result |
Passwords and Kerberos tickets are kept out of assessment output and are never written to persistent assessment output. Pentest Copilot reports the path only after the target service, not merely the domain controller, accepts the impersonated identity.
Impact: compromise of one cloud VM became access to an internal service as a stronger Active Directory user. The bridge existed because the machine identity could read the delegator's authentication material and the delegation target was useful.
A representative object-control path begins with a directory object where the source principal has full control. The assessment reads the original state, changes the target user password through the granted permission, authenticates as that user, proves one bounded service action, and restores the original state without exposing rollback material.
The path works because Active Directory access-control entries govern identity changes.
Relevant rights include:
Each right matters only when the resulting change produces an accepted identity or service action.
This path was not created from an isolated “GenericAll” edge. The source principal, target user, directory scope, reachable service, and rollback requirement all had to be present. If the rollback secret was missing, the action failed closed instead of leaving the account changed.
Impact: a directory permission became verified identity takeover. Defenders should review control over identity objects, not only membership in privileged groups, and alert on password resets, ownership changes, ACL rewrites, shadow authentication material, and delegation changes.
A domain or forest trust tells Kerberos when one domain may rely on another. It does not make every account privileged on both sides. Trust direction, selective authentication, group membership, service reachability, and the requested service principal all affect the result.
A representative trust path connects two private domains joined by an external trust. The assessment started with a scoped source-domain authentication material. It requested a referral ticket from the source domain, followed the referral into the trusted domain, obtained a service ticket for the exact target host, and used Kerberos-authenticated SSH to run one fixed command as the selected proof user.
The proof retained the source domain, destination domain, ticket types, service principal, target host, and command result. It did not return the password or ticket cache. A discovered trust without the cross-domain membership and reachable target would not have created the attack path.
Impact: one domain identity crossed the configured trust and executed on a host in the other domain. The result shows the true blast radius of the trust rather than treating the trust object itself as compromise.
Active Directory Certificate Services can issue certificates that work as logon authentication material. A dangerous template can allow a low-privileged requester to supply another user's identity while also permitting client authentication. This family is commonly called ESC1.
The assessment required the complete condition: a reachable certification authority, an enabled template, enrollment permission for the source, requester-supplied subject information, client-authentication use, and a known stronger user in the same domain. It requested a certificate naming the selected privileged account, authenticated with that certificate, and ran a fixed WMI proof on the approved target.
The certificate and derived authentication material were handled as secrets. The report contains the affected identities and accepted authentication result, not the certificate's private key or the resulting authentication hash.
Impact: enrollment permission became authentication as a stronger directory identity. Defenders should disable requester-supplied identities where they are not required, restrict enrollment, require approval for sensitive templates, and monitor certificate requests whose requested identity differs from the requester.
Every Active Directory domain has a special account used to sign Kerberos ticket-granting tickets. If its secret material is compromised, an attacker can forge a ticket for a chosen identity. The forged ticket is a Golden Ticket. Resetting an ordinary user password does not invalidate that authority.
A Golden Ticket path begins only when the assessment has authorized access to scoped domain ticket-signing material. The assessment forged an AES ticket for the exact selected privileged principal, used Kerberos-only WMI against the selected host, verified the principal and hostname, and completed an approved command as the Windows system account to demonstrate the resulting execution boundary.
Rollback removes the temporary service, process, loader, package, archive, and marker. Pentest Copilot confirms that those artifacts are absent while preserving the security finding. The ticket-signing key, ticket cache, and command script remain excluded from persistent output.
Impact: compromise of the domain's ticket-signing authority became domain-wide identity forgery and system-level execution. Recovery requires rotation of the domain ticket-signing secret according to the established two-reset procedure, investigation of issued tickets and persistence, and cleanup of affected hosts.
Not every hybrid route ends in Active Directory. Pentest Copilot also follows security authorities that cross providers or cross service boundaries.
In the Azure-to-GCP secret bridge, an Azure VM identity read one scoped secret from Key Vault and authenticated to the intended GCP project. The authentication material was fingerprinted and withheld, and the GCP call was read-only. In the federation version, the Azure machine obtained an identity assertion from its metadata service, exchanged it through a GCP federation provider, impersonated the exact GCP service account, and completed a bounded project action without persisting the assertion or tokens.
The GCP linked-database path moved in the other direction. A Compute Engine identity read a scoped SQL secret from Secret Manager, authenticated to a source SQL Server, resolved the configured linked server, and executed a four-part query against a separate server and database. The result contained one row digest, not the authentication material or row value, and no database state changed.
Azure Files introduced an identity-and-storage persistence path. Microsoft Entra Kerberos for Azure Files relies on an application and service principal connected to the storage account. Pentest Copilot temporarily added authentication material to the exact application, used the resulting session to list and read a bounded file marker through the required file-share scope, and removed the temporary authentication material and restored the application baseline. Repeated baseline checks confirmed cleanup.
Impact: cloud secrets, federation, application registrations, and database links can each transport trust into a different provider or service. Their controls must be assessed as one chain, even when separate teams own each endpoint.
Pentest Copilot covers hybrid paths in four groups. A finding is reported only when the starting authority, bridge, destination, and functional result are all present.
| Capability | Starting control | Vulnerability identified | Required confirmation |
|---|---|---|---|
| Active Directory object control | GenericAll, GenericWrite, WriteDACL, ownership, password-reset, group, or delegation rights | A lower-privileged directory identity can take over a stronger user, group, or computer | The changed identity authenticates or performs the intended action, followed by restoration |
| Kerberos constrained delegation | A service account secret and an allowed destination service principal | The service can impersonate a selected user to the delegated service | Protocol-transition and service tickets are accepted by the exact destination |
| Domain or forest trust | A source-domain identity plus a usable trust direction | The identity can cross into a trusted domain or forest | Referral and destination service tickets lead to an accepted host or service action |
| Active Directory Certificate Services | Enrollment rights on a template that permits a stronger identity and client authentication | A requester can mint authentication material for another directory identity | The certificate authenticates as that identity and reaches the intended service |
| Golden Ticket class control | Domain ticket-signing material | Kerberos tickets can be forged for a chosen domain identity | The forged ticket is accepted for a bounded host action and temporary artifacts are removed |
| Cloud secret to internal identity | Workload identity access to Key Vault, Secret Manager, or another secret store | A cloud principal can recover authentication material that works against AD, a file service, or a database | The authentication material authenticates to the exact destination without entering the report |
| Private network pivot | Cloud workload execution plus VPN, peering, or private routing | A cloud foothold can reach an internal service that is not publicly exposed | The exact protocol and destination accept the connection and identity |
| Cross-cloud federation | An AWS, Azure, or GCP workload assertion trusted by another provider | One provider's machine identity can become an identity in another provider | The assertion is exchanged, the target identity is verified, and a bounded target action succeeds |
| Cross-cloud authentication material bridge | A cloud secret containing another provider's authentication material | One provider's workload can authenticate into another cloud scope | The second provider resolves the intended identity and permits the selected action |
| Linked database traversal | A database login with access to a linked server or external data source | A query crosses from a cloud database into another cloud or internal database boundary | A four-part or external query returns a bounded result from the destination |
| Azure Files Kerberos persistence | Control of the Entra application or service principal used by Azure Files | New application authentication material or a role can preserve file-share access | The new session reaches the intended share and the temporary authentication material is removed |
| Federation signing abuse | Access to an AD FS, SAML, OIDC, KMS, or certificate signing authority | Trusted assertions can be minted for a stronger cloud identity | The relying service accepts the assertion as the selected identity |
| Hybrid management execution | Control of Azure Arc, Automation Hybrid Workers, device management, or Application Proxy | A cloud management plane can execute on or expose an internal system | The enrolled endpoint, device, worker, or connector performs the exact action on the destination |
| Identity synchronization abuse | Control of Entra Connect, Cloud Sync, Pass-through Authentication, or Seamless SSO components | Synchronization or authentication infrastructure can expose authentication material, alter identity state, or approve cloud sign-ins | A connector, service, key, synchronized identity, and accepted cloud transaction complete the chain |
| Cloud-hosted AD authentication modification | Domain-controller control capable of changing authentication behavior | A Skeleton Key style change can accept an alternate password and potentially reach synchronized services | The modified authentication works and a separate synchronized or federated cloud transaction is accepted |
Several hybrid technologies are especially easy to report too early:
Pentest Copilot stops these paths until the functional prerequisites exist. This prevents architecture facts and configuration hints from being presented as successful compromise.
When part of a hybrid chain fails unexpectedly, Pentest Copilot preserves the successful earlier transition and the boundary that stopped the next one. It does not invent a fallback route or report the unfinished chain as end-to-end compromise.
Treat cloud-hosted domain controllers, certificate authorities, federation servers, sync servers, proxy connectors, Hybrid Workers, and database gateways as both cloud assets and identity-tier assets. Their cloud IAM, network paths, attached identities, local administrators, and directory permissions must be reviewed together.
Restrict workload identities that can read domain authentication material. Keep Key Vault access scoped to exact secrets and exact workloads. Review Active Directory object permissions, delegation targets, domain trusts, and certificate templates. Separate federation and synchronization administration from ordinary cloud-resource administration. Monitor service-principal authentication material, Azure Files Kerberos applications, linked-server definitions, cloud-to-cloud federation providers, and private network changes.
Most importantly, require proof across the boundary. A useful hybrid assessment should always answer: which starting identity was available, which trust or authentication material enabled the next step, which exact host or service accepted it, what stronger authority resulted, and what was restored afterward.
