From Help Desk Impersonation to Active Directory Takeover: Microsoft Exposes ESC1 and ESC8 Certificate Abuse Attacks

1. Description

Microsoft Threat Intelligence has disclosed two human-operated intrusions that demonstrate how attackers can exploit employee trust and weaknesses in enterprise certificate infrastructure to obtain privileged access.

Both incidents started with help desk impersonation through Microsoft Teams. Attackers contacted employees while posing as IT support personnel and persuaded them to establish remote-support sessions, primarily through Quick Assist.

After obtaining interactive access, the attackers staged portable execution environments, including Python, Bun, and Java, and performed reconnaissance against compromised workstations and domain infrastructure.

The incidents diverged during the privilege-escalation stage. One attacker exploited an ESC1-vulnerable AD CS certificate template to request certificates representing privileged user accounts. The other used PetitPotam to coerce domain-controller authentication and relayed the resulting NTLM authentication to an AD CS Web Enrollment endpoint through ESC8.

The first incident involved certificate-backed privileged access, DCSync activity, and subsequent data exfiltration. In the second incident, the attacker obtained a domain-controller certificate and used it for certificate-based Kerberos authentication before the customer isolated the associated workstation.

These incidents highlight the importance of securing remote-support workflows, restricting certificate enrollment permissions, enforcing NTLM relay protections, and ensuring that incident-response controls cover every compromised identity.

2. Technical Description

2.1 Active Directory Certificate Services (AD CS)

Active Directory Certificate Services is a Windows Server role that enables organizations to issue and manage digital certificates. These certificates can support authentication, encryption, digital signatures, and other enterprise security functions.

In an Active Directory environment, authentication-capable certificates can represent user or computer identities. When correctly configured, this provides a secure method of authentication.

However, insecure certificate templates and enrollment services can allow attackers to request certificates representing identities they do not legitimately control.

A certificate issued for a privileged identity can provide an alternative authentication route that does not depend on the original account password.

This makes AD CS an important target during privilege-escalation attacks.

2.2 ESC1 – Certificate Template Abuse

ESC1 is an AD CS misconfiguration in which a certificate template permits requester-supplied identity information and allows a requester to enroll in a way that can result in a certificate representing another identity.

When an authentication-capable template combines these settings with broad enrollment permissions and insufficient issuance controls, a low-privileged account may be able to obtain a certificate representing a privileged user.

Attack significance:

• An attacker can obtain a certificate representing a privileged account.

• The certificate can support authentication as that identity.

• The attacker may gain access to privileged services and domain resources.

• The certificate can remain usable even after the original account password is changed, unless the certificate is separately revoked and the relevant revocation information is made available to relying systems.

2.3 ESC8 – NTLM Relay to AD CS Web Enrollment

ESC8 involves relaying NTLM authentication to an AD CS Web Enrollment endpoint that does not have sufficient relay protections.

The attacker causes a legitimate account, such as a domain controller's machine account, to authenticate to an attacker-controlled system. The attacker then relays that authentication to the certificate enrollment service.

If the endpoint accepts the relayed authentication without adequate protections, the attacker may request a certificate representing the authenticated identity.

Attack significance:

• The attacker does not need to know the target account's password.

• The relayed authentication can be used to request a certificate for a machine account.

• The certificate can support certificate-based Kerberos authentication through PKINIT.

• A domain-controller identity obtained through this technique can create a serious risk to the domain environment.

2.4 PetitPotam

PetitPotam is an authentication-coercion technique that abuses Windows Encrypting File System Remote Protocol (EFSRPC) functionality to cause a target Windows system to authenticate to an attacker-controlled endpoint.

In the second Microsoft incident, this technique caused a domain controller to authenticate using its machine account.

The resulting NTLM authentication was relayed to an AD CS Web Enrollment endpoint, enabling the ESC8 certificate-abuse path.

2.5 PKINIT

PKINIT stands for Public Key Cryptography for Initial Authentication. It extends Kerberos authentication to support public-key cryptography.

In the reported ESC8 incident, the attacker used the certificate obtained for the domain-controller account to perform certificate-based Kerberos authentication and obtain a ticket-granting ticket (TGT).

This converted the relayed NTLM authentication into certificate-backed Kerberos access.

3. Attack Overview

Microsoft described two incidents with a common initial-access pattern but different AD CS exploitation techniques.

3.1 Shared Attack Chain

Stage 1 – Help Desk Impersonation

Attackers contacted employees through Microsoft Teams messages and calls while impersonating IT support personnel.

They persuaded users to establish remote-support sessions and provide access through Quick Assist or another remote-support mechanism.

Stage 2 – Remote Access and Archive Transfer

After the employee granted access, attackers used the interactive session to transfer an archive into the victim's Downloads directory.

The archive was extracted into a newly created staging directory under the user's profile.

Stage 3 – Portable Runtime Execution

Attackers launched attacker-controlled scripts using portable runtimes such as Python, Bun, or Java.

Some executables were renamed or placed in update-themed directories to make their execution appear less suspicious.

Stage 4 – Host and Network Discovery

The staged components collected information about the Windows operating system, network configuration, and running processes.

The compromised workstation also communicated with domain infrastructure through LDAPS and SMB.

Stage 5 – AD CS Enumeration

The attackers examined the Active Directory certificate infrastructure for opportunities to obtain authentication certificates representing privileged identities.

Stage 6 – Certificate Abuse

The two incidents diverged:

• Case 1: ESC1 certificate template abuse.

• Case 2: PetitPotam authentication coercion followed by ESC8 NTLM relay.

Stage 7 – Privileged Access and Follow-on Activity

Case 1 involved DCSync, privileged account reuse, file-server access, and data exfiltration.

Case 2 involved certificate-based Kerberos authentication using a domain-controller identity. Customer-led workstation isolation stopped further observed progression.

3.2 Attack Chain Flow

Help Desk Impersonation through Microsoft Teams
↓
Employee Approves Quick Assist / Remote Support
↓
Attacker Gains Interactive Workstation Access
↓
Archive Transfer and Extraction
↓
Portable Python / Bun / Java Runtime Execution
↓
Host and Network Discovery
↓
AD CS Enumeration
↓
Two Separate Attack Paths

Case 1 – ESC1

• Abuse misconfigured certificate template

• Obtain certificates for privileged user identities

• Authenticate using privileged certificates

• Perform DCSync

• Reuse an excluded privileged account

• Access file servers and exfiltrate data

Case 2 – ESC8

• Use PetitPotam to coerce domain-controller authentication

• Relay NTLM to AD CS Web Enrollment

• Obtain a domain-controller certificate

• Perform Kerberos PKINIT

• Customer isolates the associated workstation

4. Technical Analysis

4.1 Microsoft Teams Help Desk Impersonation

The initial access technique relied on social engineering rather than exploiting a technical vulnerability in Microsoft Teams.

Attackers impersonated IT support personnel through Teams messages and calls, persuading employees to initiate remote-support sessions.

Microsoft reported that organization-themed onmicrosoft.com tenant names and support-oriented display names were used to make external contacts appear familiar.

Quick Assist provided the attackers with interactive access to the workstation after the employee approved the session.

Investigation indicators:

• Unexpected external Teams messages or calls.

• External users presenting themselves as internal IT support.

• Organization-themed external tenant names.

• Users being asked to open Quick Assist.

• Unusual remote-support sessions followed by archive transfers.

• Commands executed immediately after remote access was established.

A remote-support session should not automatically be considered malicious. Investigators should establish whether the session was expected, authorized, and initiated through an approved support process.

4.2 Portable Runtime Staging and Execution

After gaining access, attackers transferred archives and extracted their contents into directories under the victim's user profile.

Microsoft observed the use of portable Python, Bun, and Java runtimes to execute attacker-controlled components.

One JavaScript variant used a renamed executable that retained version metadata identifying it as the Bun runtime. Another variant used a staged Java runtime to execute a Java source file.

This technique can complicate detection because legitimate runtimes may be present in development environments.

Important forensic artifacts:

• Newly created directories with KB-prefixed names.

• Archive files in Downloads.

• Extracted scripts and runtime binaries.

• File creation and modification timestamps.

• Original filename and product-version metadata.

• Process parent-child relationships.

• Command-line arguments.

• Network connections initiated by the staged runtime.

Detection approach:

Security teams should correlate the executable's original filename, current filename, signer, metadata, directory location, parent process, and command line.

A portable runtime launched from an unexpected user-writable directory immediately after an unauthorized remote-support session deserves investigation.

4.3 Host Discovery and Network Reconnaissance

Following runtime execution, attackers performed reconnaissance to understand the compromised system and its network environment.

Microsoft documented commands used to collect:

These activities are not inherently malicious. Administrators and legitimate software also perform similar operations.

Their significance comes from the surrounding context: an unexpected Teams support session, archive extraction, portable runtime execution, and subsequent communication with domain infrastructure.

4.4 Case 1 – ESC1 Certificate Template Abuse

The first incident began with a Teams phishing wave targeting three users. One workstation was compromised.

The attacker examined AD CS and identified a certificate template vulnerable to ESC1.

The misconfiguration allowed requester-supplied identity information in an authentication-capable certificate request, enabling the attacker to obtain certificates representing privileged accounts.

First privilege-escalation wave:

1. The attacker compromised a workstation through help desk impersonation.

2. The attacker enumerated AD CS.

3. The attacker identified an ESC1-vulnerable certificate template.

4. The attacker obtained certificates for three highly privileged accounts.

5. Microsoft Defender attack disruption restricted the initially compromised user and the three certificate-compromised identities.

6. Active sessions were disconnected, and remote logons and SMB access were restricted.

However, one privileged account was excluded from automated response and remained usable.

Second phishing wave:

Approximately 90 minutes after the first disruption, the attacker launched another Teams phishing wave targeting 16 users and compromised an additional workstation.

The attacker again abused the ESC1-vulnerable template and obtained certificates for eight additional privileged accounts.

Microsoft Defender attack disruption targeted the newly compromised user and the eight certificate-compromised identities.

More than 1,000 subsequent SMB file-access attempts and additional logon attempts were blocked.

4.5 DCSync and Data Exfiltration

Within seconds of obtaining one privileged certificate, the attacker authenticated to a domain controller and performed DCSync.

DCSync abuses Active Directory replication functionality to request directory credential data. It is a high-impact activity because it can expose sensitive authentication material, including password hashes.

Microsoft reported that attack disruption limited additional replication and follow-on activity.

However, the privileged account excluded from automated containment remained accessible.

The attacker used this account for network and remote-interactive logons, accessed a file server, and launched a renamed copy of Rclone using the filename SearchApp.exe.

The tool recursively copied files from a file-server share to an external SFTP destination.

Microsoft reported the following transfer characteristics:

• 20 concurrent transfers.

• Files up to three years old.

• Recursive copying from a file-server share.

• Exclusions for several executable, database, virtual-disk, media, temporary, and log file types.

• External SFTP destination.

Security significance:

This incident demonstrates that automated containment can significantly restrict attacker activity while still leaving a viable attack path if even one compromised privileged identity is excluded.

A compromised identity should not be considered safe merely because other accounts and endpoints have been contained.

4.6 Case 2 – PetitPotam and ESC8 NTLM Relay

The second incident followed the same initial help desk impersonation and remote-access pattern.

However, the ESC1 certificate-template path used in Case 1 was not available in this environment.

The attacker instead used PetitPotam to coerce a domain controller into authenticating to an attacker-controlled system.

The domain controller authenticated using its machine account through NTLM.

The attacker then relayed this authentication to AD CS Web Enrollment, which lacked sufficient relay protection.

Attack sequence:

1. The attacker obtained access to a workstation through help desk impersonation.

2. PetitPotam was used to trigger domain-controller authentication.

3. The domain controller authenticated to an attacker-controlled system using its machine account.

4. The attacker relayed the NTLM authentication to AD CS Web Enrollment.

5. The certificate enrollment service processed the request as the relayed domain-controller identity.

6. The attacker requested a certificate using the Domain Controller template.

7. The attacker retrieved the certificate and used it for certificate-based Kerberos authentication.

4.7 AD CS Web Enrollment Abuse

AD CS Web Enrollment provides a web-based interface for certificate requests and retrieval.

In an ESC8 attack, an attacker can exploit an enrollment endpoint that accepts NTLM authentication without adequate relay protections.

Microsoft highlighted the /certsrv submission and retrieval paths as useful investigation points.

However, access to /certsrv alone does not prove malicious activity.

Investigators should correlate:

• The authenticated user or machine account.

• The source device and originating process.

• Web Enrollment access records.

• Certificate request and issuance records.

• Certificate template information.

• The certificate's subject and identity.

• Subsequent Kerberos authentication.

A particularly useful investigation pivot is a domain-controller machine account authenticating to the certificate enrollment service from an unexpected device.

4.8 Certificate-Based Kerberos Authentication

After obtaining the domain-controller certificate, the attacker used PKINIT to authenticate through Kerberos and obtain a ticket-granting ticket.

This is important because certificate-backed authentication creates a separate access path from password-based authentication.

Responders must not assume that resetting an account password or reimaging a workstation invalidates certificates and tickets already issued.

Microsoft specifically emphasizes that certificate revocation and Kerberos ticket review are separate containment actions.

4.9 Different Incident Response Outcomes

The key lesson is that identity containment and endpoint containment must work together.

If a privileged account is excluded from automated response, responders must assign and verify an alternative containment action.

5. Indicators of Compromise (IOCs)

The following SHA-256 hashes were explicitly provided by Microsoft for the reported activity.

Additional behavioral indicators

IOC handling note: The behavioral indicators above are investigation leads, not unique malicious signatures. The Microsoft source provided three SHA-256 hashes; no additional file hashes, attacker IP addresses, or malicious domains are added here.

6. Potential Impact

6.1 Privilege Escalation

ESC1 and ESC8 can enable attackers to obtain certificates representing privileged users or computer accounts, creating an alternative authentication path into enterprise infrastructure.

6.2 Domain Compromise

A certificate representing a domain-controller identity can provide a serious opportunity for further access to domain infrastructure.

DCSync activity can expose sensitive Active Directory credential material and increase the consequences of a successful compromise.

6.3 Persistent Authentication Access

Issued certificates and previously issued Kerberos tickets can remain relevant after password resets or endpoint reimaging.

Organizations that fail to revoke unauthorized certificates and review active tickets may leave attackers with a usable authentication path.

6.4 Sensitive Data Exfiltration

The first incident demonstrated how an excluded privileged account could be reused to access file servers and transfer organizational data to an external SFTP destination.

6.5 Business and Operational Disruption

A compromised privileged identity can affect authentication services, file servers, directory infrastructure, and other enterprise resources. Incident response may also require account restrictions, endpoint isolation, certificate revocation, and broader identity remediation.

6.6 Remote-Support Trust Abuse

Employees may unknowingly provide attackers with interactive access by approving support sessions initiated through convincing impersonation attempts.

7. Recommendations

7.1 Immediate Actions

1. Investigate suspicious Teams activity: Review external messages, calls, tenant identities, support impersonation attempts, and remote-support sessions.

2. Validate Quick Assist usage: Confirm whether remote-support sessions were initiated through approved internal procedures.

3. Inspect endpoint staging locations: Search for newly created KB-prefixed directories, transferred archives, portable runtimes, and suspicious scripts.

4. Review AD CS certificate requests: Identify unusual requests involving privileged user accounts or domain-controller machine accounts.

5. Investigate certificate issuance: Correlate the requester, certificate template, subject, SAN values, source device, and CA issuance records.

6. Review Kerberos activity: Investigate unexpected PKINIT events, TGT issuance, and subsequent service-ticket use.

7. Investigate DCSync: Review domain-controller authentication and directory replication activity for unauthorized accounts.

8. Review SMB and file-server access: Identify unusual privileged logons, bulk file access, and suspicious Rclone execution.

9. Contain every compromised identity: Review automated-response exclusions and assign compensating manual actions where required.

10. Revoke unauthorized certificates: Identify certificate serial numbers and thumbprints, revoke affected certificates, and publish updated revocation information.

7.2 Preventive Actions

Secure Microsoft Teams and remote support

• Train employees to verify unexpected IT support requests through known internal communication channels.

• Require verification before granting remote-control access.

• Review Teams external-access and federation policies.

• Restrict external communication to approved business requirements.

• Limit remote-support software to approved products, operators, and workflows.

• Monitor approved remote-support tools that unexpectedly extract archives or launch scripts.

Restrict portable runtime execution

• Use App Control for Business or equivalent application-control solutions.

• Restrict unapproved portable runtimes and script execution from user-writable directories.

• Monitor renamed executables and unexpected runtime metadata.

• Correlate process lineage, file paths, command-line arguments, and network connections.

• Evaluate attack surface reduction rules and endpoint protection policies.

Harden AD CS certificate templates

• Review authentication-capable certificate templates for requester-supplied subject information.

• Remove unnecessary enrollment permissions.

• Avoid broad enrollment rights on privileged authentication templates.

• Review certificate issuance requirements and approval controls.

• Identify templates that could allow low-privileged users to request certificates for privileged identities.

• Use Microsoft Defender for Identity AD CS security posture assessments to identify misconfigurations.

Mitigate ESC8 and NTLM relay

• Follow Microsoft's guidance in KB5005413: https://support.microsoft.com/help/5005413

• Inventory AD CS Web Enrollment and Certificate Enrollment Web Service endpoints.

• Remove enrollment endpoints that are not required.

• Require HTTPS.

• Enforce Extended Protection for Authentication (EPA) on applicable enrollment web endpoints.

• Disable NTLM on enrollment services where operationally feasible.

• Validate Kerberos-only authentication before broad enforcement.

Improve certificate-aware incident response

• Enable Certification Services auditing for successful and failed operations.

• Configure the Certification Authority audit filter to record certificate request and issuance activity.

• Preserve CA security events, CA database records, IIS logs, endpoint telemetry, identity alerts, and Teams interaction records.

• Revoke unauthorized certificates and publish updated revocation information.

• Review active Kerberos tickets separately from certificate revocation.

• Treat identity and device exclusions as explicit incident-response decisions requiring documented compensating controls.

8. Detection and Threat-Hunting Guidance

Security teams should correlate evidence across collaboration platforms, endpoints, Active Directory, AD CS, and Kerberos.

8.1 Teams and Remote-Support Monitoring

Investigate external Teams contacts that impersonate internal support personnel, particularly when followed by Quick Assist sessions or unusual remote-management activity.

Review the external tenant, contact identity, call timing, user approval, and endpoint activity immediately following the session.

8.2 Portable Runtime Monitoring

Monitor Bun, Python, and Java execution from newly created user-writable directories.

Prioritize events where runtime execution follows an unexpected remote-support session or archive extraction.

8.3 AD CS Monitoring

Monitor certificate requests involving:

• Privileged user identities.

• Domain-controller machine accounts.

• Unusual certificate templates.

• Unexpected source devices.

• Web Enrollment requests from unusual systems.

• Unexpected subject or SAN values.

8.4 NTLM Relay and PKINIT Monitoring

Correlate domain-controller NTLM authentication, Web Enrollment access, CA certificate issuance, and PKINIT activity.

A certificate request and a successful PKINIT event associated with an unexpected source device should receive priority investigation.

8.5 DCSync and Exfiltration Monitoring

Review directory replication activity, privileged account logons, SMB access patterns, Rclone execution, and outbound SFTP connections.

Investigators should also examine whether an identity excluded from automated containment was used after the initial response.

9. Microsoft Defender XDR Detection Coverage

Microsoft described multiple Defender detections and disruption capabilities relevant to the reported incidents. Alert names and availability depend on product configuration and enabled sensors.

Microsoft Security Copilot

Microsoft also described how Security Copilot can assist analysts in summarizing the Teams-to-remote-access sequence, reviewing staged runtime behavior, correlating certificate alerts with affected identities, and preparing containment tasks.

Analysts should validate all generated findings against the underlying telemetry and available incident evidence.

10. Advanced Hunting Queries

The following queries are adapted directly from Microsoft's published investigation guidance. They are starting points and should be tuned to the tenant's available telemetry and field values.

Query 1: Teams External Contact and Impersonation Signals

Purpose: Identify external Teams chats and available impersonation-related signals.

CloudAppEvents
| where Timestamp > ago(7d)
| where Application == "Microsoft Teams"
| where
    (ActionType == "ChatCreated" and IsExternalUser == true)
    or ActionType in~ (
        "TeamsImpersonationDetected",
        "SecurityRiskInCallDetected")
| order by Timestamp desc

Investigation focus:

• Identify unexpected external contacts.

• Review suspicious Teams calls and chats.

• Correlate timestamps with Quick Assist sessions and endpoint activity.

Query 2: Bun or Java Execution from KB-Prefixed Staging Paths

Purpose: Identify Bun or Java processes executing scripts from KB-prefixed AppData directories.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessVersionInfoOriginalFileName =~ "bun.exe"
    or FileName in~ ("bun.exe", "java.exe", "javaw.exe")
| where ProcessCommandLine contains ".js"
    or ProcessCommandLine contains ".java"
| where FolderPath matches regex
    @"(?i)\\AppData\\Roaming\\KB[0-9]+\\"
| order by Timestamp desc

Investigation focus:

• Examine the executable's original filename and current filename.

• Inspect the script operand and command line.

• Identify the parent process and archive-extraction activity.

• Correlate execution with remote-support sessions.

Query 3: Network Activity Initiated by Staged Runtimes

Purpose: Identify network connections initiated by Bun or Java from KB-prefixed staging paths.

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessVersionInfoOriginalFileName =~ "bun.exe"
    or InitiatingProcessFileName in~ (
        "bun.exe", "java.exe", "javaw.exe")
| where RemotePort in (80, 445, 636, 88)
| where InitiatingProcessFolderPath matches regex
    @"(?i)\\AppData\\Roaming\\KB[0-9]+\\"
| order by Timestamp desc

Investigation focus:

• Identify connections to domain infrastructure.

• Review the destination address and port.

• Correlate network events with process execution and identity activity.

Query 4: Enrollment, Relay, and PKINIT Alerts

Purpose: Retrieve relevant alerts and associated evidence for certificate abuse, NTLM relay, and Kerberos activity.

AlertInfo
| where Timestamp > ago(7d)
| where
    Title contains "NTLM relay"
    or Title contains "Certificate Services"
    or Title contains "PKINIT"
    or Title contains "Kerberos ticket request"
| join kind=inner (
    AlertEvidence
    | where Timestamp > ago(7d)
) on AlertId

Investigation focus:

• Identify certificate-related alerts.

• Review associated users, devices, and evidence.

• Correlate alert timestamps with CA issuance and Kerberos authentication records.

Important: These queries are investigation starting points, not definitive compromise tests. Validate table and field availability, adjust time windows, and investigate matches in the context of related events.

11. Conclusion

The Microsoft investigation demonstrates how seemingly ordinary help desk interactions can become the starting point for serious enterprise identity compromise.

Both incidents began with Teams impersonation and user-approved remote access. Attackers then staged portable runtimes, performed reconnaissance, and identified weaknesses in Active Directory Certificate Services.

The two incidents demonstrate different but equally important certificate-abuse risks. ESC1 can allow an attacker to obtain authentication certificates representing privileged users, while ESC8 can turn coerced NTLM authentication into a certificate-backed identity through an inadequately protected Web Enrollment endpoint.

The first incident also highlights a critical weakness in automated containment: excluding even one compromised privileged identity can preserve an attacker's access after other accounts have been restricted. The second demonstrates the value of rapid endpoint isolation after certificate-enrollment and Kerberos-related alerts.

Organizations should therefore treat AD CS as a critical identity-security component rather than merely a certificate-management service. Securing certificate templates, enforcing NTLM relay protections, monitoring certificate issuance, restricting unauthorized remote access, and reviewing all compromised identities are essential to preventing certificate-based privilege escalation.

The central lesson is clear: securing the endpoint is not enough if the identity and certificate infrastructure remain exposed.