Crpx0 Clickfix Ransomware Analysis

Pick the review lane closest to your task. The report is intentionally modular, so each route points to the sections most relevant for that reader.

CRPx0 is a ClickFix-delivered ransomware-as-a-service operation. The lures impersonate Windows and macOS update prompts, or Google reCAPTCHA checks. They copy an OS-specific command to the clipboard before the victim sees the instructions.

The attack then relies on the victim to run that command. On Windows, it starts a multi-stage DLL chain. On macOS, it downloads the Python payload directly.

The final payload is a cross-platform Python ransomware that exfiltrates data before encryption, encrypts files with AES-128-CBC via Fernet, wraps the per-victim key with an embedded RSA-4096 public key, attempts lateral movement, and drops ransom notes demanding Bitcoin or Monero payment within 48 hours. The most important defensive point is timing: by the time .crpx0 extensions or ransom notes appear, the data-theft phase has already completed.

For defenders, the highest-value detections sit before or during execution rather than after encryption: Run dialog abuse, RunMRU entries containing PowerShell or curl, lure telemetry using X-Captcha-Track: 1 , authenticated C2 traffic using Authorization: Bearer crpx0_c2_2026 , and the 512 KB chunked exfiltration pattern to relay.php .

No samples were executed. All behavioural description is derived from source and disassembly, so runtime behaviour on a live host may differ in detail. Where this report states what the malware "does", read it as "what the code instructs it to do".

Companion research - read in parallel. Ransom-ISAC's Rakesh Krishnan has published an independent investigation into the same operation: CRPx0 - Scammer Turned Ransomware Operator , The Raven File, 03 August 2026. This report works inward from the artefacts - lure pages, DLL chain, Python payload, builder output. His works outward from the operator - who runs CRPx0, what they were doing before June 2026, and where the infrastructure actually sits. Neither half is a complete picture of the actor on its own. What each account adds, and the five points where the two disagree, are set out in Companion Research - Reconciling the Two Accounts at the end of the report.

CRPx0 is an active ransomware-as-a-service operation delivering multi-stage payloads via ClickFix social engineering HTML pages. Two lure themes have been identified - a fake Windows Update and a fake Google reCAPTCHA - both serving as affiliate-customised entry points.

Those two lures are only half the builder's output. CRPx0 COMMAND offers four payload formats: the two HTML lures plus a standalone DLL and a standalone EXE, both of which discard the social engineering step entirely and are analysed under Alternate Delivery Formats below. All four converge on the same Stage 4 Python ransomware.

The HTML pages use document.write(atob(...)) to decode a social engineering page that hijacks the victim's clipboard with an OS-specific command:

Both paths lead to the same payload: a 1,769-line Python script that exfiltrates high-value files before encrypting with AES-128-CBC (Fernet), moves laterally via WMI/schtasks, and drops ransom notes with a 48-hour deadline.

Five actions in priority order. The first three cost nothing and blunt the entire ClickFix class of attack, not just CRPx0.

Because every build expires on its own hardcoded timer and is then replaced, prioritise behavioural detection over hash blocking. The scheduled-task names, mutex pattern, RunMRU trace, fodhelper registry write and relay POST signature all survive a rebuild. The hashes do not.

Note that actions 1 and 2 blunt only the ClickFix formats. The builder's standalone DLL and EXE reach the same payload with no Run dialog, no clipboard hijack and no RunMRU trace, so on that path actions 3 to 5 carry the weight, backed by the PE-level detections in Alternate Delivery Formats .

CRPx0 first appeared on spear[.]cx on 07 June 2026 advertising their RaaS affiliate program:

The operators were initially reported for OnlyFans lures:

Early CRPx0 promotion associated with OnlyFans-themed lures.

Early advertising also offered free affiliate access for vetted operators:

However this quickly shifted to a paid program, advertising a one-time $333 enrollment fee for lifetime affiliate access . Enrolled affiliates are promised a 70% commission on every successfully paid ransom , with the remaining 30% retained by the RaaS operator.

The program applies a flat 70:30 revenue split in favour of affiliates , with no commission tiers or minimum payout thresholds - an unusually simple model compared with many RaaS schemes.

CRPx0 affiliate revenue- terms.

The operational rules also prohibit targeting Commonwealth of Independent States (CIS) member states , reflecting a restriction commonly imposed by RaaS programs. Direct communications further indicated that Monero (XMR) is the preferred payment method , rather than Bitcoin (BTC).

CRPx0 has placed 47 victim organisation names on its Dedicated Leak Site (DLS), counted directly from the site:

CRPx0 Dedicated Leak Site victim listing used for the direct victimology count.

All 47 postings categorised. Victim names are withheld - these are claimed victims of a live extortion operation, and the categories carry the analytic value.

Assessment. The US set is small practices and firms - what an untargeted ClickFix lure catches. Eleven Turkish entities including four banks and insurers is not. Assessed at moderate confidence that a separate affiliate is deliberately targeting Turkish financial services.

All of it is leak-site claim rather than confirmed breach - see Sourcing and Confidence above - and 47 is a floor rather than a total, since victims who pay before the deadline are never posted.

The operators also appear to impose no meaningful ethical limits on victim selection.

CRPx0 leak-site posting used to assess victim-selection ethics and harm potential.

The group has extorted a nonprofit organisation that supports survivors of human trafficking - people who are already at heightened risk. In its leak-site posting, CRPx0 claims to have infiltrated the organisation and threatened to publish highly sensitive information if its demands are not met.

CRPx0 claims to have exfiltrated personal, financial, operational, and governance data. That data could enable re-identification, fraud, harassment, exploitation, or physical harm.

CRPx0 v3.0 is a complete, professional offensive control center for managing compromised remote machines from a single web dashboard. An operator can watch stolen cryptocurrency wallet addresses flow in, harvest valuable files and credentials, run remote commands, and most importantly in this version, set up automated attack reactions that fire on their own when something valuable happens on a target. Everything is built to be operated by a human with no technical background: point-and-click panels, plain-language rules, and clear status indicators. The underlying attack engine is hidden behind a clean, dark-themed interface.

Clipboard Hijacker (Clipper): Watches the target's copy/paste in real time. The moment they copy a cryptocurrency wallet address, the tool swaps it for the address you choose so any payment they make goes to you instead. Works across all major coins, including Bitcoin, Ethereum, Solana, and Monero.

Seed Phrase Catcher: If the target copies a wallet recovery phrase (those 12–24 words), the tool recognizes it, records it, and can trigger an automatic offensive reaction. Captured phrases are saved in a dedicated log, allowing you to compromise the entire wallet and drain its funds.

Cross-platform ransomware agent: The program that runs on the target works on Windows, macOS, and Linux, survives restarts (persistence), and stays hidden while communicating through a concealed relay.

Loot Vault: A secure, organized storage area inside your panel where everything collected from a target is saved and sorted per machine.

File Harvester: With one action, the tool sweeps the target's documents, crypto wallets, notes, and SSH keys, classifies what it finds, and uploads everything interesting to the Loot Vault.

Screenshot Capture: Takes a picture of the target's screen and sends it to you.

File Reader: Opens and pulls the content of any single file from the target's machine.

Process Viewer: Shows the list of programs currently running on the target.

Remote Command: Type a single command and run it on the target as if you were sitting at their keyboard.

Spreader (Propagate): Attempts to move from one machine to another on the same network (Windows), extending your reach further into an environment.

A Playbook is a simple offensive rule: "When X happens on a target, automatically do Y." You build it without writing anything technical: pick a trigger (e.g. "a seed phrase was copied"), add actions from a dropdown (Harvest files, Screenshot, Run command, Read file, List processes, Propagate), arrange them by dragging, and see a plain-English summary. Safety lock: the dangerous ransomware (encrypt target) capability can never be added to an automatic rule. It can only ever be launched by you, manually, on purpose.

When launched, the Cryptor encrypts the target's files on disk so they can no longer be opened. It is delivered and controlled entirely from the same panel, under a dedicated Encrypt Target action. The operator chooses when to fire it. Encryption can be aimed at a single target or pushed more broadly. Even though it is a major offensive feature, the Cryptor is deliberately kept manual-only. It can never be added to an automatic Playbook rule, protecting the operation from accidental or unintended deployment.

Built-in limits that protect the operation from mistakes: blocks obviously destructive commands, caps how many tasks can pile up on a single target, asks for confirmation on risky actions.

Builder: A wizard that produces the target program with your settings baked in. Client Management: See every machine you control: online/offline status, country, username, whether it has admin rights, and last-seen time. Crypto Settings: Choose which cryptocurrencies to target and the replacement address for each. Campaigns: Run the same offensive action across many targets at once. Balance Monitor: Watches the balances of stolen wallets. Seed Log: A searchable record of every seed phrase captured. Dashboard & Analytics: At-a-glance statistics: total machines, loot collected, and activity over time.

If you are interested to buy a white-label license us:

Telegram: @DataBreachPlus Session: 050546f6719172e04151c31acb37a242fa3eeff5766aa57331d26cc06e83e9e25b Tox: 17EB54B8455144E088C7E77F88A97221C319F0CFE4FE306853EEB113EE8DB5607BB6EE481C7C

On 23 August 2026, CRPx0 published a v3.0 update note on its clearnet Dedicated Leak Site at , advertising the operation as a more complete offensive control panel rather than a simple ransomware builder. The note presents v3.0 as a point-and-click dashboard for managing compromised machines, harvesting files and credentials, monitoring stolen cryptocurrency artefacts, running remote commands, and launching ransomware manually.

CRPx0 v3.0 update note published on the clearnet leak site.

The headline change is an Orchestration / Playbooks layer: a visual rule builder that lets operators trigger actions automatically when valuable events occur, such as a copied seed phrase leading to file harvesting and a screenshot. The same note advertises a File Harvester , clipboard hijacker, seed-phrase catcher, screenshot capture, file reader, process viewer, remote command execution, Windows spreader, campaign management, crypto-address replacement settings, balance monitoring, and a “Loot Vault” for organising stolen material. The ransomware component, branded the Cryptor , is described as manual-only and blocked from automatic playbooks, suggesting the operators are trying to reduce accidental encryption while still enabling automated theft and reconnaissance.

CRPx0 v3.0 advertised playbook and automation capabilities.

The commercial framing is also important. CRPx0 describes v3.0 as suitable for operators with no technical background and offers a white-label licence . The details match the broader CRPx0 infrastructure cluster: Telegram @DataBreachPlus , the same Session ID, and the same Tox ID already seen in the ransom note and companion research.

This supports the assessment that CRPx0 is being marketed as a crimeware platform, not only used by a single closed operator.

This malware analysis does not include reverse engineering of the v3.0 features advertised in the update note. That omission does not materially change the findings below: the added dashboard, playbook, harvesting, and remote-operator functions are not required for CRPx0's core ransomware operation as analysed here.

The core business model still depends on affiliate access, payload delivery, data theft, encryption, negotiation infrastructure, and leak-site pressure - all of which are covered by the sample set analysed here.

CRPx0 v3.0 commercial framing and white-label details.

These are UTF-8 characters mis-decoded as Windows-1252, corresponding to punctuation such as an em dash, arrow, and en dash. The artefacts themselves are encoding damage rather than meaningful symbols, but their presence is useful provenance: they suggest the note was copied, edited, or served through a mismatched character-encoding workflow.

Separately, the availability of Cyrillic/Russian keyboard input in the surrounding operator environment remains consistent with the Russian-language tradecraft indicators already observed elsewhere in the investigation, though the mojibake alone does not prove keyboard layout.

The cryptocurrency wallets in this section were analysed using Crystal Intelligence .

The operator advertises both BTC and XMR payment options. Direct correspondence indicated a preference for XMR , likely because of its stronger privacy properties.

Bitcoin wallet activity associated with the CRPx0 financial-tracing cluster.

The Bitcoin address 1Fv8YVf52MGqjfgnyjMoBo7ojoGnZmKCrV is attributed to Bybit, a major cryptocurrency exchange. It has received only around USD 770 across 11 transactions , which is unusually low for a ransomware payment address. Observed payments range from approximately USD 45 to USD 350 , with most falling between USD 70 and USD 120 .

The address is also aged, first becoming active in October 2023 , but shows limited overall activity. This may indicate use as a drop account , potentially opened with stolen identity documents or controlled by a money mule to frustrate attribution, seizure, or compliance action.

One notable anomaly is a direct payment from Coinbase in 2026. Direct exchange-to-exchange flows into suspected threat-actor infrastructure are unusual, as more mature threat actors typically avoid such traceable paths. This may point to poor operational security, mule infrastructure, or activity unrelated to ransomware proceeds.

TRON/USDT wallet activity attributed to Bybit infrastructure.

The TRON activity is more substantial, although there are multiple wallets that require deeper review. At a high level, the address TJridpGzorLA67Qmji8viGj953pnwbqh3F is also attributed to Bybit; however, blockchain attribution alone cannot confirm whether it is controlled by the same threat actor without exchange-side confirmation.

The address has received approximately 56,605 USDT across 258 transactions , with observed transfers ranging from 1 USDT to 3,500 USDT . This is materially higher-volume than the Bitcoin address and does not show the same dormant pattern. It first became active in July 2023 , compared with October 2023 for the Bitcoin address.

The same tradecraft concern remains: direct use of an exchange-attributed address is unusual for a mature ransomware operator. This may indicate poor operational security, mule infrastructure, or mixed activity unrelated to CRPx0 ransom payments.

CRPx0 clearnet relay and Tor-backed infrastructure overview.

The CRPx0 website advertises an end-to-end ransomware infrastructure and payload service with the following capabilities:

The clearnet relay at 207.180.29.236:8080 is a dumb PHP proxy that forwards all traffic through Tor SOCKS5 to the true C2 backend at:

xburs4nr6cbuktokhqwefeh5hsjakz6usll5o7z5uhrfcnolakj4ptad.onion/api.php

Additional infrastructure and points:

CRPx0 COMMAND panel walkthrough recording.

Full C2 panel source was obtained, revealing a mature RaaS platform branded CRPx0 COMMAND (build v3.0.0 , dated 2026-06-07 ).

The builder generates four payload types - two HTML lures and two standalone PE binaries. Both HTML formats are covered under Stage 1 below; the DLL and EXE are analysed under Alternate Delivery Formats .

CRPx0 COMMAND builder output options showing DLL, EXE, and CAPTCHA HTML formats.

CRPx0 COMMAND builder output option for the Update HTML lure.

CRPx0 COMMAND panel showing configurable evasion and payload options.

It includes 17 configurable evasion toggles, including AMSI/ETW patching, ntdll unhooking, XOR packing, and self-signed Microsoft certificate signing. The panel also includes a live Leaflet.js infection map, campaign funnel analytics, affiliate payout tracking, and a support ticket system.

The observed affiliate account (the panel username) maps to a numeric affiliate ID, the same ID sent in C2 beacons and embedded in the reCAPTCHA lure. It had $0 in payouts.

The diagram below summarises the HTML-based killchain. It covers the two ClickFix formats; the standalone DLL and EXE replace Stage 1 entirely and collapse Stages 2 and 3 into a single binary, as described in Alternate Delivery Formats .

CRPx0 ClickFix HTML killchain from lure page through stager, loader, and Python ransomware.

This is the initial attack vector - a weaponised HTML page designed to trick victims into executing malicious commands on their own machines. The outer file is a single line of HTML that uses document.write(atob(...)) to decode a full social engineering page inside the victim's browser. Once decoded, the page detects the victim's operating system via navigator.userAgent , silently copies an OS-specific malicious command to the clipboard before the victim sees any instructions, then displays fake "verification steps" that trick the victim into pasting and running the command.

Outer ClickFix HTML wrapper using document.write and atob to decode the embedded lure page.

The victim-facing sequence and the page's actual behaviour run in parallel and almost nothing. By the time the fake Windows Update screen appears, silentCopy() has already written powershell -w h -enc ... to the clipboard and __dp() has already dropped the embedded PE DLL as WindowsUpdate.log . The 15-second progress bar is pure animation with no network activity behind it, deliberately eased to stall at 95% so it can never complete - which is what pushes the victim toward the Win+R paste the page has been preparing since load. A keydown handler blocking Escape, F5 and F11 keeps them there.

CRPx0 ClickFix lure flow from page load through clipboard hijack, fake update screen, and victim-executed PowerShell.

23 translation keys per language across 8 languages - 184 strings covering the loader text, progress messages, attention panel, and both the Windows and macOS instruction steps, with an RTL layout switch for Arabic. This is well above the norm for a phishing kit and is a productisation signal: the lure is built to be resold to affiliates operating in different regions, not hand-made for a single campaign.

The ClickFix page does not blindly serve PowerShell to every visitor. Before displaying any instructions, detectOS() parses the browser’s user-agent string and branches the entire payload delivery path:

The clipboard hijack ( silentCopy() / silentCopyHelloWorld() ) copies the OS-specific command before the victim sees any instructions. PowerShell never appears on macOS; curl never appears on Windows. The entire UI - instructions, step numbering, verification text - adapts to the detected platform.

Decodes to: download DLL → save as WindowsUpdate.log → rundll32 execution.

Note that the Stage 2 stager exports only its crypto globals ( g_data , g_k1 , g_k2 , g_ko1 , g_ko2 , g_len ) and has no ExecuteStager export, so rundll32 must invoke it by ordinal. ExecuteStager belongs to Stage 3 ( data.dll ). The exact command line sits inside the base64 blob and was not recovered.

Relay diagram - three callers, one PHP file, three roles

Both lure variants talk to , the same endpoint the ransomware uses in Stage 4 - but the traffic is a different shape, carries different authentication, and is handled differently at both ends. Four distinct request types hit that one PHP file across the whole attack chain:

X-Captcha-Track: 1 is the discriminator. The lure pages are the only part of the chain that does not send the Bearer token - they send this header instead. The relay appears to use it to route browser telemetry into the panel's campaign-funnel analytics rather than the infection tracker, which the panel presents as separate views. *(Inference from client-side code plus panel structure; relay.php source was not recovered, only the panel behind it.)*

The page never reads the . reportClick() fires once behind a _reportSent flag and makes no use of the response; _sendStat() ends in .catch(e => {}) , which swallows connection failures silently. Neither function parses, renders, or gates anything on what comes back. What the relay returns to the lure page is therefore undocumented - and, from the operator's point of view, irrelevant. This is fire-and-forget telemetry, not a command channel. No samples were executed, so no response body was observed.

That has a direct defensive consequence: blocking the relay does not stop the Windows lure. The stager DLL is already embedded in the page as the __pd base64 blob and is written to disk by __dp() as a Blob download the moment the victim clicks. The clipboard hijack, the fake UI, the kiosk lock and the DLL drop all function with the C2 unreachable. Blocking 207.180.29.236 breaks only the macOS path - which genuinely fetches sys_core_*.bin from the relay - and the operator's visibility. Whether the pasted PowerShell then succeeds depends on whether its download target resolves to the same path as the Blob download; static analysis alone does not settle that, and it is worth confirming in a controlled detonation.

Detection value: this is the earliest signal in the entire chain. An X-Captcha-Track: 1 header in proxy logs means a device in your estate rendered a CRPx0 lure page - before the victim pressed Win+R, before any DLL executed, before any file was encrypted. Nearly every other indicator in Appendix A is post-execution. This one is pre-compromise, it is unauthenticated so it is visible in plaintext HTTP, and it survives a rebuild because it is baked into both lure templates.

Decoded reCAPTCHA lure page used by the affiliate [REDACTED] ClickFix variant.

14 translation keys per language across 6 languages - a leaner UI than the Windows Update variant, and ko / ja are dropped. The Windows steps instruct victims to press Win+R , paste with Ctrl+V , and press Enter . The macOS steps instruct victims to open Spotlight (Cmd+Space), type Terminal , then paste with Cmd+V and press Return .

The reCAPTCHA variant uses the Fetch API with a JSON body, compared to the Windows Update variant's XMLHttpRequest with form-encoded data:

Key differences from affiliate 1's telemetry: opid is CAPTCHA_WEB (vs WINUPDATE_TRACK ), hostname uses the persistent _vid (vs ephemeral sessionId ), and the .catch(e => {}) silently swallows network errors - the page neither reads nor needs the relay's . See What the Relay Actually Does above for how this browser telemetry differs from the ransomware's authenticated C2 traffic.

Both variants the same core tradecraft: detectOS() branching, clipboard hijacking before instruction display, embedded PE blob via __dp() , and C2 telemetry through the relay. The differences suggest either iterative development by the same author (reCAPTCHA is leaner and uses more modern APIs) or template customisation by different affiliates.

Transition to Stage 2 (Windows path): The clipboard command is powershell -w h -enc . When the victim executes it (Win+R → paste → Enter), the PowerShell one-liner downloads the stager DLL from the C2 relay ( ), saves it as WindowsUpdate.log , and executes it via rundll32 . Simultaneously, the __dp() function in the HTML triggers a Blob-based browser download of the same PE DLL from the base64 blob embedded in the page ( __pd variable).

Windows Stage 1 to Stage 2 transition through Blob download, pasted PowerShell, rundll32 execution, and RunMRU trace creation.

Direct path to Stage 4 (macOS): On macOS, the clipboard command is a curl | bash one-liner that downloads portable Python from GitHub and the ransomware bootstrap script ( sys_core_*.bin ) directly from the relay. This bypasses Stages 2 and 3 entirely - there is no DLL chain on macOS. The Python bootstrap decompresses the ransomware and exec() s it in memory.

Stage 2 stager DLL showing the compact executable wrapper around the encrypted payload blob.

This DLL is an encrypted container. Its only purpose is to decrypt and drop Stage 3. It contains only ~6 KB of executable code in .text - around 13 KB counting every non-payload section - wrapped around a 3.87 MB encrypted blob in its .data section.

Stage 2 stager section layout showing a small code section and large encrypted payload blob.

The CRPx0 builder generates this DLL with unique cryptographic parameters per affiliate build (two 64-byte XOR keys, two key offsets, unique payload length), making each copy forensically distinct even though the decryption algorithm is identical.

Transition to Stage 3: When loaded by rundll32 , the stager reads its own exported crypto globals ( g_k1 , g_k2 , g_ko1 , g_ko2 , g_len ), applies a multi-layer decryption routine - XOR with rotating 64-byte key → ROL (rotate left 1 bit) → bitwise NOT → XOR with second key - to every byte of the .data section, and writes the decrypted output as data.dll to %LOCALAPPDATA%\data.dll . It then loads data.dll via LoadLibrary and transfers execution to its ExecuteStager export, which begins the Python bootstrap process (Stage 3).

Stage 2 to Stage 3 handoff showing encrypted blob decryption, data.dll write, LoadLibrary execution, and ExecuteStager transfer.

Stage 2 affiliate 1 PE section table highlighting the high-entropy .data payload section.

The .data section is 3.87 MB at entropy 7.95 - near-random encrypted payload. The rest of the DLL is only ~13 KB of code.

Stage 2 stager export table showing the six crypto globals used for payload decryption.

All crypto parameters are exported as named globals - the decryption routine reads these at runtime to decrypt data.dll from the .data section. No ExecuteStager export in this DLL; it is called by ordinal from rundll32 .

Every parameter differs between builds - keys, offsets, and payload length are all unique per affiliate, confirming the builder generates fresh crypto material for each build.

The .data section at file offset 0x1C20 (RVA 0x3020 ) contains 3,869,696 bytes of XOR+ROL+NOT encrypted data - the entire Stage 3 DLL. First 256 bytes ( xxd ):

Note the high entropy with no readable strings or null runs - characteristic of encrypted data. Repeating byte patterns visible at 64-byte intervals (e.g. 6a76 at offsets 0x1C58 , 0x1C98 , 0x1CD8 ) correspond to the 64-byte key cycling.

The .data section contains the encrypted Stage 3 payload:

Output: data.dll written to %LOCALAPPDATA%\data.dll

This is the operational loader. It is more complex than Stage 2: 39 KB of C code, compared with Stage 2's 6 KB, plus a 3.8 MB .data section containing XOR-encoded configuration strings and the Python ransomware bootstrap.

Its job is to build a Python runtime environment on the victim's machine and then launch the ransomware. The ExecuteStager export is the entry point called by the stager chain from Stage 2.

The full step-by-step sequence is documented under Execution Flow below.

Stage 3 data.dll overview showing the loader structure and embedded Python bootstrap content.

The import view is deliberately sparse. VariantInit is the only explicit COM-related import , providing the sole static hint that one of the loader's two ZIP-extraction routes is COM automation via Shell.Application . The other route, tar.exe , leaves no import trace at all, so the import table cannot be used to determine which of the two runs first. Meanwhile, GetProcAddress indicates that additional APIs are resolved dynamically at runtime, reducing their visibility in the import table, while VirtualProtect shows that the loader can alter memory-page protections during execution. Together, these APIs demonstrate that the static import table materially understates the loader’s runtime capabilities.

.data at 3.8 MB / entropy 6.00 - lower than the stager (7.95) because it contains XOR-encoded text (Python source + config strings), not random ciphertext. .text is 39 KB vs the stager’s 6 KB, reflecting significantly more C code logic (download, extract, execute).

Stage 3 data.dll export table showing ExecuteStager and Run entry points.

Fake version information in data.dll showing mixed Oracle, Microsoft, and Intel metadata.

Dumping the info gives:

Which can then be deobfuscated; three different vendors in one version resource - a signature of automated metadata spoofing by the builder:

The builder’s “PE Metadata Spoofing” toggle (always on) generates this via a .rc resource file compiled with windres . The mixed-vendor metadata is a strong static detection signal.

wininet.dll , shell32.dll , ole32.dll are loaded dynamically via GetProcAddress after XOR 0x52 string decryption at runtime.

Stage 3 ExecuteStager flow showing runtime string decoding, Python download, extraction, and bootstrap execution.

The ExecuteStager export performs this seven-step sequence:

1. XOR 0x52 string decryption - decodes all config strings (URLs, paths, commands) from the .data section at runtime

2. Python download - resolves InternetOpenA / InternetOpenUrlA / InternetReadFile from wininet.dll via GetProcAddress , downloads python-3.10.11-embed-*.zip to %TEMP%\py.zip

3. ZIP extraction - two routes, tar.exe and COM Shell.Application - the loader carries both. The COM route is confirmed by the VariantInit import and the dynamically resolved ole32 / oleaut32 calls ( CoInitialize → CoCreateInstance(Shell.Application) → NameSpace() → CopyHere() ), and it completes without shelling out to any command. Which route is attempted first was not established from static analysis. The tradecraft point holds either way: neither route uses powershell Expand-Archive or 7z . *Detection consequence: treat a tar.exe child process writing into one of the five staging directories as a signal when it appears, but do not read its absence as evidence the chain did not run - the COM route leaves no child process at all.*

Stage 3 ZIP extraction logic showing tar.exe and COM Shell.Application paths.

4. pip bootstrap - downloads get-pip.py from bootstrap.pypa.io , executes it, then runs pip install cryptography requests pywin32

5. XOR 0xE0 Python bootstrap extraction - the loader reads the encrypted Python bootstrap from offset 0x260 in its .data section, decodes each byte using XOR key 0xE0 , and writes the resulting script to disk. In the disassembly, DAT_686cb260 references this location. The first encrypted byte, 0x89 , becomes 0x69 when XORed with 0xE0 ; 0x69 represents the character i , which is the first character of import sys, os . This confirms both the decryption key and the payload’s starting offset.

XOR 0xE0 bootstrap extraction from data.dll at offset 0x260.

6. Environment flag - sets CRPx0_LOADER=1 before executing the bootstrap

7. Bootstrap execution - the Python bootstrap uses chr() obfuscation to import builtins , base64 , zlib , then base64-decodes and zlib-decompresses a 3.8M blob into sys_service.py and exec(compile()) s it

Stage 3 data.dll execution flow: decode strings, build a Python runtime, unpack the bootstrap, and launch sys_service.py.

Repeated bootstrap extraction evidence showing the decoded Python payload starting at the data section offset.

Anti detection staging techniques; instead of dropping files into an obvious folder, it randomly picks from five legitimate-sounding directory names in %TEMP% :

Anti-detection staging directories used to hide CRPx0 loader activity under legitimate-looking names.

This captures the point at which the embedded Python payload is written to disk. The DLL reads the encrypted payload from offset 0x260 in its own .data section, decrypts it using XOR key 0xE0 , and writes the result through CreateFileA and WriteFile .

The write uses CreateFileA with CREATE_ALWAYS , producing the bootstrap that launches the final sys_service.py ransomware.

Bootstrap payload write routine showing CreateFileA and WriteFile output of the decoded Python bootstrap.

The download function ( FUN_686c1f07 ) cycles through five TLDs - .ws , .ly , .pet , .sh , .moe - shuffled at runtime via Fisher-Yates. If the primary C2 domain is taken down on one TLD, the stager automatically tries the . This is a deliberate anti-takedown mechanism: law enforcement or registrars seizing one domain extension does not neutralise the stager.

A hardcoded Unix timestamp is compiled into the loader; the value is build-generated and is not reproduced here. If time() exceeds it, the JG (*jump if greater*) instruction redirects execution to LAB_686c3ab0 , the function’s exit path. The loader then returns immediately: no payload decryption, file creation, or ransomware execution occurs.

The termination is silent, with no error message or cleanup activity, making it appear as though the DLL was never loaded.

This mechanism also functions as a commercial control for the RaaS operator. Once a build expires, affiliates must obtain a replacement containing a new expiry date, cryptographic material, and file hashes. This prevents older builds from being reused or resold and renders leaked samples inert after the deadline.

Stage 3 kill-switch logic showing expiry comparison and silent loader exit path.

The .data section (3.8MB, entropy 6.00) contains the Python payload encoded with XOR 0xE0 :

The ClickFix HTML lure is only one of the four payload formats the CRPx0 COMMAND builder offers affiliates. Two of the four are the HTML lures covered above - Update HTML and CAPTCHA HTML. The other two are a standalone DLL and a standalone EXE , both pulled from the builder panel and analysed here. Both remove the ClickFix social engineering step entirely: no HTML page, no clipboard hijack, no PowerShell paste. The affiliate delivers a single binary by whatever vector they prefer - phishing attachment, trojanised installer, USB drop, or an existing DLL sideloading opportunity.

Both builds trace to affiliate [REDACTED] , the reCAPTCHA operator. The DLL carries the internal name affiliate_20sys_e56dad8b.dll , and its compile timestamp of 2026-07-31 10:14:07 UTC falls 100 seconds after the affiliate [REDACTED] ClickFix stager at 2026-07-31 10:12:27 UTC. Assessed at high confidence that both came out of a single builder session - one affiliate generating a spread of formats in one sitting, rather than two separate campaigns.

In the ClickFix chain the work is split across two files: embedded_payload.dll (Stage 2 - carries the encrypted blob and the exported crypto globals) and data.dll (Stage 3 - decrypts the blob, downloads Python, bootstraps sys_service.py ). The standalone formats merge both roles into one binary.

Stage 1 changes completely, Stages 2 and 3 collapse into a single all-in-one binary, and Stage 4 is untouched. The encrypted payload blob, the XOR+ROL+NOT decryption routine, the Python download, the XOR 0xE0 bootstrap and the final sys_service.py execution are identical across all four formats.

Standalone DLL delivery chain - the all-in-one PE merges Stages 2 and 3 before launching sys_service.py.

Built for DLL sideloading or process injection . It exports the same six crypto globals as embedded_payload.dll but also carries the loader logic that normally lives in data.dll , so a vulnerable application that loads it triggers the whole chain in-process - decrypt, download Python, bootstrap - with no second PE ever touching disk. That removes the %LOCALAPPDATA%\data.dll artefact the ClickFix path leaves behind.

Standalone EXE delivery chain - direct GUI execution merges Stages 2 and 3 before launching sys_service.py.

Direct execution: double-click it or run it from a command line and the chain fires. The GUI subsystem suppresses any console window, so nothing appears on screen. CreateProcessA and GetStartupInfoA spawn the downloaded Python interpreter; the file-write and memory APIs match the DLL variant. No exports, no resources, no version info, no digital signature.

Neither binary is compiled Python. Both are small C stagers - 6 to 7 KB of code - wrapping a ~3.87 MB encrypted blob. The Python ransomware exists only inside that blob, after decryption.

Three things follow from the import lists, and each one changes what defenders should expect to see.

From Stage 3 onward both formats behave exactly like the ClickFix chain - Python runtime download, sys_service.py execution, C2 beacons, exfiltration, encryption, ransom notes. Every Stage 3 and Stage 4 network, filesystem and behavioural indicator in this report applies unchanged.

What is gone is the whole of Stage 1, and with it the four earliest detections in the report: there is no RunMRU write, no pasted PowerShell, no X-Captcha-Track: 1 header and no document.write(atob(...)) page. On this path, hunt instead on:

Unlike the Windows path (which uses a multi-stage DLL stager chain), the macOS delivery is a direct two-stage process that skips PE binaries entirely. The payload is the same cross-platform Python ransomware used on Windows - only the delivery wrapper differs.

When detectOS() in the ClickFix HTML identifies macOS (via user-agent matching), the page copies a curl | bash one-liner to the victim's clipboard instead of the PowerShell command used for Windows, then walks the victim through Spotlight → Terminal → paste → Return in their own language.

The one-liner (from _macCmd , captcha variant line 578) detects the CPU architecture, pulls a portable Python 3.10.13 build from GitHub so the attack works on hosts with no Python installed, downloads the payload from the relay as /tmp/sys_service.py , runs it in the background, and clears the terminal. The diagram below summarises the path:

Full C2 download URL:

macOS delivery chain using a clipboard-injected curl command, portable Python download, relay payload fetch, and direct sys_service.py execution.

No PE file ever touches disk on this path - Stages 2 and 3 are skipped entirely, so there is no rundll32 , no data.dll , and no WindowsUpdate.log artefact. The only on-disk evidence is /tmp/py.tar.gz (deleted immediately), /tmp/python/ , and /tmp/sys_service.py .

A standalone bash script variant was also recovered ( macos , 990 bytes, SHA256: e3191e13e6ff9a1a85d1dcffc4e7a8bdcc12329f8ecf0ad825f8670b0d12c97a ). This wraps the same logic but adds a fake update message as a decoy ( Applying Critical Security Update macOS 14.5 Supplemental ):

Note the different payload filename ( sys_core_9407d9e0 vs f6037e11 in the captcha variant) - each affiliate build gets unique crypto keys and an operation ID, but the same codebase. This is the RaaS model: different keys per build so victims cannot decryptors.

The file served by the relay (despite the .bin extension) is not a compiled binary - it is an obfuscated Python loader (17 lines, ~3.8 MB). SHA256: 2d3dfec60201dcc8d0b08abefa8d43efe5f62c33110f036560baa6f1bf24ea8a . Two filenames have been observed - sys_core_f6037e11.bin (reCAPTCHA lure, affiliate [REDACTED]) and sys_core_9407d9e0.bin (standalone bash dropper). The hex suffix appears to be a builder-assigned build ID rather than a file hash; only one of the two files was recovered, so the SHA256 above should not be assumed to cover both.

The obfuscation uses chr() character construction to hide import names ( builtins , base64 , zlib ) and a massive base64+zlib compressed blob containing the ransomware source. The decoded logic:

This is the same packing format as bootstrap_script.py on the Windows path. When unpacked, it produces sys_service.py - the full 1,769-line ransomware.

The Windows and macOS delivery paths converge at the Python ransomware. Everything before that point is OS-specific delivery mechanism; everything after is identical cross-platform code :

The ransomware itself handles all OS differences internally: persistence ( schtasks vs LaunchAgent ), backup destruction ( vssadmin vs tmutil ), wallpaper ( SystemParametersInfoW vs osascript ), self-destruct (VBS vs shred ).

This is the terminal payload - a 1,769-line Python script that performs the full ransomware attack across Windows, macOS, and Linux. There is no Stage 5; this script handles everything from initial environment checks to file encryption to self-destruction.

All C2 communication - telemetry beacons, key handshakes, scan reports, and exfiltrated files - is sent to , which proxies via SOCKS5 to the Tor hidden service at xburs4nr6cbuktokhqwefeh5hsjakz6usll5o7z5uhrfcnolakj4ptad.onion/api.php . Every request carries Authorization: Bearer crpx0_c2_2026 - the same token used as the secret parameter in the macOS curl command ( ). This shared token authenticates both payload downloads and C2 callbacks, proving the relay serves double duty: payload delivery AND command-and-control.

Execution runs in twelve sequential phases, each broken out below with its source. The victim is left with .crpx0 -encrypted files, HOW TO RECOVER ransom notes on a 48-hour countdown, and destroyed backups.

Values below are from the affiliate 1 build. OPERATION_ID , XOR_KEY , AES_KEY_B64 , DECOY_NAME and SELF_EXCLUDE_TAG are builder-generated per build and will differ in every other sample.

JSON payload fields: operation_id , status , device_info , affiliate_id , timestamp

IP geolocation User-Agent: curl/7.64.1

The entry point and phase ordering. Note that bootstrap() runs BEFORE main() - all anti-analysis and environment setup happens in bootstrap, then main handles the operational phases.

Decrypts all hardcoded config values. The XOR key, C2 URLs, auth token, and ransom note templates are all stored as integer arrays and decoded at runtime via dx() (XOR with XOR_KEY ). Nothing is stored in plaintext.

Seven distinct checks run in sequence. Any single detection triggers sys.exit(0) - the ransomware silently dies rather than risk analysis.

Key anti-sandbox code:

Blinds endpoint security by patching three critical Windows APIs in-memory. All three use VirtualProtect to make code pages writable, overwrite the function prologue with XOR-decoded patch bytes, then restore page protections.

Uses the fodhelper.exe auto-elevation technique. Creates a registry key under ms-settings that fodhelper.exe reads as a delegate command, causing it to launch the payload with admin privileges.

Shuffles the process and service lists randomly before iterating - varies the kill order to defeat behavioural signatures that trigger on sequential AV kills.

remove_backups() runs first, THEN file discovery. The backup commands are XOR-encoded in the binary and decoded at runtime.

Steals files BEFORE encryption begins. Two separate sweeps run:

The second list is not extortion material. .kdbx is a KeePass database, .keychain is the macOS Keychain, .pem / .pfx / .p12 are private keys and certificates, .env holds application secrets, .ovpn is a VPN profile and .keystore is a Java or Android signing store. These are credentials for follow-on access, not documents to threaten a victim with. Treat any CRPx0 infection as a credential compromise as well as a ransomware event and rotate everything reachable from the affected host - password vaults, certificates, VPN profiles, API keys and cloud tokens - regardless of whether the ransom is paid.

CRPx0 exfiltration targets: sweep 1 takes five random office documents from Desktop, Documents and Downloads as extortion leverage; sweep 2 takes ten credential files - password vaults, private keys, certificates, application secrets and VPN profiles - from anywhere in the folder for follow-on access

Both sets are packaged into a single ZIP, split into 512 KB chunks, and POSTed as multipart/form-data to . That relay is a dumb PHP proxy - it forwards over SOCKS5 to the real C2 at xburs4nr6cbuktokhqwefeh5hsjakz6usll5o7z5uhrfcnolakj4ptad.onion/api.php . Anything not paid for surfaces on the leak site at crpx0.su (clearnet) or crpxolx7.onion .

CRPx0 data exfiltration: office documents and credential files collected, bundled into one ZIP, split into 512 KB chunks, uploaded over plain HTTP to the clearnet relay and proxied onward through Tor, then published to the leak site - all before any file is encrypted

The critical timing detail: exfiltration completes *before* a single file is encrypted. By the time .crpx0 extensions or ransom notes appear on the network, the data is already on the relay and the double-extortion leverage is secured - the only detection window is the chunked multipart uploads to relay.php .

Used by every phase to report status back to the relay. Rotates through 5 browser user-agents and tries both clearnet and Tor C2 URLs.

Generates a per-victim Fernet (AES-128-CBC) key, attempts a 10-retry handshake with the C2 to register the key, then wraps it with the embedded RSA-4096 public key. Files are encrypted in parallel using ThreadPoolExecutor , with junk I/O injected every 10-20 files to break high-entropy-write detection signatures. Periodically re-patches AMSI/ETW during encryption.

set_wallpaper() (line 561) decodes an embedded base64 PNG ( BACKGROUND_B64 , ~3.7 MB of source) to ~/.d3dd0447.png and applies it via SystemParametersInfoW(20, 0, path, 3) on Windows, AppleScript ( System Events ) on macOS, and gsettings with a feh --bg-fill fallback on Linux. Decoded image: 1536 x 1024 px, 8-bit RGB PNG, 2,813,145 bytes.

CRPx0 ransomware wallpaper displayed after encryption.

6-stage domain-wide attack. Discovers network topology via domain recon + ARP + /24 sweep, then encrypts files on reachable shares and pushes copies of itself to remote hosts via WMI and schtasks. Falls back to GPO SYSVOL startup script if direct push fails. On macOS/Linux, uses SSH key-based propagation.

The ransomware uses VBScript on Windows (bypassing AMSI, which monitors PowerShell but not cscript.exe ) and a shell script on macOS/Linux. Both are launched as detached child processes with a 3-second delay, allowing the Python process to exit before the cleanup begins. The overwrite-before-delete pattern defeats simple file-recovery tools - the original bytes are gone from disk, not just unlinked.

The Python self_destruct() function builds this VBS script dynamically, targeting the payload path and its parent directory (if it's a staging directory like Cache_Sys or Temp ). It then launches it hidden via cscript.exe //NoLogo //B with CREATE_NO_WINDOW (0x08000000).

Same logic: zero the file ( cat /dev/null > ), then rm -rf the path, then delete the shell script itself. Launched via subprocess.Popen(['/bin/sh', sh_path]) with stdout/stderr redirected to /dev/null .

Lateral propagation task:

Text version: HOW TO RECOVER.txt - dropped in every encrypted directory

HTML version: HOW TO RECOVER.html - styled dark-theme page with live 48-hour countdown timer, opened in browser on Desktop after encryption completes

Ransom note in HTML format

Note also a 48 hour window for negotiation:

The template variables ( {opid} , {LEAK_URL} , {TOR_LINK} , {NEGO_URL} , {TOX_ID} , {SESSION_ID} ) are populated at runtime from XOR-decoded config constants. For this build: {opid} = OP_1785331224 , {NEGO_URL} = the Tor negotiation portal, {TOX_ID} and {SESSION_ID} = the communication identifiers listed in the C2 Infrastructure table above.

While pivoting from the payload-download endpoint, modifying the file parameter revealed a path-traversal vulnerability. Exploitation exposed files containing login details for terminal access to the CRPx0 C2 infrastructure.

Analyst notes screenshot showing weakness in adversary infrastructure.

This is the highest-value finding in the report and the most perishable - the relay is a single clearnet host the operator can rotate at any time. It is also the most sensitive: the access it implies goes well beyond passive collection. Any action taken on it should be coordinated with law enforcement in advance rather than exercised unilaterally.

The bullets above are hunting logic; the rules below are the deployable subset of it. They are written against structure - export names, packing format, encrypted-file layout, obfuscation keys - rather than the Appendix A hashes, which each build's own kill switch retires on expiry. Eleven rules covering every stage of the chain and all four builder output formats - ten written one per artefact class, plus the contributed CRPx0_ClickFix_Builder , which re-covers Stage 1 and overlaps the two lure rules by design.

YARA matches files; Sigma matches behaviour. Fourteen rules covering the process, registry, file and network events a file scanner cannot see - every phase from the victim's first paste through to self-destruct. Field names follow Sysmon. Listed in file order.

The Python source contains multiple referencing a builder tool...