EtherRAT malware spread via fake IT support calls on Microsoft Teams
Threat actors have refined a social engineering playbook that exploits legitimate Microsoft Teams infrastructure. The sequence is straightforward: a call arrives on Teams from what appears to be an internal IT support contact, the caller explains there is a security issue with the employee’s device, and they guide the target to install a remote-access tool — in this case, EtherRAT. Once installed, attackers gain persistent access to the corporate network.
Why Teams Is the New Phishing Vector
Most organisations have invested heavily in email security — spam filters, sandboxing, and phishing simulation programmes. Voice and video call channels have received far less attention. There are no equivalents to DKIM and DMARC for Teams calls; the social proof comes from the caller’s display name and the fact that the call arrived inside a trusted application.
What makes this campaign particularly effective is that Teams is trusted by default. Employees have been conditioned to treat calls from IT as legitimate, and the familiar interface removes the visual cues that might flag a suspicious email. The attacker has essentially weaponised institutional trust. This attack vector is also scalable: multiple calls can run in parallel, targeted by role, with scripts iterated quickly based on what succeeds.
The EtherRAT Payload in Context
EtherRAT provides exactly what a ransomware precursor or data-exfiltration operation requires: persistent, stealthy access that is difficult to attribute at the point of initial compromise. The malware is a vehicle for whatever the attacker wants to do next — credential harvesting, lateral movement, or holding encrypted data for ransom. Early detection depends on catching the installation event, not the downstream attack.
Practical Defences Now
The immediate countermeasure is a clear, enforced policy: IT support will never call an employee and ask them to install software or grant remote access during an unscheduled call. Employees should be empowered to hang up and call back via a known, verified number. Restrict who can initiate external calls into your Teams tenant, and audit whether guest-access policies are tighter than the defaults.
For ops leaders: this is a training and policy problem as much as a technical one. Add this specific scenario to your next phishing simulation cycle and brief your helpdesk team on how to handle employees who report suspicious inbound calls.