Hybrid Active Directory Attacks: How to Detect and Contain Kerberoasting, AD CS Abuse and Golden Ticket

Hybrid Active Directory is where most enterprise identity attacks succeed. Attackers don't need zero-days — they need a service account with a weak password, a misconfigured certificate template, a forgotten Domain Admin session. From there, the chain Kerberoasting → AD CS abuse → Golden Ticket gives them persistence that survives password resets, MFA rollouts and even DC reboots.

This is a technical playbook for SOC, IR and identity teams running hybrid environments (on-prem AD + Entra ID). It covers what the attack chain actually looks like, what to log, what to alert on, how to harden before an incident, and what to do in the first hour after detection. It's the field guide we wish we had the first time we ran into a real Golden Ticket in production.

Executive summary

Hybrid AD attacks rarely come from sophisticated exploits. The common path is: compromised user → Kerberoasting to obtain a service account hash → cracking offline → privileged AD lookup → AD CS template abuse to issue a fake certificate → Domain Admin → Golden Ticket persistence. Every step is detectable with the right telemetry, but most organisations don't have it configured.

Three priorities pay back faster than anything else: (1) high-fidelity detection rules tuned for these specific TTPs, (2) hardening of AD CS templates and Tier 0 accounts before any incident, (3) a tested containment runbook that doesn't require executive approval at 3am. This article walks through all three.

What "Active Directory abuse" means in a hybrid environment

AD abuse is the chain of techniques an attacker uses to move from an initial foothold to controlling identity infrastructure — and through it, the rest of the estate. It's distinct from generic malware: the attacker uses legitimate AD protocols (Kerberos, LDAP, ADCS enrollment) in ways the protocol allows, just at the wrong time, by the wrong principal, against the wrong target.

In a hybrid environment, identity flows in both directions. On-prem AD synchronises to Entra ID via Entra Connect, conditional access policies in Entra govern access to cloud workloads, and federation may extend on-prem credentials to SaaS. A successful AD compromise becomes a cloud compromise in minutes. This is the cross-perimeter problem our IAM and cloud posture review is built to surface before an incident exposes it.

Anatomy of a real attack chain

A realistic sequence we see in incident response:

• Initial access: phishing or AiTM token theft gets the attacker a low-privilege user session.
• Internal reconnaissance: LDAP queries enumerate service accounts with SPNs (SPN = Service Principal Name).
• Kerberoasting: TGS tickets for those service accounts are requested, captured and cracked offline.
• Privilege walk: the cracked service account has unexpected rights — often through nested group membership nobody audited.
• AD CS abuse: the attacker enrols a certificate via a misconfigured template (ESC1/ESC8), impersonating a Tier 0 account.
• Domain Admin: the certificate authenticates as Domain Admin without needing the password.
• Golden Ticket: the attacker dumps the KRBTGT hash and creates Kerberos tickets at will, surviving password resets.
• Hybrid pivot: Entra ID identities synchronised from the compromised AD give cloud access; Entra Connect itself becomes a target.

Time from initial access to Domain Admin in unprepared environments: hours to a few days. Time to detection without the right telemetry: weeks to never.

Kerberoasting: why it's still relevant in 2026

Kerberoasting exploits a Kerberos protocol feature: any authenticated user can request a service ticket (TGS) for any service principal. The ticket is encrypted with a key derived from the service account's password. Take the ticket offline, crack the password, walk in as the service account.

What hasn't changed since the technique was disclosed in 2014: service accounts still use weak passwords because nobody rotates them, many still run with Domain Admins or equivalent privileges, and AES isn't always enforced (RC4 remains the cracking-friendly cipher of choice for attackers). What has changed: cracking hardware is faster, wordlists are bigger and attackers automate the entire chain.

Detection signals for Kerberoasting

The high-confidence detection combines two signals:

• Event ID 4769 (Kerberos service ticket requested) with ticket encryption type 0x17 (RC4-HMAC) for a service that supports AES.
• Burst of TGS requests for many distinct SPNs from a single account in a short window (typical Kerberoasting tool behaviour).

Tuning is critical: legitimate workstations request TGS tickets constantly, so baseline by user and source IP. Alert on volume anomalies (>20 distinct SPNs in 5 minutes from non-DA accounts is a good starting threshold), not on isolated events. Feed alerts to your managed SOC for triage with full context.

AD CS abuse: the risk most organisations don't monitor well

Active Directory Certificate Services (AD CS) misconfigurations have become the dominant privilege escalation path since the SpecterOps Certified Pre-Owned whitepaper made the ESC1–ESC11 vulnerability classes well-known in 2021. The most damaging in our experience:

• ESC1: certificate templates that allow the requester to specify the Subject Alternative Name (SAN) — letting an attacker request a cert "as" any user, including Domain Admins.
• ESC4: weak template ACLs that allow a low-privilege user to modify the template and enable ESC1 conditions.
• ESC8: AD CS web enrollment over HTTP with NTLM relay — turns any coercible authentication into a Domain Admin certificate.

These aren't theoretical. We've seen organisations with AD CS templates inherited from 2008 that no one has reviewed since. The template runs on the CA, the CA is in the forest root, and the privilege path is one PowerShell command long.

Detection signals for AD CS abuse

Native AD CS auditing is light. Useful events to collect and watch:

• Event ID 4886/4887/4898 (CA: certificate request received/approved/issued) — alert on any issuance to non-standard accounts or where SAN differs from the requester.
• Event ID 4768 (Kerberos pre-auth) with certificate authentication where the certificate was just issued — short window between issuance and use is suspicious.
• AD CS configuration changes (template ACL modifications, new template publication) — should be rare events; alert on every one.

If you don't have AD CS audit configured to collect these events, fix that first. Detection rules without telemetry are theatre.

Golden Ticket: advanced persistence in Active Directory

A Golden Ticket is a Kerberos TGT (Ticket Granting Ticket) forged by the attacker using the KRBTGT account hash. Because the TGT validates against the KRBTGT key, and the KRBTGT password is rotated almost never in most organisations, a stolen KRBTGT hash gives the attacker the ability to mint valid Kerberos tickets for any user, any service, for years.

Golden Tickets bypass password changes, MFA, account disable. They only stop working when KRBTGT is rotated — which itself must be done twice in sequence, with a delay between rotations, to invalidate all outstanding tickets without breaking authentication. Most organisations don't have a tested KRBTGT rotation procedure. They should.

Detection signals for Golden Ticket

Forged tickets are designed to look legitimate, but they leave traces:

• Event ID 4624 (logon) with logon type 3 and a TGT lifetime longer than your policy allows (default forged TTL: 10 years).
• Event ID 4769 for accounts that don't exist in AD, or with SIDs that don't match the username — classic Mimikatz default behaviour.
• Authentication activity from KRBTGT itself outside of regular ticket-renewal patterns.
• Discrepancies between expected logon times (working hours, typical sources) and observed activity for high-privilege accounts.

Detection is hard without a baseline. This is where threat hunting earns its place: structured queries that look for forged-ticket patterns over weeks of telemetry, not just real-time alerting.

Hybrid identity: where AD and Entra ID meet

Entra Connect (formerly Azure AD Connect) is the bridge. Compromise of Entra Connect means access to AD password hashes for synchronised accounts and the ability to write back to AD in some configurations. It also means access to seamless SSO keys, federation certificates and the Entra service account itself.

Risks specific to hybrid:

• Pass-through Authentication (PTA) agents handle live credentials — compromise gives the attacker visibility into every sign-in.
• Password Hash Sync (PHS) replicates AD password hashes to Entra — a Golden Ticket in AD means cloud access through synced identities.
• Federation (ADFS or third-party) involves certificates that, if stolen, let the attacker mint SAML tokens for any user — Golden SAML.
• Entra Connect runs as a tier 0 system in practice — treat it as such, even if your operations team doesn't yet.

Hardening the bridge is as important as hardening AD itself. Cover both in your Microsoft 365 security audit scope.

Recommended telemetry sources

Detection depends on collection. Minimum sources for an effective AD security programme:

• Domain Controller security logs (4624, 4625, 4768, 4769, 4776, 4738, 4756).
• AD CS CA logs (4886-4898) and template ACL changes.
• Entra Connect logs (sign-in, configuration changes, agent activity).
• Entra ID sign-in logs and audit logs (especially Conditional Access decisions and risk events).
• EDR telemetry from DCs and from Entra Connect host — process creation, command line, parent process.
• Network telemetry: Kerberos traffic patterns to DCs, LDAP queries volume, DNS lookups for _kerberos._tcp records.

If these aren't all flowing to your SIEM, detection rules will miss half the chain. The investment is foundational, not optional.

Preventive hardening: reducing surface before the incident

Detection alone is not a strategy. The compounding wins come from reducing attack surface so the chain breaks earlier:

• Service accounts: enforce 25+ character passwords (or use Group Managed Service Accounts, gMSA, that rotate automatically), require AES, remove from privileged groups by default.
• AD CS: audit all templates for ESC1-ESC11 conditions, disable web enrollment over HTTP, enforce EPA (Extended Protection for Authentication), restrict template enrollment ACLs to the minimum needed.
• KRBTGT: rotate twice per year as standard, document the procedure, test it. After any suspected compromise, rotate immediately (twice, with 10-hour delay between rotations).
• Tier 0 isolation: Domain Admins, Enterprise Admins and KRBTGT should never log into anything but DCs. Use Privileged Access Workstations (PAW) and break-glass procedures.
• LAPS: deploy Windows LAPS so that local admin accounts on workstations and servers have unique, rotating passwords.
• Conditional Access: in Entra ID, block legacy authentication, require phishing-resistant MFA for privileged roles, enforce device compliance.

Map this to your existing vulnerability management programme: identity weaknesses aren't CVEs, but they should be tracked, prioritised and reduced with the same rigour.

Containment: what to do when the chain has already started

When detection fires on suspected AD compromise, speed matters more than perfection. A practical four-phase containment model:

Phase 0: activation and initial scope

Within 15 minutes of high-confidence alert: declare incident, page on-call IR, assemble bridge with identity team and security lead. First questions: which accounts are confirmed compromised, what's the timeline, what other systems show suspicious authentication. Don't rotate anything yet — visibility first, action second.

Phase 1: tactical brake

Within the first hour: disable confirmed-compromised accounts (not delete — preserves forensic value), block source IPs at perimeter and Conditional Access, force re-authentication on all sessions from suspicious locations. Snapshot DCs and Entra Connect for offline analysis. Engage incident response if the scope exceeds what your team can handle.

Phase 2: persistence neutralisation

Within 24-48 hours: rotate KRBTGT twice (with the required delay), revoke and reissue all certificates from any compromised CA template, rotate Entra Connect service account, rotate federation certificates if applicable. Audit Domain Admins group membership and remove anything added in the suspect window. Hunt for additional persistence (scheduled tasks, services, WMI subscriptions, GPO modifications).

Phase 3: safe recovery

Within 1-2 weeks: restore from clean backups if integrity is uncertain, validate that all persistence mechanisms have been removed, baseline traffic and authentication patterns to confirm "clean" state, hand off to threat hunting for sustained monitoring of the previously-compromised paths.

If you don't have a written runbook for this today, that's the first thing to write. A 24/7 incident response retainer gives you both the runbook and the experienced hands when minutes count.

Recommended use cases for SOC and Blue Team

Concrete detection rules to prioritise:

• Burst of distinct SPN TGS requests from a single account.
• RC4-encrypted TGS for AES-capable services.
• Certificate issuance with SAN differing from requester identity.
• Kerberos authentication from accounts not present in AD (forged TGT signal).
• DC service account password resets outside maintenance windows.
• Entra Connect configuration changes outside scheduled change windows.
• Privileged AD group membership modifications without a corresponding approved change ticket.
• DCSync activity from non-DC sources (rare, high-confidence).

Validate each rule with red team / adversary simulation exercises. Detection rules that haven't been triggered by a real attacker behaviour during an exercise are detection rules you don't know work.

Metrics that actually matter

Vanity metrics for AD security: number of monitored accounts, number of rules deployed. Real metrics:

• Mean time to detect AD-targeted activity in a tabletop or exercise.
• Number of service accounts with passwords older than 90 days and group membership including any privileged group.
• Number of AD CS templates that allow SAN specification or have weak ACLs (target: zero).
• Time since last KRBTGT rotation (target: <180 days).
• Percentage of Tier 0 accounts logging into anything other than DCs or PAWs (target: zero).
• Number of high-confidence detection rules tested in the last quarter by adversary simulation.

If you can produce these numbers reliably and they're trending in the right direction, you have a programme. If you can't, you have hopes.

Common mistakes

Patterns we see repeatedly in environments that suffer AD incidents:

• Treating service accounts as set-and-forget — never rotated, never reviewed, always over-privileged.
• Deploying AD CS once and never auditing the templates again.
• Trusting Entra ID Conditional Access as the only line of defence while AD remains weak — federation makes both equally critical.
• Detection rules written but never tested against real adversarial behaviour.
• KRBTGT rotation labelled as "too risky" and indefinitely deferred — guaranteeing Golden Ticket persistence becomes permanent on first compromise.
• Treating Entra Connect as a normal server rather than as Tier 0 infrastructure.

A 90-day plan to raise maturity

Days 1-30: visibility and triage

Inventory all service accounts and their privileges. Audit all AD CS templates against ESC1-ESC11. Confirm KRBTGT rotation history. Verify telemetry collection is complete and flowing to SIEM. Deploy or tune the high-confidence detection rules listed above.

Days 31-60: hardening

Remove unnecessary service account privileges. Migrate to gMSA where possible. Disable or fix risky AD CS templates. Implement Privileged Access Workstations for Tier 0. Deploy LAPS if not already. Rotate KRBTGT twice if it has been >180 days since last rotation.

Days 61-90: validation

Run adversary simulation focused on the Kerberoasting → AD CS → Golden Ticket chain. Validate detection rules. Write or rehearse the containment runbook. Brief leadership with the metrics defined above and quantify residual risk for the next quarter.

Containment checklist (printable)

• Compromised accounts identified and disabled (not deleted).
• Source IPs blocked at perimeter and Conditional Access.
• DCs and Entra Connect snapshotted for forensics.
• KRBTGT rotated twice with required delay.
• Compromised CA templates revoked, certificates reissued.
• Entra Connect service account rotated.
• Federation certificates rotated if applicable.
• Domain Admins membership audited and cleaned.
• Additional persistence searched for and removed.
• Threat hunting handoff for sustained monitoring.
• Lessons learned documented and runbook updated.

How this connects to NIS2, DORA, ENS and ISO 27001

Identity attack chains aren't just a SOC problem — they map directly to regulatory and standards requirements:

• NIS2 Article 21: requires risk-based identity and access controls, incident detection and response. AD hardening and Kerberoasting detection are exactly that.
• DORA: explicit on identity protection, privileged access management and incident response for financial entities.
• ENS: control families on identification, authentication and protection of management infrastructure apply directly to AD and Entra Connect.
• ISO 27001 Annex A.5.15, A.5.17, A.8.2: access control, authentication information and privileged access rights — AD security is the operational implementation.

Building detection and hardening on this attack chain doesn't just reduce technical risk; it also produces the evidence auditors will ask for. Two birds, same investment.

Conclusion

Hybrid AD is the soft target most organisations don't realise they have. The good news: the attack chain is well-understood, the detections are documented, the hardening steps are clear. The bad news: most environments haven't done the work. The window between knowing what to do and doing it is where incidents happen.

Start with telemetry, then detection rules, then hardening, then validate with adversary simulation. In 90 days a team with focus can move from "vulnerable to a competent attacker" to "would notice and contain the chain in hours". That's the difference between a controlled incident and a breach report.

If you want help building or validating this, talk to a Hard2bit specialist and we'll scope a focused first phase.

Disclaimer: The detection rules, hardening steps and response procedures in this article must be adapted to your specific Active Directory and Entra ID configuration. Telemetry sources, event IDs and recommended thresholds reflect typical enterprise environments as of mid-2026 and may need adjustment. This article is informational and does not replace a formal technical audit, configuration review or incident response engagement specific to your environment.