Microsoft Teams Impersonation: How Matanbuchus 3.0 Is Delivered via Collaboration Tools — and How CDR Defeats It

Collaboration platforms like Microsoft Teams are trusted by organizations daily, enabling remote support, chat, calls, and file sharing. But that trust can be weaponized. In a recent campaign, threat actors impersonated IT helpdesk personnel via Teams calls to manipulate victims into executing commands that deployed Matanbuchus 3.0 — a sophisticated loader used to deliver ransomware. This blog unpacks how the attack works, the innovations in Matanbuchus 3.0, and how native CDR (Content Disarm & Reconstruction) is among the strongest defenses against it.

Threat Overview: Matanbuchus 3.0 via Teams Impersonation

Evolution of Matanbuchus

• Matanbuchus has been floating in underground malware-as-a-service (MaaS) forums since ~2021. 

• The latest version, Matanbuchus 3.0, introduces advanced capabilities: in-memory execution, improved obfuscation, PowerShell & CMD reverse shells, stealthy COM-based task scheduling, and enhanced C2 (command & control) communication. 

• It supports multiple payload delivery modes (DLL, EXE, MSI, shellcode) and includes sandbox-resistance techniques (e.g., checking UI language, dynamic function resolution) to evade detection. 

Attack Vector: Teams Impersonation & Social Engineering

• In one documented campaign (mid-2025), an attacker initiated an external Microsoft Teams call impersonating IT helpdesk or support staff. 

• The attacker convinced the victim to launch Quick Assist (Windows remote support tool) and permitted a remote session. 

• During the session, the attacker guided the user to execute a PowerShell script, which fetched a ZIP archive. That archive contained a renamed Notepad++ updater (GenericUpdater.exe), a malicious XML config file, and a DLL (libcurl.dll) which is the Matanbuchus loader. 

• The benign updater is used as a loader sideload, triggering the malicious DLL via regsvr32 and COM-based mechanisms. Persistence is achieved via scheduled tasks, often every 5 minutes, and the malware probes for security programs, system details, and control paths before pulling further payloads. 

This scheme is powerful because it combines trusted tool usage (Teams, Quick Assist), social engineering, and living-off-the-land techniques to minimize suspicious artifacts and evade detection.

Why Traditional Defenses May Fail

Because the attack does not rely on a known exploit or a simple malicious file, but rather trusted tooling + social engineering, relying solely on detection-based measures is risky.

How Native CDR Can Mitigate This Threat

While CDR is traditionally thought of as a defense against malicious documents (PDFs, Office) or attachments, the principles can be extended to defending against document-driven or file-based payloads even in collaboration contexts. Here’s how GateScanner’s CDR (or an equivalent native CDR engine) can play a role in reducing the risk of Matanbuchus-style attacks:

1. Sanitization of transferred files

   • If during the attacker’s session, files (ZIPs, EXEs, DLLs, config files) are transferred over Teams or shared through file exchange, CDR applied at the gateway or file-transfer layer can sanitize or block suspicious content.

   • Any embedded scripts, macros, or executables inside archives can be unpacked, inspected, and either reconstructed or blocked.

   • GateScanner CDR could rebuild safe responsive files rather than delivering the raw malicious bundle.

2. Neutralizing embedded scripts / macros

   • For documents, CDR would remove embedded macros, scripts, or code. Although the Teams attack might not use a directly scripted document, if any documents are used as bait (e.g. a DOCX with instructions or script), CDR would nullify active content.

3. Flattening & sanitizing file metadata and overlay content

   • If attachments or files contain hidden or malicious metadata, layered content, or resource references, CDR can flatten them and remove extraneous, dangerous elements.

4. Enforced policy-based gating

   • GateScanner’s CDR engine can enforce policies that only allow certain file types (e.g. only benign formats), or demand additional scanning or rejects for unknown executables.

   • Files containing dynamic or suspicious elements can be quarantined or replaced with sanitized stubs, forcing manual review.

5. Logging, audit trail, and alerts

   • All sanitized or blocked files generate logs and alerts—SOC teams can track which sessions or file transfers attempted to carry suspicious content.

   • This helps detect possible social-engineering-assisted payload delivery attempts even if initial CDR blocks them.

While CDR cannot by itself block the live social engineering (i.e. convincing a user to run a PS command), it strengthens the defense around file payload delivery, making the attacker’s job harder and giving the organization additional layers of protection.

In production, the ideal architecture is layered:

• Use CDR on file transfers (Teams, SharePoint, email).

• Enforce least privilege / application control on endpoints.

• Monitor and alert on unusual remote assistance or script execution behavior.

• Maintain strict logging and forensic storage of blocked/sanitized files.

Recommendations & Best Practices

1. Limit or monitor usage of remote assistance tools like Quick Assist, especially for external sessions or unverified callers.

2. Strictly audit file transfers within collaboration platforms, scanning all exchanged files with advanced content sanitization (CDR + threat intelligence).

3. Employ application control / whitelisting for script execution utilities (PowerShell, regsvr32, COM invocations).

4. Train employees to verify identity of support staff, use secure channels, and be wary of unsolicited remote assistance requests.

5. Enforce telemetry & alerting on sanitized files and blocked payloads to feed SOC / IR processes.