Fake Zoom and Google Meet scams install Teramind: A technical deep dive
On 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 un
Attackers Have Been Exploiting Cisco SD-WAN Zero-Day Flaw Since 2023
On 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. Teramind 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.
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 use 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—meaning 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, meaning 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.
To complete our analysis, we added rt.teramind.co to the Windows hosts file pointing to localhost, allowing the DNS resolution to succeed and the CheckHosts action to pass. The installation then completed successfully.
Stealth mode confirmed
The successful installation log confirms what the original article suspected: Teramind’s stealth mode (called Hidden Agent, a deployment option that runs silently in the background) is enabled by default in this build. The MSI property dump shows:
Property(S): TMSTEALTH = 1
This confirms the agent installs with no taskbar icon, no system tray entry, and no visible entry in the Windows Programs list. The victim has no visual indication that monitoring software is running.
Two services, not one
The install log reveals the campaign deploys two persistent services, not just the one documented in our original article:
Service Name
Display Name
Binary
Start Type
tsvchst
Service Host
svc.exe –service
Automatic (boot)
pmon
Performance Monitor
pmon.exe
Manual (demand)
Both service names are chosen to blend in: tsvchst mimics the legitimate Windows svchost.exe naming pattern, while pmon with the display name “Performance Monitor” mimics the built-in Windows Performance Monitor. Both run as LocalSystem, the highest privilege level on a Windows machine.
Both services are configured with aggressive failure recovery: restart on first failure, restart on second failure, and restart on subsequent failures, with delays of 160 seconds (tsvchst) and 130 seconds (pmon). This means even if a user or security tool terminates the service, it automatically restarts within minutes.
Live C2 callback observed
Immediately after installation, ApateDNS captured the agent phoning home. DNS queries for rt.teramind.co appeared within seconds of the service starting, confirming the agent begins its callback cycle immediately. The queries repeated at approximately 11-second intervals, showing a persistent polling pattern.
In a real-world scenario where the victim has internet connectivity, these would resolve to Teramind’s infrastructure and the agent would begin transmitting captured data.
Full MSI configuration surface
The verbose installation log exposes every configurable parameter the MSI supports through its SecureCustomProperties list. This reveals the installer’s full configuration surface:
TMSTEALTH — Stealth mode (set to 1 in this build)
TMINSTANCE — Account identifier (extracted from filename)
TMROUTER — C2 server address (hardcoded to rt.teramind.co)
TMENCRYPTION — C2 communication encryption toggle
TMSOCKSHOST / TMSOCKSPORT / TMSOCKSUSER / TMSOCKSPASSWORD — Built-in SOCKS5 proxy support for tunneling C2 traffic through proxies
TMHTTPPROXY — HTTP proxy support
TMSKIPSRVCHECK — Skip the C2 connectivity pre-flight check
TMNODRV / TMNOFSDRV — Disable kernel filter drivers
TMNOIPCCLIPBOARD — Clipboard monitoring toggle
TMNOREMOTETS — Remote terminal services monitoring toggle
TMHASHUSERNAMES — Anonymize/hash captured usernames
TMDISABLESCREEN — Disable screenshot capture
TMADDENTRYTOARP — Add/remove entry from Add/Remove Programs (off in stealth)
TMCRASHUPLOADURL — Crash telemetry upload endpoint
TMREVEALEDPASSWORDLESS — Toggle for passwordless reveal functionality
The SOCKS5 proxy support is particularly noteworthy. It means the agent can be configured to route all surveillance data through an attacker-controlled proxy, making network-level detection significantly harder by disguising C2 traffic as legitimate proxy traffic.
Observed Teramind instance IDs
The following table lists every MSI filename and corresponding Teramind instance ID we have collected. Of these, two were directly observed in the wild through our own malware domain analysis: the Zoom variant (941afee…7cced, captured from uswebzoomus[.]com) and the Google Meet variant (06a23f8…2844d, captured from googlemeetinterview[.]click). The remaining filenames were sourced from sandbox repositories.
As noted above, some of these may represent legitimate enterprise deployments rather than malicious use. All files share the same SHA-256 hash. Two filenames share the same instance ID c0cea71…0a6d7, indicating the same attacker account was used across multiple filename variations.
MSI Filename
Instance ID
zoom_agent_x64_s-i(__941afee582cc71135202939296679e229dd7cced).msi
941afee582cc71135202939296679e229dd7cced
ZoomApp_agent_x64_s-i(__fca21db2bb0230ee251a503b021fe02d2114d1f0).msi
fca21db2bb0230ee251a503b021fe02d2114d1f0
945bd48ad7552716f4583_s-i(__d72c88943945bd48ad7552716f4583ada0b7c2a6).msi
d72c88943945bd48ad7552716f4583ada0b7c2a6
teramind_agent_x64_s-i(__572d85bb94f4f59ef947c3faf42677f9adb223c3).msi
572d85bb94f4f59ef947c3faf42677f9adb223c3
file_agent_x64_s-i(__f76fee1df21e19d93d5842f50c375286477b3f6c).msi
f76fee1df21e19d93d5842f50c375286477b3f6c
teramind_agent_x64_s-i(__653d105a51cc886dede8101d1b0cd02e20329546).msi
653d105a51cc886dede8101d1b0cd02e20329546
e411293f92e8730f717_s-i(__c0cea713de411293f92e8730f71759aa1890a6d7).msi
c0cea713de411293f92e8730f71759aa1890a6d7
0154299765aa7b198bce97d8361_s-i(__c0cea713de411293f92e8730f71759aa1890a6d7).msi
c0cea713de411293f92e8730f71759aa1890a6d7
GoogleMeet_agent_x64_s-i(__ab28818c0806ce7996c10c59b0e4e5d102783461).msi
ab28818c0806ce7996c10c59b0e4e5d102783461
teramind_agent_x64_s-i(__5ca3d9dd35249200363946b1f007b59f88dbde39).msi
5ca3d9dd35249200363946b1f007b59f88dbde39
file_agent_x64_s-i(__81c39bed817fc9989834c81352cb7f69b94342da).msi
81c39bed817fc9989834c81352cb7f69b94342da
GoogleMeet_agent_x64_s_i_94120be3942474019852c62041d2f373fdb11a0e.msi
94120be3942474019852c62041d2f373fdb11a0e
AdobeReader_agent_x64_s-i(__d57d34e76cc8c2c883cbdcb42a14c47d00be03c0).msi
d57d34e76cc8c2c883cbdcb42a14c47d00be03c0
teramind_agent_x64_s-i(__06a23f815bc471c82aed60b60910b8ec1162844d).msi
06a23f815bc471c82aed60b60910b8ec1162844d
The variety of filename prefixes is notable: zoom_agent, ZoomApp_agent, GoogleMeet_agent, AdobeReader_agent, teramind_agent, and file_agent. This suggests the campaign extends beyond video conferencing impersonation.
However, the AdobeReader-branded variant was found only in sandbox repositories and may represent testing or planned expansion rather than an active deployment. The filenames with generic prefixes like teramind_agent and file_agent similarly appear to be sandbox submissions that retained the default naming rather than a brand-specific social engineering lure.
Indicators of Compromise
File hashes
SHA-256: 644ef9f5eea1d6a2bc39a62627ee3c7114a14e7050bafab8a76b9aa8069425fa
MD5: AD0A22E393E9289DEAC0D8D95D8118B5
Domains
uswebzoomus[.]com (Zoom variant: taken down by Namecheap)
googlemeetinterview[.]click (Google Meet variant: active as of 2026-02-26)
Detection and defense recommendations
Alert on the ProgramData GUID directory {4CEC2908-5CE4-48F0-A717-8FC833D8017A}. This GUID is fixed across all observed variants.
Query for both services: sc query tsvchst and sc query pmon. Either running on a non-corporate machine confirms active surveillance.
Watch for kernel driver loads: tm_filter.sys and tmfsdrv2.sys loading on personal machines should trigger high-severity alerts.
Block MSI execution from browser download directories. Both variants rely on the user running an MSI from their Downloads folder. Application control policies that prevent MSI execution from user-writable paths would stop this attack chain.
Educate employees: Never update applications by clicking links in messages. Use the application’s built-in update mechanism or navigate to the vendor’s official website manually.
Deploy browser policies that warn on or block automatic file downloads from unrecognized domains.
Removal
To uninstall the agent, run the following command as Administrator: msiexec /x {4600BEDB-F484-411C-9861-1B4DD6070A23} /qb. This removes the services, kernel drivers, and most installed files. However, our testing confirmed the uninstaller fails to fully delete the ProgramData directory due to runtime-generated files. After uninstalling, manually remove any remnants with rmdir /s /q “C:ProgramData{4CEC2908-5CE4-48F0-A717-8FC833D8017A}” and reboot to fully unload the kernel drivers from memory.
Conclusion
This campaign demonstrates the abuse of legitimate commercial monitoring software. The attackers did not write custom malware. Instead, they took an off-the-shelf monitoring product, leveraged its built-in stealth mode and filename-based configuration system, and wrapped it in social engineering designed to exploit trust in brands like Zoom and Google Meet.
The expansion to Google Meet, plus additional sandbox-sourced variants including an AdobeReader-branded filename, suggests this is an evolving operation that may expand to impersonate other applications.
Our hands-on detonation revealed details invisible to automated sandboxes: the CheckHosts C2 pre-flight gate, the rt.teramind.co router address, the second pmon service masquerading as Performance Monitor, the confirmed TMSTEALTH = 1 flag, and the full SOCKS5 proxy capability for C2 evasion. The fact that a single binary serves unlimited attacker accounts through nothing more than a filename rename makes this campaign easily scalable.
Acknowledgments
We would like to thank security researcher @JAMESWT_WT for promptly reporting the original malicious domain to Namecheap, leading to the takedown of uswebzoomus[.]com.
Teramind has stated that the company was not involved in this campaign. Because Teramind is a legitimate commercial product, it is not flagged by security software, meaning we have no visibility into whether this campaign has resulted in real-world infections. What we can confirm is that the infrastructure we documented—including purpose-built phishing domains impersonating Zoom and Google Meet, fake Microsoft Store pages, and a Teramind agent configured in stealth mode—is consistent with a campaign designed to deploy monitoring software onto targets’ machines without their knowledge or consent.
Videos and screenshots
Fake Zoom update clickthrough.
*** This is a Security Bloggers Network syndicated blog from Malwarebytes authored by Malwarebytes. Read the original post at: https://www.malwarebytes.com/blog/threat-intel/2026/02/fake-zoom-and-google-meet-scams-install-teramind-a-technical-deep-dive
About Author
