Microsoft Exposes Dangerous Help Desk Scam: Attackers Abuse Teams, Quick Assist and Active Directory Certificates to Take Over Corporate Networks

A routine IT support interaction could be all it takes for attackers to gain control of an entire corporate network. Microsoft has uncovered intrusion campaigns in which threat actors impersonate help desk staff through Microsoft Teams, persuade employees to grant remote access using Quick Assist, and then exploit weaknesses in Active Directory Certificate Services (AD CS) to escalate privileges. By abusing certificate templates and NTLM authentication, attackers can move beyond a single compromised workstation and potentially obtain domain-level access. The findings highlight a dangerous combination of social engineering, trusted remote-support tools and poorly secured identity infrastructure.

A convincing phone call or Microsoft Teams message from someone claiming to be part of the IT support team may be all an attacker needs to gain access to an organization’s internal network. Microsoft is warning about two human-operated cyber intrusions in which attackers impersonated help desk personnel, persuaded employees to grant remote access through Quick Assist, and then exploited weaknesses in Active Directory Certificate Services (AD CS) to obtain powerful authentication credentials.

The incidents reveal a particularly concerning attack path: what begins as an ordinary-looking technical support interaction can end with attackers impersonating privileged users or even a domain controller.

Microsoft’s investigation uncovered two different approaches to abusing enterprise certificate infrastructure. One involved an improperly configured certificate template, known as ESC1. The other used PetitPotam to force a domain controller to authenticate to an attacker-controlled system, allowing its NTLM authentication to be relayed to an exposed AD CS Web Enrollment service through a technique known as ESC8.

The consequences were significant. In one incident, attackers obtained certificates for privileged accounts, performed a DCSync operation and later exfiltrated corporate data. In the second, the attackers obtained a certificate for a domain controller and used it to authenticate through Kerberos.

Microsoft’s findings are an important reminder that enterprise security is not just about preventing malicious attachments or blocking suspicious downloads. Attackers increasingly exploit trust in employees, legitimate remote-support tools and identity infrastructure to move deeper into corporate environments.

The central warning for security teams: a remote support session approved by an employee can become the starting point for a full domain compromise when certificate services are poorly configured.

Understanding the Two Certificate Abuse Techniques

To understand the seriousness of Microsoft’s findings, it helps to look at the role of Active Directory Certificate Services.

AD CS is a Windows Server component that allows organizations to issue and manage digital certificates. These certificates are used to authenticate users, computers and services across corporate networks.

When properly configured, certificate-based authentication strengthens enterprise identity security. But poorly configured certificate templates or enrollment services can give attackers a way to obtain credentials representing identities they should never control.

In the incidents Microsoft investigated, two techniques were used.

1. ESC1: Turning a Low-Privilege Account into a Privileged Identity

ESC1 is a certificate-template misconfiguration that can allow an attacker with relatively limited access to request an authentication certificate representing another user.

This becomes dangerous when a certificate template:

• Allows the requester to supply identity information.
• Supports client authentication.
• Grants enrollment permissions too broadly.
• Does not enforce appropriate approval or issuance restrictions.

Under these conditions, an attacker may obtain a certificate representing a privileged administrator account without knowing that administrator’s password.

In the first incident, the attackers used this weakness to obtain certificates for multiple highly privileged accounts.

They subsequently authenticated to a domain controller and performed a DCSync operation.

DCSync is a technique that abuses directory replication privileges to request sensitive authentication data from Active Directory domain controllers. In the wrong hands, it can expose password hashes and other credentials, potentially enabling much broader domain compromise.

2. ESC8: Using NTLM Relay to Impersonate a Domain Controller

The second incident followed a different route.

The attackers used PetitPotam, a technique that can coerce a Windows machine into authenticating to an attacker-controlled system through the Encrypting File System Remote Protocol (EFSRPC).

They then relayed the domain controller’s NTLM authentication to an inadequately protected AD CS Web Enrollment service.

This is known as ESC8.

The important point is that the attacker did not need to know the domain controller’s password. By relaying its authentication to the certificate enrollment service, the attacker was able to request and obtain a certificate representing the domain controller’s machine account.

The attackers subsequently used that certificate for Kerberos PKINIT authentication, obtaining a ticket-granting ticket (TGT) associated with the domain controller.

In practical terms, the attack turned a compromised workstation into a pathway for obtaining certificate-backed authentication as a highly trusted infrastructure identity.

Microsoft’s guidance identifies insufficient NTLM relay protections on AD CS web enrollment endpoints as a key exposure. Enforcing Extended Protection for Authentication (EPA), requiring HTTPS and disabling unnecessary HTTP access are among the recommended defenses. Microsoft Security Blog+2

Why Password Resets Alone Will Not Fix the Problem

One of the most important lessons from Microsoft’s investigation concerns certificate persistence.

When an attacker obtains a valid authentication certificate for a privileged account, resetting that account’s password does not automatically invalidate the certificate.

Likewise, reimaging the initially compromised workstation does not necessarily remove the attacker’s access to the identity infrastructure.

Issued certificates can remain usable until they expire or are properly revoked. Kerberos tickets already issued also require separate consideration during incident response.

This creates a problem for organizations that rely on conventional account recovery procedures.

Security teams may disable a compromised account, reset its password and rebuild the affected workstation, yet overlook the certificate that was issued during the intrusion.

A complete response must therefore consider:

• The identities for which unauthorized certificates were issued.
• Certificate serial numbers and thumbprints.
• Certificate revocation and publication of updated revocation information.
• Active Kerberos ticket-granting tickets and service tickets.
• Other privileged accounts that may have been compromised.
• The devices and services that participated in certificate enrollment.

Microsoft specifically highlights the importance of reviewing certificate activity and active Kerberos sessions separately. Microsoft Security Blog+1

The Containment Lesson: One Excluded Account Can Keep an Attack Alive

The two incidents also provide an important comparison of incident-response outcomes.

In the first case, Microsoft Defender attack disruption successfully restricted several compromised identities. It blocked more than 1,000 subsequent SMB file-access attempts and additional logon activity.

However, one privileged account had been excluded from automated containment.

That account remained available to the attackers, who later used it to access a file server and exfiltrate information.

The attackers launched a renamed version of Rclone, disguising it as SearchApp.exe, to transfer files from an internal file-server share to an external SFTP destination.

The transfer was configured to use 20 concurrent connections and included filters selecting files up to three years old while excluding several file types.

The second incident ended differently.

Microsoft Defender generated alerts related to ESC8 activity, and the customer isolated the workstation associated with the certificate enrollment and Kerberos authentication. Microsoft observed no further attack progression after that isolation.

The difference is significant.

Automated security controls can restrict malicious activity, but exclusions and incomplete containment can leave attackers with alternative routes into the environment.

Organizations should regularly review accounts and devices excluded from automated response policies. Any exception involving a privileged identity should have a clearly documented business justification, compensating security controls and a manual containment procedure.

Ten Security Measures Organizations Should Implement Now

Microsoft’s investigation provides a practical opportunity for security teams to review their identity infrastructure, remote-support processes and incident-response readiness.

Here are ten measures organizations should prioritize.

1. Secure Microsoft Teams against support impersonation.

Review external access and federation policies. Restrict communication with untrusted external tenants where business requirements allow. Train employees to verify unexpected IT support requests through established internal channels.

2. Restrict Quick Assist and remote-support tools.

Maintain an inventory of approved remote-support applications and authorized operators. Monitor unexpected Quick Assist sessions and investigate sessions initiated after unsolicited Teams messages or calls.

3. Harden employee endpoints.

Deploy and maintain endpoint detection and response (EDR), application control and attack surface reduction policies. Pay particular attention to devices used by IT administrators, developers and privileged support personnel.

4. Audit all AD CS certificate templates.

Review authentication-capable templates for ESC1 exposure. Remove unnecessary enrollment permissions, restrict requester-supplied identity information and introduce appropriate approval requirements.

5. Protect AD CS Web Enrollment against NTLM relay.

Apply Microsoft’s recommended mitigations, including HTTPS and Extended Protection for Authentication (EPA). Disable unnecessary HTTP access and assess whether NTLM can be disabled on enrollment services.

6. Monitor certificate issuance and authentication activity.

Enable appropriate Certification Authority auditing. Alert on unusual certificate requests, unexpected privileged identities, suspicious domain-controller certificate issuance and certificate-based Kerberos authentication from unfamiliar devices.

7. Review privileged accounts and containment exclusions.

Identify every privileged identity excluded from automated response. Reassess whether those exclusions are necessary and establish an alternative containment process for each exception.

8. Prepare certificate-aware incident-response procedures.

Ensure incident-response teams know how to identify, revoke and investigate unauthorized certificates. Include Kerberos ticket review, directory replication activity and compromised machine accounts in response playbooks.

9. Hunt for suspicious runtime execution and data transfers.

Investigate portable Python, Bun and Java runtimes launched from unusual user-writable directories. Monitor renamed executables, unexpected archive extraction, suspicious Rclone activity and unusual outbound SFTP transfers.

10. Strengthen security awareness and technical training.

Run realistic help desk impersonation exercises and provide specialized training for IT support, Active Directory administrators, SOC analysts and incident responders. Consider regular AD CS security assessments and penetration testing to identify certificate misconfigurations before attackers do.

Organizations looking to strengthen their security posture can explore Saintynet Cybersecurity for cybersecurity consulting, GRC, vulnerability management, security assessments and professional certification training.

What Security Teams Should Hunt For

Microsoft’s investigation provides several useful detection opportunities across collaboration platforms, endpoint telemetry, Active Directory and certificate infrastructure.

Rather than relying on a single suspicious command or file name, security teams should correlate activity across the entire attack sequence.

Microsoft also provides Defender XDR advanced hunting queries for investigating these patterns. Security teams using Defender should review the original Microsoft investigation and its detection guidance.

Important: Individual matches are investigation leads, not proof of compromise. Legitimate administrators may use Java, Python, remote-support software and certificate enrollment services. Context, process lineage, account identity and timing are essential.

Indicators of Compromise

Microsoft published the following SHA-256 hashes associated with the activity.

Security teams should use these indicators alongside behavioral detection and Microsoft’s broader investigation guidance. Hash-based detection alone is insufficient because attackers can easily change scripts, executables and packaging.

Why This Matters for Middle East and Africa Organizations

Microsoft’s investigation does not identify a specific geographic region or industry as the target of these incidents. Nevertheless, the techniques are relevant to organizations throughout the Middle East and Africa.

Government institutions, financial services providers, telecommunications operators, energy companies and large enterprises increasingly depend on Microsoft 365, Windows Server and centralized identity infrastructure.

Active Directory remains a critical component of many enterprise environments, particularly organizations operating hybrid infrastructures that combine on-premises systems with cloud services.

A compromise of identity infrastructure can therefore have consequences beyond a single workstation or department.

For organizations in the UAE, Saudi Arabia, South Africa, Kenya, Nigeria, Egypt and other regional markets, several priorities stand out:

• Review Active Directory and AD CS configurations as part of regular security assessments.
• Ensure external collaboration policies are appropriate for the organization’s risk profile.
• Protect privileged administrator accounts and remote-support infrastructure.
• Monitor certificate issuance and authentication activity.
• Include social engineering and identity compromise scenarios in SOC exercises.
• Ensure security incidents involving third-party access and privileged identities are covered by incident-response procedures.

The wider lesson for regional security leaders is that identity infrastructure deserves the same strategic attention as firewalls, endpoints and cloud workloads.

Related Cybersecurity Coverage

The attack techniques described by Microsoft fit into a wider pattern of attackers abusing legitimate collaboration and authentication mechanisms.

Cybercory has previously covered several related developments:

• New BOF Tool Targets Microsoft Teams Cookies: Attackers Could Hijack Chats Without Admin Rights — examining how compromised endpoints can expose active Teams sessions.
• Access Granted: How Device Code Phishing Is Fueling Account Takeovers — exploring how attackers abuse legitimate Microsoft authentication workflows.
• ARToken Exposes a Dangerous New Chapter in Microsoft 365 Phishing — examining the evolution of cloud identity compromise and phishing-as-a-service.

For additional coverage, visit Cybercory’s Identity and Access Management section.

Final Thoughts: Trust Is Becoming the Attack Surface

Microsoft’s findings highlight a dangerous combination of social engineering, legitimate remote-access software and weaknesses in enterprise certificate infrastructure.

The attackers did not need to exploit a vulnerability in Microsoft Teams. They persuaded employees to grant access, used legitimate execution environments to stage their tools and then targeted the certificate services responsible for authenticating users and machines across the organization.

That is what makes these intrusions particularly concerning.

An attacker who obtains a privileged authentication certificate can establish access that survives conventional password resets and workstation rebuilds. And as the first incident demonstrates, even effective automated containment can be undermined when a compromised privileged identity remains excluded.

Organizations should treat AD CS security, remote-support controls and privileged identity protection as interconnected parts of the same security programme.

The priority is not simply to detect suspicious activity after an employee approves a remote session. It is to prevent that session from becoming a gateway to the organization’s most trusted identities.

Stay informed. Stay secure.

Official Sources and References

1. Microsoft Security Blog – From Help Desk Impersonation to AD CS Abuse: Investigating ESC1 and ESC8 Intrusion Paths (October 30, 2026).
2. Microsoft KB5005413 – Mitigating NTLM Relay Attacks on Active Directory Certificate Services.
3. Microsoft Defender for Identity – Certificates Security Posture Assessment.
4. Cybercory – Microsoft Teams Cookie Theft Research.
5. Cybercory – Device Code Phishing and Account Takeovers.