What Did the ProArch SOC Observe in This Microsoft Teams Attack?
ProArch SOC observed an incident that started with a Microsoft Teams message from an attacker impersonating internal IT, sent from a free external “.onmicrosoft.com” tenant.
They used a legitimate open-source launcher, Keypirinha, to bundle malware with a keylogger and trusted-looking portable tools that blended into the environment.
The attacker scanned the system, stole password-manager databases, used a privileged service account to access a database server, installed another remote-access tool, and disabled antivirus on multiple servers.
A Defender ASR rule detected the malware but, because it was set to Audit mode, only logged the activity instead of blocking it.
How Did the Attack Progress from Teams Chat to Domain-Wide Antivirus Tampering?
The attacker exploited trust in Teams as an internal communications platform and combined legitimate administration tools with social engineering techniques to avoid detection.
- Teams lure from an external tenant – The attacker posed as “Help Desk,” messaging several users from a: “itadmin3[@]Snethercan[.]onmicrosoft[.]com” from 2a02:2378:1046:d41e:c217:7d55:b1cb[:]357.
- Remote access through Quick Assist – The user was persuaded to open Quick Assist, giving the attacker direct access under the user’s identity.
- Malware disguised as a software update – A malicious MSI from an attacker-controlled cloud bucket installed a keylogger and remote-management launcher. The unsigned files used legitimate developer metadata to appear safe. IOCs: msi; software-update-bucket324513[.]s3[.]us-east-1[.]amazonaws[.]com; signer metadata “Jean-Charles Lefebvre”; keypirinha-x64.exe.
- Command-and-control and data theft – The remote-management tool connected to an external IP and later transferred a large amount of data over TCP. IOCs: C2 225.226[.]92; exfiltration 142.251.211[.]79.
- Lateral movement through a service account – The attacker used a privileged service account to access a database server through RDP. They then used exe and vmtoolsd.exe to install AnyDesk and Python-based tools, possibly to host a phishing site or web service.
- Antivirus disabled across servers – The attacker changed policies to disable antivirus on multiple servers, including domain controllers.
Which Microsoft Defender Control Detected—but Did Not Block—the Malware?
The ASR rule “Block executable files from running unless they meet a prevalence, age, or trusted list criteria” detected the malware.
However, because it was in Audit mode, it only logged the activity.
In Block mode, it would have stopped the malware before system scanning, credential theft, and lateral movement.
Which Organizations Are Most at Risk from Microsoft Teams Help Desk Impersonation Attacks?
Any organization using Microsoft 365 with default Teams external access and Windows endpoints may be exposed to this type of attack.
The attack surface is:
- The combination of user trust in Teams as an internal channel,
- The availability of legitimate remote and portable tools on endpoints, and
- Privileged service accounts with broad reach.
Why Does This Teams-to-Domain Attack Matter?
This class of intrusion is dangerous precisely because every moving part looks legitimate — a Teams message, a remote-access tool, a signed-looking utility, and a normal service account.
Email filtering and signature-based antivirus never come into play.
Stealing a password vault and abusing a service account gives the attacker long-term access to move deep in the environment.
In this case, one setting made the difference between detection and prevention: the control was left in Audit mode instead of Block mode.
How Can Organizations Prevent Teams-Based Impersonation and Lateral Movement?
What Immediate Actions Should Security Teams Take?
- Restrict Teams external access in the Teams Admin Center — this setting should be set to Only Allow Messages from Specific Senders (REF: https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-teams-domains-configure)
- Move deployed ASR rules — especially “Block executable files unless they meet prevalence/age/trusted-list criteria” — from Audit to Block in Intune.
- Disable or tightly restrict Quick Assist and other remote-assistance tools where they aren’t required, and alert on their use.
- Change credentials for any password vaults or service accounts that may have been exposed and enforce MFA and Conditional Access on privileged identities.
- Awareness training programs on Teams-based helpdesk impersonation.
What Short-Term Security Controls Should Organizations Implement?
- Inventory and allowlist remote/RMM and portable tools via WDAC or AppLocker; alert on new RMM installs and portable tooling appearing in user AppData.
- Enable Defender Tamper Protection and alert on any antivirus policy change, especially on servers and domain controllers.
- Constrain service accounts — remove interactive/RDP logon rights where avoidable, scope permissions tightly, and apply logon workstation restrictions.
What Mid- and Long-Term Measures Reduce Future Attack Risk?
- Adopt phishing-resistant MFA and just-in-time privileged access for service and admin accounts.
- Deploy behavioral detection for RMM abuse, LOLBin-based tool transfer, and localhost tunneling rather than relying on signatures alone.
Ready to Turn Detection into Prevention?
ProArch can review your Microsoft 365 security posture, identify controls left in Audit mode, and help strengthen Teams access, Defender policies, privileged accounts, and endpoint protection.
Talk to a ProArch security expert to close security gaps before attackers exploit them.