Microsoft Teams Impersonation Attack Leads to AD CS Abuse, Microsoft Says

What Happened: Microsoft Teams Impersonation Attack

Microsoft Security has documented a Microsoft Teams impersonation attack that starts with a fake IT support call and ends with certificate abuse. The attack chain uses social engineering on Teams to gain remote control of a PC, then exploits insecure Active Directory Certificate Services (AD CS) settings to obtain login certificates for privileged accounts, including one for a domain controller.

Hackernews reports that Microsoft investigated two intrusions like this, and that one resulted in company data theft. The pattern is not a single software bug. It is a combination of human behavior, a collaboration tool, and certificate services settings that were not locked down. For an MSP, every part of that chain is something you can influence.

Timeline

No incident timeline has been published yet. The dated events in the public record are:

• October 30, 2026Microsoft Security published 'From help desk impersonation to AD CS abuse: Investigating ESC1 and ESC8 intrusion paths.'
• November 2, 2026Hackernews reported on the intrusions, describing Teams impersonation and AD CS abuse.

Who Is Affected

The attack path applies to any organization that uses Microsoft Teams and runs Active Directory Certificate Services. The intrusions Microsoft investigated succeeded because employees accepted a support call and because AD CS settings allowed certificates to be issued for privileged accounts. That combination can be present in an MSP's own environment and in a client's environment.

The public reporting does not name the companies or the sectors. It says Microsoft investigated two intrusions, and Hackernews describes the outcome as company data theft. If you support clients that use Teams and AD CS, this is a relevant scenario regardless of size.

Why This Matters for MSPs

An MSP has two reasons to care about this pattern. Your own staff answer Teams calls all day, and they are used to helping colleagues with remote control. The same social engineering that works on a client employee can work on your team.

The first compromise is an employee PC. The second is a certificate for a privileged account. Between those two points, the attacker used the trust employees place in a support call and the configuration of certificate services. That is a combination an MSP can actually do something about.

Technical Details

The sources do not name a CVE. The products involved are Microsoft Teams and Active Directory Certificate Services (AD CS). The sources do not name specific versions.

Microsoft Security describes the chain as Teams support impersonation that led to remote access, malicious runtime execution, and Certificate Services abuse through authentication relay and Kerberos. Attackers posing as IT support on Microsoft Teams talked employees into giving them remote control of their PCs. They then used insecure AD CS settings to obtain login certificates for privileged accounts, including one for a domain controller.

Microsoft's investigation covers ESC1 and ESC8 intrusion paths.

What to Do This Week

The following steps are standard hardening practice for this kind of threat. Do them this week, then review them as a standing routine.

1. Tell staff to treat unsolicited Teams calls from anyone claiming to be IT as suspicious. The request should be verified through a known channel, such as a phone call to the help desk number, before the employee grants remote control.
2. Restrict remote control tools to a short list of approved software. Require the user to initiate or approve each session, and make sure employees know that approved support staff will not ask them to disable security controls.
3. Review AD CS certificate templates for settings that allow a requester to specify a subject alternative name. Disable or tighten any template that does not require manager approval, and remove unnecessary enrollment permissions.
4. Harden AD CS endpoints against relay attacks. In general, that means limiting who can reach enrollment endpoints, disabling NTLM authentication on them where possible, and enabling extended protection for authentication.
5. Audit certificate issuance for privileged accounts. Treat any certificate issued to a domain controller as highly sensitive, and investigate unexpected requests.
6. Watch authentication logs for anomalous Kerberos activity and for unexpected certificate-based logins. An alert on a new certificate for a privileged account is worth a manual review.

What to Tell Clients

Microsoft has documented an attack chain where a caller posing as IT support used Microsoft Teams to get remote control of an employee's computer. From there, the attacker abused certificate services to create login credentials for privileged accounts, including a domain controller. We treat unsolicited support requests as suspicious and verify them through a known channel.

We are reviewing our certificate services settings and checking for unexpected certificates issued to privileged accounts. If you get a call from someone claiming to be IT and asking for remote access, stop and contact us directly. Do not share a one-time code or approve a session unless you initiated it.

Frequently Asked Questions

Sources

• From help desk impersonation to AD CS abuse: Investigating ESC1 and ESC8 intrusion pathsMicrosoft Security · Reported
• Attackers Pose as IT Support on Microsoft Teams, Abuse AD CS to Steal Company DataHackernews · Reported