Microsoft says attackers posing as IT support on Microsoft Teams talked employees into giving them remote control of their PCs and then abused insecure Active Directory Certificate Services settings to obtain login certificates for privileged accounts, including one for a domain controller. In one of two intrusions, the attackers copied company data to an external server, and Microsoft did not link the activity to any known group.
What the intrusions looked like
Both intrusions began with messages and calls on Teams from outside tenants that used support-themed names so the contact appeared familiar. The attackers persuaded each target to open Quick Assist, the Windows remote-help tool, and read back a connection code, which gave them direct control of the workstation. From there, they dropped an archive into the Downloads folder, unpacked it into a new folder that looked like a Windows update, and executed it with a portable Python, Bun, or Java runtime. One copy was renamed, but the runtime version details still gave it away.
How certificate abuse extended access
AD CS issues the certificates users and computers present when they log in. Microsoft said a certificate from a badly configured template can let the holder sign in as the account named on it, and that the access can survive a password reset or even wiping the first machine used in the attack. The company said the attackers did not exploit a flaw in Teams itself. They relied on social engineering and on insecure AD CS configuration.
First intrusion left one path open
In the first intrusion, the attackers found a certificate template weakness known as ESC1. That weakness let the requester name the account the certificate would represent, so a low-privileged user could request one for a privileged account. The first wave of calls targeted three users and one workstation and produced certificates for three highly privileged accounts. Microsoft Defender’s automatic attack disruption cut those identities off and dropped their active sessions, but one privileged account was left out of that response and remained usable.
About 90 minutes later, a larger wave targeted 16 users and a second workstation and produced certificates for eight more privileged accounts. Microsoft said more than 1,000 later attempts to reach files over SMB or to log in were blocked. Within seconds of getting a certificate, the attacker signed in to a domain controller and ran DCSync to copy password data from Active Directory. The operation had already started when containment took hold, and Microsoft did not say how much credential data was taken. The excluded account remained the opening, the attacker kept using it, reached a file server, and ran a renamed copy of Rclone to move data from a share to an outside SFTP server. Microsoft did not say how much data was taken.
Second intrusion used relayed authentication
The second intrusion followed the same opening steps, but a different certificate path was available because the first weakness was absent. The attacker used PetitPotam to force a domain controller to authenticate to a machine under attacker control. That NTLM login was relayed to the AD CS web enrollment page through ESC8, which did not require a password. The attacker used the relayed login to request a certificate for the domain controller itself. With that certificate and Kerberos PKINIT, the attacker obtained a ticket-granting ticket for the domain controller.
This case was contained. Defender raised ESC8 alerts, the customer isolated the workstation, and Microsoft said no further activity followed. The difference between the two cases came down to containment, since the first left one privileged account open while the second was stopped by isolating a single workstation.
Defender guidance centers on configuration
Microsoft said there is no patch because the issues involved configuration and response rather than software flaws. It recommends confirming unexpected support requests through a known internal channel before sharing a screen or giving remote control, limiting which outside Teams tenants can reach employees, and allowing only approved remote-support tools. It also says administrators should review certificate templates that let the requester name the account or that allow too many users to enroll, and remove unneeded enrollment rights.
The company also advises requiring HTTPS and enabling Extended Protection for Authentication on web enrollment endpoints, turning off NTLM there where possible, and using KB5005413 along with Defender for Identity posture checks to flag ESC1 and ESC8 exposure. Certificate auditing should be enabled, bad certificates should be revoked, and active Kerberos tickets should be reviewed separately because revocation does not cancel tickets already issued. Any account left out of automatic containment should be treated as a deliberate choice and given a manual response.
What Microsoft says remains unknown
Microsoft did not name a group and did not give the dates of the intrusions. It said the techniques are not new, noting that researchers named ESC1 and ESC8 in 2021 and that PetitPotam was disclosed the same year. Microsoft had also documented the Teams help-desk-to-remote-access entry method earlier in 2026. The company said the report shows how the two techniques can combine in real intrusions and highlights the risk of leaving one privileged account outside containment. It also said newer Windows is less exposed to ESC8 because Windows Server 2025 turns on EPA by default, while Server 2022 and 2019 need it enabled manually.
Indicators and detection data
Microsoft’s report lists Defender alerts across Teams, endpoints, and identity signals, and four advanced hunting queries that it describes as starting points for investigation rather than proof on their own. It also published three file hashes tied to the initial-access scripts.
| SHA-256 | Description |
|---|---|
| 85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17 | JavaScript initial-access script |
| f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001 | Python initial-access script |
| 06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7 | Python initial-access script |