The attacker never needed a domain administrator's password. They asked the directory's own certificate service to issue them a credential instead. Microsoft's security teams describe two human-operated intrusions that began with a Microsoft Teams message or call from someone posing as IT support, persuaded the user to hand over remote access, and then abused Active Directory Certificate Services to obtain certificates for privileged accounts. Microsoft says no vulnerability in Teams was involved; the activity relied on social engineering and insecure certificate-service configuration.
A certificate is a credential that outlives a password reset. That is why this is a secrets story as much as an identity one.
What Microsoft describes
- Getting in. Teams messages and calls from an impersonated help desk persuaded victims to grant remote access, mainly through the built-in Quick Assist tool.
- Setting up. The attackers staged portable Python, Bun or Java runtimes, then ran host, network and certificate-service discovery.
- Case one: a bad template (ESC1). A certificate template let the requester supply the subject, so the attacker could ask for a certificate in a privileged user's name. Microsoft reports certificates for three privileged accounts in a first wave and eight more in a second, larger phishing wave that began about 90 minutes after the first was disrupted. Credential replication from the directory, known as DCSync, began within seconds of obtaining a privileged certificate. A privileged account that had been excluded from containment was later used to reach a file server and exfiltrate data with the Rclone tool.
- Case two: relay to web enrolment (ESC8). The attackers coerced a domain controller to authenticate, relayed that authentication to the certificate service's web enrolment endpoint and used the resulting domain-controller machine certificate to obtain a Kerberos ticket.
What is not known
- Who did it. Microsoft does not attribute either case to a named actor.
- How long the intruders were in. Overall dwell time is not stated.
- The full extent of data theft in either case.
- How widespread the pattern is. The report covers two intrusions. It does not say how many organisations were targeted by the same technique.
Why a password reset is not enough
A certificate issued in a privileged user's name lets its holder authenticate as that user for as long as the certificate is valid, whatever happens to the password. Resetting the password, or even disabling and re-enabling the account, does not remove it. Case one also shows a second failure: containment worked, then an account that had been excluded from it became the route to the data. Microsoft's advice is to treat containment exclusions as incident decisions that deserve review.
What to do
- Verify support contacts out of band. Make it a rule that unsolicited Teams messages or calls from “IT” asking for a remote session are confirmed through a known internal channel first. Tell staff the real help desk will never ask them to read out codes or start a remote tool unprompted.
- Restrict remote-support tools and stray runtimes. Use application control to limit remote tools and to block programs that run from user-writable folders.
- Review certificate templates. Look for templates where the requester can supply the subject, and for broad enrolment rights, which is the ESC1 condition. Remove or tighten anything you do not need.
- Close the relay path. Remove web enrolment endpoints you do not use, require HTTPS and Extended Protection for Authentication on those you do, and disable NTLM on enrolment services where feasible.
- Turn on certificate auditing and review issued certificates for privileged accounts you did not expect, then revoke unauthorised ones. Review Kerberos tickets separately, since a ticket obtained with a certificate is a different credential.
- If DCSync may have run, plan a directory-wide credential reset. That means service accounts, privileged accounts and the key-distribution account, done in an order your directory team has rehearsed. This is standard Active Directory recovery practice and is our recommendation, not a step from Microsoft's report.
- Audit your containment exclusions after every incident, and treat each one as a risk to be justified, not a convenience.
The handover during recovery
A directory-wide reset produces dozens of new privileged credentials for the administrators who install them. During an incident that is the moment they get pasted into the chat the attacker may already be watching. Deliver each value once, to the one person who needs it, over a channel that does not depend on the compromised environment.
Where Secretus fits, and where it does not
Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret, such as a break-glass administrator password.
It is not an identity or directory security tool. It cannot harden certificate templates, revoke a certificate, detect a fake help desk or reset a directory. Use Microsoft's guidance and your identity tooling for that, and a one-time link for the moment one person gives another a credential.