BlueNoroff ClickFix Kit Threat Investigation Report

The threat actor did not strip `.map` files from their webserver. These `.map` files map the minified JavaScript back to the original source code with function names, comments – everything. There were two variants observed. One for Zoom, and one for Teams. And based on a `googie.us-gmeet.com`string found in the Zoom chat handler, a Google meet variant likely also exists.

The source code includes:

• All JavaScript source code for the Zoom page built to be a Single-Page Application (SPA)
• TS/TSX files, Teams page (essentially a rewrite of the Zoom page)
• `dropper.vb_s` (named as we obtained it), 497-line VBScript implant classified as Trojan.NukeSped, a known Lazarus Group malware family.
• 11 initial C2/lure domains.

These 11 initial domains were the seed. Pivoting across passive DNS, VirusTotal, urlscan.io and reverse DNS data expanded the investigation beyond the original infrastructure set, uncovering additional campaign infrastructure discussed in the Infrastructure Analysis section. Everything high confidence and medium confidence is still active as of July 22^nd, 2026.

The lure link initially comes from an account the target already trusts and has met in real life. In two observed attempts, hijacked Telegram accounts of real industry contacts were used to message high-ranking employees of major companies.

Figure 1 – A founder announcing their Telegram account as compromised.

Figure 2 – A victim (right, purple messages) messaging a compromised Telegram account (left)

Imagine if a prominent leader in your industry who you recognise, admire and trust reached out to you on LinkedIn. After checking that a profile is legit with thousands of followers and common connection, it is reasonable to accept a request to connect, message or join a call to discuss a common interest.

Figure 3 – A victim (right, purple messages), unknowingly messaging a DPRK compromised Telegram account (left)

Figure 4 – The user who DPRK compromised, announcing their Telegram account has been compromised

None of the standard user sender verification advice works here. The sender is real and there is no real way to verify who you are talking to without some previously-agreed-upon code word or PGP-like authentication, which is uncommon.

As illustrated below, in the case of Victim A’s compromise, Victim B met the real Victim A at the “FT Live Dinner”, which ultimately strengthens the trust when unknowingly messaging the Victim A’s compromised Telegram account. The pre-existing relationship is the angle here; the operators just need to sit on the right accounts and wait for the opportunity.

Figure 5 – The self-propagating system that continues to bring fresh victims in

Every victim who runs the payload with Telegram Web open or Telegram Desktop installed is a candidate for their Telegram session to be stolen and reused against their own contacts. 2 of the 3 cases JUMPSEC analysed were used to further message other contacts and we observed the same cyclical self-propagating pipeline that Kaspersky documents as “GhostCall”, attributed to the BlueNoroff group, suggesting that this propagation model remains a preferred operational technique rather than a one-off campaign characteristic: compromise A >> use A to lure B >> compromise B >> use B to lure C >> repeat.

If someone seemingly well known in the crypto space reaches out with an investment opportunity, collaboration request or interview, it’s worth taking a moment to verify who you’re actually talking to. BlueNoroff have repeatedly demonstrated that a trusted Telegram account can be far more valuable than a freshly registered phishing domain.

We built a fully working demo of the full kit based on the exposed source code, what follows is what a real victim would see, phase by phase:

Phase 1: The lure

Victim clicks the link, which routes to something like:

This looks like a Zoom invite, but the domain is just `06webin.us`, with `us.zoom.` as the subdomain.When the victim clicks the link, they are presented with the following page:

Figure 6 – The initial fake Zoom meeting page

Clicking on “Continue” after inputting their username, the victim is asked for permission for the page to access the webcam as any normal meeting would go, once they allow this, the webcam stream is silently piped to the operators panel via mediasoup WebRTC.

Figure 7 – (OBS Virtual Cam for demo purposes)

After clicking “Join Meeting” the victim is shown another page where they are seemingly in a Zoom call by themselves, “waiting for other participants”:

Figure 8 – Victim screen after clicking “Join Meeting”

Once the victim has joined, the Operator can then continue to use their panel in order to control the meeting, send fake “your mic isn’t working” messages, and trigger the “Zoom SDK Update”, ultimately resulting in the ClickFix payload.

Figure 9 – Zoom SDK notification that triggers the ClickFix prompt

Alongside this control, the kit runs a full wallet fingerprinting sweep on the browser via EIP-6963 discovery, legacy `window.ethereum` dlag scanning, plus non-EVM globals like Solana coin. The result is silently exfiltrated to the operators panel which can be seen in the below screenshot (MetaMask detected as I installed MetaMask on my browser to test it), the victim never sees this exfiltration occurring.

Figure 10 – The operators panel, with multiple features

At this point, when the “admin” joins the fake meeting, the video the victim sees isn’t the operators live webcam. It’s a pre-edited video the operator plays into the WebRTC transport as if it were live. The headshots used are AI generated by ChatGPT and composited over real body motions captured from prior meetings. So, each successful attack feeds source material into the composites used against the next target. This combined with the Telegram account takeover method, means that the fake meeting shows a plausibly familiar looking face, moving with the body language of someone who was actually captured on camera.

Below you can see an illustrated example of what the victim would see on their screen:

Figure 11 – Operator joins the fake call, and the simulated deepfake video plays

After the operator has joined, it’s all meant to be social engineering, on very specific timeframes:

• T+0s – Operator joins the meeting, deepfake video is playing, but there is no audio
• T+2.5s – Operator pushes first message – “Hi [Victim name] can you hear me? Camera and audio look good on my end”
• T+6.5s – Operator pushes second message – “Weird, my mic keeps cutting. One sec – I think our Zoom SDK is out of date, let me push a quick update. You’ll see a prompt on your side too.”
• T+10.5s – A fake “SDK deprecated” message with a progress bar appears, auto advances for 3 seconds
• T+13.5s – ClickFix box appears

The displayed commands look benign. However, when the victim clicks Copy, or even highlights the text and CTRL+C’s, their clipboard is of course replaced with the operators ClickFix payload:

Figure 12 – PowerShell payload copied to clipboard

We managed to capture two distinct variants, a Zoom lure and a Teams lure, and comparing them shows quite the evolution:

Zoom variant – 26 JavaScript files

• Plain JavaScript
• Single `App.js` with inline meeting logic
• `SdkUpdateModal.js` for ClickFix
• `ChatModal.js` for handling C2 commands
• Simpler wallet probe (fewer chains)
• URL display swap for google.com/teams/zoom domains in chat

Teams variant – 44 TypeScript/TSX files

• Full TypeScript rewrite
• Service layer pattern
• MediaPipe background blur/virtual background support
• Full emoji reaction system
• Full device settings panels
• Mobile/tablet blocking
• Post-meeting redirect page
• Advanced wallet probe (EIP-6963 discovery + expanded non-EVM)
• LauncherPage mimicking the Teams “Continue on this browser” flow

The Teams variant is written well. It includes a UX polish, emoji reactions, background effects and even device settings. Both variants share the same `executeLinkFromDownURL` crypto module, confirming they are both from the same threat group.

We recovered the full Windows attack chain across two different deployed variants, confirmed via VT sandbox data and source code analysis.

Stage 0 – PowerShell loader

The base64 decoded payload from the copied ClickFix payload is a small PowerShell script less than 600 bytes, we obtained two variants:

Both do the same core things:

1. Download a VBScript dropper from the C2 and save to Temp
2. Execute the VBScript twice via wscript.exe with different numeric arguments (1 and 2)
3. Disable Windows Defender via PowerShell exclusion addition
4. Force-restart Defender so the exclusion applies immediately

The dual execution is intentional, both numeric arguments feed into different functions, which generate different UUIDs and handle different beacon tasks. VT sandbox data confirms one instance beacons to `?topic=s` (system info) and another to `?topic=v957` (main C2 loop)

There is no obfuscation, the stage 0 payload relies on the ClickFix social engineering plus the Defender exclusion running before the stage 1 VBS lands on disk.

Stage 1 – VBScript C2 implant

Two variants recovered, this is the main implant:

The VT classification for the primary dropper as Trojan.NukeSped is significant as NukeSped is a known Lazarus group backdoor family. Further raising our attribution confidence to DPRK actors.

The difference between the two variants is primarily the Telegram Web detection functionality, which is absent in Variant B. This function checks `IndexedDB` for:

• `telegram.org_0.indexeddb.leveldb`
• `telegram.org_0.indexeddb.leveldb`
• `telegram.org_0.indexeddb.leveldb`

It checks for these across Chrome, Edge, Brave and Firefox profile directories. If successfully found, it appends “telegram” to the beacon data. There are two reasons why this most likely exists. First, a lot of Crypto/DeFi communities are on Telegram, so it is no surprise that the operator would want to be aware of a victim with an active Telegram account.

Secondly, and more interestingly, the delivery model we have documented above uses hijacked Telegram accounts of trusted contacts to message victims directly. Every marked victim with an active Telegram account is a candidate for their session cookie to be stolen and reused as a new delivery account.

Apart from that, the beacon architecture itself is identical in both:

The browser extension enumeration walks extension directories for Chrome, Chrome Beta, Chrome Dev, Chromium, Edge, Brave, Opera, Opera GX, Vivaldi, and Firefox. It reports raw extension IDs, which the C2 can match against known Cryptocurrency Wallet extension IDs like MetaMask to identify potentially high-value targets.

C2 Commands:

Stage 2 – Post exploitation payloads

The in-memory and disk-drop payloads are delivered dynamically via C2 tasking. These are where the actual credential theft, wallet theft, and keylogging live. One VT sandbox capture shows a response from `/3?payload=` starting with `MZ` (Windows PE header), confirming Windows executables are served to victims. We have unfortunately not yet recovered these payloads,

Two shell script variants were recovered, both completely undetected by VirusTotal.

Stage 0 – shell script

Figure 13 – macOS kill chain

The self-deletion happens first, by the time anything downloads, the original script is gone. The fake Teams installer app keeps the victim occupied via osascript while the real payload executes in the background.

The dual execution pattern matches the Windows kill chain, which also executes twice with arguments `1` and `2`, the macOS payload gets the same type of thing.

Regarding the “fake Teams installer”, there are multiple other lures that the operator can choose depending on the scenario, for example:

The “google” type exists, but it is not implemented in this build. The source code also references `googie.us-gmeet.com` in URL display transforms.

We were able to recover these macOS payloads through OSINT investigation, and documented our findings, the first binary we found was the fake “Zoom SDK” installer, we found this based off the shell scripts we analysed and found a “ZoomSDK” string inside of. We then searched VirusTotal for `name:ZoomSDK.bin` and found `b149e207a3aad68605785710c58e8439aef61f48776c136d5a0ec6682d7dd2c0`, a 2.08MB Mach-O ARM x64 executable named “winapp.bin” (VT classification is “ZoomSDK.bin”)

Figure 14 – ZoomSDK.bin/winapp.bin on VirusTotal

Pivoting on this report, we found four variants:

Figure 15 – The four variants discovered

It should be noted that the report that isn’t squared in red is the self-deleting dropper script, the four reports that are squared in red are the interesting binaries we analysed.

The size doubles between May and June, this is when the stealer code got added alongside the fake installer code. The May 29^th variant is the most interesting, as it includes the full stealer and fake installer, with no obfuscation.

Stage 1 – winapp.bin (the dropper)

The dropper is a ARM64 Mach-O, 2.18 MB. Pure C++, imports only `libc++` and `libSystem`. 214 functions, 70 strings. Uses `/usr/bin/curl` for everything. It takes two arguments when it is executed, a server URL and an app type, there are five app types: zoom, teams, google, system, and none. The “google” type prints “not yet implemented” – planned but not shipped yet.

The Stage 2 stealer payload is downloaded and executed in the background while the fake Teams/Zoom installer (selected from the server URL and app type arguments) keeps the user busy as mentioned previously while the malware installs.

Figure 15 – The four variants discovered