RedLab

Exploit Development & Malware Analysis Sandbox

RedLab is an isolated offensive security lab that I built to study classic exploitation primitives and to walk live malware samples through a reproducible static + dynamic analysis pipeline. It captures the artefacts of that work: vulnerable C targets, PoC exploits in Python, malware writeups, and the MITRE ATT&CK mapping that ties everything together.

Everything in this repository is intended for controlled, isolated lab use only. The vulnerable binaries are deliberately built without protections; the exploits are tuned for local addresses on a snapshot VM. Do not deploy any of it in production.

---

What's inside

RedLab/
  lab_setup.md            # VMware/VirtualBox topology, VM hardening, OPSEC
  attack_chain.md         # Aggregated MITRE ATT&CK matrix across all artefacts
  vulns/
    stack_overflow.c      # Linux x86 stack BOF target
    seh_overwrite.c       # Windows x86 SEH-overwrite target
    format_string.c       # Linux x86 format-string target (read + write)
    Makefile              # Builds with -fno-stack-protector -no-pie etc.
  exploits/
    exploit_bof.py        # ret2win / shellcode / ROP variants
    exploit_seh.py        # SEH-overwrite + POP POP RET + short-jmp
    exploit_fmt.py        # %p leak chain and %hhn 4-byte write
    shellcode.md          # Shellcode reference + msfvenom recipes
  analysis/
    sample1_writeup.md    # WannaCry-style worm: triage -> dynamic -> ATT&CK
    sample2_writeup.md    # Synthetic in-lab dropper: WININET -> RWX -> stage2

---

Why I built this

The job description I was preparing for asked specifically for "developing basic payloads, scripts, and proof-of-concept exploits for testing environments" and "analyzing malware samples and understanding attack behavior using reverse engineering tools." Reading about those topics is one thing - sitting in front of a debugger and watching EIP land on a NOP sled, or watching a packet leave a sandboxed VM toward a listener you set up two windows over, is what actually builds intuition.

So I rebuilt the foundational primitives from scratch, snapshot-by- snapshot, and wrote down what I saw. Each exploit script is short on purpose: I wanted the reasoning visible, not buried under abstraction.

---

Quick start - exploits

# Linux exploitation host
cd vulns
make linux                        # stack_overflow, format_string

# Disable ASLR for the session
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

# Find win() address from the binary banner, then:
python3 ../exploits/exploit_bof.py \
    --binary ./stack_overflow \
    --mode ret2win --win 0x080491D6 --launch

# Format-string write primitive
python3 ../exploits/exploit_fmt.py \
    --mode write --offset 7 \
    --target-addr 0x0804C034 --win 0x080491D6 --launch

# Windows SEH-overwrite (Win7 lab VM, target built without SafeSEH)
python exploit_seh.py --offset 256 --gadget 0x1001abcd --shellcode calc --launch

---

Quick start - malware analysis

The two writeups in analysis/ follow the same structure: triage -> static -> dynamic -> IOCs -> ATT&CK -> remediation. They double as a checklist when you sit down with a new sample.

The sample1 writeup is keyed to a known-public WannaCry hash so the techniques can be reproduced against any educational corpus. The sample2 writeup uses a synthetic in-lab dropper so the loader pipeline (InternetReadFile -> VirtualAlloc(RWX) -> indirect CALL) is visible end-to-end without ever touching a live in-the-wild binary.

---

Tooling

Job	Tool
Static analysis	Ghidra 11, Radare2 / Cutter, IDA Free
Dynamic analysis (Win)	x64dbg, Immunity Debugger 1.85 + mona.py
Dynamic analysis (Linux)	GDB + pwndbg, ltrace / strace
Behaviour capture	ProcMon, Sysmon, Wireshark
Payload generation	msfvenom (Metasploit), pwntools
Network sandbox	INetSim, FakeNet-NG

The detailed VM layout, IPs, and per-VM tooling lives in lab_setup.md.

---

OPSEC stance

• Lab network is host-only / internal; NAT is off by default.
• Live samples are handled in a snapshot VM and reverted immediately.
• C2 infrastructure mentioned in writeups is sinkholed or simulated.
• Hashes are recorded for traceability, but writeups redact partial hashes when republishing might assist a real-world attacker.
• Reverse-shell payloads in exploits/ use LHOST=192.168.56.10 - the lab attacker - and exit cleanly. They are not designed to evade AV; AV evasion is out of scope for this lab.

---

Roadmap

• Heap exploitation primitives (tcache poisoning, fastbin dup)
• Win10 mitigations baseline (CFG, ACG) and bypass survey
• One Linux LPE chain (kernel exploit, e.g. Dirty Pipe analogue)
• FlareOn 2024 sample writeups using the same template

---

License

MIT - see ../VulnHawk/LICENSE (same author, same terms).

Author

Built by Om Pandey - B.Tech (Data Science & AI), IIIT Dharwad. GitHub - LinkedIn