Microsoft Teams Helpdesk Impersonation Chains to AD CS ESC1: 400+ Enterprises Breached — Is Yours Next?
Your organisation’s Microsoft Teams is open right now, and attackers are on the other end — disguised as your own IT helpdesk. In the last week of October 2026, Arctic Wolf Labs documented more than 400 enterprise intrusions that began with a single Teams external chat message pretending to be internal IT support. What followed was not a sophisticated zero-day exploit. It was a perfect blend of human trust and an Active Directory Certificate Services misconfiguration that most organisations have never audited. The result: stolen privileged certificates, lateral movement across the entire network, and terabytes of company data silently uploaded to attacker-controlled cloud storage.
Microsoft published its own threat intelligence on 30 October 2026, confirming that attackers in at least two documented intrusion chains leveraged AD CS ESC1 template abuse to forge certificates for 11 privileged accounts. If your organisation runs AD CS — and most enterprises in India that have not migrated to Azure-only identity do — you are almost certainly exposed to this exact misconfiguration.
- Attackers abuse Microsoft Teams external chat to impersonate IT helpdesk staff and trick employees into granting remote access via Quick Assist.
- Once inside, they exploit AD CS ESC1 template misconfigurations to mint forged certificates for domain-privileged accounts — no password needed.
- Arctic Wolf Labs counted 400+ intrusions following this pattern in a single analysis period (October 2026).
- Data is exfiltrated silently using Rclone to attacker-owned cloud storage; lateral movement leverages PsExec and LSASS credential dumps.
- This attack requires no CVE, no zero-day — it works because Teams allows external contact by default and AD CS is rarely hardened.
- Immediate actions: Disable Teams external access (or enforce strict allow-listing), audit AD CS templates for ESC1 right now, and enforce MFA on certificate enrollment.
How the Attack Chain Works: From One Chat to Total Domain Compromise
The attack is deceptively simple, which is exactly why it is so effective. An employee receives a Teams message from what appears to be an internal helpdesk account. In reality, the message comes from an external Teams tenant — one that attackers have registered with a name like IT Support – [Company Name] or HelpDesk-Tier2. Microsoft’s default Teams configuration allows external federation, meaning anyone with a Microsoft tenant can reach your users directly.
The pretext is always routine: a “security policy update,” a “device compliance check,” or a “suspicious login we need to investigate with you.” The employee is asked to open Quick Assist or another legitimate remote desktop tool and share their screen. Because it looks and feels exactly like a real IT interaction, most employees comply.
From that remote session, attackers move quickly:
- Recon: PowerShell and WMI queries map the domain, identifying AD CS server addresses, installed remote management tools, and accessible file shares.
- AD CS ESC1 exploitation: If the environment has an AD CS certificate authority with overly permissive templates (the ESC1 misconfiguration), attackers use tools like Certify to request a certificate on behalf of any privileged user — including Domain Admin. The certificate is valid, signed by your own CA, and bypasses password and MFA checks entirely.
- Lateral movement: Using the forged certificate, attackers authenticate as domain admins, deploy PsExec for remote command execution, and dump LSASS memory via Task Manager to harvest all cached credentials.
- Data exfiltration: Rclone, a legitimate cloud-sync tool often allowed by endpoint controls, quietly uploads mapped drives, SharePoint libraries, and email archives to attacker-controlled storage.
In the two intrusions Microsoft documented, ESC1 abuse yielded forged certificates for 11 privileged accounts across two intrusion waves. The entire progression from first Teams message to domain-wide certificate theft took under two hours in observed incidents.
What Is AD CS ESC1 and Why Is It So Dangerous?
Active Directory Certificate Services (AD CS) is Microsoft’s on-premises public-key infrastructure service, used by most mid-to-large enterprises in India for internal authentication, VPN, Wi-Fi (802.1X), email signing, and code signing. It is powerful — and when misconfigured, it is catastrophic.
ESC1 is the first and most commonly exploited of the SpecterOps “Certified Pre-Owned” AD CS attack classes. The misconfiguration arises when a certificate template:
- Allows the Subject Alternative Name (SAN) to be specified by the requester (Client Authentication EKU + enrollee-supplies-subject), and
- Is enrollable by a broad group such as Domain Users or Authenticated Users.
When both conditions are met, any authenticated user can request a certificate claiming to be anyone — including the Domain Administrator. The certificate is fully valid, signed by the enterprise CA, and accepted for authentication by all domain services. There is no alert, no anomalous login, and no failed password attempt for defenders to catch.
| Attack Type | Requires Valid Password? | Bypasses MFA? | Leaves Failed Login? |
|---|---|---|---|
| Password spray / brute force | Yes | No | Yes |
| Pass-the-Hash / Pass-the-Ticket | No (hash needed) | No | Partial |
| AD CS ESC1 certificate forgery | No | Yes | No |
This is why AD CS ESC1 is so dangerous: it is invisible to most SIEM rules and bypasses the MFA controls organisations spent years implementing.
The India Factor: Why Indian Enterprises Are Especially Exposed
Many large Indian enterprises — in BFSI, manufacturing, IT/ITeS, and government-adjacent sectors — still run hybrid identity: on-premises AD DS with AD CS for internal PKI, alongside Microsoft 365 and Teams for collaboration. This is exactly the configuration attackers are targeting.
Teams external federation is enabled by default in most India tenants. IT teams often leave it on for partner communication, vendor coordination, or client management. Meanwhile, AD CS was set up years ago by infrastructure teams who may no longer be at the organisation, using templates copied from Microsoft documentation examples that had enrollee-supplied SANs enabled by design.
India also has a significant cultural factor: employees are accustomed to receiving IT support calls and messages from central helpdesk teams, especially after large hybrid-work rollouts. The social engineering pretext is extraordinarily convincing in this context. Zero Trust architecture — with device trust and identity verification at every layer — is the structural answer, but most organisations have only partially deployed it.
What You Should Do Right Now: Sanjay Seth’s Expert Guidance
Having spent three decades securing enterprise networks in India — from Tier-1 BFSI to large campus environments — here is the priority action list I would give any IT leader reading this today:
1. Audit AD CS Templates for ESC1 Today
Run Certify (Certify.exe find /vulnerable) or BloodHound with the AD CS module against your certificate authority to identify templates with enrollee-supplied SAN enabled for broad user groups. Restrict enrollment on any such template to named service accounts only, or disable Subject Alternative Name override. CrowdStrike’s AD CS abuse white paper is an excellent operational reference.
2. Lock Down Teams External Access
In the Microsoft Teams Admin Center, go to Users → External Access. Either disable external federation entirely, or switch from “Allow all external domains” to a strict allow-list of named partner domains. For internal-only organisations, disabling it entirely is the right call — the risk of leaving it open far outweighs the convenience.
3. Enforce Approval Workflows for Certificate Enrollment
For any high-privilege certificate template that cannot be immediately restricted, enable CA Manager Approval so that certificate requests go through a human approval step before issuance. This breaks the silent, instant ESC1 exploitation chain.
4. Block Rclone and Unsanctioned Cloud Sync Tools
Add Rclone, MEGAcmd, and similar cloud-sync binaries to your endpoint’s application blocklist. If your DLP solution is deployed, create a rule that alerts on large volumes of data being uploaded to non-approved cloud storage destinations from workstations.
5. Deploy LSASS Protection
Enable Windows Credential Guard on all Windows 10/11 and Windows Server 2019+ machines. Also set the LSASS protection registry key (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1) to prevent Task Manager-based LSASS dumps.
Frequently Asked Questions
Does this attack work if my organisation uses Azure AD only (no on-premises AD CS)?
In a pure Azure Active Directory (Entra ID) environment with no on-premises AD CS, the ESC1 exploitation component does not apply — Microsoft Entra’s certificate infrastructure does not have the same template misconfiguration model. However, the Teams impersonation and Quick Assist social engineering element still works and can lead to credential theft and remote access abuse. Organisations that use Microsoft Entra Certificate-Based Authentication (CBA) with on-premises subordinate CAs may still have AD CS exposure. Audit your certificate authority deployment regardless.
We have MFA on all accounts. Are we protected?
Not against the AD CS ESC1 component. Certificate-based authentication in Windows environments bypasses traditional MFA at the point of authentication. Once the attacker holds a valid Kerberos certificate (obtained via ESC1), they can authenticate as the target user without triggering an MFA prompt — the certificate is the credential. The only effective controls are: preventing ESC1 exploitation (template hardening), detecting anomalous certificate requests in your CA logs, and deploying Privileged Access Workstations (PAWs) for domain admin activities.
How do I detect if this attack has already happened in my environment?
Check your Certificate Authority event logs for Event ID 4886 (certificate requested) and Event ID 4887 (certificate issued). Look for requests where the Subject Alternative Name field contains a high-privilege account name (Domain Admin, service accounts) submitted by a standard user account. Also review Event ID 4768 and 4769 in your domain controllers’ Security log for Kerberos ticket requests using certificate-based authentication (pre-authentication type 16). Arctic Wolf’s detection guidance is available in their threat research blog.
Is Fortinet’s Zero Trust Network Access (ZTNA) relevant to stopping this?
Yes — significantly. FortiGate ZTNA, integrated with FortiAuthenticator and FortiClient, enforces device posture checks and identity verification for every access request, including lateral movement attempts. An attacker who has compromised a user session via Quick Assist is working from a device whose posture FortiClient can evaluate in real time. If the device has a compromised LSASS or unexpected administrative tools installed, ZTNA policies can quarantine it automatically — before the attacker pivots. I cover this in detail in my write-up on Zero Trust across campus environments with FortiGate and FortiAuthenticator.
The Microsoft Teams helpdesk impersonation wave is a sharp reminder that the human layer and the PKI layer are as critical to defend as the perimeter. Four hundred breaches — logged in a single analysis period by one security vendor — tells you this is not a theoretical risk. It is a live, active campaign targeting enterprises of every size.
If you are not sure whether your AD CS templates are vulnerable, or whether your Teams federation policies are creating exposure, the answer is to find out now — before an attacker does.
At P J Networks, we conduct AD CS posture reviews, Teams external access audits, and full Zero Trust readiness assessments for enterprises across India. Get in touch for a security assessment today — the first conversation is always free.