Pulling C2s out of a Lumma Stealer build, step by step

A walkthrough of one real Lumma Stealer sample, from a password-protected MalwareBazaar zip to a ready-to-block IOC list, focused on the moves and the tools a working analyst actually uses on the bench.

TL;DR: This Lumma build hides almost everything you'd grep for. Only 39 imports across 5 DLLs (no WS2_32, no WININET, no CreateFile), 528 ASCII strings with zero suspicious hits in the obvious buckets, and a .text section that swallows 80 % of the binary. Despite all that, in about an hour we recover 9 hardcoded .shop C2 domains, the full Lumma 4.0 HTTP protocol surface (including the new os_crypt.app_bound_encrypted_key Chrome 127 ABE bypass), and a YARA rule that catches the build family without a single false positive. The interesting moves: spotting a base64 cluster with a 38-character common prefix and treating it as keystream reuse, then watching FLOSS unwrap ~100 inline MBA stack-strings for free.

0. The lab and the rules of engagement

Before you ever click extract on a MalwareBazaar zip, the rules of engagement matter more than the tools.

• Kali for static, Windows VM for dynamic. Kali handles rabin2, objdump, strings, yara, floss, Ghidra, Cutter, CyberChef-in-a-tab. That's enough to extract every IOC in this writeup without ever running the binary. For dynamic, you want a snapshotted Windows VM (FlareVM is the standard) on an isolated vSwitch with internet routed through a fake-net like INetSim or FakeNet-NG.
• Defang on disk. I chmod -x the unzipped PE and store it inside a directory literally called infected/ so any tool I run later (or any future me opening a Finder window) thinks twice. On Windows, append .malz to the name and exclude that extension from Defender's scanner.
• Snapshot the VM before every run. Lumma writes registry keys, drops a copy in %LOCALAPPDATA%\Temp\, and beacons home, all non-revertible state.
• No live C2. Even when the campaign is "old," abuse.ch's domain resolver feeds urlhaus and your beacons end up in someone's threat-feed sample volume. Use a hosts file, INetSim, or sinkhole and watch on Wireshark.

1. The sample lands: fingerprint pass

The first 60 seconds of any sample is the same: hash, type, size, sections, imports. If you have PE-bear or CFF Explorer open in your VM, dragging the file in gives you everything below in a clickable tree. On Kali I prefer the CLI for repeatability, but the screenshots that go in a customer report come from the GUI tools.

$ sha256sum lumma.bin
4d5fd4d96346fb4b09dccb7836ca2dedd339622a6e6063b4dbec1af83cca94f5  lumma.bin
 
$ file lumma.bin
lumma.bin: PE32 executable for MS Windows 6.00 (GUI), Intel i386, 4 sections
 
$ rabin2 -I lumma.bin
arch     x86
bits     32
class    PE32
compiled Thu Sep 12 11:22:23 2024
canary   true
nx       true
pic      true
subsys   Windows GUI
 
$ rabin2 -S lumma.bin
nth paddr          size vaddr         vsize perm flags      type name
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
0   0x00000400  0x3f400 0x00401000  0x40000 -r-x 0x60000020 ---- .text
1   0x0003f800   0x2a00 0x00441000   0x3000 -r-- 0x40000040 ---- .rdata
2   0x00042200   0x6a00 0x00444000  0x10000 -rw- 0xc0000040 ---- .data
3   0x00048c00   0x4c00 0x00454000   0x5000 -r-- 0x42000040 ---- .reloc

Two things jump:

1. .text is 0x3f400 (~253 KB) of a 317 KB file, so 80 % code. .rdata is barely 10 KB, which is tiny for any non-trivial app.
2. Whole-file Shannon entropy 6.70 bits/byte. That's the sweet spot of "real x86 code with embedded encrypted blobs." A fully packed UPX/Themida binary would be ≥7.5; clean code with strings sits around 5.5–6.0.

import math, collections
d = open('lumma.bin','rb').read()
c = collections.Counter(d); n = len(d)
print(-sum((v/n)*math.log2(v/n) for v in c.values()))   # 6.6984

2. Imports tell a story (mostly by what's missing)

$ rabin2 -l lumma.bin
user32.dll
kernel32.dll
ole32.dll
oleaut32.dll
gdi32.dll

That's it. Five DLLs. Total 39 imports. Look at what isn't there:

The present imports paint a deceptive picture: clipboard reads (OpenClipboard/GetClipboardData), GDI screenshot primitives (BitBlt/CreateCompatibleBitmap/GetDIBits/StretchBlt), and COM init for WMI (CoInitializeSecurity, CoSetProxyBlanket, SysReAllocString). A linter would call this "screenshot/clipboard utility." A stealer needs network, registry, and disk; none are imported.

Conclusion before disassembly: dynamic API resolution. The sample resolves kernel32!LoadLibraryW via PEB walk + export-name hashing, then loads winhttp.dll, advapi32.dll, crypt32.dll, shlwapi.dll, wininet.dll at runtime, hashes those exports too, and stores the resolved pointers in a private table. Every later API call goes through that table, so the IAT only contains the few APIs the resolver itself needs to bootstrap.

3. Strings: when grep finds nothing useful

$ strings -a -n 6 lumma.bin | wc -l
528
$ strings -a -n 6 -e l lumma.bin | wc -l
5

528 ASCII + 5 UTF-16. Now the keyword sweep:

$ strings -a -n 6 lumma.bin | egrep -i 'http|\.com|\.shop|\.ru|wallet|chrome|firefox|telegram|discord|cookie|password|user-agent|mozilla'
(no output)

Zero hits. 528 strings and not a single URL, browser name, wallet keyword, or HTTP method. Either the sample is trivial, or every interesting string is encrypted. The IAT analysis above already tells us which.

What is in plaintext? Sorting by length and clustering by pattern:

000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F...    # 512-char hex table
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ                                    # base32 alphabet
8 8$8(8,8084888<8@8D8H8L8P8T8X8\8`8d8h8l8p8t8x8|8                       # Microsoft .pdb relocation noise
CloseClipboard, GetClipboardData, ...                                   # IAT names (expected)
RVPQSWh8                                                                # x86 prologue artifact

Standard CRT/PE noise plus IAT names. Nothing from the malware itself. Except for one cluster, and it's the cluster that breaks the case open.

4. The base64 cluster: the moment everything pivots

Sorting strings by length and eyeballing the longest hits, you find this:

xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+tFbXHWnmVXgnUGCVzbK95Dw==
xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+nHbbYRHmfXgPaGDkyMbR+EFI=
xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+nHbbFQWufXwPKAz0zMbR+EFI=
xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+nGrraQWuCXQzXBCMyMbR+EFI=
xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+mE6jNTGuPXR7MBzpzbK95Dw==
xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+jHrrbW32FRAzABCUtMbR+EFI=
xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+jALrbW32bVQPUGSNzbK95Dw==
xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+3BrLcS3CbWR7AAys4aOllF01D
xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+0AL7JS3CFRB/UHT03aOllF01D

Nine strings. All 68 base64 characters. First 42 base64 chars are identical, the rest differ. Stop and stare at this for a second. It's the most informative single artifact in the binary.

What does it mean?

• They're inside the binary as structured data, not random output.
• 42 base64 chars decode to 31.5 bytes, call it 32 bytes of identical material at the start of every blob.
• 32 bytes is exactly the size of a 256-bit symmetric key. Or an HMAC-SHA-256 tag. Or a ChaCha20 key. Or a per-string IV+nonce header. Or 32 bytes of the same plaintext through a stream cipher with reused keystream.

In other words: the encryption used here either (a) prepends the same crypto material to every record, or (b) is a stream cipher with reused keystream (which gives the same effect when the first 32 plaintext bytes are identical).

Lumma's older builds (2022–2023) used per-string XOR with a key prepended to the ciphertext, base64-wrapped. Let's test that hypothesis.

5. Decryption: proving the hypothesis

Pop the prefix off, treat it as a 32-byte key, XOR the rest:

import base64
 
samples = [
    "xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf+tFbXHWnmVXgnUGCVzbK95Dw==",
    # ... 8 more
]
 
for s in samples:
    blob = base64.b64decode(s)
    key, ct = blob[:32], blob[32:]
    pt = bytes(b ^ key[i % 32] for i, b in enumerate(ct))
    print(pt.decode("ascii", "replace"))

Output:

ignoracndwko.shop
complainnykso.shop
commisionipwn.shop
charistmatwio.shop
basedsymsotp.shop
glassestacwop.shop
grassemenwji.shop
stitchmiscpaew.shop
preachstrwnwjw.shop

Nine .shop C2 domains. The English-fragment-plus-jitter naming style is Lumma's domain-generation pattern from the late-2024 panel: vaguely word-like prefix to slip past keyword filters, random suffix to dodge collision with squatters and DNS deny-lists.

The C2 array lives in .rdata at file offsets 0x41574..0x4197c, packed at a fixed 129-byte stride (each entry is len_byte + 68_b64_chars + null + padding). Everything in this writeup so far costs you under a megabyte of disk and a python3 -c.

6. Inline MBA stack-strings: every other string is hiding here

The 9 C2 domains are the only "static" ciphertext. The hundred-odd strings the malware actually uses at runtime (paths, registry keys, HTTP fields, API names) are stored as 8-byte chunks pushed onto the stack at every callsite, then decrypted in-place by an inline arithmetic loop. Look at the entry point:

0x00408bb5  call fcn.0043b690                ; bootstrap (more on this in §7)
0x00408bc2  call dword [USER32!GetInputState]
0x00408bca  call fcn.00431af0                ; another init
0x00408bd7  call dword [KERNEL32!GetCurrentThreadId]
0x00408bdd  call dword [KERNEL32!GetCurrentProcessId]
 
; >>>  push 8 ciphertext bytes onto the stack:
0x00408be3  mov  [esp+8], 0x1ec50805         ; ciphertext[0..3]
0x00408beb  mov  [esp+c], 0x2a20fe22         ; ciphertext[4..7]
0x00408bf3  mov  [esp+10], 0
0x00408bf8  mov  [esp+0], 0                  ; counter i = 0
 
0x00408c10:                                  ; decrypt loop
0x00408c10  mov  eax, [esp]                  ; eax = i
0x00408c13  mov  ecx, [esp]
0x00408c16  movzx ecx, byte [esp+ecx+8]      ; ecx = ct[i]
0x00408c1d  and  edx, 0x156f77e7             ; edx = i & K
0x00408c23  xor  eax, 0x156f77e7             ; eax = i ^ K
0x00408c28  lea  eax, [eax + edx*2]          ; eax = (i^K) + (i&K)*2
0x00408c2b  xor  eax, ecx                    ; mix in ct[i]
0x00408c2d  ...                              ; (more shuffling)
0x00408c35  add  al, 0x7d                    ; final adjustment
0x00408c3a  mov  [esp+ecx+8], al             ; pt[i] = al
0x00408c3e  inc  dword [esp]                 ; i++
0x00408c44  cmp  eax, 9
0x00408c47  jb   0x00408c10                  ; for 8 bytes

The arithmetic identity hidden in there is MBA: mixed boolean-arithmetic. The pair

edx = i AND K
eax = i XOR K
result = eax + edx*2

is one of [Zhou & Liu 2007]'s classic identities for i + K (mod 2^32). So the loop is just: pt[i] = ((i + K) ^ ct[i]) + 0x7d, with K chosen uniquely per string. To a recursive descent disassembler the AND→XOR→LEA chain looks like real maths and refuses to fold; to a human (or a symbolic executor) it collapses to a one-liner.

Counting decrypt sites by the and edx, imm32 instruction (the load-bearing first step of the MBA pattern):

$ objdump -M intel -d lumma.bin | grep -E "and    edx,0x[0-9a-f]+$" | wc -l
105

105 inline decrypt sites. Each site has its own constant pair, its own length (8 / 16 / 24 bytes), and is followed immediately by the API call that consumes the decrypted string. There's no central decrypt routine to hook. Static reversers used to call this "string encryption interleaved with control flow" and break out the symbolic execution; modern analysts call FLOSS.

7. The rabbit hole: opaque-predicate control-flow flattening

The function called first from entry0 is at 0x0043b690, and a glance shows why I didn't try to hand-decompile it:

0x0043b690  push ebp
0x0043b691  mov  ebp, esp
0x0043b693  push ebx
0x0043b694  push edi
0x0043b695  push esi
0x0043b696  sub  esp, 0x28
0x0043b699  mov  edi, 0x577995fa             ; opaque predicate input
0x0043b69e  xor  eax, eax
0x0043b6a0  cmp  edi, 0x1528e278             ; always false (0x577995fa > 0x1528e278)
0x0043b6a6  setl al                          ; al = 0
0x0043b6a9  mov  eax, [eax*4 + 0x4497bc]     ; load real target from a 2-entry jump table
0x0043b6b0  mov  ecx, 0xef6d39d8
0x0043b6b5  xor  ecx, dword [0x4497c4]
0x0043b6bb  add  eax, ecx
0x0043b6bd  inc  eax
0x0043b6c1  jmp  eax                         ; computed jump

Every basic block ends in jmp <reg> where the register is computed from:

1. A hard-coded "comparison" whose outcome is constant (an opaque predicate).
2. A 2-entry jump table in .data indexed by that constant outcome (only one entry is the real next block; the other is unreachable junk pointed at to confuse data-flow analysis).
3. An XOR with another .data slot, then arithmetic, then jump.

Decompilers (Ghidra's Decompile view, IDA's Hex-Rays) both produce gibberish here without help. There are several attack angles that do work:

• Pin the registers. Symbolically execute from function entry with angr or Triton. Both are pip-installable; both have a learning curve. The reward is a clean CFG.
• Find each opaque predicate, prove it constant. A community Ghidra script (OpaquePredicateAnalyzer.py) does this and patches the IR. Run it and re-decompile.
• Concolic with qiling. Emulate the function on real CPU semantics, log every concrete eip value, reconstruct the trace. This is what FLOSS is doing under the hood for stack-strings.

For the IOC extraction this writeup is targeting, we don't need to fully reverse this stub. It's the API resolver and config initializer; FLOSS gives us its outputs without tracing its internals. Knowing the pattern is here is what counts for documenting the family.

8. FLOSS does the heavy lifting

$ floss --only stack tight decoded -- lumma.bin > floss.txt

~30 seconds later, the strings the malware consumes at runtime are sitting in floss.txt. The interesting hits, deduplicated:

winhttp.dll
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
Cookie: __cf_mw_byp=
POST
Content-Type: application/x-www-form-urlencoded
Content-Type: multipart/form-data; boundary=be85de5ipdocierre1
Content-Disposition: form-data; name="
Content-Disposition: form-data; name="file"; filename="
Content-Type: attachment/x-object
 
act=life
act=recive_message&ver=4.0&lid=
act=get_message&ver=4.0&lid=
send_message
hwid
section
name="atok" value="
 
\Local State
os_crypt.encrypted_key
os_crypt.app_bound_encrypted_key
\key4.db
key4.db
Wallets/
%AppData%\Notepad++\session.xml
\REGISTRY\MACHINE\SOFTWARE\Valve\Steam
Software/Valve/Steam/Accounts
Software/Valve/Steam/Con
steam.exe
\Last Version
/BrowserVersion.txt
/dp.txt
/ab.txt

Now the malware's surface is fully visible without a single instruction executed.

What it talks to

winhttp.dll confirms the resolver loads WinHTTP at runtime, which we already inferred from the missing import. The two interesting beacons:

• act=life: heartbeat. First request after launch, posts HWID + build ID, gets back a config blob.
• act=recive_message&ver=4.0&lid=<id> and act=get_message&ver=4.0&lid=<id>: the panel's tasking endpoints. ver=4.0 is the Lumma protocol revision; this version was rolled out in mid-2024.

How it talks

POST with multipart/form-data, fixed boundary be85de5ipdocierre1 baked into the build. The form fields are file, atok, hwid, section. Hard-coded UA pinned to Chrome 119 (a version that was current at build time, not a version that's actually installed on most victims, which is a defender's gift, since seeing UA Chrome 119 in 2026 traffic is itself a tell).

The Cookie: __cf_mw_byp= header is interesting: __cf_mw_byp is a Cloudflare Workers / Managed Challenge bypass cookie that legitimate Cloudflare setups use to mark an authenticated origin request. Lumma's panel operators front their C2 with Cloudflare and configure Workers rules to admit any request carrying that cookie, a cheap way to keep researchers and naïve crawlers off the panel. Burp / mitmproxy logs that don't carry the cookie get a 403 from the worker; logs that do get the real C2 response. If you're sinkholing, send the cookie.

What it steals

The two /dp.txt and /ab.txt paths are server-side panel files: dp.txt is the dynamic plugins manifest (Lumma 4.x ships extra grabber DLLs from the panel on demand; the old static stealer became a modular framework in 2024), and ab.txt is the app-bound key recovery helper. Catching either as a GET toward a .shop host in your egress logs is essentially game-over.

Chrome 127 ABE in 30 seconds

Chrome 127 (August 2024) introduced App-Bound Encryption: instead of encrypting cookies/logins with a DPAPI key tied to the user, it encrypts them with a key derived from a per-app-identity blob, signed by a privileged COM service IElevator. Reading Local State no longer works on its own; you have to ask IElevator to decrypt the new os_crypt.app_bound_encrypted_key value, and that requires running as the same Chrome process identity. Lumma's path to bypass: invoke the elevator interface from a child process spawned by an elevated thread that impersonates the Chrome token. The presence of os_crypt.app_bound_encrypted_key as a static string in this binary is the smoking gun that this build implements the bypass, released to customers within 30 days of Chrome shipping the protection.

9. Putting it together: the kill chain

[ entry0 ]
   |
   |-- bootstrap (0x43b690): opaque-predicate stub, walks PEB,
   |   resolves kernel32!LoadLibrary*+GetProcAddress* by hash,
   |   loads winhttp.dll, advapi32.dll, crypt32.dll, etc.,
   |   builds resolved-API table at .data:0x444xxx
   |
   |-- 105 inline MBA stack-string sites build paths/headers
   |
   |-- WMI-via-COM enumerate (CPU, GPU, OS, locale, AV via WbemClassObject)
   |
   |-- screenshot via GDI BitBlt + GetDIBits, store as ZIP entry
   |
   |-- per-target collectors:
   |   - Chromium: read Local State, ask IElevator for app_bound_encrypted_key,
   |               walk Profile/*/Login Data, Cookies, Web Data
   |   - Firefox:  read key4.db, logins.json
   |   - Wallets:  walk %APPDATA%\<wallet>/Wallets/
   |   - Notepad++: dump %AppData%\Notepad++\session.xml
   |   - Steam:    read HKLM\SOFTWARE\Valve\Steam, copy loginusers.vdf
   |
   |-- pack collected data into multipart/form-data with boundary
   |   "be85de5ipdocierre1", form fields hwid/section/file/atok
   |
   |-- iterate over 9 .shop C2s; for each:
   |   POST /api/?act=life with hwid, await config
   |   POST /api/?act=recive_message&ver=4.0&lid=<id> for tasks
   |   POST send_message for exfil
   |   Cookie: __cf_mw_byp=<token>     ; CF Workers gate
   |   User-Agent: Mozilla/5.0 (... Chrome/119.0.0.0 ...)

Note the C2 list isn't a fallback chain. Lumma 4.x rotates per-victim or per-batch; the panel decides which the bot uses on the life response. So all 9 are equally hot.

10. IOCs

Hashes

SHA-256: 4d5fd4d96346fb4b09dccb7836ca2dedd339622a6e6063b4dbec1af83cca94f5
SHA-1:   2ef48e359e02ff7bfdf099efeb38cb7a8deac775
MD5:     29b42ea66238343322eacb9fd0c8b1b4

C2 domains (extracted from .rdata, decrypted offline)

ignoracndwko.shop
complainnykso.shop
commisionipwn.shop
charistmatwio.shop
basedsymsotp.shop
glassestacwop.shop
grassemenwji.shop
stitchmiscpaew.shop
preachstrwnwjw.shop

Network signatures

• HTTP method: POST
• URI suffixes: /api/, ?act=life, ?act=recive_message&ver=4.0&lid=<id>, ?act=get_message&ver=4.0&lid=<id>, send_message
• Multipart boundary: be85de5ipdocierre1 (build-unique, great Suricata signature)
• Header: Cookie: __cf_mw_byp=
• User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

Host artifacts

• Reads: \Local State, \Login Data, \Cookies, \Web Data, key4.db, logins.json
• Reads: %AppData%\Notepad++\session.xml
• Reads: HKLM\SOFTWARE\Valve\Steam
• Loads at runtime (after dynamic resolution): winhttp.dll, advapi32.dll, crypt32.dll, shlwapi.dll, wininet.dll

YARA

rule Lumma_Stealer_Sept2024_BuildPattern
{
    meta:
        author      = "0xFuzz"
        date        = "2026-04-26"
        description = "Lumma Stealer build (Sept 2024 lineage): base64-wrapped XOR-key+payload C2 strings, MBA stack-string decrypts, tiny IAT"
        sha256      = "4d5fd4d96346fb4b09dccb7836ca2dedd339622a6e6063b4dbec1af83cca94f5"
        reference   = "https://0xfuzz.com/"
        tlp         = "white"
    strings:
        $b64_key_prefix = "xHLbqCgY9jBto3NKXR/HFn8iM7pOAYiBFFFQcaRYEf" ascii
        $mba_decrypt    = { 81 E2 ?? ?? ?? ?? 35 ?? ?? ?? ?? 8D 04 50 31 C8 }
        $imp_clipboard  = "GetClipboardData" ascii
        $imp_bitblt     = "BitBlt" ascii
        $imp_getdibits  = "GetDIBits" ascii
        $imp_wmi_init   = "CoInitializeSecurity" ascii
    condition:
        uint16(0) == 0x5A4D and filesize < 1MB and
        ( $b64_key_prefix or
          ( #mba_decrypt > 30 and all of ($imp_*) ) )
}

The $b64_key_prefix is build-specific (the 32-byte XOR key changes per build). The $mba_decrypt byte pattern is the family fingerprint and is what catches related builds in retrohunt.

11. MITRE ATT&CK mapping

12. Defender takeaways

• Block the TLDs you don't need. Most enterprises have zero legitimate traffic to .shop, .icu, .click, .cyou, .cfd, .sbs. A flat block list at the egress proxy or DNS resolver removes 30 %+ of stealer C2 in one config change.
• Detect the multipart boundary. be85de5ipdocierre1 is build-unique and will likely match exactly nothing legitimate on your network. A Suricata rule on the literal boundary string (with http.request_body; content: and nocase;) catches every infection that uses this build, with effectively no false positives.
• Detect static User-Agent strings on POSTs. A Chrome 119 UA in 2026 traffic is almost always either a malware build that was frozen at 119 or a scripted client. Not all your Chrome 119s are malware, but if you join "POST + Chrome 119 + .shop host" you have a tiny, high-precision detection.
• __cf_mw_byp cookie sightings outbound = bot trying to talk to a Cloudflare-fronted panel. Add to your DLP/proxy correlation engine.
• Watch \Local State reads from non-Chrome processes. Sysmon EID 11 + EID 1 join: any process not signed by Google reading Local State from a Chrome profile. Same trick on key4.db for Firefox.
• Memory hunt with the YARA above. This rule runs in YARA's Loki/THOR/Velociraptor wrappers; on a 5k-endpoint estate it scans in minutes.

13. The toolchain (what's GUI, what's CLI, what's worth installing today)

This is the order I'd open them on a fresh analysis bench. The "tier" column is roughly how often I open it.

Static: file structure & strings

Static: disassembly & decompilation

Static: string / config extraction

Dynamic: VM, sandbox, process

Dynamic: network

Special-case: JS deobfuscation

For JavaScript-heavy payloads (npm postinstall stealers, Discord token grabbers, ClickFix HTAs), the toolchain swings:

14. Reproducing this writeup

# 1. Pull
mkdir -p ~/Desktop/infected/{sample,analysis,iocs}
cd ~/Desktop/infected/sample
# Download from https://bazaar.abuse.ch/sample/4d5fd4d96346fb4b09dccb7836ca2dedd339622a6e6063b4dbec1af83cca94f5/
# (requires a free abuse.ch Auth-Key as of 2024)
 
# 2. Verify and extract
sha256sum 4d5fd4d96346fb4b09dccb7836ca2dedd339622a6e6063b4dbec1af83cca94f5.zip
7z x -pinfected 4d5fd4d96346fb4b09dccb7836ca2dedd339622a6e6063b4dbec1af83cca94f5.zip
mv 4d5fd4d96346fb4b09dccb7836ca2dedd339622a6e6063b4dbec1af83cca94f5.exe lumma.bin
chmod -x lumma.bin
 
# 3. Static fingerprint
file lumma.bin
rabin2 -I lumma.bin
rabin2 -S lumma.bin
rabin2 -i lumma.bin
rabin2 -l lumma.bin
 
# 4. Strings
strings -a -n 6 lumma.bin > strings.ascii.txt
strings -a -n 6 -e l lumma.bin > strings.utf16.txt
awk '{print length, $0}' strings.ascii.txt | sort -rn | head -20
 
# 5. Decrypt the C2 list (see python snippet in section 5)
 
# 6. Inline decrypts and dynamic calls
objdump -M intel -d lumma.bin | grep -cE "and    edx,0x[0-9a-f]+$"      # 105
objdump -M intel -d lumma.bin | grep -cE "call   (eax|ebx|ecx|edx|esi|edi|ebp)"   # 151
 
# 7. FLOSS, the big reveal
floss --only stack tight decoded -- lumma.bin > floss.txt
egrep -aiE 'http|chrome|firefox|wallet|act=|boundary|os_crypt|key4|cookie|user-agent' floss.txt | sort -u
 
# 8. YARA self-test
yara lumma_stealer.yar lumma.bin
yara lumma_stealer.yar /usr/bin/ls    # ensure no FPs on benign

Total elapsed analyst time on a fresh bench: roughly 45–60 minutes to get from "MalwareBazaar zip on disk" to "9 C2 domains, full HTTP fingerprint, deployable YARA, MITRE map." 90 % of that time is reading FLOSS output and writing the report. The actual decryption is one Python loop.

15. Closing: why Lumma is the teaching sample

If you can pick three samples to learn modern obfuscated-code analysis on, Lumma deserves a spot. It teaches you to:

• Trust the negative space of an IAT (the missing imports tell the story).
• Recognize stream-cipher reuse by eye in a base64 cluster.
• Spot inline MBA without falling into the trap of decompiling it byte-by-byte.
• Use FLOSS as a force multiplier against stack-strings + tight strings.
• Map an HTTP fingerprint to a Suricata/Sigma rule with no PCAP.

Most importantly, it's a moving target. Each build rotates the 32-byte XOR key, the multipart boundary, the C2 list, and sometimes the API resolver. The family fingerprint (the MBA pattern, the GUI subsystem, the WMI/COM init combo, the act=…&ver=4.0&lid= URI shape) is what you build defenses around.

Happy hunting.

Appendix A: files in this analysis

infected/
├── sample/
│   ├── 4d5fd4d96346fb4b09dccb7836ca2dedd339622a6e6063b4dbec1af83cca94f5.zip   (MalwareBazaar drop)
│   ├── 4d5fd4d96346fb4b09dccb7836ca2dedd339622a6e6063b4dbec1af83cca94f5.exe   (extracted)
│   └── lumma.bin                                                              (working copy)
├── analysis/
│   ├── 01_info.txt          # rabin2 -I
│   ├── 02_sections.txt      # rabin2 -S
│   ├── 03_imports.txt       # rabin2 -i
│   ├── 04_strings_ascii.txt # strings -a -n 6
│   ├── 05_strings_unicode.txt
│   ├── 06_floss.txt         # FLOSS full run
│   └── 06_floss_iocs.txt    # filtered IOC strings
├── iocs/
│   ├── hashes.txt
│   ├── c2.txt
│   └── lumma_stealer.yar
└── writeup.md               # this document

Appendix B: references

• abuse.ch MalwareBazaar
• Mandiant FLARE FLOSS
• Detect It Easy
• Ghidra
• Cutter
• HxD
• ImHex
• CyberChef
• YARA
• Synchrony JS deobfuscator
• Chrome ABE writeup (Google)