Microsoft

Microsoft says attackers used Teams support lures to steal certificates

IT support scam and certificate theft illustration

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

Leave a Reply

Your email address will not be published. Required fields are marked *

🧰

Free Tools: IP, DNS, SSL

40+ free network and other tools in one place. No signup. Click explore or visit https://technochat.in/tools

Explore