Fake IT support on Microsoft Teams led to AD CS certificate abuse; here's how to check your clients' certificate servers.
Fake "IT support" messages on Microsoft Teams got employees to hand over remote control, and the caller came away with login certificates for 11 privileged accounts. Microsoft described that intrusion and a second one on 30 October 2026, both escalated through misconfigured Active Directory Certificate Services (AD CS), the Windows server that issues login certificates. Check every client's certificate templates and enrollment pages today.
The Teams-to-AD CS attack is help desk impersonation on Microsoft Teams followed by abuse of misconfigured AD CS, and Microsoft Threat Intelligence documented it in two real intrusions. In the first, an ESC1 template (one that lets the requester name any account) produced certificates for 3, then 8 more, privileged accounts, and a renamed copy of Rclone, a file-copying tool, sent file-share data to an outside server. In the second, a relayed domain controller login, forced with PetitPotam (CVE-2021-36942, rated 7.5 (CVSS)), made the web enrollment page (ESC8) issue a certificate for that domain controller.
Microsoft says no Teams flaw was involved and named no threat actor. Its sharpest lesson: one privileged account excluded from Defender's automatic response stayed usable after the rest were shut down.
Run these checks on each client's certificate authority (CA) server, a domain admin PC with the ActiveDirectory module, and every workstation through your RMM (remote management tool). Microsoft gives no intrusion dates, so read the CA's full history and the oldest retained logs.
Preserve evidence. Back up the CA database with certutil, export the Security log with wevtutil, then hash both. Pass: the CSV holds one hash line per copied file.
# CA server, elevated PowerShell; keep this session open for check 4
$D = "C:\IR\$env:COMPUTERNAME"; New-Item -ItemType Directory $D -Force | Out-Null
certutil -backupdb "$D\cadb"
wevtutil epl Security "$D\Security.evtx"
Get-ChildItem $D -Recurse -File | Get-FileHash -Algorithm SHA256 | Export-Csv "$D.sha256.csv" -NoTypeInformation
Find ESC1 templates. Lists templates with the "enrollee supplies subject" bit (0x1) set, then the CA's published templates. Pass: no published template from the first list has Client Authentication, Smart Card Logon, PKINIT or Any Purpose on its Extensions tab.
$cfg = (Get-ADRootDSE).configurationNamingContext
$base = "CN=Certificate Templates,CN=Public Key Services,CN=Services,$cfg"
Get-ADObject -SearchBase $base -Filter * -Properties msPKI-Certificate-Name-Flag |
Where-Object { $_.'msPKI-Certificate-Name-Flag' -band 1 } | Select-Object Name
certutil -CATemplates # run on the CA server
Test web enrollment for ESC8. This asks the CA's CertSrv page for a plain-HTTP login, which KB5005413 says relay attacks need. Pass: it prints 000 or 403, not 401.
curl.exe -s -o NUL -w "%{http_code}" http://<ca-host>/certsrv/
Hunt for rogue certificates. Export who requested which certificate on which template. Pass: no ordinary user requested a certificate on a template found in check 2.
# same CA session as check 1
certutil -view -out "RequestID,RequesterName,CommonName,CertificateTemplate,NotBefore,SerialNumber" csv > "$D\issued.csv"
Search workstations for Microsoft's indicators. Through your RMM, this looks for KB-numbered staging folders, a stray SearchApp.exe and the three SHA-256 hashes Microsoft published. Pass: no output.
$h = @('85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17',
'f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001',
'06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7')
Get-CimInstance Win32_UserProfile | ForEach-Object {
$p = $_.LocalPath
Get-ChildItem "$p\AppData\Roaming" -Directory -Force -ErrorAction SilentlyContinue | Where-Object Name -match '^KB\d+$'
Get-ChildItem $p -Recurse -File -Force -Filter SearchApp.exe -ErrorAction SilentlyContinue
Get-ChildItem "$p\Downloads","$p\AppData\Roaming" -Recurse -File -Force -ErrorAction SilentlyContinue |
Get-FileHash -Algorithm SHA256 | Where-Object Hash -in $h
}
Check Defender alerts. For clients on Defender XDR, this advanced hunting query matches the alert-title words Microsoft's own query uses for relay, AD CS and certificate-login activity; it covers only the tenant's retained data. Pass: no rows.
AlertInfo
| where Title has_any ("NTLM relay", "Certificate Services", "PKINIT", "Kerberos ticket request")
| project Timestamp, Title, Severity
Check Teams external access. This shows who outside the tenant can message staff, per Microsoft's cmdlet docs. Pass: AllowedDomains is a named list and ExternalAccessWithTrialTenants reads Blocked.
Get-CsTenantFederationConfiguration | Select-Object AllowFederatedUsers,AllowedDomains,ExternalAccessWithTrialTenants
Close both certificate paths first, then clean up: Microsoft says a password reset or reimage doesn't revoke an issued certificate.
Close ESC1. In the Certificate Templates console, untick "Supply in the request" on each template from check 2, or unpublish it if the client doesn't use it. Pass: check 2 finds no published risky template.
certutil -SetCATemplates -<TemplateName>
Close ESC8. Per KB5005413, set Extended Protection to Required and turn on Require SSL for CertSrv and the enrollment web service in IIS Manager, then restart IIS. Pass: check 3 prints 000 or 403.
iisreset /restart
Remove footholds. Copy check 5's hits into the evidence folder, then isolate and reimage each flagged PC. Pass: check 5 prints nothing on the rebuilt PC.
Revoke rogue certificates. Revoke each serial from check 4 with reason 1 (key compromise), then publish a new revocation list. Pass: each serial appears in certutil -view Revoked csv.
certutil -revoke <SerialNumber> 1
certutil -CRL
Reset credentials. Reset each privileged account a rogue certificate named; if check 6 returns any row, reset krbtgt (the account that signs domain logins) twice, 10 hours apart. Pass: the old password fails and PasswordLastSet shows the second reset.
Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object PasswordLastSet
Hardening (agree with the client first): allow-list Teams. Permit only named partner domains, your own included; staff can then no longer chat with unlisted outside domains. Pass: check 7 shows the list and Blocked.
$list = New-Object Collections.Generic.List[String]
$list.Add("partner.example")
Set-CsTenantFederationConfiguration -AllowedDomainsAsAList $list -ExternalAccessWithTrialTenants "Blocked"
Rerun the checks. Pass: checks 2 to 7 all pass.
KinoSec's autonomous Active Directory pentest checks whether each client's domain can be taken over from an ordinary foothold, such as a certificate template that lets a normal account request an administrator's certificate. It chains what it finds into a path and writes each step up with remediation, in a report you hand your client. These attackers ran an intrusion; a pentest is the same reconnaissance, run with your client's permission, scope limits and a report they can act on. KinoSec doesn't watch Teams chats or stop someone reading out a Quick Assist code; checks 5 to 7 and staff training cover that part.
No. Microsoft says neither intrusion used a Teams flaw: the attackers talked staff into granting remote control, then abused AD CS settings the victims had left permissive. ESC1 and ESC8 were named by SpecterOps researchers in 2021, according to The Hacker News.
First, run certutil -CATemplates on the CA and compare it with the templates whose name flag allows a requester-supplied subject. Second, run curl.exe -s -w "%{http_code}" http://<ca>/certsrv/ and treat a 401 as ESC8 exposure. Third, export requests with certutil -view -out "RequesterName,CertificateTemplate" csv and look for ordinary users requesting on risky templates.
No. Microsoft says a password reset or a reimage leaves an issued certificate valid, so revoke it by serial number with certutil -revoke. Revocation does not cancel Kerberos tickets already issued, which last 10 hours by default, per Microsoft's krbtgt guidance.
Usually not. Microsoft's cmdlet docs show that setting AllowFederatedUsers to False blocks all external domains, while an allowed-domains list keeps chats with named partners. Put your own MSP domain on that list so your technicians stay reachable, and have staff verify any unexpected support request through a known internal channel, as Microsoft advises.