REV: RedLine Stealer — Static & Dynamic Analysis
Overview
This post walks through a complete static and dynamic analysis of a real-world malware sample pulled from MalwareBazaar — cataloged under the signature Backdoor.TeamViewer, carrying the file name WEXTRACT.EXE .MUI, and flagged on VirusTotal as RedLine Stealer (Trojan). The workflow covers isolated lab setup, sample acquisition and hashing, PE structure and metadata dissection across nine static tools, sandbox detonation, and live runtime monitoring.
All analysis was performed inside an isolated Windows 10 x64 VM (VMware Workstation, NAT networking) with no host exposure. The sample is a known public malware artifact sourced from the MalwareBazaar database.
Phase 1: Lab Environment Setup
An isolated Windows 10 x64 virtual machine was built in VMware Workstation Pro using the official Microsoft developer VM images, with the network adapter set to NAT so the guest could reach the internet for lookups (VirusTotal, MalwareBazaar) without exposing the host to the sample’s traffic.
.NET Desktop Runtime 9.0.4 (x64) installer — a VM dependency required by several of the analysis tools used later
VMware network adapter configured to NAT — the VM shares the host’s IP rather than bridging directly onto the network
Windows 10 x64 analysis VM — HashCalc and PEiD shortcuts staged on the desktop alongside the standard toolset
Phase 2: Sample Acquisition & Hashing
The sample was pulled from MalwareBazaar under the Backdoor.TeamViewer signature.
MalwareBazaar entry — signature “Backdoor.TeamViewer”, 14 vendor detections, file size 1,917,440 bytes, first seen 2023-10-10. The imphash (646167cce332c1c252cdcb1839e0cf48) is shared with 8,467 other RedLine Stealer samples, 4,786 Amadey samples, and 290 Smoke Loader samples — strong evidence of a common builder/loader lineage
Hashes were computed twice, with a GUI tool and a CLI tool, to cross-verify:
HashCalc — MD5, SHA1, SHA256, RIPEMD160, and CRC32 computed locally, confirming the published hash set
md5deep64 / sha1deep64 / sha256deep64 run against the sample — output matches the hashes published on MalwareBazaar
Sample hashes:
| Algorithm | Hash |
|---|---|
| SHA256 | 248fcc901aff4e4b4c48c91e4d78a939bf681c9a1bc24addc3551b32768f907b |
| SHA1 | 7ccfb7678c34d6a2bedc040da04e2b5201be453b |
| MD5 | 18cbe55c3b28754916f1cbf4dfc95cf9 |
Phase 3: Static Analysis
VirusTotal
57 / 71 vendors flag the file as malicious. Popular threat label: trojan.crfl/redline. Family labels: crfl, redline, stealer. Behavioral tags: checks-disk-space, checks-user-input, spreader, executes-dropped-file, detect-debug-environment, persistence, long-sleeps
Grouped sandbox reports (CAPE, VMRay, VirusTotal Jujubox, Zenbox, Dr.Web vxCube, Sangfor ZSand and others) roll up to 5 detections, MITRE ATT&CK signatures, IDS/Sigma rule hits, ~80 dropped files, and network activity spanning 62 HTTP requests, 13 DNS requests, and 165 contacted IPs
Malware family: RedLine Stealer — a commodity infostealer that targets browser-stored credentials/cookies, cryptocurrency wallets, and applications such as FileZilla, Discord, Steam, Telegram, and VPN clients.
Strings Extraction
1
strings -u WEXTRACT.EXE > strings_output.txt
Sysinternals Strings v2.54 — kernel32.dll plus a run of Cabinet-SDK-style tokens (ADMQCMD, EXTRACTOPT, FILESIZES, PACKINSTSPACE, RUNPROGRAM, SHOWWINDOW, USRQCMD) and license/prompt text
BinText 3.0.3 — the VERSIONINFO block resolves cleanly: CompanyName “Microsoft Corporation”, FileDescription “Win32 Cabinet Self-Extractor”, OriginalFilename “WEXTRACT.EXE .MUI”, ProductName “Internet Explorer”. That last field is a mismatch worth flagging — a cabinet self-extractor reporting itself as part of Internet Explorer
PEiD
PEiD v0.95 — Entry Point 00006A60 (.text), File Offset 00005E60, First Bytes E8,F0,06,00, Linker 14.13, Subsystem Win32 GUI. Main scan: “Nothing found”. Entropy: 6.19 (Not Packed). EP Check: Not Packed. Fast Check: Packed — the four indicators don’t agree with each other
The conflict between “nothing found” and a positive fast-check hit is typical of PEiD against anything newer than its signature database — it means “inconclusive,” not “clean.”
LordPE
LordPE Deluxe — full PE header dump
| Field | Value | Meaning |
|---|---|---|
| EntryPoint | 00006A60 | RVA where execution starts |
| ImageBase | 00400000 | Preferred load address |
| SizeOfImage | 001D9000 | Total in-memory image size |
| NumberOfSections | 0005 | Five PE sections |
| TimeDateStamp | 628D60E2 | Compiles to 2022-05-24 22:49:06 UTC |
| Subsystem | 0002 | Windows GUI application |
PEview
IMAGE_DOS_HEADER — MZ signature (0x5A4D), offset to the PE header at 0x000000E0
IMAGE_FILE_HEADER — Machine: IMAGE_FILE_MACHINE_I386, 5 sections, timestamp 2022/05/24 22:49:06 UTC, Characteristics 0102 (IMAGE_FILE_EXECUTABLE_IMAGE | IMAGE_FILE_32BIT_MACHINE)
Dependency Walker
Imports from ADVAPI32.DLL, KERNEL32.DLL, GDI32.DLL, USER32.DLL, MSVCRT.DLL, CABINET.DLL, and VERSION.DLL, plus several unresolved delay-load dependencies. The CABINET.DLL import lines up with the “Win32 Cabinet Self-Extractor” identity seen in the version resource
| DLL | Legitimate Use | Malware-relevant Abuse |
|---|---|---|
ADVAPI32.DLL | Registry, services, security | Persistence via Run keys, privilege escalation, credential access |
KERNEL32.DLL | Processes, files, memory | Code injection, payload execution, anti-debugging |
CABINET.DLL | Cabinet (.cab) extraction | Unpacks and drops the embedded payload at runtime |
MSVCRT.DLL | C runtime functions | Keeps the custom-compiled payload running correctly |
VERSION.DLL | File/OS version checks | Fingerprints the target environment |
Resource Hacker
Version Info resource — CompanyName “Microsoft Corporation”, FileDescription “Win32 Cabinet Self-Extractor”, FileVersion 11.00.17763.1, InternalName “Wextract”, OriginalFilename “WEXTRACT.EXE .MUI”
Dialog 2002 — a genuine “Temporary folder” extraction prompt with Browse/OK/Cancel controls. This is the real UI of Windows’ own wextract.exe cabinet self-extractor, not a custom-built decoy dialog
Detect It Easy (DiE)
DiE v3.10 — PE32, 1.83 MiB, Entry point 00406A60, 5 sections. Linker: Microsoft Linker 14.13.26213. Compiler: Microsoft Visual C/C++ 19.13.26213 (Visual Studio 2017 v15.6). Heuristic packer flag: “Compressed or packed data [High entropy + Section 3 (‘.rsrc’) compressed]”. Identified as a Microsoft Cabinet SFX (v11.00.17763.1) archiving 2 files at 94.7% compression
DiE’s SFX/CAB identification, combined with the CABINET.DLL import and the real “Temporary folder” dialog above, confirms this binary is a genuine, unmodified wextract.exe — Windows’ own self-extracting cabinet utility — repurposed to carry and drop an embedded payload rather than being a custom packer.
PEstudio
PEstudio 9.61 — entry-point 0x00006A60 (section .idata), entropy 7.976, file signature “Microsoft Linker 14.13”, VirusTotal score 57/71 pulled inline, debug file wextract.pdb, version original-file-name = “WEXTRACT.EXE .MUI”
PEstudio’s entropy reading (7.976) is noticeably higher than PEiD’s (6.19) — the two tools scope their entropy calculation differently (whole file vs. specific regions), but both point the same direction: parts of this binary are compressed/obfuscated, consistent with the embedded CAB payload.
ExifTool
ExifTool v13.27 — File OS: Windows NT, Entry Point 0x6a60, Subsystem: Windows GUI, Company Name: Microsoft Corporation, File Description: “Win32 Cabinet Self-Extractor”, Original File Name: “WEXTRACT.EXE .MUI”, PDB File Name: wextract.pdb
Key finding: the PDB path, version resource, and imports are all internally consistent with the real Microsoft wextract.exe — this isn’t spoofed metadata bolted onto a custom dropper, it’s a legitimate signed-looking Windows component being used as a carrier for a malicious payload extracted at runtime.
Phase 4: Dynamic Analysis
AnyRun Sandbox
The sample was detonated in AnyRun for automated behavioral analysis.
Process tree: explorer.exe → 248fcc90...907b.exe → Yt8gc85.exe → GY4IC43.exe → hE8Zq97.exe → 1Zn59od7.exe → AppLaunch.exe / WerFault.exe, with a sibling 2PO9885.exe. Network panel shows 4 HTTP requests, 79 connections, and 76 DNS requests, including outbound traffic to Microsoft-owned ASNs and an Akamai-hosted crl.microsoft... endpoint — legitimate-looking infrastructure used as cover traffic
The sandboxed browser navigates to facebook.com/login (“Log Into Facebook”) during the run — consistent with a stealer probing for saved browser credentials/session data
A second tab opens accounts.google.com (“Sign in - Google Accounts”) in the same session — the same credential/session-harvesting pattern targeting a second major account provider
AnyRun’s activity classification: MALICIOUS — execution of an untrusted-certificate binary (5uR3IF9.exe), code injection by AppLaunch.exe, and explorer.exe itself receiving injected code. SUSPICIOUS — legitimate Windows executables dropped/overwritten, a Microsoft-named app launched from a non-standard path, child processes that crash on execution, commands run from a .bat file via CMD.EXE, and a connection to an unusual port. INFO — language/locale checks, temp-directory file creation, computer-name and machine-GUID registry reads
Process Monitor (ProcMon)
ProcMon capturing the sample’s thread lifecycle, large IRP_MJ_READ operations against C:\Windows\System32\wow64win.dll, and a run of RegQueryKey/RegOpenKey calls against HKLM/HKCU, including HKCU\Software\Microsoft\CTF\DirectSwitchHook — CTF (input/IME) key access is a pattern often seen around process-injection setup on Windows
Process Explorer
The running sample (PID 7032) reports 5,080 K private bytes / 12,792 K working set, described as “Win32 Cabinet Self-Extractor” by “Microsoft Corporation” — but the Verified Signer column reads “(No signature was present in the subject) Microsoft Corporation”. The binary claims a Microsoft identity through its version resource while carrying no actual Authenticode signature — a reliable static-vs-runtime tell that Process Explorer surfaces directly
RegShot — Registry & File System Comparison
A before/after snapshot across C:\WINDOWS and C:\Users\r3 was taken to capture every persistence and file-system change made during execution.
RegShot 1.9.0 x64 — scan directories set to C:\WINDOWS;C:\Users\r3, output path C:\Users\r3\Desktop, ready to take the first and second shots around detonation
9 keys added, all under HKU\...\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags / BagMRU / Shell — including a new GUID-named subkey {80213E82-BCFD-4C4F-8817-BB27601267A9}
44 values added — Explorer RecentDocs MRU entries and a full set of Shell Bags view-state values (MRUListEx, IconSize, LogicalViewMode, Sort, GroupByKey:FMTID/PID) tied to the new Bags key
32 values modified, notably HKLM\SYSTEM\ControlSet001\Services\bam\State\UserSettings\... entries referencing Program Files\Google\Chrome\Application\chrome.exe — Background Activity Moderator tracking data for Chrome, despite Chrome never appearing in the sample’s own process tree
5 files modified: two Chrome prefetch files (CHROME.EXE-5A1054B0.pf, CHROME.EXE-5A1054B7.pf), SEARCHAPP.EXE-C8E48E53.pf, and both NTUSER.DAT.LOG transaction logs under the NetworkService profile. Total changes: 90
The Chrome-related BAM and prefetch touches, paired with the AnyRun evidence of the sample opening Facebook/Google login pages, line up with RedLine Stealer’s known focus on harvesting browser-stored credentials — the malware is interacting with Chrome’s on-disk artifacts without ever spawning chrome.exe itself as a visible child process.
Phase 5: Behavioral Summary
| Category | Observed Behavior |
|---|---|
| Network | 79 connections / 76 DNS requests in AnyRun; traffic blended with legitimate Microsoft/Akamai-hosted endpoints |
| Persistence | 9 new Shell Bags registry keys, 44 new values under HKCU\...\Shell\Bags; BAM service-tracking entries touched |
| Process | Multi-stage child process chain (Yt8gc85.exe → GY4IC43.exe → hE8Zq97.exe → 1Zn59od7.exe); code injected into explorer.exe and by AppLaunch.exe |
| File System | Files dropped/overwritten under legitimate Windows paths; Chrome and SearchApp prefetch files modified; 90 total registry/file changes recorded by RegShot |
| Data Theft | Browser navigation to Facebook and Google account pages; family known to target browser credentials, crypto wallets, FileZilla, Discord, Telegram, and VPN clients |
| Evasion | Genuine (unsigned-in-practice) wextract.exe carrier abused as a dropper; conflicting packer signals across PEiD/DiE/PEstudio; unsigned binary reported as Microsoft Corporation |
Phase 6: Conclusions & Takeaways
What this sample does:
- Uses a real Windows cabinet self-extractor (
wextract.exe) as a carrier to drop and execute a multi-stage payload chain - Injects code into
explorer.exeand spawns a sequence of short-lived child processes - Opens Facebook and Google account pages in the sandboxed browser, consistent with credential/session harvesting
- Touches Chrome’s prefetch and BAM service-tracking data despite never spawning
chrome.exedirectly - Writes 9 new registry keys and 44 new values for Shell Bags-based persistence/state tracking
Lessons from the toolchain:
- No single static tool is authoritative. PEiD’s own four checks disagreed with each other (Not Packed / Packed) on the same file; entropy alone ranged from 6.19 (PEiD) to 7.976 (PEstudio) depending on scope.
- “Legitimate” metadata isn’t proof of legitimacy. The PDB path, version resource, and imports all point to a genuine
wextract.exe— but Process Explorer shows it carries no real digital signature, and it’s being used to smuggle a payload. - Dynamic analysis resolves what static analysis leaves ambiguous. AnyRun’s process tree and RegShot’s before/after diff turned a “maybe packed, maybe not” static picture into a concrete, multi-stage injection and persistence chain.
- Cross-referencing artifacts matters. The imphash on MalwareBazaar linking this sample to thousands of other RedLine/Amadey/Smoke Loader binaries was as useful for family attribution as any single tool’s verdict.
References: