Fake IT support calls on Teams end with attackers forging domain controller certificates
Microsoft investigators describe two intrusions that started with help desk impersonation and ended with the abuse of Active Directory Certificate Services, including a PetitPotam relay that handed attackers a domain controller's identity.
Key points
- Microsoft Threat Intelligence investigated two intrusions where attackers posed as IT staff on Microsoft Teams, talked users into opening a Quick Assist remote session, and then abused Active Directory Certificate Services to forge logon certificates for privileged accounts.
- In one case the attacker exploited a misconfigured certificate template, known as ESC1, to issue certificates for high-privilege users and then run DCSync, a trick for stealing password data from a domain controller.
- PetitPotam forced a domain controller to authenticate to attacker-controlled infrastructure in the second case; that logon was relayed to the AD CS Web Enrollment service, an abuse path tracked as ESC8.
- Microsoft says no flaw in Teams was exploited; the chain relied on social engineering and permissive AD CS configurations documented in advisory 5005413 and in Defender for Identity's ESC11 posture assessment.
- Automated containment stopped most follow-on activity in one incident, but a privileged account excluded from automatic lockdown stayed usable and was later involved in data theft.
What stands out in Microsoft's writeup isn't the phishing. It's how fast a user-approved remote session becomes a certificate the attacker can keep using after passwords are reset and machines are rebuilt.
How did the attackers get in?
They called people on Microsoft Teams and pretended to be the help desk. Users were walked through opening Quick Assist, Microsoft's built-in remote support tool, and handing over a connection code, giving the attacker direct workstation control with no malware attachment involved.
We've tracked this impersonation pattern since our first report on 2 September; the certificate abuse described here is the sharpest escalation we've seen it reach. The callers used tenant names ending in onmicrosoft.com and display names styled to look like internal support. Teams flagged the sessions with "External" and "Scam suspected" labels, which Microsoft notes are the user-facing warnings that matter most during this kind of impersonation.
Once connected, the attacker dropped a compressed archive into the Downloads folder, extracted it into a new folder under the user profile, and launched the contents using a portable copy of Python, the Bun JavaScript runtime, or Java. The renamed executables kept their original version information, which is why Microsoft tells defenders to check where a runtime was launched from, not just its file name.
What is Active Directory Certificate Services and why does it matter here?
AD CS is the Windows service that issues digital certificates inside a company network. Those certificates can authenticate a logon. If an attacker tricks AD CS into issuing a certificate for a privileged account, that certificate works independently of the account's password.
Resetting the password doesn't revoke the certificate. Reimaging the first infected laptop doesn't revoke it either. Kerberos tickets already issued stay valid. That's why Microsoft treats this path as high impact.
What are ESC1 and ESC8 in plain terms?
| Technique | What the attacker abuses | Outcome in these cases |
|---|---|---|
| ESC1 | A certificate template that lets a low-privilege user request a certificate while naming someone else as the subject | Certificates issued for privileged accounts, used to run DCSync and copy password hashes |
| ESC8 | An AD CS Web Enrollment endpoint that accepts relayed NTLM logons without protections such as Extended Protection for Authentication | A domain controller's own identity captured and reused for Kerberos logon via PKINIT |
| PetitPotam | A coercion technique that forces a Windows server to authenticate to an attacker's machine | Supplied the NTLM logon that was relayed into ESC8 |
Microsoft's own guidance in support article 5005413 tells administrators to enable Extended Protection for Authentication and SMB signing, and to disable NTLM on AD CS Web Enrollment where possible. Defender for Identity also publishes a posture check for ESC11, which flags certificate authorities that accept RPC enrollment without packet privacy.
Should you worry about the Teams vector specifically?
The honest answer is yes, even if you've seen this headline before. The social engineering entry point is unchanged. What's new is the exit: forged certificates that survive a full credential reset.
What should defenders and ordinary users do?
For users: a Teams call from outside your organisation, even one that looks like IT, shouldn't end with you reading a Quick Assist code to the caller. If Teams shows "External" or "Scam suspected," hang up and call your real help desk on a known number.
For administrators: audit certificate templates for requester-supplied subject names and broad enrollment rights, apply the AD CS Web Enrollment hardening in advisory 5005413, and confirm that no privileged identity is excluded from automated containment in Defender. Microsoft's second case ended when the customer isolated the workstation after an ESC8 alert. The first was messier because a privileged account sat outside the containment scope.
