Fake Zoom and Google Meet scams install Teramind: A technical deep dive

Attackers don’t always need custom malware. Sometimes they just need a trusted brand and a legitimate tool.

UPDATE (February 27, 2026): We have added more clarity around the abuse of legitimate commercial products, and of Teramind’s stealth mode.

Important note: Teramind, the software vendor referenced in this article, has stated they are not affiliated with the threat actors described, did not deploy the software referenced, and condemn any unauthorized misuse of commercial monitoring technologies. Teramind is a legitimate commercial product with lawful enterprise use cases.

February 24, 2026, we published an article about how a fake Zoom meeting “update” silently installs monitoring software, documenting a campaign that used a convincing fake Zoom waiting room to push a legitimate Teramind installer abused for unauthorized surveillance onto Windows machines.

Following publication of our findings, the malicious domain was reported to its domain name registrar, Namecheap, which confirmed it suspended the service. Despite the takedown, our continued monitoring shows the campaign is not only still active but growing: we have now identified a parallel operation impersonating Google Meet, running from a different domain and infrastructure.

In this article, we’ll provide the deeper technical analysis behind both variants, cataloguing the use of Teramind instance IDs by scammers that we have directly observed or collected from sandbox repositories, document our hands-on detonation of the installer in a controlled environment, and answer a question that emerged during our research: How can a single, identical Windows installer package serve several different attacker accounts?

The campaign expands to Google Meet

While the original Zoom-themed site at uswebzoomus[.]com was taken down by Namecheap following community reporting, a second site at googlemeetinterview[.]click is actively deploying the same payload using an identical playbook adapted for Google Meet.

The Google Meet variant presents a fake Microsoft Store page branded as “Google Meet for Meetings” published by “Google Meet Video Communications, Inc,” which is a fabricated entity. A “Starting download…” button is displayed while the MSI file is silently delivered via the path /Windows/download.php. The referring page is /Windows/microsoft-store.php, confirming the fake Microsoft Store screen is served by the attacker’s infrastructure, not by Microsoft.

Our Fiddler traffic capture of the Google Meet variant shows the response header:

Content-Disposition: attachment; filename="teramind_agent_x64_s-i(__06a23f815bc471c82aed60b60910b8ec1162844d).msi".

Unlike the Zoom variant, where the filename was disguised as a Zoom component, this variant does not even attempt to hide the scammer’s abuse of Teramind in the filename. We verified both files are byte-for-byte identical (MD5: AD0A22E393E9289DEAC0D8D95D8118B5), confirming a single binary is being served across both campaigns with only the filename changed.

Infrastructure differences between variants

Despite using the same payload, the two variants are hosted on different infrastructure. The Zoom variant at uswebzoomus[.]com ran on Apache/2.4.58 (Ubuntu) and was registered through Namecheap on 2026-02-16. The Google Meet variant at googlemeetinterview[.]click runs on a LiteSpeed server.

Both serve the download via PHP scripts and use the same fake Microsoft Store redirect pattern, but the switch in web server and domain registrar suggests the operator anticipated takedowns and pre-positioned fallback infrastructure.

One binary, many identities. How the installer reads its own filename

During our investigation, we identified 14 distinct MSI filenames sharing the same SHA-256 hash. Of these, two were directly captured from malicious infrastructure through our malware domain analysis: the Zoom variant from uswebzoomus[.]com and the Google Meet variant from googlemeetinterview[.]click. The remaining filenames were sourced from sandbox repositories.

It is important to note that some of these sandbox-sourced filenames may represent legitimate corporate Teramind deployments rather than malicious activity. Teramind is a commercial product with lawful enterprise use cases, and files submitted to sandbox services do not necessarily indicate abuse. Nevertheless, they all share the same binary and demonstrate the same filename-based configuration mechanism.

Every file shares the same SHA-256 hash: 644ef9f5eea1d6a2bc39a62627ee3c7114a14e7050bafab8a76b9aa8069425fa. This raised an immediate question: if the Teramind instance ID changes with every filename, but the binary is byte-for-byte identical, where is the ID actually stored?

The answer lies in a .NET custom action embedded inside the MSI. Our behavioral analysis reveals the following sequence:

Calling custom action Teramind.Setup.Actions!Teramind.Setup.Actions.CustomActions.ReadPropertiesFromMsiName

PROPERTY CHANGE: Modifying TMINSTANCE property. Its current value is 'onsite'. Its new value: '__941afee582cc71135202939296679e229dd7cced'.

PROPERTY CHANGE: Adding TMROUTER property. Its value is 'rt.teramind.co'.

The MSI ships with a default TMINSTANCE value of onsite. This is the standard Teramind on-premise default. At install time, the ReadPropertiesFromMsiName custom action parses the installer’s own filename, extracts the 40-character hex string from the s-i(__) portion, and overwrites the default with the attacker-specific instance ID.

The log also shows the message Failed to get router from msi name. The installer attempted to extract a C2 server address from the filename but could not. In this case, it falls back to the default value rt.teramind.co, which is preconfigured inside the MSI. However, TMROUTER is an exposed MSI property, so it could potentially be overridden at install time or changed in a different build. The filename in this campaign carries only the instance ID; the C2 destination is determined by the MSI’s default configuration.

Live detonation: what the installer actually does on a real system

To go beyond sandbox-based behavioral analysis, we detonated the MSI installer in an isolated Windows 10 virtual machine with verbose MSI logging enabled, ApateDNS for DNS interception, and Fiddler for network monitoring. This hands-on analysis revealed several critical behaviors not visible in automated sandbox reports.

Installation chain and the CheckHosts gate

The MSI installer progresses through four .NET custom actions in sequence, all executed via the WiX Toolset’s zzzzInvokeManagedCustomActionOutOfProc mechanism:

• ReadPropertiesFromMsiName: Parses the MSI’s own filename to extract the Teramind instance ID and overwrites the default onsite value

• CheckAgent: Determines whether a Teramind agent is already installed on the machine

• ValidateParams: Validates the extracted configuration parameters

• CheckHosts: Performs a pre-flight connectivity check against the C2 server rt.teramind.co

The CheckHosts action is a hard gate: if the installer cannot reach the Teramind server, installation aborts with error code 1603. Our initial detonation attempt in a network-isolated VM failed at exactly this point:

TM: TMINSTANCE = __941afee582cc71135202939296679e229dd7cced

TM: TMROUTER = rt.teramind.co

CustomAction CheckHosts returned actual error code 1603

This behavior is significant for two reasons. First, it reveals the C2 server address: rt.teramind.co. Second, it means that victims on corporate networks with restrictive DNS or outbound filtering may be inadvertently protected. The installer will silently fail if it cannot phone home during installation. However, the MSI does support a TMSKIPSRVCHECK property that can bypass this check, and its default value is no.

[...]

Original source