Teams Help Desk Scam Uses Quick Assist and AD CS to Steal Privileged Access

CNET reported on the investigation and framed it as a reminder that social engineering still works while most security coverage focuses on AI. The full Microsoft report, published October 30, 2026, matters more to Windows administrators than that framing suggests. The opening move was a phone-scam tactic. What followed was a detailed abuse of Active Directory Certificate Services (AD CS), and in one case it ended in data theft.

How the Teams help desk scam worked​

According to Microsoft, attackers used Teams messages and calls to pose as IT or help desk staff. They talked users into granting interactive remote access, mostly through Quick Assist. Microsoft says no Teams vulnerability was involved. Instead, the attacks relied on "social engineering and insecure or overly permissive AD CS configurations."

The disguise was simple and effective. Attackers used Microsoft Teams messages and calls from organization-themed onmicrosoft.com tenants to impersonate IT support personnel, convincing users to open Quick Assist and share a connection code. Microsoft's report includes a screenshot of a Teams call showing "External" and "Scam suspected" labels. The warnings were there, but the user still had to notice them and act on them.

Microsoft says the remote session was the turning point. Once the user handed over control, the attacker:

1. Placed an archive in the victim's Downloads folder.
2. Created a staging folder with a "KB" prefix under the user's profile, styled to look like a Windows update.
3. Extracted the archive into that folder.
4. Launched attacker-controlled code with a portable Python, JavaScript (Bun) or Java runtime.
5. Ran host and network discovery, including Windows version, network configuration and running processes, then began examining AD CS.

In one variant, a renamed executable kept version metadata identifying it as the Bun runtime. Another used a staged Java runtime to run a Java source file. Microsoft warns that file names alone are weak indicators. The pattern to look for is a portable runtime launched from a newly created, user-writable folder after an unexpected remote session, followed by discovery commands or connections to identity infrastructure. The compromised workstation also connected to domain infrastructure over LDAPS and SMB.

Microsoft did not attribute the activity to any specific threat actor.

Section summary: No malicious attachment and no Teams exploit. The attackers used a convincing support persona, a built-in Windows remote-help tool and legitimate runtimes running from places they shouldn't.

Case 1: ESC1 and the account left out of containment​

In the first environment, the initial Teams phishing wave targeted three users and compromised one workstation. The attackers found a certificate template vulnerable to ESC1. That misconfiguration lets a requester supply identity information in the certificate request and receive an authentication-capable certificate. Combined with broad enrollment rights and weak issuance controls, it allows a low-privileged account to obtain a certificate for a privileged one.

The attackers got certificates for three highly privileged accounts. Microsoft Defender attack disruption restricted the original user and those three identities, blocked remote logons and SMB access, and disconnected active sessions. However, one privileged account had been excluded from automated response, so containment never applied to it.

The attackers kept going:

• About 90 minutes after the first disruption, a larger Teams phishing wave targeted 16 users and compromised a second workstation.
• The same ESC1 template produced certificates for eight more privileged accounts. Across both waves, ESC1 template abuse yielded certificates for 11 privileged accounts.
• Attack disruption blocked more than 1,000 later SMB file-access attempts plus further logon attempts.
• Within seconds of obtaining one privileged certificate, the attacker authenticated to a domain controller and started DCSync while containment was still taking effect.

The excluded account caused the real damage. The attacker used it to reach a file server and run a renamed copy of Rclone called SearchApp.exe. The tool copied data to an external SFTP server using 20 concurrent transfers. It selected files up to three years old and skipped executables, databases, virtual disks, media, temp files and logs.

Section summary: Automated disruption blocked a lot, but one exclusion left a privileged account usable, and that account was used for data theft.

Case 2: PetitPotam and ESC8​

The second environment had no ESC1 template to abuse, so the same help desk impersonation entry followed a different escalation path. The attacker used PetitPotam, which sends requests over the Encrypting File System Remote Protocol (EFSRPC), to make a domain controller authenticate to an attacker-controlled system with its machine account. The attacker relayed that NTLM authentication to AD CS Web Enrollment, which is the ESC8 technique. This produced a certificate for the domain controller account using the Domain Controller template, without the attacker ever knowing the domain controller's password.

The attacker then used that certificate for Kerberos PKINIT and obtained a ticket-granting ticket for the domain controller. Microsoft calls PKINIT success the response threshold. It also points to a useful investigation lead: the AD CS server authenticated the domain controller's machine account even though the connection came from a different device.

Defender raised ESC8-related alerts. The customer isolated the associated workstation, and Microsoft observed no further attacker activity after that.

Section summary: Same entry point, different certificate technique, and a better outcome because the device doing the enrollment was isolated.

Password resets won't remove certificate access​

Microsoft says that once an attacker holds an authentication certificate for a privileged user or machine, they can use it independently of the original password. Resetting the user's password or reimaging the first workstation does not revoke an issued certificate or invalidate Kerberos tickets already issued. Revoking the certificate also doesn't retroactively cancel tickets that already exist, so certificate revocation and Kerberos ticket review are separate tasks.

Many incident response playbooks still end with resetting the password and reimaging the laptop. Against ESC1 or ESC8 abuse, that leaves the attacker's access intact.

What Microsoft says it's changing in Teams​

In a statement to CNET, a Microsoft representative said the company is rolling out AI-powered phishing detection for higher-risk messaging scenarios, especially first-contact chats with external users. CNET reported that Microsoft's Teams roadmap also lists ways to report suspicious guest invitations and blurring of QR codes from external senders.

Microsoft's support documentation describes how the phishing detection works. When a conversation with a new external contact starts, Teams briefly analyzes recent messages and conversation context, and it may show a warning. The warning is advisory only: Teams doesn't automatically block the sender. Microsoft also states plainly that the detection may not catch every attempt, and users shouldn't assume a message is safe just because there's no warning.

The rest falls to customers. Microsoft's spokesperson told CNET that users should verify a sender's identity and request before acting on it. Administrators can block external Teams users and limit which employees may chat or meet with people outside the organization.

That position is fair up to a point. Teams did show "External" and scam-suspected labels in Microsoft's example. But a system that relies on stressed employees reading a small label during a confident "urgent security update" call is partly asking users to be the last line of defense. Teams warnings help, and configuration choices made long before the call help more.

Action list for Windows and Teams admins​

These steps come from Microsoft's recommendations in its October 30 report:

Reduce help desk impersonation risk

• Require users to verify any unsolicited support request through a known internal channel before joining a call, sharing a screen or starting remote control.
• Review Teams external access and federation policies. Allow only the external domains the business needs, and investigate new tenants with organization-themed or help-desk-themed names.
• Check files by signer, original filename, product metadata, path, parent process and behavior. A renamed executable can still carry legitimate version information.
• Test attack surface reduction rules, and don't assume controls for Windows script hosts also cover JavaScript run through Bun or source files launched through Java.
• Several security write-ups on the incidents also suggest you restrict or disable Quick Assist where it is not needed.

Harden AD CS against ESC1 and ESC8

• Apply Microsoft's KB5005413 guidance on mitigating NTLM relay against AD CS.
• Audit authentication-capable templates for requester-supplied subject information, broad enrollment permissions, weak issuance requirements and excessive certificate purposes. Require approval where appropriate.
• List all Web Enrollment and Certificate Enrollment Web Service endpoints and remove the ones you don't need.
• Require HTTPS and enforce Extended Protection for Authentication (EPA) on enrollment endpoints. HTTPS protects confidentiality, and EPA provides the channel binding that resists relay.
• Disable NTLM on enrollment services where you can, after confirming Kerberos-only authentication works.
• Use the Defender for Identity AD CS posture assessments to find ESC1 template exposure and insecure enrollment IIS endpoints.

Prepare certificate-aware response

• Enable the Certification Services advanced audit subcategory for success and failure, and set the CA audit filter to record requests and issuances.
• If an unauthorized certificate was issued, record its serial number and thumbprint, revoke it, publish updated revocation information, and check that relying systems receive the update.
• Treat containment exclusions as incident decisions. If an identity can't be contained automatically, assign a manual action and confirm it was completed.

Social engineering is still the entry point​

CNET quoted Yu Cai, associate director of Michigan Tech's Institute of Computing and Cybersystems. He said AI and human-led attacks aren't separate categories, since AI tools such as voice cloning can make scams more convincing. Microsoft's report does not say either intrusion used AI-generated voices or deepfakes. The attackers in these two cases succeeded with a believable display name, a plausible request and an employee who wanted to help.

This isn't Microsoft's first warning about the tactic. In September 2026, Microsoft Threat Intelligence described a separate campaign that also abused Teams external collaboration to impersonate IT staff. In that campaign, remote-support access led to a malicious MSI, a portable Node.js implant, and lateral movement over WinRM toward domain controllers and certificate authorities. That campaign is distinct from the two October cases, but the pattern is the same: Teams has become a common channel for social engineering.

Microsoft's report says no Teams vulnerability was involved, and that's accurate. The weaknesses were procedural: users with no reliable way to verify the help desk, external access open to any tenant, certificate templates that issue privileged certificates on request, and an automation exclusion nobody revisited. Teams can't patch those for you, so admins need to fix them before an attacker calls.