Analyse a PCAP with Snort¶
Run saved traffic through a pinned engine, configuration and ruleset so another analyst can reproduce the result.
Treat packet captures as sensitive
Use only authorised captures. Malware-training PCAPs may contain payloads, credentials, personal data or indicators that trigger security controls. Analyse them on an isolated host and do not replay them onto a network.
Prepare the evidence¶
Record the PCAP source, licence, filename, size and checksum. Prefer a locally generated benign fixture for the first exercise.
sha256sum <CAPTURE.pcap>
/usr/local/bin/snort -V
sudo /usr/local/bin/snort -c /usr/local/etc/snort/overview.lua -T
Create a case directory that separates immutable input from generated output:
mkdir -p snort-case/{input,output,notes}
cp --preserve=timestamps <CAPTURE.pcap> snort-case/input/
chmod a-w snort-case/input/<CAPTURE.pcap>
sha256sum snort-case/input/<CAPTURE.pcap> > snort-case/input/SHA256SUMS
Record the source URL or acquisition system, licence or handling restriction, capture time zone, snap length if known, and whether packets were filtered. Do not infer that absence from a truncated or filtered capture means an event did not occur.
Inspect capture metadata before detection:
If these tools are unavailable, record that limitation rather than silently omitting the metadata check.
Run the analysis¶
Use an explicit output directory and preserve console output separately:
mkdir -p analysis-output
/usr/local/bin/snort -q \
-c /usr/local/etc/snort/overview.lua \
-r <CAPTURE.pcap> \
-A alert_fast \
-l analysis-output \
> analysis-output/snort-console.txt 2>&1
For the case structure above:
/usr/local/bin/snort -q \
-c /usr/local/etc/snort/overview.lua \
-r snort-case/input/<CAPTURE.pcap> \
-A alert_fast \
-l snort-case/output \
> snort-case/output/snort-console.txt 2>&1
printf '%s\n' "$?" > snort-case/output/snort-exit-status.txt
Run as an unprivileged analyst when file permissions and the selected logger allow it. Offline PCAP reading does not normally require raw-interface access.
Triage the results¶
Count alerts by GID:SID:revision and message, but retain the original lines:
awk -F'[][]' '/\[\*\*\] \[[0-9]+:[0-9]+:[0-9]+\]/ {print $4, $6}' \
snort-case/output/alert_fast.txt | sort | uniq -c | sort -nr
For each candidate finding:
- Read the exact rule and its metadata.
- Confirm the packet direction and addresses.
- Identify the packets or stream that satisfied the rule.
- Review surrounding DNS, TCP, TLS and HTTP context.
- Separate decoder/inspector events from detection-rule alerts.
- Document benign explanations and missing host telemetry.
The earlier PoC used a public malware-training capture and produced repeated ARP, DNS and UPnP alerts. Those counts demonstrated rule execution, not that every alert represented malware. Public training captures can change or be removed, so keep a checksum and do not make the exercise depend on a filename alone.
Compare configurations or rulesets¶
Never overwrite the first run. Create a second output directory and change one input at a time:
mkdir -p snort-case/output-rules-b
/usr/local/bin/snort -q \
-c /path/to/snort-rules-b.lua \
-r snort-case/input/<CAPTURE.pcap> \
-A alert_fast -l snort-case/output-rules-b
diff -u snort-case/output/alert_fast.txt \
snort-case/output-rules-b/alert_fast.txt
Explain added and removed alerts using rule changes, not just count differences.
Historical PoC: Pikabot training capture¶
The original walkthrough downloaded the password-protected training archive for the 8 February 2024 TA577/Pikabot exercise from Malware-Traffic-Analysis.net. The filename used was:
Treat this as an optional historical exercise. Confirm the current source, licence, archive password instructions and checksum on the publisher's exercise page before downloading it. Analyse it in an isolated environment; do not replay the traffic onto a network.
The historical Snort command was equivalent to:
/usr/local/bin/snort -q \
-c /usr/local/etc/snort/overview.lua \
--plugin-path /usr/local/etc/so_rules/ \
-r 2024-02-08-TA577-Pikabot-infection-traffic.pcap \
-A alert_fast -l analysis-output
The earlier ruleset produced examples including:
110 (arp_spoof) unicast ARP request
4 PROTOCOL-DNS SPOOF query response with TTL of 1 min. and no authority
4 INDICATOR-SCAN UPnP service discover attempt
1 (http_inspect) URI path contains consecutive slash characters
1 (http_inspect) Content-Transfer-Encoding used as HTTP header
Those counts are historical, not success criteria. Engine, built-in inspector and ruleset changes can alter them. The preservation goal is to retain the example while requiring a new analysis to explain its own packet evidence.
Review alerts by SID and then return to the relevant packets. A high count is not proof of compromise; document the rule logic, packet evidence, environment and plausible benign explanations.
Record the analysis¶
Retain:
- Snort and LibDAQ versions;
- configuration and ruleset checksums;
- PCAP checksum and capture time zone;
- exact command and exit status;
- SID, revision, classification and count;
- packet numbers supporting each conclusion; and
- limitations, false positives and missing telemetry.
Repeat the command and confirm the same inputs produce the same findings.
Package generated evidence separately from the original PCAP and checksum the report bundle. Apply the capture's handling restrictions to all derived output, because alert text can expose IP addresses, hostnames, URLs or payload content.
Troubleshooting¶
| Symptom | Check |
|---|---|
| No alerts | Confirm rules loaded, link type is supported, HOME_NET matches the capture and traffic is present |
| Different timestamps | Record Snort host time zone and the capture timestamp interpretation |
| Different alert counts | Compare engine, configuration, rules, built-ins and PCAP hashes |
| Inspector warnings | Determine whether capture truncation, missing stream direction or midstream pickup caused them |
| Output directory empty | Check logger selection, directory permissions, command exit status and console log |
| Excessive alerts | Group by SID, inspect the highest-volume rule and avoid equating volume with severity |