Skip to main content

Teams helpdesk impersonation led to AD CS abuse in two Microsoft cases

Microsoft's October case study follows fake support contacts into privileged certificate access. Recovery has to consider issued certificates and sessions alongside the first device.

Two plain dark equipment enclosures behind a glass partition, with warm light on the left and cool light on the right.
TechKili · AI-generated conceptual illustration with Cloudflare Workers AI FLUX.2 klein.
Share this article:
In this article

Microsoft traced two intrusions from fake IT-support contacts on Teams to abuse of Active Directory Certificate Services, the infrastructure that issues authentication certificates in some Windows organisations. The practical lesson is that recovering the first workstation may leave other forms of access to investigate.

The case study was published on October 30, 2026, before CNET's originating coverage on November 4. Those dates describe disclosure and reporting, not the start of the intrusions. Microsoft attributes the entry path to social engineering, not a Teams vulnerability.

A certificate can outlast the initial foothold

In both cases, users were persuaded to grant remote access, primarily through Quick Assist. Attackers then reached certificate infrastructure. One case abused a permissive certificate template, known as ESC1; the other used an authentication-relay path known as ESC8.

Microsoft reports that a privileged identity excluded from automated containment remained usable in the first case and later supported data theft. In the second, customer-led workstation isolation followed alerts, with no further progression observed. These are two different outcomes, rather than evidence that a single defensive product always stops the chain.

The report warns that a password reset does not revoke an issued certificate. Responders also need to assess existing Kerberos authentication tickets separately. The recovery question is therefore which identities and credentials remain usable, not merely whether the original remote session has ended.

Hardening the enrollment service is a separate task

Microsoft's AD CS relay guidance recommends Extended Protection for Authentication and HTTPS for relevant enrollment services, plus restricting NTLM where feasible. These controls address the certificate service; updating a collaboration client does not perform that configuration work.

Administrators should use the guidance to review their own enrollment endpoints and authentication dependencies. A setting needs to fit the deployed service and be validated before broad changes. The case study is a reason to inspect exposure, not proof that every organisation using Teams has the same certificate configuration.

Verify support before approving control

Microsoft's Teams security guidance tells users to verify unfamiliar senders and gives administrators controls over external communications. A familiar display name is insufficient evidence of an internal technician.

For an unexpected request, confirm it through an established internal support channel before granting remote control. If access has already been approved, report it promptly so responders can connect the conversation, endpoint activity and identity records. That escalation gives the organisation a chance to investigate the whole path rather than treating the chat as an isolated suspicious message.

Sources