Hackers Use Microsoft Teams Messages and Calls to Trick Users and Gain Remote System Access

Attackers are abusing Microsoft Teams messages and voice calls to pose as IT support staff, convince employees to grant remote access, and then move deeper into corporate networks.

Microsoft investigated two intrusions that illustrate how a routine help‑desk interaction can lead to stolen data and access to highly privileged accounts.

These incidents did not exploit a flaw in Microsoft Teams. Instead, the threat actors combined social engineering, legitimate remote‑support tools, and insecure Active Directory Certificate Services (AD CS) configurations to progress their attacks.

AD CS issues digital certificates used to authenticate users and machines; if certificate templates or enrollment endpoints are poorly configured, attackers can abuse them to impersonate privileged identities.

Microsoft researchers recovered malicious JavaScript and Python scripts used for initial access and documented portable runtime variants used to execute attacker code. Their October 30 investigation describes two distinct certificate‑abuse paths once the intruders gained remote control. Microsoft did not attribute the activity to a named group.

Hackers using Microsoft Teams messages and calls

Both intrusions began with attackers contacting employees over Teams, impersonating help‑desk personnel. Display names and tenant names crafted to look like internal IT made the external accounts seem familiar.

The technique echoes prior abuse of Teams and Quick Assist where trusted collaboration tools were used to persuade employees to hand over control.

In these cases attackers walked users through approving an interactive remote‑support session—primarily via Quick Assist. That approval was the turning point: the attacker could operate the workstation directly.

Microsoft’s example screenshots show “External” and “Scam suspected” call indicators; employees should check such warnings before approving unexpected support requests.

After gaining control, the attacker placed an archive in the user’s Downloads folder, created an update‑themed staging directory in the user profile, and extracted its contents. Portable runtimes—variants of Python, Bun, or Java—were used to run attacker‑controlled code.

One renamed executable still contained metadata identifying it as Bun, demonstrating that a familiar filename alone does not guarantee safety.

The staged components collected Windows system information, network configuration, and running processes, then contacted domain infrastructure for further action.

While similar Teams help‑desk calls have been used before for malware deployment and internal reconnaissance, Microsoft emphasizes that each incident’s certificate activity must be validated directly rather than inferred from runtime artifacts alone.

Certificate abuse, data theft, and defensive priorities

In the first incident the attacker abused a certificate template vulnerable to ESC1. That template’s permissions allowed a low‑privileged requester to supply an alternate identity and obtain an authentication certificate for that account.

An initial phishing wave targeted three users, leading to compromise of one workstation and issuance of certificates for three highly privileged accounts.

About 90 minutes later a second wave targeted 16 users and compromised a second workstation; the attacker obtained certificates for eight additional privileged accounts.

Microsoft Defender blocked more than 1,000 subsequent SMB file‑access attempts, but DCSync activity had already started while containment measures were being applied.

Because one privileged account was excluded from automated containment it remained usable. The attacker used that account to access a file server and run a renamed Rclone binary to copy files to an external SFTP destination.

The transfer command used 20 concurrent connections and selected files up to three years old.

The second incident followed a different path, abusing ESC8 via PetitPotam to coerce a domain controller into authenticating to an attacker‑controlled host. The attacker relayed that NTLM authentication to AD CS Web Enrollment, obtained a domain‑controller certificate, and then used certificate‑based Kerberos authentication to acquire a ticket‑granting ticket (TGT).

After Defender generated alerts the customer isolated the compromised workstation and no further progression was observed. Microsoft recommends that defenders correlate Teams interactions with remote‑session records, process activity, certificate issuance, and Kerberos events when investigating similar incidents.

Prior reporting on abuse of Teams collaboration features explains how collaboration logs can help reconstruct timelines. Employees should verify unexpected support requests using a known internal channel before granting remote access.

Microsoft’s defensive recommendations include restricting external Teams access and unapproved remote‑support tools, reviewing certificate‑template permissions, and following AD CS relay mitigation guidance. Enrollment endpoints should require HTTPS and Extended Protection for Authentication. Responders must revoke unauthorized certificates and separately review Kerberos tickets—resetting passwords alone does not remove certificate‑backed access.

Containment exclusions need immediate review: leaving even one privileged identity available can preserve the attacker’s access path while other accounts are blocked.

Indicators of compromise (IoCs):

Note: IP addresses and domains in the source material are intentionally Q‑defanged (for example, using “[.]”) to prevent accidental resolution or hyperlinking. Re‑fanging should only be done within controlled threat‑intelligence platforms such as MISP, VirusTotal, or your SIEM.

Give your SOC the alert context to stop incidents quickly. Integrate Threat Intel from 16K SOCs.