An impersonated IT support call on Microsoft Teams gave intruders remote control of workstations in two investigated incidents. In one, an Active Directory Certificate Services (AD CS) template let them obtain privileged authentication certificates; an account excluded from automated containment later accessed a file server and supported data theft. In the other, an NTLM relay through AD CS Web Enrollment yielded a domain-controller certificate before the customer isolated the workstation. Microsoft’s October 30 investigation describes both cases. The callers used Teams to pose as support staff, then abused AD CS configurations after users granted remote control.
For an organization running AD CS, the immediate question is whether a certificate was issued to an identity the requester should never have held. Microsoft describes the risk as “a user-approved remote session can become certificate-backed access to privileged identities and domain infrastructure.” A password reset or a rebuilt first workstation leaves an issued certificate and already-issued Kerberos tickets to handle separately.
A support call reached the workstation
The callers posed as help desk staff in Teams messages and calls, then persuaded a user to start Quick Assist, enter a connection code and grant control. Organization-themed tenants under onmicrosoft.com and support-like display names helped the outside contact look familiar. The user-approved session let the attacker deposit an archive in Downloads, unpack it into a new KB-prefixed directory under the user profile and launch code with a portable Python, Bun or Java runtime. One renamed executable still carried Bun version metadata. The two cases shared this entry route and host discovery, including connections to directory infrastructure over LDAPS and SMB.
An unexpected support session followed by an archive extraction and an interpreter running from a writable profile is the recognition pattern. Correlate Teams chat and call time with Quick Assist session start, endpoint process parentage, original filename metadata and the account that made later certificate requests. A renamed bun.exe, java.exe or javaw.exe in AppData\Roaming\KB-prefixed staging deserves inspection in that sequence; the name alone is a weak signal. Microsoft’s endpoint hunting examples use connections on ports 80, 445, 636 and 88 to connect runtime activity to web, SMB, LDAPS and Kerberos traffic.
Two certificate routes split the cases
In the first case, an ESC1-vulnerable certificate template let a low-privileged requester supply identity information and obtain authentication certificates for privileged accounts. Broad enrollment rights and weak issuance controls made the template useful to the intruder. In a first phishing wave that targeted three user accounts and compromised one workstation, the attacker obtained certificates for three highly privileged accounts. About 90 minutes after disruption, a second wave targeted 16 users, compromised another workstation and obtained certificates for eight more privileged accounts.
In the second case, the attacker used PetitPotam to trigger domain-controller NTLM authentication over EFSRPC, relayed that authentication to AD CS Web Enrollment and requested a certificate with the Domain Controller template. This is ESC8: the web endpoint accepted an identity authenticated from another device without sufficient relay protection. The attacker then used the certificate for Kerberos PKINIT and received a ticket-granting ticket for the domain-controller account. Tie requests to /certsrv submission and retrieval endpoints to the source device, machine account, CA issuance record and subsequent Kerberos activity; ordinary enrollment also uses those paths.
The excluded account carried the theft
Microsoft Defender attack disruption restricted covered identities and disconnected active sessions in the first case. It blocked more than 1,000 subsequent SMB file-access attempts and additional logons during the second phishing wave. Within seconds of obtaining a privileged certificate, though, the attacker performed DCSync while containment was taking effect. One privileged account excluded during the first disruption remained usable: the attacker reached a file server and ran a renamed Rclone copy as SearchApp.exe, sending data from a share to an external SFTP destination.
Defender alerted on the ESC8 activity, the customer isolated the associated workstation, and Microsoft observed no further attack progression after that isolation. Microsoft evaluated its own Defender response in these cases; the excluded identity and the customer’s separate isolation action explain why a product-level disruption alert is only one part of containment. Microsoft leaves the operator unattributed.
Rebuild the certificate trail
Start with the support contact and remote session, then join the initiating workstation to CA request and issuance records. For ESC1, inspect the requesting account, template enrollment permissions, supplied subject and Subject Alternative Name, certificate serial and thumbprint, and first authentication as the privileged identity. For ESC8, correlate EFSRPC activity and domain-controller outbound authentication with the source device in IIS Web Enrollment logs, CA issuance and later PKINIT. The domain-controller machine account authenticating to AD CS from a different device is the important mismatch.
Three SHA-256 values Microsoft supplies for initial-access scripts are 85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17 (JavaScript), f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001 (Python) and 06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7 (Python). Search them in endpoint inventory alongside the remote-session and certificate timeline; changed runtimes and archives call for behavioral correlation too. Passive network inspection of LDAPS will not reveal the LDAP query inside TLS, so use endpoint and directory records to establish what the process did.
Harden enrollment and verify containment
For ESC1, restrict enrollment on authentication-capable templates, remove requester-supplied identity where it is unnecessary, and review approval requirements. For ESC8, inventory CA Web Enrollment and Certificate Enrollment Web Service endpoints. Microsoft’s relay mitigation guidance calls for Extended Protection for Authentication (EPA) on both, with Required as the stronger setting, and Require SSL so enrollment accepts HTTPS; test clients before applying the changes and restart IIS to load them. Disable NTLM where the enrollment workflow permits it. Defender for Identity’s certificate assessments list insecure IIS enrollment endpoints for ESC8 and exposed templates for ESC1; the ESC1 assessment is in preview, and the ESC8 assessment requires a sensor on an AD CS server. Its impacted-entity list updates within minutes after remediation, while score and status update daily.
If the trail includes unauthorized issuance, revoke each certificate by serial number and thumbprint, publish updated revocation information and verify relying systems can retrieve it. Separately review active Kerberos tickets and privileged logons. Remove containment exclusions for compromised identities when possible; where an exclusion must remain, assign and verify manual containment of that account. Then repeat the CA/IIS and identity checks: the enrollment endpoint should require HTTPS and EPA, the template should deny the unauthorized enrollment path, and the response record should account for every issued certificate and active ticket. Use the CA and Kerberos records for the last check, even after the workstation goes quiet.