Fake IT support on Teams, then domain certificates: Microsoft details two intrusions through AD CS

Microsoft has investigated two intrusions that began with attackers posing as IT support on Teams and went on to abuse Active Directory Certificate Services. In one case, certificates for privileged accounts led to data being stolen from a file server. No Teams vulnerability was exploited: the weak points were a persuaded employee and an unsafe AD CS configuration.

What happened

In a report dated 30 October 2026, Microsoft Threat Intelligence describes two hands-on intrusions at unnamed organisations. Both began the same way: Teams messages and calls from accounts styled as help desk staff, which persuaded employees to open a Quick Assist or similar remote session. Microsoft states that no Teams vulnerability was exploited and does not attribute the activity to a specific actor.

How the attackers got in

First case (ESC1). A first wave targeted three users and compromised one workstation. A misconfigured certificate template then gave the attacker certificates for three highly privileged accounts. About 90 minutes after the first session was disrupted, a second wave targeted 16 users and yielded certificates for eight more privileged accounts. Within seconds of obtaining one certificate, the attacker authenticated to a domain controller and began a DCSync. One privileged account had been excluded from automated response: it was used to reach a file server, where a renamed copy of Rclone sent data to an external SFTP destination.

Second case (ESC8). PetitPotam forced a domain controller to authenticate to a system under the attacker’s control. That authentication was relayed to AD CS Web Enrollment, producing a certificate and then a Kerberos ticket for the controller’s account. The customer isolated the workstation after alerts, and Microsoft saw no further progression.

What to do now

1. Tighten Teams and remote support: limit external domains, allow only approved support tools, and confirm any unsolicited support request through a known internal channel.
2. Audit certificate templates: run certutil -v -template and look for CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT on templates that allow authentication. Turn off Supply in the request, restrict enrollment rights or require manager approval.
3. Secure web enrollment: list the Web Enrollment and Certificate Enrollment Web Service endpoints and remove unneeded ones. Otherwise require HTTPS and set Extended Protection for Authentication to Required, as described in KB5005413, then run iisreset /restart.
4. Enable CA auditing for certificate requests and issuance. If a certificate is illegitimate, revoke it, but also review Kerberos tickets: revocation does not invalidate those already issued.
5. Review containment exclusions: any account left out of automated response needs a named person and a manual action.

Our take

Phishing explains how the attackers got in, but certificate settings explain how fast they rose: a single workstation was enough to reach domain-level accounts. AD CS is often installed once and then forgotten, even though it deserves the same protection as a domain controller. An audit of templates and enrollment endpoints takes little time, and is well worth doing before an incident.

Sources

• Microsoft Security Blog — From help desk impersonation to AD CS abuse: Investigating ESC1 and ESC8 intrusion paths
• Microsoft Support — KB5005413: Mitigating NTLM relay attacks on Active Directory Certificate Services
• Microsoft Learn — Certificates security posture assessment in Defender for Identity
• SpecterOps — Certified Pre-Owned
• The Hacker News — Attackers Pose as IT Support on Microsoft Teams, Abuse AD CS to Steal Company Data

How we choose, verify and write our analyses →