The External Caller Who Claims to Be your Admin
The phone rings. You look down, and it's a Microsoft Teams call from an external user displaying as 'System Administrator'.
If you run incident response, it's your worst-case scenario.
It starts with a simple corporate annoyance. An email lands in an employee's inbox detailing an HTML lure for an 'Employee Survey results.' Click it, and it loads a PDF named EE Survey - How to log on.pdf. It is boring. It looks like standard corporate HR administration. But it is the setup.
Immediately after, they get a Teams voice call. The caller account looks authentic. In this campaign, the attackers utilized the tenant [email protected] (from tenant ID 310e9ead-4f6f-491e-aafe-feb08c8d17a4). Because cross-tenant communications are allowed by default in many organizations, the external user bypasses the perimeter entirely. The employee answers, thinking it is their internal IT service desk solving a survey issue.
We see these kinds of initial access shifts all the time. Traditional email filters are getting better, forcing scammers to adapt. To secure the entry point before a user even answers, organizations are looking at behavioral analysis systems. You can read about how this works in Why Your Email Security Team Is Drowning—And How Behavioral AI Is the Lifeline. When you let external callers drop straight into your employees' chats, you're setting yourself up for an intrusion. It's not a matter of if, but when. We have dismantled our network borders for the sake of collaboration, and threat actors are happy to walk right through the front door.
Inside the Teams remote control hijacking
Once the employee answers, the social engineering moves fast. The 'System Administrator' explains there is a critical configuration error. They request screen control directly through the Teams interface.
This is where the native client becomes the attacker's best friend.
When the user clicks 'give control,' Teams sets up native system artifacts—specifically generating virtual cursor windows like CtrlVirtualCursorWin_*. For an IR analyst, these artifacts are invaluable clues during a post-mortem, but during the live attack, they're invisible to the victim. The attacker uses this temporary control to download secondary remote monitoring and management (RMM) tools like HopToDesk and AnyDesk.
Why do they do this? To establish persistence that survives a hung-up Teams call.
Using commercial RMM tools is a smart way to bypass Endpoint Detection and Response (EDR) agents. EDR agents see commercial RMM binaries as legitimate tools. It's the classic 'living off the land' strategy. Once HopToDesk or AnyDesk is installed, the attacker no longer needs the Teams session. They have a backdoor they can access whenever they want, completely separated from the original vishing session.
This highlights the failure of traditional identity boundaries. If a user can arbitrarily grant permanent administrative access to a session, your security controls are obsolete. You should review how these identity shifts happen in When Login Isn't Enough: How Infostealers and Session Hijacking Are Breaking Identity Security. EDR won't save you if the attacker is using the user's own hands to invite them in.
Triggering the Silent Node.js MSI Chain
With remote control established, the attacker drops the hammer. They open a command prompt and use curl to download a loader helper named v7.msi from the domain camorreado.click.
This MSI installer acts as the staging ground.
Once executed, the MSI drops several critical files: a batch script named R2YxSP2m.cmd, an encrypted payload z0SYYdWk9g.dat, and a configuration file named eXYlcnebRLrWyBc.ini. The batch script executes a silent download of a legitimate Node.js v18.20.5 runtime, saving it in a local directory under AppData, typically named 1DIZ0D.
Think about this for a second. The attacker installs a massive, legitimate developer runtime environment on an accounting supervisor's laptop.
And it works. Because Node.js is a signed, legitimate tool, standard heuristics don't bat an eye. The batch script then calls the Node.js binary to run the payload script, decrypting the contents of the .dat file. What you get is a cross-platform remote access trojan (RAT) running inside a Node.js wrapper, completely bypassing traditional executable analysis. If your detection strategy relies on flagging raw binary executable formats, you'll miss this every time. Writing rules for Node.js execution within non-developer profiles is now a necessity, not an option.
Decentralized Control and Ethereum Core Contracts
The payload injected by this Node.js runner is a variant of EtherRAT. It is a capable remote access trojan that opens command shells, steals operational data, and logs keystrokes. But its Command and Control (C2) configuration is where it gets interesting.
It uses Web3 smart contracts to resolve its IP addresses.
Instead of hardcoding a server address or using a traditional domain generation algorithm (DGA), EtherRAT queries Ethereum smart contracts. Specifically, it reads transactions from contracts 0x6e044e19000487c4a6e6af15b4132a5561b5ee1f or 0x788a5336c0ef70be87619a3c13a43050c426f7ec. The transaction data contains hex-encoded directions pointing to the current active C2 servers.
These C2 endpoints are hosted on temporary Microsoft Azure services. If the Ethereum lookup fails, the RAT falls back to a hardcoded domain: necropatia.com. In our threat intelligence research, we found that active builds of EtherRAT (versions v1 through v9) were hosted in an open directory on camorreado.click.
This Web3 approach to C2 is a nightmare for standard firewall rules. You can't block the Ethereum blockchain without breaking legitimate developer or financial access. The attacker essentially hides their control signals inside normal public blockchain explorer traffic. To hunt this, you have to monitor outbound HTTP/HTTPS payloads targeting Ethereum JSON-RPC nodes or public block explorers, looking for reads of those specific contract addresses. It's a cat-and-mouse game, but the actors currently have the upper hand.
Defending the Collaboration Perimeter
How do we stop this cross-tenant Teams abuse?
First, you have to address the Teams configuration. Microsoft has rolled out updates to help defend against this, including an 'External unfamiliar' tag for chats with accounts outside your organization. But tagging is not enough. Users ignore warnings.
You must enforce strict external communication rules.
In MS Teams administrative settings, restrict external access. Set your tenant collaboration settings to allow chats only with verified domains, or disable external domains completely if your business model allows it. Additionally, change default meeting and lobby policies to prevent external participants and third-party bots from joining or sharing screens without explicit admin approval.
From a forensic perspective, you need to configure your SIEM with alerts tailored to collaboration logs. Search your Unified Audit Log (UAL) for the HasForeignTenantUsers flag in Teams events. Correlate this with endpoint alerts for new RMM tools like HopToDesk or AnyDesk, and monitor for virtual cursor process creations.
Ultimately, vishing on Teams is successful because security teams treated collaboration tools as safe zones. They aren't. If you treat Teams like the open internet, you might actually catch the intruders before they install their next runtime.