Help Desk Impersonation to AD CS Abuse: What to Check

A message arrives in Microsoft Teams from someone who says they work on the IT help desk. A call follows. The caller asks the employee to open Quick Assist, the remote support tool built into Windows, and read out a code. Then the caller is driving the PC.

On October 30, 2026, Microsoft Threat Intelligence published an analysis of two intrusions that started this way. In both, the attackers went from that remote session to Active Directory Certificate Services (AD CS), the Windows server role that issues certificates for sign-in, and used weak certificate settings to act as privileged accounts. Microsoft names no threat actor, and it states plainly that the activity did not exploit a vulnerability in Microsoft Teams. The attackers used a Teams call, a Teams chat and a built-in tool, each doing its normal job.

Microsoft Defender's automatic attack disruption locked down the accounts it covered in the first intrusion and blocked much of the activity that followed. One privileged account had been excluded from that automation, and the attacker used it to copy a file share out of the network.

ABT is a Tier-1 Microsoft Cloud Solution Provider serving 750+ financial institutions, and its M365 Guardian service pairs automated containment with ABT security engineers on covered incidents.

This guide is for IT and security leaders at community banks, credit unions, and mortgage companies that run Microsoft 365 and Microsoft Defender. Microsoft keeps both victims anonymous. The lesson applies to any institution whose staff use Teams and whose network still runs on Active Directory. The quickest check is the list of accounts your automation is told to leave alone.

What Microsoft found in two intrusions

Both intrusions opened the same way. Attackers impersonated IT or help desk staff in Teams messages and calls, then talked users into opening a remote session, primarily through Quick Assist, and sharing the connection code. From there they placed an archive in the Downloads folder, unpacked it into a folder under the user profile named to look like a Windows update, and ran portable Python, Bun or Java runtimes. Those tools let them look around the network and reach the domain controllers, the servers that approve every sign-in.

The first intrusion, as Microsoft's report lays it out, moved fast once the attacker found a misconfigured certificate template:

The second intrusion took a different path to the same place. The attacker used a technique called PetitPotam to make a domain controller authenticate to a machine the attacker controlled, then relayed that sign-in to the AD CS web enrollment page. That weakness is known as ESC8. The attacker came away with a certificate from the Domain Controller template and used it to request a Kerberos ticket, a sign-in credential, as the domain controller.

Defender raised ESC8 alerts, the customer isolated the workstation, and Microsoft reports no further progress by the attacker.

We've covered the Teams opening before. Our April guide to the nine-stage Teams helpdesk impersonation chain walks through that entry in detail. What's new in Microsoft's October report is what happened after automation stepped in.

The one account automation left alone

Automatic attack disruption is Microsoft Defender XDR's built-in containment. When it is confident an account or device is compromised, it can disable the account, restrict its sign-ins and isolate devices without waiting for a person. In the first intrusion it did that job for every identity it was allowed to touch.

Defender also lets administrators exclude identities, device groups and IP ranges from those automated actions. Microsoft's documentation describes user exclusions as a way to keep specific user identities from being automatically disabled, and names service accounts, emergency admin accounts and accounts behind critical business processes as typical candidates. The same page carries a caution: "Excluding assets from automated responses isn't recommended."

Exclusions usually exist for good reasons. An institution excludes the account that runs its core banking integration because a disabled service account can stop payments. It excludes its emergency access account so a lockout cannot strand the administrators. Those are sensible choices, and each one marks an account that an attacker can keep using after the alarm goes off.

Microsoft's own recommendation in the report is to "treat containment exclusions as incident decisions" and to assign a compensating manual action, and verify it was completed, for every identity or device that automation cannot contain.

Review your attack disruption exclusions this week

The list lives in the Microsoft Defender portal under Settings, then Microsoft Defender XDR, then Automated response. Identity exclusions sit on the Identities page, and device groups and IP exclusions sit on the Devices page. A Security Reader can view the exclusions, so anyone on your security team with that role can run the review.

The review also has to cover the systems that touch those accounts after an incident starts.

Two more points from Microsoft's setup guide matter for a small institution. Attack disruption is available with Microsoft Defender for Business as well as with the enterprise Defender products. And each Defender product has to be deployed to carry out its own actions: turning off an on-premises Active Directory account during an attack needs a Defender for Identity sensor on the domain controller.

On Microsoft 365 Business Premium, the Microsoft Defender Suite for Business Premium add-on brings Defender for Identity, along with Microsoft Entra ID P2 and Defender for Endpoint Plan 2. Our guide to Microsoft Defender for Identity covers the sensor itself. The same discipline applies to sign-in policies; our piece on Conditional Access exclusions makes the case for reviewing that list on a schedule too.

Attack disruption contained the accounts it was allowed to touch. The excluded privileged account is the one the attackers kept using.

The front door: Teams external access and Quick Assist

Every step after the first call depended on an outsider being able to reach an employee in Teams and get a remote session. Microsoft's report recommends reviewing Teams external access and federation, limiting external domains to the ones the business needs, and investigating new tenants named to look like your organization or a help desk.

Teams external access allows all external domains by default. In the Teams admin center, under Users and then External access, you can switch to allowing only specific domains, block specific domains, or block all external domains. A separate setting controls chat with Teams accounts that no organization manages, including whether those accounts can start a conversation with your staff. For most community institutions, the realistic list of outside organizations that need to chat with staff is short: your core processor, a few vendors and partner institutions.

Quick Assist needs the same attention. Microsoft's own guidance tells users to allow a helper to connect only if they started the interaction by contacting support themselves. For organizations, Microsoft recommends Intune Remote Help, which adds Conditional Access, role-based access and session logging, and says to disable or remove Quick Assist where another remote support tool is in use. Removal is one command, run as administrator:

Get-AppxPackage -Name MicrosoftCorporationII.QuickAssist | Remove-AppxPackage -AllUsers

Blocking the Quick Assist service endpoint is the other route, and Microsoft notes it also stops Remote Help from working, so pick one approach and test it. Our guide to RMM phishing (attacks that misuse remote monitoring and management tools) covers the approved-tools list that settles which remote support product your help desk uses.

Microsoft's report adds two endpoint controls. One is an alert when an approved remote tool unpacks an archive or starts a script interpreter from a user folder. The other is App Control for Business, which stops portable Python, Bun or Java runtimes your institution never approved.

The people control is the cheapest of all. Tell staff, in writing, how your real help desk contacts them, and that a surprise call or chat from "IT" gets verified through a known internal number before anyone opens a remote session.

If you run Active Directory Certificate Services

If your institution runs AD CS, perhaps installed for Wi-Fi, VPN or smart card sign-in, its settings deserve a review. Both of Microsoft's intrusions turned on AD CS settings. These are the checks Microsoft lists, with the place to make each one:

Microsoft's support article KB5005413 names Certificate Authority Web Enrollment and Certificate Enrollment Web Service as the role services exposed to PetitPotam-style relay, and calls Extended Protection set to Required "the more secure and recommended option." If you have Defender for Identity with a sensor on the AD CS server, its certificate posture assessments flag ESC1 and ESC8 conditions in Secure Score (the ESC1 assessment is still in preview). Microsoft calls the "Supply in the request" template setting behind ESC1 one of the most common misconfigurations.

Revocation needs care during cleanup. Microsoft's report notes that revoking an unauthorized certificate does not retroactively invalidate Kerberos tickets already issued with it, so those tickets and the accounts behind them need their own review. Our incident response plan guide covers who makes those calls and in what order.

The Defender alerts that fired

Microsoft lists more than a dozen Defender detections tied to this activity. These five mark the main steps. If your security provider or your own team sees any of these, investigate it at once as a possible active intrusion:

Which of these your institution sees depends on which Defender products cover its Teams, PCs and domain controllers, and that is a fair question to put to whoever reads your alerts overnight. On M365 Guardian Resolve, after-hours escalation puts a human on the incident at any hour.

Questions for your board and examiners

These belong on the next security committee agenda:

• Which accounts are excluded from Defender's automatic containment, why, and who acts on each one during an incident?
• Which outside organizations can reach our staff in Teams chat and calls, and who approved that list?
• Which remote support tool is our help desk allowed to use, and is Quick Assist removed or controlled everywhere else?
• Do we run Active Directory Certificate Services, and when were its templates and web enrollment last reviewed?
• How does staff verify a call or chat from "IT" before opening a remote session?

Five questions that turn Microsoft's report into an agenda item for your next security committee.

How ABT helps

M365 Guardian puts automation and people on the same incident. Guardian Contain adds round-the-clock detection and pre-authorized automated containment that revokes a compromised session in seconds at any hour. Guardian Respond adds ABT security engineers working covered incidents during business hours, and Guardian Resolve adds after-hours escalation with a human on the incident at any hour. Before any incident, confirm in writing which identities, systems and response actions your service agreement covers.

The free ABT Security Assessment is a starting point for the Teams question on the board list. Its Identity and Access area reviews admin account hygiene and guest access settings, and its External Sharing area reviews Teams guest policies and external collaboration boundaries. It connects read-only through a service principal that is removed afterward, most assessments finish within two weeks, and you get a written report and a 90-day roadmap.

Frequently Asked Questions