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

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

Statistics → Protocol Hierarchy:

• TCP: 97.9%


• TLS: 8.2% — encrypted C2 and payload retrieval

Step 2 — Identifying the Victim

Filter: dhcp

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

MITRE ATT&CK Map

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

1. Isolate 10.2.24.101


2. Block all 4 attacker IPs


3. Sinkhole 3 C2 domains at DNS


4. Hunt for .avi GETs from non-CDN IPs in 30 days of proxy logs


5. 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