No zero-day. No malware-laced attachment. No exploit chain worth a conference talk.

Microsoft just published an investigation into two intrusions where the entire entry point was a phone call on Microsoft Teams from someone claiming to be the help desk, and the whole thing worked because employees did what most of us would do, which is trust a message that looks like it came from internal IT.

The attackers then abused Active Directory Certificate Services to mint login certificates for privileged accounts, including one for a domain controller. In one of the two cases, company data ended up on an external server.

The Call That Started It

Both intrusions opened the same way. Attackers messaged and called employees on Teams, posing as the company's own IT or help desk, and they did it from outside tenants with support-themed names so the contact looked familiar at a glance.

They talked each user into opening Quick Assist, the remote-help tool built into Windows, and reading the connection code back to them over the call. That single code handed the attacker direct, hands-on control of the workstation.

From there, the attacker dropped an archive into the Downloads folder, unpacked it into a new folder named to resemble a Windows update, and ran its contents using a portable Python, Bun, or Java runtime.

File names alone were a weak signal, because one copy had been renamed while still carrying the real runtime's version details embedded in it.

Why a Certificate Is Worse Than a Password

AD CS is the Windows role that issues the certificates users and machines present when they authenticate. When a template is configured badly, whoever holds a certificate from it can sign in as the account that certificate names.

Microsoft's report makes one point that should reshape how you think about incident response. That certificate keeps working after the account's password gets reset. It keeps working after the first machine gets wiped.

Neither of those steps ends the attacker's access. That is why certificate abuse shows up so often in ransomware intrusions now, and why "we reset the password" is no longer a complete answer.

Case One: ESC1, Three Privileged Accounts, and One That Slipped Through

The first intrusion found a certificate template with a weakness tracked as ESC1. With that template, the requester can name which account the certificate represents, which means a low-privileged user can ask for one that impersonates a domain admin.

The first wave of calls hit three users and one workstation, and it produced certificates for three highly privileged accounts. Microsoft Defender's automatic attack disruption cut those identities off and killed their active sessions.

One privileged account had been left out of the automatic response. It stayed usable.

About ninety minutes later, a larger wave landed on sixteen users and a second workstation, producing certificates for eight more privileged accounts. Microsoft says more than 1,000 subsequent attempts to reach files over SMB or to log in were blocked.

Within seconds of obtaining a certificate, the attacker signed into a domain controller and ran DCSync, the tool for replicating password data out of Active Directory. Containment had already begun, which limited how much could be replicated. Microsoft did not say how much credential data the attacker actually got.

The excluded account was the opening. The attacker kept using it, reached a file server, and ran a renamed copy of Rclone to push data from a share to an outside SFTP server.

Microsoft's own summary of the case is the sentence worth remembering. Partial identity containment can reduce attack activity while still leaving a viable privileged route.

Case Two: PetitPotam, ESC8, and a Domain Controller Certificate

The second intrusion started the same way but went somewhere else, because that ESC1 template weakness was not present.

Instead, the attacker used PetitPotam to force a domain controller to authenticate to a machine the attacker controlled. That NTLM login got relayed to the AD CS web enrollment page, a technique tracked as ESC8, and it required no password at all.

The attacker used the relayed login to request a certificate for the domain controller itself. With that certificate in hand and Kerberos PKINIT, they obtained a ticket-granting ticket for the domain controller, which turned a one-off relayed login into a durable identity.

This time the response held. Defender raised ESC8 alerts, the customer isolated the workstation, and Microsoft says nothing followed.

Where the Two Cases Diverged

The difference came down to containment, and to one account being left out of an automated response that otherwise worked.

What Defenders Actually Need to Change

There is no patch here, because nothing in this chain was a software flaw. Microsoft's guidance is about configuration and about response discipline.

• Verify support requests through a channel you already trust. Before anyone shares a screen or hands over remote control, they confirm through a known internal phone number or a ticket they can see.
• Limit which outside Teams tenants can reach your employees. And allow only approved remote-support tools, not whatever a caller asks someone to open.
• Review your certificate templates. Look for ones that let the requester name the account, or that too many users can enroll in. Remove enrollment rights nobody needs.
• Require HTTPS and turn on Extended Protection for Authentication on web enrollment endpoints. Turn off NTLM there where you can. Microsoft's KB5005413 covers the details.
• Use Defender for Identity posture checks. They flag templates and endpoints exposed to ESC1 and ESC8.
• Turn on certificate auditing. If a bad certificate gets issued, revoke it, but understand that revocation does not cancel Kerberos tickets already issued. Review active tickets separately.
• Treat any account excluded from automatic containment as a deliberate decision. If you leave it out, assign a manual action in its place.

One environmental note worth checking. Windows Server 2025 enables EPA by default for AD CS, while Server 2022 and 2019 require you to turn it on yourself. If you are still on the older versions, that switch is probably still off.

Indicators of Compromise

Microsoft published three SHA-256 hashes tied to the initial-access scripts.

• 85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17 (JavaScript initial-access script)
• f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001 (Python initial-access script)
• 06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7 (Python initial-access script)

The report also lists Defender alerts across Teams, endpoint, and identity telemetry, plus four advanced hunting queries that Microsoft describes as starting points for investigation rather than proof on their own.

FAQ

What was the actual entry point in these attacks?

A phone call on Microsoft Teams. The attacker posed as internal IT support from an outside tenant with a support-themed name, convinced the employee to open Quick Assist, and had them read the connection code out loud. That code gave full remote control of the workstation.

Was there a vulnerability in Teams?

No. Microsoft is clear that Teams itself was not flawed. The attacker relied on social engineering, and on Active Directory Certificate Services being configured insecurely.

What is ESC1?

It is a misconfigured certificate template that lets the person requesting a certificate name which account the certificate represents. A low-privileged user can request one that stands in for a domain admin, which is exactly what happened in the first intrusion.

What is ESC8?

It is an NTLM relay against the AD CS web enrollment endpoint. An attacker coerces a machine, like a domain controller, into authenticating to them using PetitPotam, then relays that login to the enrollment page to request a certificate with no password.

Why doesn't a password reset fix this?

Because the certificate stays valid after the password changes. It also survives wiping the original machine. The attacker keeps a working credential until the certificate is revoked and any Kerberos tickets already issued are dealt with.

What went wrong in the first case?

Defender's automatic disruption worked, but one privileged account had been excluded from the automatic response. That single excluded identity stayed usable, and the attacker kept using it to reach a file server and move data out.

What should I check on my own network?

Review your certificate templates for ESC1 conditions, confirm EPA and HTTPS are enforced on web enrollment endpoints, turn off NTLM there where possible, and confirm that every account has a manual action assigned if it is excluded from automatic containment.

Source: The Hacker News