Zero Day Exploit

Introduction

In late December 2025, a threat group tracked as UNC6692 executed a sophisticated multistage intrusion campaign. By combining persistent social engineering, a custom modular malware suite, and clever pivoting within victim environments, they achieved deep network penetration. This guide breaks down their attack methodology into actionable steps, helping security analysts understand and defend against similar tactics. The campaign relied heavily on impersonating IT helpdesk staff, exploiting victim trust in enterprise software like Microsoft Teams, and deploying a custom malicious browser extension (SNOWBELT).

What You Need

To fully grasp this guide, you should have:

• Basic understanding of social engineering techniques
• Familiarity with Microsoft Teams and its external chat capabilities
• Knowledge of AutoHotkey scripting and its execution model
• Awareness of Chromium browser extensions and sideloading
• Access to system logs (Windows Event Logs, MS Teams logs, AWS S3 access logs)
• Ability to analyze malicious artifacts like AutoHotkey scripts and browser extension files

Step-by-Step Attack Breakdown

Step 1: Initiate a Distraction Campaign

UNC6692 began by overwhelming the target with a large volume of emails. This email flood created a sense of urgency and distraction, making the victim more receptive to subsequent helpdesk contact. The attacker likely used compromised email accounts or botnets to send hundreds of messages in a short period.

• Goal: Disrupt normal workflow and lower victim vigilance.
• Indicator: Sudden spike in spam or phishing emails from external domains.

Step 2: Impersonate Helpdesk via Microsoft Teams

After the email flood, the attacker sent a phishing message through Microsoft Teams. They posed as IT helpdesk personnel, offering assistance to resolve the email volume issue. The message came from an account outside the victim’s organization, exploiting the default Teams setting that allows external chats.

• Social Engineering Tactic: Impersonation of a trusted internal role (helpdesk) to gain credibility.
• Technical Detail: The attacker initiated a chat from a non-tenant account, bypassing internal controls.

Step 3: Deliver Malicious Link to Install a Fake Patch

In the Teams message, the victim was prompted to click a link to install a “local patch” that would prevent further email spamming. The link pointed to a threat actor-controlled AWS S3 bucket:

https://service-page-25144-30466-outlook.s3.us-west-2.amazonaws.com/update.html?email=<victim_email>

The HTML page appeared as a Microsoft Spam Filter Update interface. Clicking it triggered the download of two files with the same name: a renamed AutoHotKey binary and an AutoHotkey script. The binary and script were stored in the same folder.

• Key Technique: AutoHotkey automatically executes a script file if the binary and script share the same name in the same directory.
• Evasion: The binary was renamed to blend in, and the script performed initial reconnaissance.

Step 4: Execute Initial Reconnaissance and Deploy SNOWBELT Extension

Immediately after the download, the AutoHotkey script ran. It executed reconnaissance commands and installed a malicious Chromium browser extension named SNOWBELT. This extension was not distributed through the Chrome Web Store; instead, it was sideloaded by the script. The exact AutoHotkey script was not recovered by Mandiant, but its effects were observed.

• Reconnaissance: The script likely gathered system information, network details, and browser data.
• Malicious Extension: SNOWBELT allowed attackers to monitor and manipulate browser traffic, steal credentials, and maintain persistent access.

Step 5: Establish Persistence via Startup and Scheduled Task

UNC6692 ensured SNOWBELT survived reboots through two persistence mechanisms:

1. Startup Folder: A shortcut to an AutoHotkey script was added to the Windows Startup folder. This script checked if SNOWBELT was running.
2. Scheduled Task: The AutoHotkey script also verified the presence of a scheduled task. The code (recovered in part) shows:

   if !CheckHeadlessEdge(){
      try{
         taskService:=ComObject("Schedule.Service")
         taskService.Connect()
         rootFolder:=taskService.GetFolder("\")
         if FindAndRunTask(rootFolder){
            Sleep 10000
            if CheckHeadlessEdge(){
            ExitApp
            }
         }
      }
      Run 'cmd /c start "" "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --user-data-dir="%LOCALAPPDATA%\Microsoft\Edge\System Data" --headless=new --load-extension="%LOCALAPPDATA%\Microsoft\Edge\System Data\Extension"
   }

   This snippet runs a headless Edge browser process that loads the SNOWBELT extension, ensuring it stays active even if the main browser is closed.

• Persistence Goal: Continuous operation of the malware for data exfiltration and lateral movement.
• Indicator: Unusual Edge processes running in headless mode without a visible browser window.

Tips for Defenders

• Restrict External Teams Chat: Configure Microsoft Teams to block chat invitations from external organizations unless explicitly allowed.
• Monitor for Helpdesk Impersonation: Educate users to verify helpdesk contacts through secondary channels (e.g., phone call or email).
• Deploy AppLocker or Software Restriction Policies: Block execution of unsigned scripts (AutoHotkey) from untrusted locations like Downloads or TEMP folders.
• Review Browser Extension Permissions: Audit installed extensions, especially those not from official stores. Look for extensions that modify web traffic or access all data.
• Alert on Headless Browser Processes: Create detection rules for msedge.exe running with --headless and --load-extension flags initiated from unusual parent processes (e.g., cmd.exe or AutoHotkey).
• Investigate S3 Bucket Access: Monitor cloud storage access logs for suspicious URLs that mimic legitimate service endpoints (e.g., contains "outlook" or "microsoft").
• Implement Multi-Factor Authentication (MFA): Even if credentials are stolen via the browser extension, MFA can block unauthorized access.

By understanding these steps, security teams can better detect and prevent similar social engineering-driven attacks. The key is to combine user awareness with technical controls that limit the impact of initial compromise.