Overview
This lab has two parts. The first documents the build of a custom Wireshark analyst profile — a purpose-built configuration that makes the triage workflow from Lab Log 003 executable in one click rather than by memory. The second is an independent malware analysis: a fresh pcap from malware-traffic-analysis.net (2026-01-31), analyzed independently using the profile and workflow built across the previous labs.
The exercise — "Lumma in the Room-ah" — introduced a different malware family than Lab Log 003. Where Easy As 123 used simple unencrypted HTTP beaconing, Lumma Stealer used a more sophisticated pattern: HTTP for reconnaissance and registration, TLS for actual credential exfiltration. Recognizing that difference without being told what to look for is the skill this lab validates.
Part 1 — Building the SOC Analyst Profile
Wireshark's default configuration is designed for general network troubleshooting, not security triage. The default columns show information useful for engineers debugging connectivity — not analysts hunting malware. The SOC Analyst profile reconfigures Wireshark from the ground up: optimized columns, color-coded protocol identification, and one-click filter buttons that execute the full triage workflow without typing.
Profile Creation
A named profile in Wireshark stores all display settings, color rules, columns, and filter buttons independently from the default configuration. Switching profiles with one click gives a completely different view of the same pcap — the same traffic, different lens.
Edit → Configuration Profiles → + (new profile) Name: SOC Analyst All color rules, columns, and filter buttons configured below are saved to this profile only — default is untouched.
Column Layout
The default Wireshark columns include Length — rarely useful for security triage. The SOC Analyst layout replaces it with source and destination port columns, making protocol identification instant. The critical addition is the Delta column — the single most useful column for detecting beaconing behavior.
| Column Title | Type | Why It Matters |
|---|---|---|
| No. | Number | Packet reference number for cross-referencing findings |
| Time | Relative time | Seconds since capture start — consistent across all pcaps |
| Src IP | Source address | Where the packet came from |
| Dst IP | Dest address | Where the packet is going — external IPs stand out immediately |
| Src Port | Src port (unresolved) | Raw number faster to scan than service name |
| Dst Port | Dest port (unresolved) | Port 80=HTTP, 443=TLS, 445=SMB, 88=Kerberos — instant protocol ID |
| Protocol | Protocol | Wireshark's protocol identification |
| Delta | Delta time displayed | Time since previous displayed packet — repeating values = beaconing |
| Info | Information | Packet summary — GET/POST paths, flags, domain names |
Color Rules
Color rules apply top to bottom — the first matching rule wins. Order is critical. C2 Beacon and HTTP External must sit above the generic HTTP rule or all HTTP matches the generic rule first and the specific ones never fire.
| Rule Name | Filter | Color / Purpose |
|---|---|---|
| C2 Beacon | http.request.method == "POST" and !(http.host contains "microsoft") | Red — highest priority. POST to non-Microsoft = investigate immediately |
| HTTP External | http.request and !(http.host contains "microsoft") and !(http.host contains "windowsupdate") and !(http.host contains "msocsp") | Dark orange — non-Microsoft HTTP requests |
| HTTP Unencrypted | http | Orange — all HTTP including Windows noise |
| DNS Query | dns | Light blue — domain lookups |
| Kerberos | kerberos | Purple — authentication packets containing usernames |
| DHCP | dhcp | Green — machine identity packets |
| SMB | smb or smb2 | Yellow — Windows file sharing, confirms domain environment |
Filter Buttons — One-Click Triage Workflow
Filter buttons are saved to the profile and appear as a persistent toolbar below the filter bar. Each button includes a comment — visible on hover as a tooltip — explaining what the filter finds and what to look for in the results. The buttons are ordered to match the triage sequence: machine identity → user identity → DNS → HTTP → exfiltration detection.
| Button Label | Filter Expression | Tooltip Comment |
|---|---|---|
| DHCP | dhcp | Step 1 — Find MAC address, hostname, and IP. Click Request packet (source 0.0.0.0) |
| Kerberos | kerberos | Step 2 — Find username. Look for AS-REQ, expand req-body → cname → CNameString |
| NBNS | nbns | Windows NetBIOS hostname. Alternative to DHCP on older or unmanaged Windows machines |
| mDNS | mdns | Mac and Linux hostname discovery. Use instead of Kerberos on non-domain machines |
| DNS | dns | Works on any OS. What domains is this machine resolving? Unusual domains = red flag |
| HTTP — All | http | All unencrypted HTTP. Rare in 2026 — any plain HTTP to external hosts warrants investigation |
| HTTP — External | http.request and !(http.host contains "microsoft") and !(http.host contains "windowsupdate") and !(http.host contains "msocsp") | HTTP with Windows noise removed. What remains has no automatic legitimate explanation |
| C2 POST | http.request.method == "POST" and !(http.host contains "microsoft") | POST to non-Microsoft hosts. Data being sent outbound — exfiltration or C2 beacon check-in |
| TLS | tls | Encrypted traffic. Check SNI in Client Hello for destination domain — visible even in TLS |
| Beaconing | ip.dst == 0.0.0.0 | Replace 0.0.0.0 with suspicious IP. Check Delta column for repeating intervals. Use I/O Graph to visualize |
On dynamic IP filtering: Wireshark filter buttons are static — they cannot accept variable input. The Beaconing button uses ip.dst == 0.0.0.0 as a placeholder. In practice, after finding a suspicious IP via HTTP External, the analyst edits the IP directly in the filter bar. Tools like Zeek, Suricata, and SIEM platforms handle automated dynamic detection — Wireshark is the right tool for manual forensic investigation of a specific pcap.
Part 2 — Independent Analysis: Lumma Stealer
With the SOC Analyst profile configured, the January 31, 2026 exercise pcap was analyzed independently — no guided steps, no hints. The workflow from Lab Log 003 was applied in sequence using the filter buttons. What follows is the complete analysis as it unfolded.
Step 1 — Host Identification via DHCP
The DHCP button returned 4 packets. The Request packet (source 0.0.0.0) contained all three machine identifiers in the options fields. The green color rule made the DHCP packets immediately visible in the full packet list before any filter was applied.
DHCP Request (source: 0.0.0.0 → 255.255.255.255) Client MAC address: 00:21:5d:c8:0e:f2 Option (50) Requested IP Address: 10.1.21.58 Option (12) Host Name: DESKTOP-ES9F3ML
Step 2 — User Identification via Kerberos
The Kerberos button returned 16 packets. The purple color rule made them visible in the list. Expanding an AS-REQ packet and navigating to req-body → cname → CNameString returned the username. The realm field confirmed the Active Directory domain.
AS-REQ — note: KRB5KDC_ERR_PREAUTH_REQUIRED also present This error is normal — Windows always requests pre-auth before issuing a ticket. Not a red flag. CNameString: gwyatt realm: WIN11OFFICE.COM
Confirmed Host Identity
Malware Behavior — Lumma Stealer
Initial Detection — TLS Spike in I/O Graph
Before applying any filters, the TLS color rule flagged a large volume of encrypted traffic in the packet list. Opening Statistics → I/O Graph and filtering to TLS traffic revealed a pronounced spike — a burst of encrypted connections concentrated in a short window. This was the first indicator that something beyond normal background activity was present.
How the profile helped: The TLS color rule turned the suspicious packets visible in the raw packet list before any filter was applied. Without the color rule, TLS packets are indistinguishable from normal background traffic at a glance. The color rule made the spike obvious — the analyst's eye was drawn to it immediately.
HTTP External — C2 Registration
The HTTP External button returned 6 packets — 4 GET requests and 2 POST requests, all to the same external IP: 153.92.1.49 over port 80. This IP was referenced in the exercise scenario as the suspicious destination, confirming the infected host was identified correctly.
All 6 requests → 153.92.1.49:80 GET /api/set_agent?id=3BF67EC05320C5729578BE4C0ADF174C&token=842e...&agent=Chrome GET /favicon.ico ← connectivity check GET /api/set_agent?id=3BF67EC05320C5729578BE4C0ADF174C&token=842e...&agent=Edge GET /favicon.ico ← connectivity check POST /api/set_agent?id=3BF67EC05320C5729578BE4C0ADF174C&token=842e...&act=log POST /api/set_agent?id=3BF67EC05320C5729578BE4C0ADF174C&token=842e...&act=log Key observation: two separate set_agent registrations → agent=Chrome (first browser profile) → agent=Edge (second browser profile) Lumma infected both browsers independently.
POST Payload — Browser Fingerprint Exfiltration
Both POST packets contained identical structure: a comprehensive browser fingerprint sent to the C2 server. This was reconnaissance, not credential theft. Lumma profiled gwyatt's machine before proceeding to the exfiltration phase.
| Field Exfiltrated | Value Observed | Intelligence Value to Attacker |
|---|---|---|
| Platform / OS | Win32 · Windows NT 10.0 | Confirms Windows target, rules out VM detection evasion |
| Browser (POST 1) | Chrome 144.0.0.0 | Identifies which credential store to target |
| Browser (POST 2) | Edge 144.0.0.0 | Second credential store — separate cookie and password database |
| GPU / WebGL | AMD Radeon R9 200 (Chrome) · Microsoft Basic Render (Edge) | Hardware fingerprint — uniquely identifies this machine even if IP changes |
| Canvas fingerprint | Base64 PNG rendering | GPU-specific rendering signature — machine re-identification across sessions |
| Screen | 1920×1080 · 24-bit color | Additional fingerprint layer |
| Hardware | 12-core CPU | Confirms real machine — sandbox environments typically show 1-2 cores |
| webdriver | false | Sandbox check — confirms this is a real user machine, not automated analysis. Triggers exfiltration phase. |
The webdriver check is the trigger: "webdriver":false confirms the browser is not being controlled by automated testing software. Malware analysis sandboxes often use Selenium or similar tools which set webdriver=true. Lumma checked for this before proceeding — false means real user, real credentials worth stealing. This check passing is what activated the TLS exfiltration phase.
TLS Exfiltration — Credential Theft Over Encrypted Channel
Following the HTTP fingerprinting phase, Lumma switched to TLS for the actual credential exfiltration. Filtering to ip.dst == 153.92.1.49 showed TLS connections to the same C2 IP on port 443, with multiple Application Data packets — the encrypted stolen data being transmitted.
The TLS Client Hello packets revealed an additional C2 domain via the SNI field: whitepepper.su. The SNI field in a TLS handshake is not encrypted — it must be sent in plaintext so the server knows which certificate to present. This means even TLS traffic reveals the destination domain to any analyst capturing at the network level.
Packet 25410 — TLS Client Hello Transport Layer Security → Handshake Protocol → Extension: server_name → Server Name: whitepepper.su Why .su is a red flag: .su = Soviet Union ccTLD — a country that ceased to exist in 1991. The domain extension remains active and is almost exclusively used by Russian cybercriminal infrastructure because .su domains are difficult to take down through normal legal channels. Legitimate businesses do not use .su domains.
Easy As 123 vs Lumma Stealer — Comparing Attack Patterns
Having now analyzed two different malware families, the contrast in technique is instructive. The same triage workflow identified both infections — but the behavior patterns, and what they reveal to the defender, are meaningfully different.
C2 channel: Plain HTTP — fully readable
Pattern: 264 POST requests at 60-second intervals — classic beaconing
Payload: CMD=POLL check-ins — waiting for commands
Detection: Immediately obvious in I/O Graph — regular spikes across 4.3 hours
Sophistication: Low — no encryption, no sandbox detection, no fingerprinting
Stage: Post-infection persistence — malware is installed and waiting
C2 channel: HTTP for recon, TLS for exfiltration — partially hidden
Pattern: 6 HTTP requests then TLS burst — act fast, get out
Payload: Full browser fingerprint + encrypted credential exfiltration
Detection: TLS spike visible in I/O Graph, SNI reveals domain in Client Hello
Sophistication: Medium — sandbox detection, dual-browser targeting, canvas fingerprinting
Stage: Active theft — by the time pcap is captured, credentials are already gone
Critical difference in response urgency: Easy As 123 was a persistent beacon waiting for instructions — isolating the machine stops the threat. Lumma Stealer had already acted. By the time this pcap was analyzed, gwyatt's Chrome and Edge credentials, cookies, and saved passwords were in the attacker's hands. The correct response is not just machine isolation — it is immediate credential rotation for every service gwyatt was logged into on both browsers.
Findings
Host DESKTOP-ES9F3ML (10.1.21.58, user: gwyatt) was infected with Lumma Stealer. The malware registered gwyatt's machine as a new agent with C2 server 153.92.1.49, profiled both Chrome and Edge browser environments, confirmed the machine was not a sandbox, and proceeded to exfiltrate credentials over encrypted TLS connections.
Immediate action required: Isolate the machine. Rotate all credentials for every service gwyatt accessed through Chrome or Edge — email, VPN, corporate systems, banking, any saved passwords. Assume all session cookies are compromised — active sessions on every logged-in service should be terminated.
Lumma registered as both a Chrome agent and an Edge agent independently. Chrome and Edge maintain separate credential databases, cookie stores, and saved password vaults. Both are compromised. Any credentials stored exclusively in Edge and not Chrome — or vice versa — are still stolen. The scope of compromised credentials is the union of both browser stores, not just one.
TLS Client Hello packets revealed connections to whitepepper.su — a Soviet Union ccTLD domain. The .su namespace is associated almost exclusively with Russian cybercriminal infrastructure. This attribution is not definitive but provides threat intelligence context: Lumma Stealer is a known commodity malware sold on Russian-language cybercriminal forums. The C2 infrastructure is consistent with that attribution.
NIST SP 800-171 Control Mapping
Lessons Learned
The Profile Works — Color Rules Are the Analyst's First Line of Detection
In the Lumma exercise, the TLS color rule drew attention to the suspicious traffic before any filter was applied. The color rules are not decoration — they are an active detection layer. Opening a new pcap with the SOC Analyst profile active means the first visual scan of the packet list already highlights anomalies. The profile turns passive observation into active detection.
SNI Is the Key to Reading TLS Traffic
TLS encrypts the content of traffic but not the destination hostname. The SNI field in every TLS Client Hello reveals exactly which domain is being contacted — visible to any analyst with network capture access. whitepepper.su was immediately identifiable as suspicious because of the domain extension alone. Learning to read SNI fields in TLS packets is what makes encrypted C2 traffic partially transparent to the defender.
Malware Families Have Recognizable Signatures
After two exercises, patterns are already visible. Beaconing malware sends regular POST intervals — visible in I/O Graph as equally spaced spikes. Stealers act fast — small number of HTTP requests followed by TLS burst. The /api/set_agent path and the browser fingerprint payload are Lumma-specific signatures that, once seen, are immediately recognizable in any future pcap. Pattern recognition builds with each exercise.
Next Lab
Lab Log 005 will introduce Zeek (formerly Bro) — the network analysis framework that automates what Wireshark does manually. Where Wireshark requires an analyst to apply filters and read packets, Zeek generates structured logs automatically: conn.log, http.log, dns.log, ssl.log. The same Lumma traffic analyzed manually in this lab would be identified by Zeek in seconds. Understanding both tools — manual forensics and automated detection — is the complete picture of network security analysis.