Microsoft reports Teams help desk scam paths to AD CS ESC1 and ESC8 abuse

What happened

Microsoft Threat Intelligence reports that it investigated two human-operated intrusions. In both, threat actors used Microsoft Teams messages and calls to impersonate IT or help desk staff and persuaded users to grant remote access, mainly through Quick Assist (Microsoft Security).

According to Microsoft, once connected, the attackers took these steps (Microsoft Security):

• They placed an archive in the user’s Downloads folder.
• They extracted it into a KB-prefixed staging directory under the user’s profile.
• They ran the payload with portable Python, Bun or Java runtimes.
• They ran host and network discovery and assessed AD CS for certificate-based authentication paths.

Microsoft says the two cases then diverged:

• Case 1 (ESC1): The attacker abused an ESC1-vulnerable certificate template to obtain authentication certificates for privileged accounts and performed DCSync. Microsoft says Defender attack disruption restricted covered identities. However, a privileged identity excluded from automated containment remained usable and later supported data exfiltration (Microsoft Security).
• Case 2 (ESC8): The attacker used PetitPotam to coerce domain-controller authentication. The attacker then relayed the domain controller’s NTLM authentication to AD CS Web Enrollment, obtained a certificate for the domain-controller account, and used it for PKINIT Kerberos authentication. Microsoft says the customer isolated the workstation after ESC8-related alerts, and no further progression was observed (Microsoft Security).

Microsoft states that the activity did not exploit a vulnerability in Microsoft Teams. Instead, it relied on social engineering and insecure or overly permissive AD CS configurations. Microsoft also says the activity is not attributed to a specific threat actor (Microsoft Security).

The following are not confirmed:

• Which organisations were affected.
• How many organisations were targeted beyond the two cases.
• What data, or how much data, was exfiltrated in Case 1.

The source does not associate any CVE with this activity.

Am I affected?

Microsoft describes the following exposure conditions (Microsoft Security):

• ESC1 exposure: An authentication-capable certificate template permits requester-supplied identity information and broad enrollment. This lets a low-privileged user obtain a certificate for a privileged account.
• ESC8 exposure: An AD CS web enrollment endpoint lacks relay protections. This lets a relayed NTLM authentication be used to request a certificate as that identity.
• Signs of intrusion: Microsoft lists these signals:
  • An unexpected Quick Assist or other remote-support session started after an external Teams contact. Microsoft notes these contacts used organisation-themed onmicrosoft.com tenant names and support-style display names.
  • A portable or renamed runtime launched from a newly created user-writable directory.
  • Discovery commands, or LDAPS and SMB connections to domain infrastructure, following such a session.
• Containment exclusions: Microsoft says identities excluded from automated containment can remain usable by an attacker.

What to do now

1. Review AD CS certificate templates for the ESC1 conditions Microsoft describes: requester-supplied identity combined with authentication use and broad enrollment (Microsoft Security).
2. Check whether AD CS Web Enrollment endpoints lack relay protections, which is the ESC8 condition Microsoft describes (Microsoft Security).
3. If you suspect compromise, review issued certificates as well as passwords. Microsoft notes that resetting a password or reimaging the first workstation does not revoke an issued certificate. It also does not invalidate Kerberos tickets already issued (Microsoft Security).
4. Review exclusions from automated containment, especially for privileged identities. Microsoft says an excluded identity preserved the attacker’s path in Case 1 (Microsoft Security).
5. Hunt for portable runtimes launched from new user-profile staging directories after remote-support sessions. Microsoft says file names alone are weak indicators (Microsoft Security).
6. Brief users on support impersonation via Teams. Microsoft’s post includes an example Teams call showing “External” and “Scam suspected” indicators, and describes such labels as important user-facing signals during support impersonation attempts (Microsoft Security).
7. See Microsoft’s post for its full mitigation recommendations, Defender detection guidance and advanced hunting queries (Microsoft Security).

Sources

• Microsoft Security: From help desk impersonation to AD CS abuse: Investigating ESC1 and ESC8 intrusion paths