Python Loader Evolution: Five Encryption Generations

Every RAT in this campaign -- nine families across six parallel attack chains -- entered through the same pipeline. A batch file downloads a ZIP from a disposable Cloudflare tunnel. The ZIP contains a Python runtime and one or more loader scripts. Each loader decrypts embedded shellcode, and that shellcode bootstraps the .NET Common Language Runtime (CLR) to load the actual payload. The RATs themselves barely changed over 176 days. The delivery pipeline evolved five times.

This post is the fifth and final entry in the SERPENTINE#CLOUD (tracked by Securonix, June 2025) breach analysis series. Prior posts covered the inner layers: PureLogs (the infostealer), PureCrypter (the .NET 3DES loader), Violet RAT (the 120-command dispatcher), and Remcos (AutoIt persistence and banking fraud). This one covers the outer layers -- batch download, Python loader, Donut shellcode, then .NET handoff.

Intelligence refresh (2026-02-26)

We re-validated the Dec17 and Feb1 stager URL mapping from decoded batch scripts and refreshed sandbox coverage for representative Python loaders from the Nov10, Nov19, and Nov24 sets.

The delivery stack

Batch stager (Cloudflare tunnel download)
  -> Python loader (5 encryption generations)
    -> Donut shellcode (Chaskey CTR, AMSI bypass)
      -> PureCrypter (.NET 3DES loader) -- covered in post 2
        -> Inner RAT -- covered in posts 1, 3, 4

Seven waves

Seven waves, 48 loader files, the same five RAT families repackaged over and over. Each wave either upgrades the encryption, changes the injection method, or both.

Wave 1 (October 5) -- XOR + RC4

The first deployment used two distinct loader architectures. All four files deliver the same .NET payload (Fviwknzr.exe, the PureCrypter loader analyzed in post 2). Python version: 3.14 (pre-release at time of deployment) -- the only wave to use it. All later waves drop to 3.12.

Type A: MOF loaders (double-XOR + process injection)

Two files (Oct05_MOF.py, Start_Oct05_MOF.py), each ~841 KB. Shellcode is XOR-encrypted with two 16-byte keys, then base64-encoded:

base64_decode -> XOR(key2) -> XOR(key1) -> raw shellcode

Injection technique: create a suspended notepad.exe, allocate RWX memory, write shellcode via WriteProcessMemory, queue an APC, resume the thread. The code is 151 lines, well-structured, with readable variable names and full ctypes structure definitions. A comment in the source reads: "CHANGE 2: Use the process argument from mof.py as the default here". This is development-stage code.

Type B: Python loaders (RC4 + junk code)

Two files (Oct05_pyt.py, Start_Oct05_Python.py), each ~820 KB. RC4 with 8-character keys:

Instead of process injection, these decrypt in-place and execute via ctypes.CFUNCTYPE -- shellcode runs directly in the Python process. Variable names are randomized 64-character strings with dead-code conditional blocks scattered throughout, but the RC4 implementation underneath is standard Key Scheduling Algorithm (KSA) + Pseudo-Random Generation Algorithm (PRGA).

The full chain (Wave 1)

Python (XOR or RC4)
  -> Donut shellcode (Chaskey CTR, 16 rounds)
    -> Fviwknzr.exe (.NET 3DES-CBC, 588,288 bytes)
      -> Jaglt resource (AES-encrypted + GZip-compressed)
        -> Qdjlj.dll (PureLogs, ConfuserEx-protected, protobuf C2)

Waves 2--3 (November 10) -- AES-256-CBC + dual XOR

14 plaintext Python loaders deployed across two staging directories (3D0bj for Wave 2/BKSNO, 3Dadu for Wave 3/BKNO). All use an identical 172-line template. Python version: 3.12.

The encryption scheme gets its first upgrade:

Encryption: XOR(key1) -> XOR(key2) -> AES-256-CBC(key, iv)
Decryption: base64_decode -> extract IV (first 16 bytes)
  -> AES-256-CBC decrypt (PyCryptodome)
  -> XOR(xor_key2) -> XOR(xor_key1) -> raw Donut shellcode

The injection method also changes. Instead of notepad.exe, the loaders now create a suspended explorer.exe and use Early Bird APC injection -- queuing the APC before the first instruction executes. Explorer blends in better than Notepad as a long-running process.

Seven RAT families deployed simultaneously per directory:

Wave 3 (BKNOLazy) carries the same seven payloads re-encrypted with different keys. Shellcodes are byte-identical to Wave 2 -- redundant deployment to two directories.

Each loader has unique AES-256 keys, unique XOR keys, and unique IVs. All Wave 2/3 payloads are delivered through Donut v0.9.2 directly to .NET assemblies in memory. The scripts are still plaintext and easy to read. This is the transition stage before the Kramer shift.

Waves 4--5 (November 19) -- Kramer obfuscator

The biggest architectural shift in the campaign. Files are named .py but are compiled Python 3.12 bytecode (magic cb0d0d0a). The encryption simplifies back to RC4 with 8-character keys. Everything else gets dramatically more complex.

The Kramer class

Each file contains a single class definition instantiated at module scope:

Kramer(_kramer=False, _rasputin=False, _sparkle=<encoded_blob>)

The __init__ method chains four lambda functions into a decode pipeline:

Lambda 1 (self._bit) -- hex decode. Imports binascii by reconstructing the module name from string indices ([1,8,13,0,18,2,8,8] into a _decode string). Calls unhexlify on each /-separated segment of input. Returns decoded UTF-8 characters.

Lambda 2 (self._bits) -- chain function. Connects decode output to execution: calls self._exit(Lambda3(input)).

Lambda 3 -- anti-debug + triple decode.

1. Opens __file__ and checks if the strings print or input appear anywhere in the source. Since the files are compiled bytecode, these strings are absent by default. If an analyst adds print() statements for debugging, the check triggers exit().
2. Layer 1: Hex unhexlify via Lambda 1 -- produces Unicode codepoints
3. Layer 2: Character shift: chr(ord(c) - SHIFT_CONSTANT) for non-zeta characters; Greek zeta (U+03B6) maps to newline
4. Layer 3: Alphabet rotation: +1 position in abcdefghijklmnopqrstuvwxyz0123456789 (a->b, z->0, 9->a)

Lambda 4 (self._exit) -- execution. Constructs the strings exec, globals, and utf8 from index operations, then runs eval(exec(globals(decoded_source))).

Polymorphic shift constants

Each sample uses a unique Unicode Private Use Area (PUA) shift constant, embedded deep in the bytecode constants of a nested generator expression. PUA codepoints (U+E000--U+F8FF) have no standard meaning and no displayable glyph -- they're invisible to signature-based detection that expects ASCII or common Unicode. Every file has a different constant, and the encoded blob is completely different even when the decoded payload is identical.

All 15 samples decode to the same Python template:

import ctypes
import base64

def rc4_decrypt(key, data):
    # Standard RC4 (KSA + PRGA)
    ...

def execute_shellcode():
    encrypted_data = base64.b64decode('<base64_blob>')
    key = '<RC4_KEY>'.encode('ascii')
    shellcode = rc4_decrypt(key, encrypted_data)

    shellcode_buffer = ctypes.create_string_buffer(shellcode)
    ctypes.windll.kernel32.VirtualProtect(
        ctypes.byref(shellcode_buffer),
        ctypes.sizeof(shellcode_buffer),
        0x40,  # PAGE_EXECUTE_READWRITE
        ctypes.byref(ctypes.c_ulong())
    )
    shellcode_func = ctypes.cast(
        shellcode_buffer,
        ctypes.CFUNCTYPE(ctypes.c_void_p)
    )
    shellcode_func()

execute_shellcode()

The WBKS delta

Three build profiles exist: EMP, OBKS, and WBKS. EMP and OBKS carry identical shellcode sizes per RAT family but use different shift constants and RC4 keys -- the build system repackages the same shellcode with fresh obfuscation parameters.

WBKS shellcodes are consistently +26,628 bytes larger than EMP/OBKS across all five RAT families:

The constant delta across all five payloads strongly suggests WBKS adds an additional ~26 KB stage to the shellcode. We did not extract the WBKS-specific stub to confirm its purpose -- it could be an extra unpacking layer, an AMSI/ETW bypass, or a different Donut configuration -- but the exact +26,628 byte consistency across five unrelated RAT families rules out coincidence.

File size bloat

The obfuscation cost is significant. Nov10 plaintext loaders range from 119 KB to 1,959 KB. Nov19 Kramer loaders range from 4,126 KB to 20,684 KB. The Violet RAT loader -- the largest -- is 20.7 MB for a file that decodes to the same ~40-line RC4 template. That is a ~30x file size increase for the same functional payload.

The 7-layer chain (Nov19 only)

Wave 4/5 introduces the deepest nesting observed in the campaign. The Nov19 Donut instances deliver native x64 PE wrappers instead of .NET assemblies directly:

Layer 1: Python (.pyc disguised as .py)
  Layer 2: Kramer decode (hex -> unicode shift -> rotation -> RC4 -> base64)
    Layer 3: Donut #1 (Chaskey CTR, v0.9.3, 20,345-byte stub)
      Layer 4: Native x64 AES crypter PE
        Layer 5: AES-256-CBC + 16-byte XOR overlay
          Layer 6: Donut #2 (Chaskey CTR)
            Layer 7: .NET RAT assembly

The native AES crypter at Layer 4 uses per-sample keys stored in the .rdata section: 32-byte AES-256 key at offset +0x210, 16-byte CBC IV at +0x230, 16-byte XOR overlay key at +0x240. All Nov19 modules share an identical 176 KB .text section (the native loader stub) plus a _sysc section for direct syscalls.

Nov10 vs Nov19 comparison

Donut v0.9.2 -- Chaskey CTR and AMSI bypass

Donut is the bridge between the Python shellcode and .NET. Every wave uses it. The framework packages .NET assemblies as position-independent shellcode that bootstraps the CLR from scratch.

Chaskey cipher

All Donut instances use the Chaskey block cipher -- a lightweight permutation-based MAC designed for microcontrollers (Mouha et al., 2015), repurposed by Donut as a stream cipher in CTR mode:

• Block size: 128 bits (16 bytes)
• Rounds: 16
• Mode: CTR with big-endian byte-array counter (incremented from byte[15] toward byte[0] with carry propagation)
• Pre-whitening: block XOR key
• Post-whitening: block XOR key

Instance layout

[+0x000] uint32    len          -- total instance size
[+0x004] byte[16]  Chaskey key  -- 128-bit key
[+0x014] byte[16]  Chaskey ctr  -- 128-bit counter/nonce
[+0x024] byte[4]   (zero pad)
[+0x028] uint64    API hash     -- VirtualAlloc
[+0x048] uint64    API hash     -- VirtualProtect
  ...
[+0x230] byte[]    Encrypted module data (v0.9.2)
[+0xC08] byte[]    Encrypted module data (v0.9.3)

AMSI/WLDP patching

Before loading the .NET assembly, every Donut instance runtime-patches five security scanning functions:

After patching, Donut loads mscoree.dll, calls CLRCreateInstance to start the .NET CLR (v4.0.30319), and invokes ExecuteInDefaultAppDomain with the target class and method names stored in the instance.

v0.9.2 vs v0.9.3

The x64 decoder stub is 3x larger than x86 due to 64-bit register operations and wider instruction encoding.

Per-instance Chaskey keys (Oct05)

Batch stager infrastructure

The batch stagers are the initial execution layer. 29 .bat files recovered across six evidence directories deduplicate to 13 unique templates in four categories.

Download stagers

Two template families handle the initial download:

2Embambed -- AV-branched ZIP selection from a single Cloudflare tunnel per wave. Checks for AvastUI.exe and AVGUI.exe via tasklist. If detected, downloads abb11.zip (OBKS-only, Avast-safe profile). If not, downloads quz11.zip (full WBKS + BKSNO deployment). Each stager also downloads Shoopify.bat, PWS.vbs, and pws1.vbs into the Startup folder.

2bibo -- dual-ZIP download with fallback servers and random filenames. Downloads two ZIPs (Mfraq.zip and Sgraq.zip) into separate staging directories. Generates random 5-character uppercase filenames for local ZIPs. Has primary Cloudflare tunnel URLs plus fallback HTTP servers for redundancy.

Nine Cloudflare tunnels

Each deployment wave uses 2--3 disposable tunnels. A new tunnel is generated for each wave, with one exception: the Feb 1 Main_HV_x86 stager reuses the Dec 17 tunnel.

Fallback servers

The 2bibo template includes non-Cloudflare fallback servers for when tunnels go down:

RAT launcher evolution (Shoopify.bat)

Three versions of Shoopify.bat recovered, deployed to the Startup folder for persistence:

Version 1 (Nov 28): References Nov20 filenames for OBKS/WBKS, Sep07 filenames for BKSNO. No XWorm. AV detected: 5 loaders. No AV: 12 loaders.

Version 2 (Jan 7): References Dec16 filenames across all sets. No XWorm. Same loader counts.

Version 3 (Feb 1): Adds XWorm (Xwrm3) to the OBKS and WBKS sets. AV detected: 6 loaders. No AV: 13 loaders. XWorm was never added to the BKSNO background set -- it was patched in between Jan 7 and Feb 1 by adding two lines to the foreground sets only.

This is the largest deployment profile in the campaign. When no Avast/AVG is detected, the system boots with 13 simultaneous Python RAT loaders, plus the Oct05 pair via Kindle_x86.bat, plus the AutoIt chains, plus two anti-idle VBS scripts.

Anti-forensic evolution

Early stagers used simple taskkill /f /im python.exe. By Nov 28, they switched to WMI parent-process hunting:

Get-CimInstance Win32_Process -Filter "Name='explorer.exe'" |
  ForEach-Object {
    $p = Get-Process -Id $_.ParentProcessId -ErrorAction Stop
    if ($p.ProcessName -eq 'python') {
      Stop-Process -Id $p.Id -Force
    }
  }

The method is narrower: instead of killing all python.exe processes, it finds explorer.exe instances whose parent is python.exe and kills only that parent. Kindle_x86.bat extends this to also hunt notepad.exe parents, because Wave 1 MOF loaders inject into notepad.

Anti-idle scripts

Deployed by all download stagers to the Startup folder:

F15 resets the idle timer without producing visible keystrokes. Both scripts keep the session alive for PureHVNC remote access.

Encryption evolution summary

Progression summary: readable Python with two XOR keys -> AES-256 with PyCryptodome -> compiled bytecode with polymorphic Unicode PUA ciphertext and 30x file bloat. The RAT payload families stayed the same.

Indicators of compromise

Cloudflare tunnel domains

mustang-allowing-them-legislative.trycloudflare.com
valuation-throws-sixth-disc.trycloudflare.com
brochure-pot-tested-clubs.trycloudflare.com
candidates-burlington-hugh-anymore.trycloudflare.com
render-seen-sensor-urban.trycloudflare.com
avoiding-ended-holiday-encyclopedia.trycloudflare.com
blowing-paris-indoor-links.trycloudflare.com
brunette-assembled-america-homepage.trycloudflare.com
stomach-cite-personality-money.trycloudflare.com

Fallback servers

Python loader hashes (Wave 1)

Batch stager hashes

Behavioral indicators

Five posts, one kill chain

This post is the fifth and final entry in the SERPENTINE#CLOUD analysis series:

1. PureLogs: Reverse Engineering a .NET RAT -- the ConfuserEx-protected infostealer with protobuf C2
2. PureCrypter: Reverse Engineering a .NET Loader -- the 3DES event-driven pipeline
3. Violet RAT v4.7: The Most Dangerous Payload in a 9-RAT Toolkit -- 120-command dispatcher with ransomware and HVNC
4. Remcos Banking Fraud via Three AutoIt Persistence Chains -- BYOI persistence and Canadian banking fraud
5. Python Loader Evolution (this post) -- the delivery pipeline

Most development effort went into the delivery pipeline: polymorphic build systems generating unique keys per file, AV-aware branching selecting deployment profiles at runtime, and disposable Cloudflare tunnels rotated by wave. The inner RATs -- DcRat, AsyncRAT, VenomRAT, Violet, and PureLogs -- ran on the same C2 infrastructure throughout.

The outer layers changed constantly. The inner layers barely changed at all.