Why MFA misses Teams Quick Assist AD CS abuse

A yes on Quick Assist is not a login challenge. According to the Microsoft Security Blog on 30 October 2026, Microsoft Threat Intelligence investigated two human-operated intrusions where operators impersonated IT over Microsoft Teams messages and calls, won user-approved remote control on already-signed-in workstations, and abused misconfigured Active Directory Certificate Services for privileged authentication certificates. Device-bound phishing-proof sign-in does not prevent that remote-assist grant, and it does not revoke certificates a weak CA already issued. Defenders need collaboration policy, remote-assist lockdown, and AD CS hardening, not a different OTP at morning sign-in.

What Microsoft disclosed from Teams chat to certificates

Microsoft’s public cases share one on-ramp. Operators stood up organization-themed onmicrosoft.com tenants and support-style display names so Teams chrome looked like internal help desk traffic. Targets approved interactive remote control, primarily through Quick Assist, on machines that already held legitimate desktop sessions. 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 the activity was not attributed to a specific threat actor.

Case 1 opened with a Teams wave against three user accounts and one compromised workstation. ESC1-vulnerable templates let requesters supply identity information and walk away with authentication certificates for three highly privileged accounts. About ninety minutes later a second wave hit sixteen users, compromised another workstation, and produced certificates for eight more privileged accounts. Across both waves Microsoft counted eleven privileged accounts covered by that enrollment abuse. Defender attack disruption then constrained many covered identities and blocked more than 1,000 subsequent SMB file-access attempts plus further logon attempts. Operators ran DCSync within seconds of obtaining one privileged certificate, while containment was taking effect. One privileged identity excluded from automated containment stayed usable and later carried Rclone exfiltration from a file server to attacker SFTP.

Case 2 followed the same help desk theater into a remote session, then used PetitPotam-style coercion with ESC8 NTLM relay to AD CS Web Enrollment. Operators obtained a domain-controller certificate usable for Kerberos PKINIT. Customer teams isolated the workstation after ESC8-related Defender alerts, and Microsoft reported no further progression once the host was cut off.

Microsoft Threat Intelligence put the certificate problem in plain language: 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 or reimaging the first workstation leaves issued certificates and related tickets useful until revocation and template fixes catch up. The full attack narrative, case tables, and disruption timeline sit on the companion write-up at legacymfa.sucks.

Why a stronger sign-in factor never saw this path

Initial access never asked the employee to type a password, paste an OTP, or finish a proxied IdP form. The workstation was already unlocked under a real session. The transferable object was interactive control the user handed over after fake IT coaching in Teams. Microsoft’s disclosure does not name the MFA method on those original logins, does not describe password or OTP theft at the door, and does not describe AiTM or Temporary Access Pass abuse at recovery. The source never showed a failed MFA login ceremony.

From the assisted host, operators staged portable runtimes, discovered AD CS, and enrolled authentication material the CA should never have issued. ESC1 templates that accept requester-supplied subject information turn any enroll-capable principal into a privileged-identity printer. ESC8 Web Enrollment that accepts unprotected NTLM turns coercion into domain-controller-equivalent certificates. Those steps sit after the desktop session exists. They are certificate enrollment and Kerberos PKINIT problems, not interactive workforce MFA prompts.

Containment still mattered. Automated disruption shrank follow-on noise after the second Case 1 wave. Isolation ended Case 2 before further progression. Neither outcome came from a second factor on the morning login the employee had already completed. Session kills on identities Defender fully covered also did not retire every certificate-backed path operators had already minted from the CA.

Similar enterprise patterns push RMM or remote tools after help desk theater instead of harvesting a factor on a fake sign-in page. The shared failure is a coached yes on a support tool while a real session is open. Certificate Services then multiplies that foothold into identities that ignore the first password. Password reset and first-host recovery alone are incomplete once AD CS has printed authentication certificates.

What device-bound MFA changes, and what it leaves alone

Device-bound, phishing-proof authentication removes transferable secrets at workforce sign-in. Private keys stay on hardware. Signatures are origin-bound. There is no OTP, push, or recovery code for an attacker to coach across a fake page when the attack actually is a fake page. That class of prevention applies to credential-phase AiTM, push fatigue, and helpdesk re-enrollment that hands out a typed factor. Prevention, Not Detection covers those login paths.

This Microsoft pair is a different surface. Quick Assist approval on a live session is a remote-assist and collaboration-trust decision. Phishing-proof device-bound MFA does not intercept that grant, and it does not sit in the AD CS enrollment path that minted privileged certificates afterward. Device-bound keys alone would not have blocked the intrusion; login cryptography does not substitute for endpoint control and CA policy. The scoped win is stopping phishable sign-in ceremonies, not every post-session admin tool.

Passkeys and FIDO2-style WebAuthn are phishing-resistant at the login act. A generic enterprise IdP that issues only hardware-bound signatures still binds the authentication ceremony to the real origin and keeps the private key off the wire. That hardens authentication. It does not, by itself, police a Teams remote-assist prompt or fix ESC1 templates that allow requester-specified identities. Full-lifecycle phishing-proof design goes further by refusing phishable factors at registration, device onboarding, authorisation, authentication, and decommissioning, which is why phishing-proof coverage is stronger than phishing-resistant login alone. Even that full-lifecycle coverage still does not turn a CA misconfiguration into a non-issue after an operator already has keyboard control.

Microsoft did not describe a helpdesk factor reset or new-device enrollment path in these cases. The social engineering ask was remote control, not a Temporary Access Pass read-out or a recovery secret. Enrollment and recovery remain the usual weak joints in other workforce breaches, and phishing-proof design closes those joints by requiring an already-enrolled device instead of a transferable code. That architecture is still worth deploying for the attacks that actually hit enrollment. It is not the control that would have stopped these Quick Assist grants or the ESC1 and ESC8 enrollments that followed.

Key takeaways for defenders

• Treat Teams help desk chrome as an untrusted identity surface: verify out-of-band before any remote-assist approval, and restrict who can initiate Quick Assist-style control.
• Inventory AD CS for ESC1-class templates that allow requester-supplied identities, and remove enrollment rights that can mint privileged authentication certificates.
• Harden or isolate Web Enrollment against NTLM relay, and monitor PetitPotam-style coercion paths that feed ESC8.
• Assume issued authentication certificates survive password reset and first-host reimage until you revoke certificates, invalidate tickets, and fix templates.
• Keep phishing-proof sign-in for credential-phase attacks, and stop expecting login MFA to police post-session remote tools or CA abuse.

The forward path is explicit sign-on discipline where login still matters, plus boring CA and collaboration engineering where this chain actually lived. Fake IT will keep calling. The expensive part is still a CA that prints privileged keys for anyone who already has a foothold.

FAQ

Does MFA stop Teams help desk Quick Assist social engineering?

No. In the Microsoft Teams help desk impersonation cases disclosed on 30 October 2026, operators won user-approved Quick Assist on workstations that were already signed in. Login MFA had already completed earlier. Device-bound phishing-proof authentication still does not block a remote-assist grant on a live session, so it would not have stopped that initial access step.

Would passkeys have stopped the AD CS certificate abuse?

No. Passkeys are phishing-resistant at authentication, and phishing-proof device-bound MFA covers the full identity lifecycle, but ESC1 and ESC8 abuse happened after operators already controlled a workstation. Certificate enrollment from a misconfigured CA is outside the interactive login ceremony. Template lockdown, enrollment rights, Web Enrollment channel protections, and certificate revocation address that stage.

Why did password reset fail to end the intrusion?

According to Microsoft Threat Intelligence, an authentication certificate for a privileged user or machine account can be used independently of the initially compromised password. Resetting the first employee secret or reimaging the first host does not revoke certificates already issued or Kerberos tickets already minted from them. In Case 1, a privileged identity excluded from automated containment stayed usable after disruption constrained other accounts, and it later carried Rclone exfiltration to attacker SFTP.

What should security teams fix first after reading these cases?

Security teams should restrict and verify remote-assist tools reached through Teams, then audit AD CS for ESC1-vulnerable templates and ESC8 NTLM relay exposure on Web Enrollment. Microsoft’s cases show eleven privileged certificates across two Case 1 waves and a domain-controller certificate path in Case 2. Those CA failures scaled small user sets (three accounts, then sixteen) into directory-level access. Login MFA upgrades alone do not retire that blast radius.

Is this the same failure as helpdesk TAP or AiTM login phishing?

No. Microsoft’s write-up does not describe password or OTP theft, AiTM proxies, or helpdesk re-enrollment factors at initial access. The shared social-engineering flavor is live coaching, but the object transferred here was interactive control of an existing desktop session, then CA-issued certificates. Credential-phase phishing kits need phishing-proof sign-in. This path needs remote-assist policy and AD CS repair.