Fake Teams Help Desk Calls Lead to AD CS Certificate Abuse and Data Theft — Megathread

SC Media reported the warning, citing The Hacker News. Attackers are leveraging social engineering and insecure Active Directory Certificate Services configurations to compromise corporate environments. Microsoft's own investigation, published October 30, 2026, has more detail than the news summaries. It covers how the two intrusions differed, why one ended in data theft, and why changing a password does not undo the damage.

The shared opening: a call from "IT"​

Both intrusions started the same way. Both incidents followed the same initial sequence: help desk impersonation through Teams, a user-approved Quick Assist or other remote-support session, archive transfer and extraction, portable runtime execution, and host and AD CS discovery.

The social engineering was simple. Techaeris summarized it this way: the caller claims to be from IT and walks the user through opening Quick Assist and reading out the connection code. GBHackers noted that organization-themed tenant names and support-oriented display names helped make external contacts appear familiar. That means onmicrosoft.com tenants named to look like your own company's support desk.

Teams itself was not compromised. Microsoft Threat Intelligence says the activity exploited no flaw in Teams. Microsoft's report also points to the "External" and "Scam suspected" labels Teams can show on incoming calls. Those labels only help if users notice them and act on them.

What happened after the user clicked "Allow"​

Microsoft calls the remote session the decisive transition in the attack. Here is the sequence it describes:

• The attacker dropped an archive into the victim's Downloads folder.
• Commands created a staging directory with a KB prefix under the user's profile. The name is meant to look like an update folder.
• The archive was extracted there, and the payload was launched with a portable Python, Bun (JavaScript) or Java runtime.
• The payload collected Windows version, network configuration and running-process information, then connected to domain infrastructure over LDAPS and SMB.

In one variant, a renamed executable still carried version metadata identifying it as the Bun runtime. Another variant used a staged Java runtime to run a Java source file. Microsoft's point is that file names are weak indicators. The sequence is the signal: an unexpected remote session, then a portable runtime launched from a new user-writable folder, then script execution and discovery commands, then connections to identity infrastructure.

Section summary: The attackers used a fake support call, a real Microsoft remote-help tool and a disguised runtime. They needed no exploit and sent no malware attachment.

Case 1: ESC1 template abuse, DCSync and one costly exclusion​

ESC1 is a certificate template misconfiguration. In Microsoft's words, it lets the requester supply identity information in the request and still receive a certificate that works for authentication. Add broad enrollment rights and weak issuance controls, and a low-privileged user can request a certificate that represents a domain admin.

Here is how the first case unfolded, according to Microsoft:

• Wave one: Teams phishing targeted three users and compromised one workstation. The attacker found an ESC1-vulnerable template and obtained certificates for three highly privileged accounts.
• Automated response: Microsoft Defender attack disruption contained the first user and the three certificate-compromised identities. It restricted remote logons and SMB access and disconnected active sessions. One privileged account was excluded from automated response, so containment never reached it.
• Wave two: About 90 minutes later, the attacker sent a larger Teams phishing wave to 16 users and compromised a second workstation. Reusing the same template, they obtained certificates for eight more privileged accounts. Techaeris counted certificates for 11 privileged accounts across two waves.
• Disruption, round two: Defender contained the new identities and blocked more than 1,000 later SMB file-access attempts plus additional logons.
• DCSync: Within seconds of obtaining one privileged certificate, the attacker authenticated to a domain controller and started DCSync while containment was still taking effect. Disruption limited further replication, but the operation had already begun.
• Exfiltration: The attacker used the excluded account to reach a file server and ran a renamed copy of Rclone called SearchApp.exe. It copied file-share data recursively 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.

The automation did its job on every identity it was allowed to touch. The attacker went through the one account it was told to skip. Microsoft's conclusion is that partial identity containment can reduce attack activity and still leave a working privileged route.

Exclusions are usually added for good reasons: a service account, an executive, or a break-glass admin nobody wants locked out. Every one of them is also an account attackers can use.

Section summary: ESC1 turned one phished user into eleven privileged certificates. Automated disruption contained most of them, and a single exclusion was enough for data theft.

Case 2: PetitPotam plus ESC8 turns a workstation into a domain controller​

The second environment had no ESC1 template to abuse, so the attacker attacked the enrollment web service instead. PetitPotam sent requests over the Encrypting File System Remote Protocol to make the domain controller authenticate to an attacker-controlled machine, and that NTLM authentication was relayed to AD CS Web Enrollment, a technique known as ESC8.

The attacker never needed the domain controller's password. According to Microsoft:

• The AD CS server authenticated the DC's machine account even though the connection came from a different device. Microsoft calls that identity-to-source mismatch a strong investigation lead.
• The attacker requested and retrieved a certificate using the Domain Controller template through the /certsrv submission and retrieval endpoints.
• They then used the certificate for Kerberos PKINIT and obtained a ticket-granting ticket (TGT) as the domain controller.

This case ended better. Defender raised ESC8-related alerts. The customer isolated the workstation tied to the certificate enrollment and Kerberos activity, and Microsoft observed no further progression after that.

Microsoft cautions that requests under /certsrv are not malicious by themselves. Web Enrollment is a legitimate service. They become evidence when correlated with the authenticated identity, the source device, the process and the CA request record.

Section summary: ESC8 converted relayed NTLM into a certificate-backed Kerberos identity for a domain controller. Fast device isolation stopped it from going further.

Why there's no patch​

Both attack paths abuse configuration, not code. Microsoft says the activity relied on social engineering and insecure or overly permissive AD CS settings. You can't patch your way out of a certificate template that lets anyone request a certificate for anyone else. You have to fix the template.

These techniques are not new. ESC1 and ESC8 come from the AD CS attack research community years ago, and PetitPotam has been known since 2021, when Microsoft published KB5005413, "Mitigating NTLM Relay Attacks on Active Directory Certificate Services." That's general industry history, not a claim in Microsoft's new report. It does explain why Microsoft's hardening advice still points back to that knowledge base article. The new part is the delivery: a Teams call that walks the attacker straight to an internal workstation, where these older weaknesses are reachable.

Why resetting passwords won't save you​

Microsoft spells out a point many incident responders miss. An authentication certificate for a privileged user or machine account keeps working regardless of what happens to the original password. Resetting the password or reimaging the first workstation does not revoke an issued certificate. It also does not invalidate Kerberos tickets that have already been issued.

Revoking the certificate does not fix that either. Microsoft says revocation does not retroactively invalidate TGTs or service tickets already issued, so active Kerberos sessions need to be reviewed as a separate task.

Hardening checklist for Windows admins​

Microsoft's mitigation guidance falls into four areas.

1. Stop the fake help desk​

• Require users to verify unsolicited support requests through a known internal channel before they join a call, share a screen or start remote control.
• Review Teams external-access and federation policies. Limit external domains to what the business needs, and investigate new organization-themed or helpdesk-themed tenants.
• Restrict remote-support tools to approved products, operators and workflows. Alert when an approved RMM tool extracts archives, starts interpreters or runs scripts from user-writable paths.

2. Constrain portable runtimes​

• Use App Control for Business, or equivalent application control, to block unapproved portable runtimes and script execution from user-writable locations.
• Identify files by signer, original filename, product metadata, path, parent process and behavior, not by the displayed name.
• Test your attack surface reduction rules. Microsoft warns that controls for Windows script hosts do not automatically cover JavaScript run through Bun or source files launched through Java.

3. Fix AD CS​

• Follow KB5005413.
• Audit authentication-capable templates for requester-supplied subject information, broad enrollment permissions, weak issuance requirements and excessive certificate purposes. Remove unnecessary enrollment rights and require manager approval where it makes sense.
• Inventory Web Enrollment and Certificate Enrollment Web Service endpoints, and remove any you don't need.
• Require HTTPS and enforce Extended Protection for Authentication (EPA) on enrollment endpoints. Microsoft notes that HTTPS provides confidentiality, while EPA provides the channel binding that resists NTLM relay. You need both.
• Disable NTLM on enrollment services where you can, but confirm Kerberos-only authentication works before enforcing it broadly.
• Use the Defender for Identity AD CS security posture assessments to find ESC1-exposed templates and insecure IIS enrollment endpoints associated with ESC8.

4. Get ready for certificate-aware incident response​

• Enable the Certification Services advanced audit subcategory for success and failure, and set the CA audit filter to record requests and issuance.
• Preserve CA security events, CA database records, IIS and Web Enrollment logs, endpoint process lineage, identity alerts and Teams interaction records.
• For any unauthorized certificate, find its serial number and thumbprint, revoke it, publish updated revocation information, and confirm relying systems can retrieve it.
• Treat every containment exclusion as a deliberate incident decision. Assign a compensating manual action for it and confirm that action was completed.

Detection notes​

Microsoft lists Defender XDR coverage across the chain. It includes Defender for Identity alerts for ESC1 template abuse and ESC8 machine-certificate issuance abuse, plus a Defender for Endpoint alert for suspicious domain controller authentication to an AD CS server. Alert names and availability depend on product configuration and which sensors are enabled.

For hunting, Microsoft says to rebuild the full chain rather than chase single artifacts:

• ESC1: Correlate the requester identity with the subject and SAN values in the certificate, then look at the first authentication performed with that certificate.
• ESC8: Correlate EFSRPC activity, outbound authentication from the DC, the relaying device, Web Enrollment access, CA records and PKINIT from the originating workstation.

Microsoft also publishes file hashes and advanced hunting queries, and recommends validating them against local telemetry before relying on them. The attackers have already shown they can switch runtimes, so the behavior chain is the more durable detection.

The bottom line​

Neither intrusion used anything advanced. One was a convincing Teams call followed by a certificate template configured too loosely. The other was a fake support call followed by an enrollment endpoint without EPA. AD CS often gets little attention after it's set up, and these cases show what that can cost. When was your template inventory last reviewed? And does anyone know how many accounts are excluded from your automated response policies?

Those two questions would have changed the outcome of Case 1.

Update: Additional details (November 4, 2026)​

In a statement to CNET, a Microsoft representative said the company is rolling out AI-powered phishing detection for higher-risk Teams messaging, particularly first-contact chats with external users.

According to Microsoft’s support documentation, the detection may show a warning but does not automatically block the sender. It may also miss attempts, so the absence of a warning does not mean a message is safe.