Hackers are posing as IT support staff on Microsoft Teams to trick employees into granting remote access to their Windows machines.
The campaign combines convincing helpdesk identities, deliberate inbox flooding, and the misuse of legitimate remote-support tools, turning routine workplace conversations into opportunities to install malware and probe corporate networks.
This activity exploits trust rather than a vulnerability in Microsoft Teams. Attackers use external messaging to contact employees from separate Microsoft 365 tenants when both organizations permit cross-tenant communication.
Earlier incidents involving fake IT support calls show how inbox flooding creates confusion before an impersonator contacts a target offering to “fix” the problem.
Researchers at Arctic Wolf identified what may be a new malware infection chain while investigating this abuse. In an October 26 report, they analyzed more than 400 incidents involving external Teams chats, documenting repeated impersonation patterns, misuse of remote-access software, and shared infrastructure across multiple intrusions.
How attackers impersonate IT support on Microsoft Teams
Attackers commonly create or acquire Microsoft 365 tenants and configure accounts that resemble corporate support identities.
About 30–40% of the cases analyzed used default Microsoft tenant domains. Other malicious accounts used purchased domains; the .top extension accounted for roughly half of the paid domains observed in recent months.
Display names strengthen the deception: attackers append friendly first names, support titles, company names, or an “Internal” label to make an external account appear legitimate.
These labels do not change the account’s trust level, but they make employees more likely to ignore external-user warnings and accept an unexpected support request.
In many incidents, the Teams contact followed hundreds of newsletter subscriptions or confirmation emails delivered in minutes. The attacker then offers help via chat or a Teams voice call.
The staged issue provides a credible reason to request screen sharing, remote control, or the installation of software.
Quick Assist was the most commonly observed remote-support tool, with AnyDesk, ScreenConnect, TeamViewer, Atera and others also seen. Prior Teams “vishing” attacks used authorized remote sessions to deliver backdoors and malware.
These legitimate applications are not malicious by themselves; the risk comes from granting access to an unverified person. The transition from contact to compromise can be rapid.
Customers reported payload execution within 15 minutes of initial engagement, and attackers often messaged several employees within about five minutes.
After gaining control, operators sometimes install an additional remote-management application to create a persistent access channel that can remain available even if the first malicious component is removed.
Malware delivery, detection and defensive measures
In the infection chain described by Arctic Wolf, the impersonator instructs an employee to run PowerShell to launch a downloaded installer.
The command fetches an MSI package from Azure Blob Storage that contains a script and a compressed archive. Both initial actions run under the victim’s account with Windows Explorer recorded as the parent process.
About 30 seconds after installation, a bundled script executes from the user’s local application data folder. It decodes hexadecimal content and decrypts another PowerShell stage using an embedded AES key and initialization vector.
A hash comparison checks the decrypted content before it is executed via a PowerShell ScriptBlock. The next stage extracts a Python interpreter and an implant, and launches the implant after a five-second delay.
The malware initiates another MSI transaction and queries Active Directory for computer and user objects. Collected account names and descriptions are sent to command-and-control endpoints randomly chosen from destinations embedded in the code.
Arctic Wolf identifies the initial ChatCreated event as an early detection opportunity, but defenders should correlate that event with mass email or subscription activity, remote-support tool launches, PowerShell execution, and identity alerts.
Guidance from related Teams investigations highlights audit-log visibility limitations, so endpoint evidence is important when reconstructing how an employee interaction led to compromise.
Recommended defenses include following Microsoft’s external-access guidance and restricting external communications to trusted partner domains where practical. Limit the presence of remote-support applications, investigate unexpected installations, and require employees to verify unsolicited help requests through a known helpdesk phone number or service portal. A familiar chat interface does not prove the sender is a member of internal IT.
Indicators of compromise (IoCs)
| Type | Source-reported indicators |
|---|---|
| Attacker tenant domains |
supportedge33[.]onmicrosoft[.]com supportedge39[.]onmicrosoft[.]com helpdeskteam365[.]onmicrosoft[.]com itendpoint365[.]onmicrosoft[.]com itcoreportal[.]onmicrosoft[.]com networkadmin797[.]onmicrosoft[.]com networkadmin916[.]onmicrosoft[.]com itadmin922[.]onmicrosoft[.]com supportagentonline[.]onmicrosoft[.]com threatpro[.]onmicrosoft[.]com ithelpplus42[.]onmicrosoft[.]com corporateitservicellc[.]onmicrosoft[.]com techsupport2337[.]onmicrosoft[.]com |
| Payload and C2 domains (appendix) |
update-software[.]top infoupdate-it[.]top soft-program[.]top getsysmonitor[.]top programupdate-assis[.]top expertassist[.]top sec-check-it[.]top upd-check-soft[.]top assis-programupdate[.]top get-info-check[.]top updsysseq[.]top techrelay[.]top verifsec-update[.]top sys-update-check[.]top get-help[.]top it-assistant[.]top ms-system-check[.]top scan-updseq[.]top it-seccontrol[.]top verifcontrol-update[.]top get-upd-sys[.]top get-sys-info[.]top getsystembridge[.]top data-sys-seq[.]top soft-network[.]top |
| Additional domains in ATT&CK mapping |
getitconnect[.]top get-help-systems[.]top helpdesk-sys[.]top help-desk-get[.]top fix-it[.]top |
| Helpdesk lookalike domains |
helpdesk-support-us-ny[.]com helpdesk-support-office-3[.]com helpdesk-support-office-4[.]com helpdesk-support-us3[.]com helpdesk-call[.]com helpdesk-s1x[.]com itdeskassist[.]com |
| Payload or credential-phishing domains |
kilan[.]com[.]pl saludcentro[.]gov[.]co ggc[.]com[.]ph scapini[.]com[.]br |
| Files and execution artifacts |
archive6.zip cleaner.ps1 ss.py pythonw.exe AppDataLocalPowershellCleanerscripts |
| Impersonation names and patterns |
IT Support (Internal) Help Desk IT Support HelpDesk Manager IT Service Desk – Liam IT Service Desk (Liam) IT Service Desk – Matt IT Service Desk – Scott IT Support – Christopher Thomas HelpDesk Supervisor Enterprise IT & Security (Internal) IT Tech Support Internal Business IT Solutions & Support (Internal) Maintenance Service IT-Representative IT/Help Desk IT Support (Scott McGhee) IT Service Desk (Matthew) Supporte TI IT Support 🛡 | Corporate IT Service 🛠 (Internal) |
| File hashes | Not provided in the source report. |
Note: IP addresses and domain names above are intentionally defanged (for example, using [.] ) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat-intelligence platforms such as MISP, VirusTotal, or your SIEM.
Security teams should monitor for suspicious external Teams chats (ChatCreated events), correlate them with unusual email or subscription activity, watch for remote-support tool installs and PowerShell execution, and verify any unsolicited help requests through established helpdesk channels. Limiting external access and restricting unneeded remote-support applications will reduce the risk of this impersonation technique being successful.
Organizations that want to shorten response times should integrate relevant threat intelligence and ensure SOCs have the context to detect and stop incidents quickly.
