Teams helpdesk Quick Assist to AD CS abuse

Nobody stole a typed password at the door. Attackers impersonated IT over Microsoft Teams messages and calls, coaxed employees into approving Quick Assist on workstations that were already signed in, then abused misconfigured Active Directory Certificate Services so privileged authentication no longer depended on the first host or its password. According to the Microsoft Security Blog on 30 October 2026, Microsoft Threat Intelligence investigated two human-operated intrusion paths built on that chain. Microsoft stated the activity did not exploit a vulnerability in Teams. It relied on social engineering plus insecure or overly permissive AD CS configurations. Victim organizations were not named, and no threat actor was attributed.

How fake Teams IT won the desktop

Operators stood up organization-themed onmicrosoft.com tenants and support-oriented display names so chat and call chrome looked like internal help desk traffic. Targets saw familiar branding in a channel they already trusted for IT. The ask was interactive remote control, primarily through Quick Assist, not a login form on a spoofed identity provider page. Microsoft’s write-up does not describe password or one-time-code theft at that step, and it does not name which MFA method sat on the employees’ original sign-ins. The foothold was a user-approved remote session on a machine that already held a legitimate desktop session.

Once the helper window was accepted, the operator could stage tooling the same way a real technician would. Portable runtimes landed on the host. Discovery looked for domain services worth abusing next. That sequence matters for anyone who still frames every “help desk” incident as a stolen OTP story. Here the transferable object at initial access was control of an interactive session the user had already unlocked, not a factor typed into a fake sign-in page. Reimaging or resetting the first password later does not rewind the minutes the operator spent with hands on the keyboard.

Case 1 opened with a Teams phishing wave against three user accounts. One workstation fell. Roughly ninety minutes later a second wave hit sixteen users and compromised another workstation. Case 2 followed the same help-desk theater into a remote session, then diverged into a different certificate path. In both stories the product boundary that failed first was human trust in Teams identity chrome plus a remote-assist prompt, not a CVSS-scored Teams bug.

ESC1, ESC8, and certificates that outlived the first host

From the assisted hosts, operators hunted Active Directory Certificate Services. In Case 1 they abused ESC1-vulnerable templates: enrollment paths that let the requester supply identity information and walk away with authentication certificates for accounts they should never have represented. Wave one produced certificates for three highly privileged accounts. Wave two added certificates for eight more. Across both waves Microsoft counted eleven privileged accounts covered by that enrollment abuse.

Microsoft Defender attack disruption then restricted the covered identities and blocked substantial follow-on activity. Microsoft reported more than 1,000 subsequent SMB file-access attempts plus additional logon attempts stopped after the second-wave disruption. One privileged identity sat outside automated containment. That excluded account stayed usable for network and remote-interactive logons and later ran a renamed Rclone copy that moved file-server data to an attacker SFTP endpoint. DCSync had already started within seconds of the first privileged certificate, while containment was taking effect. Session kills and identity blocks on the accounts Defender fully covered did not retire every certificate-backed path the operators had already minted.

Case 2 used a different AD CS failure mode. Operators combined PetitPotam-style coercion with ESC8, relaying NTLM authentication to AD CS Web Enrollment, and obtained a domain-controller certificate usable for Kerberos PKINIT. Customer teams isolated the workstation after ESC8-related Defender alerts. Microsoft reported no further progression in that case once the host was cut off. The technical lesson still stands: a domain-controller authentication certificate is a different class of secret from the password on the laptop that helped issue it.

According to Microsoft Threat Intelligence, an attacker who obtains an authentication certificate for a privileged user or machine account can use that certificate independently of the initially compromised password. Password reset on the phished employee, or a wipe of the first workstation, leaves issued certificates and related tickets useful until certificate revocation, template lockdown, and ticket invalidation catch up. That is why the intrusion narrative keeps moving after the “reset the user” reflex. The CA became the identity factory. The help-desk call was only the on-ramp.

What containment caught and what certificates ignored

Defenders reading only the Teams chapter will under-scope the blast radius. The chat lures targeted small user sets, three accounts then sixteen, not a mass mailbox dump story. The damage scaled when AD CS handed out privileged authentication material. DCSync and Rclone activity in Case 1 show directory and file-stage objectives after the certificate step, not before it. Microsoft did not publish victim names, exfiltrated record counts, or data types. Those figures remain unknown in the public disclosure.

Operationally, the boring misconfigurations did the expensive work. Templates that allow requester-specified subject information turn any enroll-capable principal into a privileged-identity printer. Web Enrollment endpoints that accept NTLM without channel protections turn coercion into domain-controller-equivalent certificates. Neither failure is fixed by telling employees to “check MFA” harder on a morning login they already completed hours earlier. The remote-assist grant and the CA policy lived downstream of that login.

Similar Teams-themed help-desk theater has shown up in other recent enterprise intrusions that push RMM or remote tools instead of harvesting a password at a fake IdP. The shared pattern is live coaching toward a yes on a support tool while a real session is already open. This Microsoft pair of cases is the cleanest public bridge from that social step into documented ESC1 and ESC8 outcomes, complete with certificate counts, disruption metrics, and an explicit non-attribution statement.

If you want to skip the attack details and go straight to what can stop this class of failure, read the related article on mfa2point0.com: Does MFA stop Teams help desk Quick Assist and AD CS abuse?.

FAQ

Did attackers hack a Microsoft Teams vulnerability?

No. According to the Microsoft Security Blog disclosure on 30 October 2026, the activity did not exploit a vulnerability in Microsoft Teams. Operators used social engineering, organization-themed onmicrosoft.com tenants, support-style display names, and user-approved Quick Assist remote control, then abused insecure AD CS configurations.

How did the Teams help desk impersonation turn into domain privilege?

Operators who won Quick Assist on already-signed-in workstations staged portable tooling, found Active Directory Certificate Services, and enrolled authentication certificates through ESC1-vulnerable templates or, in the second case, ESC8 NTLM relay to Web Enrollment after coercion. Those certificates enabled privileged Kerberos access and DCSync, and a privileged identity left outside automated containment later carried Rclone exfiltration.

Would resetting the employee password have ended the intrusion?

Not by itself. Microsoft Threat Intelligence stated that an authentication certificate for a privileged user or machine account can be used independently of the initially compromised password. Resetting the first user secret or reimaging the first workstation does not revoke certificates already issued or Kerberos tickets already minted from them.

How many privileged certificates did Case 1 produce?

According to Microsoft’s case notes, the first Teams wave supported ESC1 certificates for three highly privileged accounts, and the second wave added certificates for eight more, for eleven privileged accounts across both waves. After disruption on the second wave, more than 1,000 SMB file-access attempts and further logon attempts were blocked, while one privileged identity excluded during the first disruption still supported later SFTP exfiltration via Rclone.

Was a specific threat actor named?

No. Microsoft’s disclosure states the activity described was not attributed to a specific threat actor, and the public write-up does not name victim organizations or the volume of data taken.