analyzing-network-traffic-for-incidents
Analyzes network traffic captures and flow data to identify adversary activity during security incidents, including command-and-control communications, lateral movement, data exfiltration, and exploitation attempts. Uses Wireshark, Zeek, and NetFlow analysis techniques. Activates for requests involving network traffic analysis, packet capture investigation, PCAP analysis, network forensics, C2 traffic detection, or exfiltration detection.
- License 许可
- Apache-2.0
- 最近更新
- 2026-08-31
- Stars
- ★ 3.6w
- Forks
- 4.4k
01 前言 Front Matter
- name
- analyzing-network-traffic-for-incidents
- tags
- [ "network-forensics", "PCAP-analysis", "Wireshark", "Zeek", "traffic-analysis" ]
- author
- mahipal
- domain
- cybersecurity
- license
- Apache-2.0
- version
- 1.0.0
- nist_csf
- [ "RS.MA-01", "RS.MA-02", "RS.AN-03", "RC.RP-01" ]
- subdomain
- incident-response
- description
- Analyzes network traffic captures and flow data to identify adversary activity during security incidents, including command-and-control communications, lateral movement, data exfiltration, and exploitation attempts. Uses Wireshark, Zeek, and NetFlow analysis techniques. Activates for requests involving network traffic analysis, packet capture investigation, PCAP analysis, network forensics, C2 traffic detection, or exfiltration detection.
- mitre_attack
- [ "T1071", "T1095", "T1573", "T1572" ]
02 资源文件 4
- 许可证LICENSE11.0 KB
- 许可证LICENSE.txt1.4 KB
- 参考文档references/api-reference.md2.8 KB
- 脚本scripts/agent.py7.6 KB
03 SKILL.md 正文
Analyzing Network Traffic for Incidents
When to Use
- SIEM alerts on anomalous network traffic patterns requiring deeper investigation
- C2 beaconing is suspected and needs confirmation through packet-level analysis
- Data exfiltration volume or destination must be quantified from network evidence
- Lateral movement between systems needs to be traced through network connections
- An IDS/IPS alert requires packet-level validation to confirm or dismiss
Do not use for host-based forensic analysis (process execution, file system artifacts); use endpoint forensics tools instead.
Prerequisites
- Full packet capture (PCAP) infrastructure or on-demand capture capability (network tap, SPAN port)
- Wireshark installed on the analysis workstation with appropriate display filters knowledge
- Zeek (formerly Bro) deployed for network metadata generation (conn.log, dns.log, http.log, ssl.log)
- NetFlow/IPFIX collection from network devices for traffic flow analysis
- Network architecture diagram showing VLAN layout, firewall placement, and monitoring points
- Threat intelligence feeds for correlating observed network indicators
Workflow
Step 1: Capture or Acquire Network Traffic
Obtain the relevant traffic data for the investigation:
Live Capture (if incident is active):
# Capture on specific interface filtering by host
tcpdump -i eth0 -w capture.pcap host 10.1.5.42
# Capture C2 traffic to specific external IP
tcpdump -i eth0 -w c2_traffic.pcap host 185.220.101.42
# Capture with rotation (1GB files, keep 10)
tcpdump -i eth0 -w capture_%Y%m%d%H%M.pcap -C 1000 -W 10
From Existing Infrastructure:
- Export PCAP from full packet capture appliance (Arkime/Moloch, ExtraHop, Corelight)
- Pull Zeek logs from the Zeek cluster for the investigation timeframe
- Export NetFlow data from network devices for high-level traffic analysis
Step 2: Identify C2 Communications
Detect command-and-control traffic patterns:
Beaconing Detection (Zeek conn.log):
# Extract connections to external IPs with regular intervals
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p duration orig_bytes resp_bytes \
| awk '$4 ~ /^185\.220/' | sort -t. -k1,1n -k2,2n
Wireshark Beacon Analysis:
# Filter for traffic to suspected C2 IP
ip.addr == 185.220.101.42
# Filter HTTPS traffic to non-standard ports
tcp.port != 443 && ssl
# Filter DNS queries for suspicious domains
dns.qry.name contains "evil" or dns.qry.name matches "^[a-z0-9]{32}\."
# Filter HTTP POST (common C2 check-in method)
http.request.method == "POST" && ip.dst == 185.220.101.42
Beaconing characteristics to identify:
- Regular time intervals between connections (e.g., every 60 seconds with 10-15% jitter)
- Consistent packet sizes in requests and responses
- HTTPS to external IPs not associated with legitimate CDNs or services
- DNS queries with high entropy subdomains (DNS tunneling indicator)
Step 3: Analyze Lateral Movement Traffic
Trace adversary movement between internal systems:
Key protocols for lateral movement detection:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SMB (TCP 445): PsExec, file share access, ransomware propagation
RDP (TCP 3389): Remote desktop sessions
WinRM (TCP 5985): PowerShell remoting
WMI (TCP 135): Remote command execution
SSH (TCP 22): Linux lateral movement
DCE/RPC (TCP 135): DCOM-based lateral movement
Wireshark Filters for Lateral Movement:
# SMB lateral movement
smb2 && ip.src == 10.1.5.42 && ip.dst != 10.1.5.42
# RDP connections from compromised host
tcp.dstport == 3389 && ip.src == 10.1.5.42
# Kerberos ticket requests (potential pass-the-ticket)
kerberos.msg_type == 12 && ip.src == 10.1.5.42
# NTLM authentication (potential pass-the-hash)
ntlmssp.auth.username && ip.src == 10.1.5.42
Step 4: Detect Data Exfiltration
Identify unauthorized data transfers leaving the network:
# Identify large outbound transfers in Zeek conn.log
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p orig_bytes \
| awk '$5 > 100000000' | sort -t$'\t' -k5 -rn
# DNS tunneling detection (high volume of TXT queries)
cat dns.log | zeek-cut query qtype | grep TXT | cut -f1 \
| rev | cut -d. -f1,2 | rev | sort | uniq -c | sort -rn | head
# Unusual protocol usage (ICMP tunneling, DNS over HTTPS)
cat conn.log | zeek-cut proto id.resp_p orig_bytes | awk '$1 == "icmp" && $3 > 1000'
Wireshark Exfiltration Filters:
# Large HTTP POST uploads
http.request.method == "POST" && tcp.len > 10000
# FTP data transfers
ftp-data && ip.src == 10.0.0.0/8
# DNS with large TXT responses (tunneling)
dns.resp.type == 16 && dns.resp.len > 200
Step 5: Extract and Correlate IOCs
Pull network-based indicators from traffic analysis:
- External IP addresses contacted by compromised hosts
- Domains resolved via DNS during the incident timeframe
- URLs accessed via HTTP/HTTPS (if SSL inspection is in place)
- TLS certificate details (subject, issuer, serial number, JA3/JA3S hashes)
- User-Agent strings from HTTP requests
- File transfers captured in PCAP (extract using Wireshark Export Objects)
Step 6: Document Network Forensic Findings
Compile analysis into a structured report with evidence references:
- Reference specific PCAP files, frame numbers, and timestamps for each finding
- Include packet captures of key evidence as screenshots or exported PDFs
- Map network activity to the incident timeline
- Correlate network findings with host-based evidence from endpoint forensics
Key Concepts
| Term | Definition |
|---|---|
| PCAP (Packet Capture) | File format storing raw network packets captured from a network interface for offline analysis |
| Beaconing | Regular, periodic network connections from a compromised host to a C2 server, identifiable by consistent timing intervals |
| JA3/JA3S | TLS client and server fingerprinting method based on the ClientHello and ServerHello parameters; unique per application |
| NetFlow/IPFIX | Network traffic metadata (source, destination, ports, bytes, duration) collected by routers and switches without full packet capture |
| DNS Tunneling | Technique encoding data in DNS queries and responses to exfiltrate data or maintain C2 through DNS protocol |
| Network Tap | Hardware device that creates an exact copy of network traffic for monitoring without impacting network performance |
| Zeek Logs | Structured metadata logs generated by the Zeek network analysis framework covering connections, DNS, HTTP, SSL, and more |
Tools & Systems
- Wireshark: Open-source packet analyzer for deep inspection of network protocols at the packet level
- Zeek (formerly Bro): Network analysis framework generating structured metadata logs from live or captured traffic
- Arkime (formerly Moloch): Open-source full packet capture and search platform for large-scale network forensics
- NetworkMiner: Network forensic analysis tool for extracting files, images, and credentials from PCAP files
- RITA (Real Intelligence Threat Analytics): Open-source beacon detection and DNS tunneling analysis tool for Zeek logs
Common Scenarios
Scenario: Confirming C2 Beaconing and Quantifying Exfiltration
Context: EDR detects a suspicious process on a workstation but cannot determine the volume of data exfiltrated. Network team provides PCAP from the full packet capture appliance covering the incident timeframe.
Approach:
- Filter PCAP to traffic from the compromised host IP to external destinations
- Identify the C2 channel by analyzing connection timing patterns (beacon detection)
- Extract TLS certificate and JA3 hash from the C2 connection for IOC generation
- Calculate total bytes transferred to C2 infrastructure over the incident duration
- Check for additional exfiltration channels (DNS tunneling, cloud storage uploads)
- Extract any unencrypted files transferred using Wireshark Export Objects feature
Pitfalls:
- Analyzing only HTTP traffic when C2 is operating over HTTPS without SSL inspection
- Missing DNS tunneling because the data volume per query is small (but total over time is significant)
- Not correlating network timestamps with endpoint timestamps (timezone mismatches)
- Overlooking legitimate cloud services abused for exfiltration (OneDrive, Google Drive, Dropbox)
Output Format
NETWORK TRAFFIC ANALYSIS REPORT
=================================
Incident: INC-2025-1547
Analyst: [Name]
Capture Source: Arkime full packet capture
Analysis Period: 2025-11-15 14:00 UTC - 2025-11-15 18:00 UTC
Total PCAP Size: 4.7 GB
C2 COMMUNICATIONS
Source: 10.1.5.42 (WKSTN-042)
Destination: 185.220.101.42:443 (HTTPS)
Beacon Interval: 60 seconds ± 12% jitter
Sessions: 237 connections over 4 hours
JA3 Hash: a0e9f5d64349fb13191bc781f81f42e1
TLS Certificate: CN=update.evil[.]com (self-signed)
Total Data Sent: 147 MB (outbound)
Total Data Recv: 2.3 MB (inbound - commands)
LATERAL MOVEMENT
10.1.5.42 → 10.1.10.15 (SMB, TCP 445) - 14:35 UTC
10.1.5.42 → 10.1.10.20 (RDP, TCP 3389) - 14:42 UTC
10.1.5.42 → 10.1.1.5 (LDAP, TCP 389) - 15:10 UTC
EXFILTRATION SUMMARY
Protocol: HTTPS to C2 server
Volume: 147 MB outbound
Duration: 14:23 UTC - 18:00 UTC
Files Extracted: [list if recoverable from unencrypted channels]
DNS ANALYSIS
Suspicious Queries: 0 DNS tunneling indicators
DGA Detection: 0 algorithmically generated domains
EVIDENCE REFERENCES
PCAP File: INC-2025-1547_capture.pcap (SHA-256: ...)
Zeek Logs: /logs/zeek/2025-11-15/ (conn.log, ssl.log, dns.log)
04 同仓库更多 Skills
verifying-build-provenance-with-slsa-sigstore
Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI/CD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.
validating-tpm-measured-boot-attestation
Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote/tpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware/kernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.
validating-backup-integrity-for-recovery
Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable/air-gapped backups for silent corruption or tampering.
triaging-windows-with-kape
Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment/triage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.
triaging-vulnerabilities-with-ssvc-framework
Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track/Track*/Attend/Act decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.
triaging-security-incident
Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM/EDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.