Your IT Help Desk Just Messaged You on Teams. Are You Sure It’s Really Them?

A message from “IT Support” inside Microsoft Teams can feel more trustworthy than a suspicious email. Microsoft Threat Intelligence says attackers are exploiting exactly that assumption: contacting employees through Teams, impersonating help desk personnel, and persuading users to grant remote control through legitimate support tools such as Quick Assist. In two recent intrusions, that initial user-approved session led to deeper identity attacks against Active Directory Certificate Services (AD CS) through ESC1 and ESC8.

By CompuAce Team Published November 2, 2026 Reviewed against Microsoft Security and Microsoft Learn guidance as of November 2, 2026

Key Takeaways

• Microsoft says the attacks do not exploit a vulnerability in Teams; they abuse legitimate external collaboration and remote-support workflows.
• Attackers impersonated IT/help desk staff and convinced users to approve remote access, primarily through Quick Assist.
• After gaining interactive access, attackers staged legitimate portable runtimes and performed host, network, and identity discovery.
• One intrusion abused an ESC1-vulnerable AD CS certificate template to obtain authentication certificates for privileged accounts.
• Another used PetitPotam and NTLM relay against AD CS Web Enrollment, an ESC8 path, to obtain a certificate for a domain-controller identity.
• Businesses should review Teams external access, remote-support workflows, endpoint controls, AD CS posture, certificate auditing, and help desk verification procedures.

The Short Version

On October 30, 2026, Microsoft published an investigation into two human-operated intrusions that began with a familiar social-engineering tactic: attackers used Microsoft Teams messages and calls to pose as IT or help desk personnel. The goal was not to steal a password through a fake login page. It was to persuade the employee to open or approve a remote-control session.

Once connected, the attacker had hands-on-keyboard access to an already authenticated workstation. Microsoft observed attackers placing archives in the user profile, launching portable Python, Bun, or Java runtimes, performing host and network discovery, and evaluating Active Directory Certificate Services for privilege-escalation paths.

The two investigated cases then diverged. One exploited a certificate template vulnerable to ESC1. The other used PetitPotam to coerce domain-controller authentication and relay that NTLM authentication to an AD CS Web Enrollment endpoint vulnerable to ESC8.

The business lesson:

A secure login is not enough if an employee can be persuaded to give an attacker legitimate remote control of an authenticated device. Help desk identity, support workflows, endpoint controls, and certificate infrastructure are all part of the security perimeter.

First, This Is Not a Microsoft Teams Vulnerability

Microsoft explicitly states that the documented activity did not exploit a technical vulnerability in Teams. Attackers used legitimate external collaboration features and social engineering to make the contact appear believable.

In earlier related activity documented by Microsoft in September 2026, attackers operating from external Microsoft 365 tenants used helpdesk-themed display names and organization-themed tenant names. Lures included messages about “security updates,” “spam filter updates,” “account verification,” or actions supposedly required to prevent account deactivation.

The attacker’s objective was consistent: convince the user that the contact was legitimate, then move the interaction into a remote-support session.

How the Teams Help Desk Attack Chain Works

Why Quick Assist Is So Effective for Social Engineering

Quick Assist is a legitimate Windows remote-support application. Its purpose is to let one person help another by viewing or controlling a Windows device after the user approves the session.

That same usability is what makes support impersonation dangerous. The attacker does not need to break the remote-support software. The victim is persuaded to open it, enter or share the connection code, and approve control.

Once control is granted, the attacker can interact with the workstation in the same user context the real support technician would use. Microsoft describes the remote session as the decisive transition from social engineering to hands-on-keyboard access.

Why MFA Alone Does Not Stop This Attack

Multifactor authentication is still essential, but this attack shows why authentication cannot be the only control. The employee has already completed the legitimate sign-in process. The attacker instead convinces that authenticated user to hand over interactive access.

That means a mature defense needs multiple layers:

• Phishing-resistant authentication for account sign-in
• Teams external-access controls
• Verified help desk workflows
• Restricted remote-support tooling
• Endpoint monitoring and application control
• Strong Active Directory and AD CS configuration
• Certificate-aware incident response

CompuAce previously covered Microsoft's move toward phishing-resistant passkeys. That identity layer remains important, but support impersonation demonstrates why strong authentication and operational verification have to work together.

Related: Microsoft Is Making Passkeys the Default: What Businesses Need to Know.

Legitimate Runtimes Can Become Part of the Attack Chain

In the October 30 incidents, Microsoft observed portable or renamed Python, Bun, and Java runtimes launched from newly created user-writable directories after the remote session began.

This matters because defenders cannot treat every legitimate runtime as malicious. The useful signal is the sequence and context: an unexpected support session, a newly created staging directory, archive extraction, a portable interpreter, discovery commands, and network connections to identity infrastructure.

Microsoft recommends application-control strategies such as App Control for Business or equivalent controls to restrict unapproved portable runtimes and script execution from user-writable paths where appropriate.

Why Active Directory Certificate Services Changes the Risk

Active Directory Certificate Services is used by many Windows environments to issue and manage certificates for users, computers, services, authentication, encryption, and other enterprise purposes.

In a properly configured environment, AD CS is valuable identity infrastructure. In a misconfigured environment, it can become a privilege-escalation path because certificates can authenticate as users or machines.

Microsoft makes an especially important operational point: if an attacker obtains an authentication certificate for a privileged identity, resetting the password on the originally compromised account does not automatically revoke that certificate. Certificate revocation and active Kerberos ticket review are separate incident-response tasks.

ESC1: When a Certificate Template Can Represent the Wrong Identity

ESC1 refers to a risky certificate-template configuration in which a requester can supply identity information in the certificate request and receive a certificate that can be used for authentication.

The danger appears when that setting is combined with overly broad enrollment rights and weak issuance controls. A low-privileged user may be able to request a certificate representing a more privileged identity.

In Microsoft's first October 30 case, the attacker found an ESC1-vulnerable template and obtained authentication certificates for privileged accounts. During a later phishing wave, Microsoft says the attacker obtained certificates for eight additional privileged accounts. Defender disruption blocked more than 1,000 subsequent SMB file-access attempts and additional logons, but a privileged account excluded from automated containment remained usable and was later involved in data exfiltration.

Microsoft Defender for Identity now includes certificate security posture assessments that can identify ESC1-related exposure and other AD CS weaknesses.

ESC8: NTLM Relay to AD CS Web Enrollment

The second Microsoft case used a different path. The attacker used PetitPotam to coerce a domain controller into authenticating to an attacker-controlled system using its machine account. That NTLM authentication was then relayed to an AD CS Web Enrollment endpoint.

This technique is commonly described as ESC8. If the enrollment endpoint accepts NTLM without adequate relay protections, an attacker can request a certificate as the relayed identity.

In the Microsoft case, the attacker requested a certificate for the domain-controller account and then used that certificate for Kerberos PKINIT authentication. Microsoft Defender generated ESC8-related alerts, the customer isolated the workstation, and Microsoft says no further attack progression was observed after isolation.

How Businesses Should Harden AD CS Against ESC1 and ESC8

Microsoft recommends treating certificate infrastructure as privileged identity infrastructure, not as a background Windows service that can be left on default settings indefinitely.

For ESC1 exposure

• Review authentication-capable certificate templates.
• Remove unnecessary enrollment rights from low-privileged users or groups.
• Review templates that allow the requester to supply identity information.
• Use stronger issuance requirements or approval where business requirements justify it.
• Use Microsoft Defender for Identity certificate posture assessments where available.

For ESC8 exposure

• Inventory AD CS Web Enrollment and Certificate Enrollment Web Service endpoints.
• Remove enrollment endpoints that are not required.
• Require HTTPS.
• Enable Extended Protection for Authentication (EPA).
• Disable NTLM on enrollment services where operationally feasible after testing.

Microsoft Support specifically recommends enabling EPA and disabling HTTP on affected AD CS web enrollment services as the primary mitigation for NTLM relay risk.

Microsoft Teams External Access: What Businesses Should Review

Microsoft Teams external access allows employees to communicate with people outside the organization. That is useful for customers, partners, vendors, and consultants, but it also gives attackers a path to contact users directly if policy is overly broad.

Microsoft documents several options for administrators, including allowing all external domains, allowing only specified domains, blocking selected domains, or blocking all external domains. Microsoft Defender guidance specifically recommends considering Allow only specific external domains when business requirements permit it.

The correct policy depends on how the business collaborates. A company that frequently works with many external organizations may need a different configuration from an internal-only operation. The important point is that external access should be an intentional policy, not an unreviewed default.

Build a Help Desk Workflow Employees Can Verify

Security awareness advice such as “be careful” is too vague. Employees need a support process they can actually verify.

A practical workflow should answer:

• Which channels can IT use to initiate support?
• Can IT ever request remote control without an open ticket?
• Which remote-support applications are approved?
• How does the employee verify the technician's identity?
• Should the technician know the ticket number before the session begins?
• Who should the employee call if a support request feels unusual?
• Can external Teams users ever provide IT support?

Simple rule for employees:

If an unsolicited “IT support” contact asks for screen control or a Quick Assist session, verify the request through a known internal channel before approving anything.

Warning Signs of a Teams-Based Help Desk Impersonation Attempt

• The caller is labeled External or Teams displays an impersonation/scam warning.
• The user did not open a support ticket.
• The caller creates urgency around an account, security update, spam filter, or deactivation.
• The “technician” asks the employee to open Quick Assist or another remote-control tool immediately.
• The caller wants the user to ignore an external-contact warning.
• The caller uses voice instructions to keep suspicious links or commands out of the chat history.
• Command shells, PowerShell, script runtimes, or archives appear immediately after the remote session begins.

None of these signals alone proves compromise. The pattern and context matter.

What Security Teams Should Monitor

Microsoft recommends reconstructing the full sequence across collaboration, endpoint, identity, and certificate systems rather than relying on one command or one alert.

Useful investigation pivots include:

• Unexpected external Teams chats or calls using helpdesk-themed identities
• Quick Assist or other remote-support sessions that were not associated with a valid ticket
• New archive extraction and staging directories in user-writable locations
• Portable Python, Bun, Java, Node.js, or other interpreters launched from unusual user paths
• Discovery commands and connections to domain infrastructure immediately following remote access
• Unexpected certificate requests for privileged user or machine identities
• NTLM authentication to AD CS Web Enrollment from an unexpected source device
• PKINIT or certificate-based Kerberos authentication following suspicious certificate issuance
• DCSync, unusual SMB activity, file-server access, or unexpected data-transfer tooling

If a User Already Granted Remote Access

Treat the event as a potential interactive compromise rather than simply telling the user to change a password.

1. End the remote session and isolate the device when appropriate.
2. Preserve endpoint and Teams evidence before cleanup where incident-response procedures require it.
3. Identify processes and files created during the session.
4. Review the user's identity and active sessions.
5. Check for AD CS certificate requests associated with the device or identity.
6. Revoke unauthorized certificates and publish updated revocation information if certificates were issued.
7. Review Kerberos tickets separately. Certificate revocation does not retroactively invalidate already issued tickets.
8. Review lateral movement and data access from the affected workstation and identities.
9. Confirm all compromised identities and devices are included in containment.

The 15-Point Microsoft Teams & Help Desk Security Checklist

1. Define an approved help desk contact process.
2. Require verification of unsolicited support requests through a known internal channel.
3. Review Teams external-access settings.
4. Consider an allowlist of trusted external domains where practical.
5. Teach employees what the External and scam-warning indicators mean.
6. Restrict remote-support software to approved products and operators.
7. Require a valid ticket before remote control when possible.
8. Monitor Quick Assist and other remote-support activity.
9. Use endpoint application control to reduce unapproved portable runtime execution where appropriate.
10. Protect privileged identities with phishing-resistant authentication.
11. Assess AD CS certificate templates for ESC1 exposure.
12. Assess AD CS enrollment web endpoints for ESC8 exposure.
13. Require HTTPS and EPA on AD CS web enrollment services.
14. Enable certificate auditing and retain CA logs.
15. Test incident response for certificates, Kerberos tickets, remote access, and privileged identities.

What This Means for South Florida Businesses

The Microsoft incidents are not specific to South Florida, but the operating model is highly relevant to small and mid-sized businesses in Miami, Miami Lakes, Fort Lauderdale, Broward County, and the wider region. Many organizations rely on Microsoft 365 and have employees who receive remote support from internal IT, an MSP, a software vendor, or an outside consultant.

That creates an important trust question: how does an employee know that the person asking for remote control is actually an approved technician?

Small teams often rely on informal support relationships, which can make a convincing Teams call feel normal. Formalizing support verification, remote-access rules, and Microsoft 365 external-collaboration policies can reduce that ambiguity without preventing legitimate support.

The same pattern of trusted tools being misused appears in our coverage of AI agents as new insider risks, hybrid cloud resilience after the Azure outage, and the PHP2Shell web server advisory.

How CompuAce Helps Reduce Help Desk and Microsoft 365 Security Risk

CompuAce helps businesses strengthen the layers that support secure collaboration and remote IT operations, including endpoint protection, Microsoft 365 security, email and phishing defense, identity hygiene, remote-support workflows, monitoring, backup, and broader cybersecurity planning.

Relevant areas can include:

• Microsoft 365 and Teams security review
• External collaboration and access-policy review
• Endpoint security and monitoring
• Remote-support workflow design
• User phishing and impersonation awareness
• Privileged-account and authentication review
• Windows server and Active Directory security review
• Backup and recovery planning
• Ongoing managed IT and cybersecurity support

Learn more about CompuAce SMB Security, our IT solutions, CompuAce, and our editorial and sourcing standards.

Would Your Employees Know If “IT Support” Was Actually an Attacker?

CompuAce can help review Microsoft 365, Teams external access, endpoint controls, remote-support workflows, and the identity infrastructure behind your business before a convincing support request becomes a hands-on-keyboard compromise.

Review Your Microsoft 365 & Help Desk Security

Microsoft Teams Help Desk Impersonation FAQ

Is Microsoft Teams vulnerable in this attack?

No. Microsoft says the activity does not exploit a vulnerability in Microsoft Teams. Attackers abuse legitimate external collaboration features and social engineering to persuade users to start or approve a remote-support session.

What role does Quick Assist play?

Quick Assist is a legitimate Windows remote-support tool. In the incidents Microsoft investigated, attackers posing as IT support persuaded users to open Quick Assist, provide the connection code, and grant interactive control of the workstation.

Why is this more dangerous than ordinary phishing?

The user can voluntarily give the attacker hands-on-keyboard access to an already authenticated workstation. From there, the attacker can stage tools, perform network and identity discovery, and search for privilege-escalation paths without relying on a conventional malicious attachment.

What is ESC1 in Active Directory Certificate Services?

ESC1 is a certificate-template misconfiguration in which a low-privileged requester can supply identity information in a certificate request and obtain an authentication-capable certificate representing another, potentially privileged, account when enrollment permissions and issuance controls are too permissive.

What is ESC8?

ESC8 is an NTLM relay path against Active Directory Certificate Services web enrollment endpoints. If NTLM is accepted without protections such as Extended Protection for Authentication, an attacker can relay another account's authentication to AD CS and request a certificate as that identity.

Does MFA stop this kind of help desk impersonation?

MFA helps protect sign-in, but it does not by itself prevent a user who is already authenticated from approving a remote-control session. The attack therefore also requires controls around support verification, Teams external access, remote-support tooling, endpoint behavior, and identity infrastructure.

What should businesses do first?

Require employees to verify unsolicited support requests through a known internal channel, review Teams external-access policies, restrict remote-support tools to approved workflows, monitor remote sessions and suspicious child processes, and assess AD CS for ESC1 and ESC8 exposure where applicable.

Sources & Editorial Transparency

This article is based primarily on first-party Microsoft Threat Intelligence, Microsoft Security, Microsoft Learn, and Microsoft Support guidance. Technical claims and mitigation recommendations were reviewed against the sources below on November 2, 2026.

• Microsoft Security Blog — From help desk impersonation to AD CS abuse: Investigating ESC1 and ESC8 intrusion paths
• Microsoft Security Blog — Impersonating IT support: how threat actors turn a remote session into enterprise-wide access
• Microsoft Learn — Reduce the attack surface for Microsoft Teams
• Microsoft Learn — Manage external access in Microsoft Teams
• Microsoft Learn — Certificates security posture assessment in Microsoft Defender for Identity
• Microsoft Support — KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services

Editorial note: Microsoft 365, Teams, Defender, Windows, and AD CS capabilities and detections evolve over time. Availability also depends on licensing, tenant configuration, sensors, and deployed security products. Organizations should verify current Microsoft documentation and test configuration changes before production rollout.

By CompuAce Team — November 2, 2026

Schedule a Consultation  |  View Our Solutions  |  Back to Blog