As reported by BleepingComputer, threat actors are actively abusing Microsoft Teams voice call functionality to impersonate corporate IT support personnel and manipulate employees into installing EtherRAT — a remote access trojan that hands attackers a persistent foothold inside enterprise networks. This campaign is a textbook example of a tactic that is rapidly maturing: vishing-as-initial-access, where voice-based social engineering replaces traditional phishing links entirely.
Why This Attack Pattern Is Particularly Dangerous
Most enterprise security awareness training focuses heavily on suspicious email links and attachments. Voice calls — especially those arriving through a trusted, org-internal platform like Microsoft Teams — occupy a significant blind spot in both user psychology and technical controls. Employees are conditioned to trust their helpdesk. When that helpdesk reaches out through a legitimate collaboration tool rather than an unknown phone number, the credibility of the interaction is dramatically amplified.
What makes this campaign especially insidious is the abuse of tenant trust boundaries. Microsoft Teams, by default in many configurations, allows inbound calls and messages from external federated tenants or even unauthenticated guests. Attackers exploit this to make impersonation seamless — the contact appears within the Teams UI, lending an air of legitimacy that a cold call from a spoofed number simply cannot replicate.
Shield53 Perspective: The shift from email to voice-over-platform social engineering represents a deliberate attacker response to improving email security controls. As organizations have hardened their inboxes, adversaries have migrated to the next weakest link: human trust in real-time voice interaction.
EtherRAT: What Defenders Need to Know
EtherRAT is a .NET-based remote access trojan that communicates over the Ethereum blockchain's smart contract infrastructure — a technique designed specifically to evade traditional network-based detection. Because the C2 channel leverages decentralized blockchain infrastructure rather than attacker-controlled IP addresses or domains, conventional blocklists and domain reputation feeds offer virtually no protection. This places enormous pressure on endpoint detection and behavioral analysis capabilities.
Key characteristics that defenders should be aware of include:
Who Is Most at Risk
This campaign targets the full spectrum of Microsoft Teams enterprise deployments, but organizations with the following characteristics face elevated exposure:
- Large enterprises with distributed IT helpdesk functions, where employees may not personally recognize every IT staff member
- Organizations with permissive Teams external access or guest access policies enabled without compensating controls
- Companies that have not implemented verified helpdesk call-back procedures or identity verification workflows
- Environments relying primarily on signature-based AV without behavioral EDR coverage
- Industries with high Teams adoption and geographically distributed workforces: financial services, healthcare, professional services, and technology sectors
The Broader Implication: Platform Trust as an Attack Surface
This campaign is a signal, not an anomaly. As enterprise adoption of unified communications platforms accelerates, those platforms become increasingly attractive vectors for social engineering. We have already seen Teams abused for phishing document delivery; adding real-time voice impersonation closes the gap between a convincing pretext and a successful compromise. Security teams that treat Teams, Slack, Zoom, and similar platforms as inherently trusted internal tools — rather than as externally-reachable attack surfaces — are operating with a dangerous assumption.
Shield53 Recommendations
Immediate Actions
- Audit Microsoft Teams external access settings immediately. Disable or restrict external federation and guest access unless operationally required. Navigate to Teams Admin Center → External Access and review all enabled domains.
- Establish and communicate a verified helpdesk identity protocol. Employees should never install software based solely on a Teams call. Require helpdesk staff to verify identity through a secondary channel (ticketing system reference number, manager confirmation).
- Deploy application allowlisting or control policies to prevent unauthorized executables from running, particularly those downloaded from non-standard locations or initiated by users without admin rights.
- Update EDR behavioral rules to flag .NET process execution following Teams activity, and monitor for anomalous outbound connections to Ethereum RPC nodes (e.g., infura.io, alchemy.com) from non-development endpoints.
- Hunt for EtherRAT indicators across your environment using available threat intelligence. Review endpoint telemetry for unexpected .NET binary execution, unusual scheduled tasks, and registry persistence mechanisms created by non-standard processes.
Longer-Term Controls
- Incorporate vishing simulation exercises into your security awareness program — specifically scenarios involving Teams and Zoom, not just email.
- Implement Conditional Access policies that restrict Teams app functionality on unmanaged or non-compliant devices.
- Consider network-level blocking of Ethereum JSON-RPC endpoints on corporate egress paths for non-development environments as a blanket C2 disruption measure.
- Establish a clear employee reporting mechanism for suspicious IT support contacts — and actively track and investigate these reports as potential indicators of targeted campaigns against your organization.
The convergence of trusted platform abuse, sophisticated blockchain-based C2, and high-quality social engineering makes this threat cluster one that security teams cannot afford to treat as a low-priority edge case. The attack chain is proven, the tooling is evasive, and the entry point is your own employees.