Coder Legion - Recent posts tagged dfir

Built an Autonomous DFIR Agent SIFT-AEGIS — Here's What I Learned

Tue, 16 Jun 2026 11:14:16 +0000

I just submitted to the SANS Find Evil! Hackathon and wanted to share what I built: SIFT-AEGIS, a fully autonomous Digital Forensics and Incident Response agent that investigates a real criminal case end-to-end without human intervention.
The Problem
DFIR investigations are slow and analyst-dependent. A skilled investigator working the M57-Patents case (real NIST CFReDS corporate espionage scenario) might take hours to correlate memory artifacts, disk evidence, emails, and browser history into a coherent theory. I wanted to know: can an AI agent do this autonomously with the same rigor — and prove it with ground-truth benchmarks?
What I Built
SIFT-AEGIS runs on a SANS SIFT Workstation and connects to a custom Model Context Protocol (MCP) server with 20 read-only forensic tools wrapping Volatility3. The key architectural decision: the write-block is architectural, not prompt-based. The MCP server has zero write/delete/shell tools. The agent physically cannot destroy evidence.
The investigation pipeline:

Iteration 1 — Memory forensics (process list, malfind injection detection, network connections, registry persistence)
Iteration 2 — Disk forensics (MFT timeline, email artifacts, browser history, document staging)
Iteration 3 — Cross-correlation, theory finalization, disconfirmation searches

The Competing Case Theory Engine simultaneously scores three theories — Insider Threat, Authorized Business Research, Accidental Activity — updating confidence as evidence accumulates. Theory evolution: 70% → 99% across iterations.
Honest Benchmark Results
Against the 10-item M57-Patents ground truth:

Disk-Layer Precision: 1.0 (zero false positives)
Disk-Layer Recall: 0.8 (8/10 ground truth items found)
Disk-Layer F1: 0.8889
Hallucination Rate: 0.0
Total tool calls: 33
Self-corrections applied: 45
Runtime: ~6 minutes

I report two scores transparently — disk-layer only and full-finding (which includes memory injection artifacts that have no ground truth entry). Most submissions would hide the lower number. I reported both and documented why.
Biggest Technical Challenges

Volatility3 output noise — raw output has stderr, progress bars, and warnings that corrupted MCP responses. Fixed with a stdio wrapper.
Ground truth scope mismatch — M57 ground truth covers disk only. Memory injection findings (csrss.exe, winlogon.exe) are real artifacts but score as false positives. Solved with dual-score methodology.
Self-correction memoization — early iterations re-ran failing tools repeatedly. Fixed with a persistent failure tracker that marks degraded tools and routes to alternatives.
Autonomous polling — getting the agent to monitor a 6-minute investigation without human prompting required careful tool return message design.

What I'd Do Differently
Start with ground truth benchmarking on day 1, not day 3. The benchmark revealed gaps that shaped the entire architecture — if I'd built it first I'd have made better tool coverage decisions earlier.
Stack
Python, FastMCP, Volatility3, OpenClaw, Gemini API, Google ADK, SIFT Workstation

Links

GitHub: https://github.com/ssurekumar01111-hue/sift-aegis
Demo: https://youtu.be/iaf47TIKkLw
Devpost: https://devpost.com/software/sift-aegis

Built solo in 4 days. Happy to answer questions about the MCP architecture, the self-correction loop, or the benchmarking methodology.

Ursnif Malware — Reconstructing a 6-Stage Infection Chain from a PCAP

Tue, 07 Apr 2026 17:43:08 +0000

date: 2026-03-20
description: A walkthrough of my first real malware PCAP investigation — how Ursnif used .avi file extensions to disguise DLL payloads, TLS C2 beaconing, and how I mapped the full attack to MITRE ATT&CK with Splunk detection rules.

One of the most powerful skills a SOC analyst can develop is the ability to look at a packet capture and reconstruct exactly what an attacker did — step by step, packet by packet.

This write-up walks through my first real PCAP investigation using a controlled Ursnif/Gozi banking trojan dataset from malware-traffic-analysis.net — a site widely used in the security community for analyst training.

Result: 6-stage infection chain reconstructed · 10 IOCs extracted · 5 Splunk detection rules written — from 2,180 packets.

What is Ursnif?

Ursnif (also known as Gozi or ISFB) is one of the oldest banking trojans documented in the wild. Key characteristics:

Delivered via malicious Office document macros
Multi-stage payload delivery using disguised file extensions
Encrypted C2 communication over TLS
Modular credential theft and web injection

Tools Used

Wireshark 4.x — packet analysis
VirusTotal — hash and domain reputation
MITRE ATT&CK Navigator — TTP mapping
Splunk SPL — detection rule development

Step 1 — Getting Bearings

Before any filters, I start with Statistics.

Statistics → Conversations → TCP

External IP	Packets	Role (discovered later)
46.102.153.16	906	Payload server
68.168.123.78	18	C2 server
217.138.205.170	8	Initial C2

Statistics → Protocol Hierarchy:

TCP: 97.9%
TLS: 8.2% — encrypted C2 and payload retrieval

Step 2 — Identifying the Victim

Filter: dhcp

Field	Value
IP Address	10.2.24.101
MAC Address	00:08:02:1c:47:ae

Step 3 — The Full Infection Chain

Stage 1 — Initial Compromise

Consistent with Ursnif's delivery: malicious Excel file with embedded VBA macro. Not captured in PCAP.

MITRE: T1566.001 T1059.005

Stage 2 — First TLS Contact (Packet 10)

Filter: ssl.handshake.type==1

Source:      10.2.24.101
Destination: 217.138.205.170
SNI:         fatturapagamentodi.pw

The SNI field in a TLS Client Hello is plaintext — even without decrypting traffic, we can see exactly which domain the malware contacted.

MITRE: T1071.003 T1573.001

Stage 3 — Payload Download (Packets 218–1116)

Filter: http.request.method == "GET"

906 packets to 46.102.153.16. Files had .avi extensions — but were Ursnif DLL segments reassembled in memory. The .avi extension bypasses firewalls that block .exe and .dll downloads.

MITRE: T1105 T1027

Stage 4 — Secondary Payload (Packets 1299, 1563)

GET /grabb32.rar  →  37.10.71.149
GET /grabb64.rar  →  37.10.71.149

Both 32-bit and 64-bit binaries from a separate server.

Stage 5 — C2 Beaconing (Packets 1215–2167)

Filter: ssl.handshake.type==1

Destination: 68.168.123.78
SNI:         asistenzaonline.xyz
Interval:    ~5–10 minutes

Human browsing is random and bursty. Malware is a clock. The consistent interval between TLS handshakes is machine behavior — your detection signal.

MITRE: T1071.001 T1573.001

Stage 6 — Persistence (Inferred)

Registry injection under HKCU\Software\[random key].

MITRE: T1547.001

Indicators of Compromise

Type	Value	Role
IP	217.138.205.170	Initial C2
IP	46.102.153.16	Payload server
IP	37.10.71.149	Secondary payload
IP	68.168.123.78	Primary C2
Domain	fatturapagamentodi.pw	Stage 2 C2
Domain	asistenzaonline.xyz	Persistent C2
Domain	pizdelko.xyz	Fallback C2
URL	http://46.102.153.16/*.avi	DLL delivery
File	grabb32.rar	32-bit binary
File	grabb64.rar	64-bit binary

MITRE ATT&CK Map

ID	Technique
T1566.001	Phishing: Spearphishing Attachment
T1059.005	Command and Scripting Interpreter: VBA
T1105	Ingress Tool Transfer
T1071.001	Application Layer Protocol: Web Protocols
T1071.003	Application Layer Protocol: Mail Protocols
T1547.001	Boot/Logon Autostart: Registry Run Keys
T1027	Obfuscated Files or Information
T1573.001	Encrypted Channel: Symmetric Cryptography

Detection Rules (Splunk SPL)

Rule 1 — TLS to suspicious SNI

index=network ssl.handshake.type=1
| stats count by src_ip, ssl.handshake.extensions_server_name
| where NOT ssl.handshake.extensions_server_name LIKE "%.google.com"
  AND NOT ssl.handshake.extensions_server_name LIKE "%.microsoft.com"
  AND NOT ssl.handshake.extensions_server_name LIKE "%.cloudflare.com"
| sort -count

Rule 2 — C2 beaconing via TLS regularity

index=network ssl.handshake.type=1
| bucket _time span=10m
| stats count by src_ip, dest_ip, _time
| streamstats window=6 current=t stdev(count) as regularity by src_ip, dest_ip
| where regularity < 1.5

Rule 3 — Media file extension from non-CDN IP

index=network http.request.method=GET
| rex field=uri "(?<ext>\.[a-z0-9]{2,4})$"
| where ext IN (".avi",".mp4",".mp3")
| eval dest_is_cdn=if(match(dest_ip,"^(151\.101|104\.16|172\.67)"),1,0)
| where dest_is_cdn=0
| stats count by src_ip, dest_ip, uri, ext
| where count > 3

Rule 4 — Chunked download from single external IP

index=network http.request.method=GET
| stats dc(uri) as unique_files, count as total_requests by src_ip, dest_ip
| where unique_files > 3
| eval internal=if(match(dest_ip,"^(10\.|192\.168\.)"),1,0)
| where internal=0
| sort -total_requests

Rule 5 — Suspicious archive by name pattern

index=network http.request.method=GET
  (uri="*.rar" OR uri="*.zip")
| where NOT dest_ip LIKE "192.168.%" AND NOT dest_ip LIKE "10.%"
| eval suspicious=if(match(uri,"(grabb|drop|stage|payload|inject)"),1,0)
| where suspicious=1
| stats count by src_ip, dest_ip, uri

Three Key Lessons

1. The .avi trick works because defenders trust file extensions. Fix: inspect file content, not just extension.

2. Beaconing regularity is your strongest behavioral detection signal. Low standard deviation in connection intervals = machine, not human.

3. Multi-stage infrastructure creates more IOCs, not fewer. Four servers = four things to block and hunt for.

Immediate Response Actions

Isolate 10.2.24.101
Block all 4 attacker IPs
Sinkhole 3 C2 domains at DNS
Hunt for .avi GETs from non-CDN IPs in 30 days of proxy logs
Deploy rules 1–5 to SIEM

Full Report on GitHub

github.com/himanshumodi3108/cybersec-portfolio

This analysis was performed on a controlled training dataset from malware-traffic-analysis.net for educational purposes.

Himanshu Kumar Modi · Associate at PwC India · SOC Analyst in Training
LinkedIn · Cybersecurity Portfolio

Emotet + Cobalt Strike — Dissecting a Multi-Stage Attack in Wireshark

Tue, 07 Apr 2026 17:42:27 +0000

description: How I identified Cobalt Strike C2 servers using Host header masquerading detection, found 3 payload domains via time-bounded TLS SNI hunting, and traced a malspam campaign — all from a single PCAP in the TryHackMe Carnage room.
tags: security, dfir, wireshark, tutorial
cover_image:

canonical_url:

The TryHackMe Carnage room presents one of the most realistic attack scenarios available for free — a complete Emotet infection chain followed by Cobalt Strike post-exploitation and a malspam campaign generating 1,439 SMTP packets.

This write-up focuses on three techniques that make the biggest practical difference in real SOC investigations.

Dataset: TryHackMe Carnage room — controlled training environment.

Attack Chain Overview

Zip email → XLS macro → payload from 3 domains
      ↓
Cobalt Strike C2 (Host header spoofed as Verisign)
      ↓
Post-infection C2 → maldivehost.net
      ↓
IP recon → api.ipify.org (17:00:04 UTC)
      ↓
Malspam → 1,439 SMTP packets

Technique 1 — Hex Inspection for Zip Contents

Filter: HTTP response for documents.zip → View → Packet Bytes

Zip central directories are stored at the end of the archive. Checking the hex from the bottom found chart-1530076591.xls immediately — without downloading or executing anything.

The 10-digit epoch timestamp filename is a known Emotet naming pattern. Recognizing this from hex alone is a core analyst skill.

Answer: chart-1530076591.xls

Technique 2 — Time-Bounded TLS SNI Hunting

tls.handshake.type == 1 returned 181 Client Hello packets. Too many to check manually.

Solution: Use the infection timestamp as a filter boundary.

First malicious HTTP: 16:44:38 UTC → narrow TLS filter to 16:45:11–16:45:30 UTC

181 packets → 5 packets. Each SNI checked on VirusTotal:

finejewels.com.au → malicious
thietbiagt.com → malicious
new.americold.com → malicious

The SNI field in TLS Client Hello is plaintext — you see the destination domain without decrypting anything. Time-bounding with the infection timestamp is what makes this technique practical.

MITRE: T1573.001

Technique 3 — Cobalt Strike Host Header Masquerading

Filter: ip.dst == 185.106.96.158 && http

Host: oscp.verisign.com
Actual destination: 185.106.96.158 (Cobalt Strike C2)

The Host header claimed Verisign. The actual IP had nothing to do with Verisign.

Cobalt Strike's malleable C2 profiles allow operators to set any HTTP header to any value — attackers routinely spoof trusted domains (verisign.com, microsoft.com, windowsupdate.com) to blend with enterprise traffic.

Detection: Cross-reference Host domain with actual destination IP. Mismatch where Host is a trusted domain but IP is external and flagged = confirmed masquerading.

MITRE: T1036

Technique 4 — SMTP Forensics

frame contains "MAIL FROM"

Lesson: smtp contains "FROM" returned wrong results. Always search for the complete field name.

1,439 SMTP packets from an internal host = machine enrolled in Emotet malspam botnet. The infected machine was sending phishing emails on the attacker's behalf.

MITRE: T1071.003

Cobalt Strike Identification — Full Workflow

Filter http.request.method == "GET" → Statistics → Conversations → TCP → sort by frequency
Note top recurring external IPs
Check each on VirusTotal → Community tab (not just detection — community notes confirm Cobalt Strike)
Cross-reference Host header with actual destination IP for masquerading

C2 servers: 185.106.96.158 (survmeter.live), 185.125.204.174 (securitybusinpuff.com)

IOC Table

Type	Value	Role
Domain	attirenepal.com	Initial zip
File	documents.zip → chart-1530076591.xls	Macro payload
Domain	finejewels.com.au	Secondary payload
Domain	thietbiagt.com	Secondary payload
Domain	new.americold.com	Secondary payload
IP	185.106.96.158	Cobalt Strike C2
IP	185.125.204.174	Cobalt Strike C2
Domain	maldivehost.net	Post-infection C2
Email	farshin@mailfa.com	Malspam sender

MITRE ATT&CK

ID	Technique
T1566.001	Phishing: Spearphishing Attachment
T1059.005	VBA Macro
T1105	Ingress Tool Transfer
T1071.001	Web Protocols
T1573.001	Encrypted Channel
T1036	Masquerading
T1016	System Network Config Discovery
T1583	Acquire Infrastructure
T1071.003	Mail Protocols

Detection Rules (Splunk SPL)

Rule 1 — Cobalt Strike Host Header Masquerading

index=network http.request.method=GET
| where http.host LIKE "%.verisign.com"
    OR http.host LIKE "%.microsoft.com"
    OR http.host LIKE "%.windowsupdate.com"
| eval dest_internal=if(match(dest_ip,"^(10\.|192\.168\.)"),1,0)
| where dest_internal=0
| stats count by src_ip, dest_ip, http.host

Rule 2 — TLS to Suspicious TLD

index=network ssl.handshake.type=1
| eval tld=mvindex(split(ssl.handshake.extensions_server_name,"."), -1)
| where tld IN ("live","xyz","top","pw","online","site","club","icu")
| stats count by src_ip, ssl.handshake.extensions_server_name
| sort -count

Rule 3 — Internal Malspam Detection

index=network sourcetype=stream:smtp
| stats count as smtp_count by src_ip
| where smtp_count > 50
| join src_ip [search index=network http.request.method=POST
    | stats count by src_ip]
| table src_ip, smtp_count, count

Three Key Takeaways

Time-bound your TLS filters. The infection timestamp reduces 181 packets to 5. Always know your starting timestamp before filtering TLS.

Cobalt Strike hides in the Host header. Cross-referencing the Host domain with the actual destination IP catches it every time — no threat intel feed required.

1,439 SMTP packets means you're already losing. The machine is sending phishing on behalf of the attacker. Detecting this early is why malspam volume thresholds matter in SIEM rules.

Full Report on GitHub

github.com/himanshumodi3108/cybersec-portfolio

TryHackMe Carnage room — controlled training environment.

Himanshu Kumar Modi · Associate at PwC India · SOC Analyst in Training
LinkedIn · Cybersecurity Portfolio