The Technician Who Came to Help: How Fake Microsoft Teams Support Turned a Crisis Into a Ransomware Attack
The office was having a terrible morning.
Hundreds of emails were arriving without warning. Newsletter confirmations, subscription notifications, unfamiliar messages. The inbox was overflowing faster than anyone could clear it.
Then came the message.
A Microsoft Teams notification.
IT Support (Internal): “Hello. We’ve detected an issue affecting your mailbox. I can help you resolve it.”
The employee hesitated.
The name looked official. The timing was perfect. The person on the other side seemed to know exactly what was happening.
A remote support session was offered.
The employee accepted.
And somewhere on the other side of the connection, the technician stopped pretending to help.
The emergency had been manufactured. The rescue had been staged. And the person invited to fix the problem was the person who created it.
That is the recurring social engineering pattern identified by Arctic Wolf Labs across hundreds of incidents involving Microsoft Teams, fake IT support identities, remote-access software and, in some cases, ransomware.
Phase 1 — Manufacturing the Emergency
The operation often begins before the first Teams message appears.
The attackers flood a target’s inbox with hundreds of newsletter subscriptions, registration confirmations and other automated emails.
This technique, known as email bombing, is designed to overwhelm the victim.
The objective is psychological.
An employee confronted with an apparently malfunctioning mailbox may become distracted, frustrated and eager for assistance.
Then, at the height of the disruption, someone arrives with an explanation.
The attacker has created both the problem and the apparent solution.
The fire was deliberately started so the arsonist could arrive wearing a firefighter’s uniform.
Phase 2 — A Familiar Name on an Unfamiliar Screen
Microsoft Teams allows communication between users belonging to different organizations when external access is enabled.
That capability supports legitimate business collaboration.
But it also gives attackers a route to contact employees without first compromising the target organization’s Microsoft 365 tenant.
According to Arctic Wolf, threat actors establish identities using newly created or acquired Microsoft 365 tenants.
They then choose display names designed to resemble internal technical support.
Observed examples include:
Help Desk
IT Support
HelpDesk Manager
IT Service Desk – Liam
IT Support – Christopher Thomas
Enterprise IT & Security (Internal)
IT Tech Support Internal
HelpDesk Supervisor
Some attackers also incorporate the target organization’s name or domain into their display names.
The deception is simple but effective.
A warning indicating that a Teams user is external may be present, yet the displayed name and the surrounding circumstances encourage the employee to interpret the conversation as legitimate internal support.
The uniform was fake. But it looked convincing enough to get past the receptionist.
Phase 3 — Building a Fake IT Department
The impersonation extends beyond a single display name.
Arctic Wolf found that approximately 30–40% of investigated cases involved tenants using Microsoft’s automatically generated onmicrosoft.com domains.
Examples included:
helpdeskteam365.onmicrosoft[.]com
itendpoint365.onmicrosoft[.]com
itcoreportal.onmicrosoft[.]com
itadmin922.onmicrosoft[.]com
corporateitservicellc.onmicrosoft[.]com
These are not necessarily compromised Microsoft domains.
They are tenant identities chosen or created by attackers to resemble corporate IT infrastructure.
Researchers also observed a shift toward custom domains.
Among the paid domains identified in these scams, approximately half used the .top top-level domain, around 40% used .com, and a smaller proportion used multi-level domains such as .com.pl, .com.vn and .com.br.
The purpose was credibility.
A technician appearing under a support-themed tenant name can seem more trustworthy than an unfamiliar external account.
The attackers weren’t merely pretending to be technicians. They were constructing an entire counterfeit help desk around the disguise.
Phase 4 — The Perfectly Timed Rescue
Once the victim is sufficiently distracted by email bombing, the fake technician initiates contact.
The message may be calm, professional and reassuring.
The attacker offers to fix the mailbox problem, investigate the flood of emails or perform a routine maintenance task.
The next step is often a voice conversation or a sequence of instructions designed to convince the victim to start a remote support session.
This introduces a critical shift.
Until this point, the attacker has only been communicating with the employee.
Now the attacker wants control of the endpoint.
And rather than deploying an obviously malicious remote-control application, the impostor may recommend a legitimate tool.
The employee sees recognizable software.
The attacker sees an open door.
Phase 5 — The Remote-Control Handover
Researchers observed attackers abusing legitimate remote monitoring and management tools, including:
Microsoft Quick Assist
AnyDesk
ConnectWise ScreenConnect
TeamViewer
Atera
Zoho Assist
NetSupport
LogMeIn
These products are widely used for legitimate administration and technical support.
Their presence alone is not evidence of malicious activity.
But when an attacker persuades a user to establish a remote session, the same capabilities can be abused to interact with the machine, run commands and introduce additional software.
This is what makes the attack particularly dangerous.
The initial access may not require exploitation of a software vulnerability.
Instead, the attacker exploits the employee’s trust in the support process.
The technician didn’t steal the office keys. He persuaded the employee to hand them over.
Phase 6 — The Repair Tools Become Weapons
After obtaining remote access, the attacker can begin operating directly on the endpoint.
Arctic Wolf documented activity involving reconnaissance, additional malware deployment and attempts to expand access.
In one case, the attacker instructed the victim to execute a PowerShell command that downloaded an MSI installer from Microsoft Azure Blob Storage.
When executed, the installer launched a PowerShell script that extracted and ran an embedded Python implant.
The implant subsequently initiated another MSI transaction.
That activity performed LDAP queries against Active Directory, enumerating computer and user objects before transmitting the information to an external server.
The sequence illustrates how a seemingly ordinary support interaction can develop into an internal reconnaissance operation.
The attacker is no longer trying to solve an email problem.
The attacker is learning how the organization’s environment is structured.
The fake technician has stopped examining the broken mailbox. He is studying the building’s floor plan.
Phase 7 — From One Computer to the Entire Network
Once attackers establish a foothold, they may seek broader access.
Observed activity includes deployment of the GoGRPC backdoor, reconnaissance against internal infrastructure and lateral movement toward domain controllers.
Attackers have also installed additional remote-management software, including Level, to create redundant access paths.
This redundancy matters.
If defenders discover and terminate one remote session, another management agent may allow the attacker to return.
The progression can involve:
Identifying privileged accounts and systems.
Mapping Active Directory relationships.
Installing additional remote-access tools.
Moving between compromised endpoints.
Accessing sensitive information.
Exfiltrating data.
Not every incident reaches every stage.
But the reported cases demonstrate how a single social engineering success can provide a starting point for much more extensive compromise.
The technician was invited to inspect one computer. He began looking for the keys to the entire building.
Phase 8 — The Final Service Call: Ransomware
Some of the observed activity aligns with the threat cluster tracked as STAC4749.
Sophos has associated related attacks with the deployment of Chaos ransomware.
The attackers reportedly used IT-themed cloud domains, convincing employee-style identities and remote-access tools to establish access before pursuing additional objectives.
In ransomware-related cases, the attack chain could progress from the initial Teams conversation to malware installation, internal reconnaissance, data theft and eventual ransomware deployment.
The transformation is striking.
What began as a request to fix an overflowing inbox can end with business systems encrypted and sensitive information stolen.
The person who promised to restore normal operations may become the reason operations stop.
The repair appointment was never about fixing the machine. It was about gaining enough control to shut the organization down.
Phase 9 — Why the Security Filters May Miss the Intruder
The attackers also adapt their behavior to avoid straightforward message-based detection.
Arctic Wolf observed that threat actors sometimes avoided posting malicious download links directly into Teams conversations.
Instead, after obtaining remote access, they navigated to payload locations themselves or initiated downloads through commands executed on the endpoint.
This can reduce the effectiveness of controls focused primarily on scanning links shared through Teams.
The suspicious activity shifts from the messaging platform to the operating system.
Defenders therefore need to correlate several sources of evidence:
Messaging telemetry: unexpected external Teams conversations, newly encountered tenant identities and suspicious support-themed display names.
Email telemetry: sudden bursts of newsletter confirmations or subscription messages.
Endpoint telemetry: remote-support sessions, unusual process execution, PowerShell activity, MSI installations and unexpected remote-management agents.
Identity telemetry: abnormal authentication, Active Directory enumeration and suspicious privileged-account activity.
The crucial point is that no single security control necessarily sees the entire attack.
The fake technician enters through the reception desk, but the damage happens in the server room.
Phase 10 — How to Recognize the Impostor
Defending against these scams requires both technical controls and reliable support procedures.
Restrict external Teams communication where unnecessary.
Organizations should review external-access policies and determine which users or business groups genuinely require communication with external tenants.
Verify support requests independently.
Employees should confirm unexpected IT requests through established internal channels, especially when the contact asks for remote access or command execution.
Treat email bombing as a potential intrusion precursor.
A sudden flood of subscription emails should trigger investigation, particularly when followed by unsolicited support messages.
Control remote-access software.
Organizations should monitor and, where appropriate, restrict unauthorized use of Quick Assist, AnyDesk, ScreenConnect and other remote-support tools.
Monitor suspicious execution chains.
Unexpected PowerShell commands, MSI installations, Python execution and downloads from unfamiliar locations deserve attention when associated with unsolicited support interactions.
Detect lateral movement and persistence.
Monitor new remote-management agents, unusual LDAP enumeration, privileged account activity and access to domain controllers.
Train employees to recognize manufactured urgency.
The objective is not to make users distrust every technician. It is to ensure that legitimate support can be verified without relying solely on the name displayed in a chat window.
A convincing uniform is not proof of identity.
Neither is a familiar Microsoft Teams interface.
The Final Scene — The Technician Was the Threat
The most effective element of this campaign was not necessarily the malware.
It was the story the attacker told.
First, the employee was overwhelmed by an apparent technical problem.
Then, a helpful stranger appeared at precisely the right moment.
The stranger wore the name of an internal support technician, used familiar collaboration software and offered a solution involving legitimate remote-access tools.
Only after trust had been established did the operation reveal its real purpose.
Backdoors, reconnaissance, lateral movement, data theft and ransomware could follow.
The attack demonstrates how legitimate enterprise workflows can become entry points when identity and intent are accepted without independent verification.
No vulnerability in Teams was required for the initial deception.
The attackers simply took advantage of the fact that employees expect IT support to help when something goes wrong.
The most dangerous part of the attack wasn’t the moment the technician took control.
It was the moment the employee believed he had come to help.
The Hacker News
Comentarios