This is the final part of a three-part series. Part 1 explained why the network is the hunter’s ground truth. Part 2 walked through the four core hunts: long connections, lateral movement, beacons, protocol anomalies, DNS and outliers. Now we practise.

Threat hunting is a skill, and skills come from repetition. The good news is that network hunting is one of the cheapest disciplines to practise: everything in this article is free or open source, it runs on a laptop, and there are years of real malicious traffic published for exactly this purpose.

Pick your lab architecture

There are three sensible levels. Start at the first and grow.

Level 1 — the analyst workstation (an afternoon). A single Linux VM (Ubuntu or Debian, 4 vCPU, 8 GB RAM, 100 GB disk) with:

• Zeek to turn PCAPs into logs
• tshark / Wireshark for packet-level validation
• RITA for beacon, long-connection and DNS scoring
• zeek-cut, awk, sort, uniq, datamash — the Unix toolbox from Part 2
• Optionally Zui (formerly Brim), a desktop app that loads a PCAP, runs Zeek and Suricata behind the scenes, and lets you search the logs with a query language

This is all you need to work through every exercise below.

Level 2 — a full NSM platform (a weekend). When you want the experience of hunting in a SOC-style stack with dashboards and retention:

• Security Onion — free Linux distribution bundling Zeek, Suricata, full packet capture, Elastic stack, and hunt/case-management interfaces. Can import PCAPs for offline analysis or run as a live sensor.
• Malcolm — from Idaho National Laboratory with CISA. Docker-based; ingests PCAP, Zeek and Suricata data into OpenSearch with Arkime for packet search. Particularly strong for ICS/OT protocols.
• Arkime — indexed full packet capture with session search, great for pivoting from a Zeek finding to the actual packets.

Level 3 — a live range (ongoing). A small isolated network with a few Windows and Linux victims, a sensor on a SPAN/virtual switch mirror port, and an “internet” segment where you run your own C2 server. This is where you generate traffic, watch it on the wire, and then hunt it as if you didn’t know it was there. More on this below.

Whatever you build: keep malicious PCAPs and lab C2 isolated from production and from your personal machines. Many datasets contain live malware binaries that can be carved from the traffic.

Set up the Level 1 toolkit

Zeek. The easiest route is the official container image, which avoids dependency headaches:

# Process a PCAP into Zeek logs in the current directory
docker run --rm -v "$(pwd)":/data -w /data zeek/zeek \
  zeek -C -r sample.pcap

ls *.log
# conn.log  dns.log  http.log  ssl.log  x509.log  files.log ...

-C tells Zeek to ignore bad checksums, which are common in captures taken on the sending host because of NIC checksum offloading. Keep the default tab-separated output for these labs — zeek-cut works on TSV. (If you later ship logs to a SIEM, JSON output via LogAscii::use_json=T is usually easier.) For zeek-cut on the host, install Zeek from your distribution or the Zeek package repositories, or run it inside the container.

tshark. sudo apt install tshark on Debian/Ubuntu. Handy one-liners for validation:

# Conversations summary with durations
tshark -r sample.pcap -q -z conv,tcp

# TLS SNI per client
tshark -r sample.pcap -Y tls.handshake.type==1 \
  -T fields -e ip.src -e tls.handshake.extensions_server_name | sort | uniq -c | sort -nr

RITA. Current RITA releases run on Docker and are installed with the installer from the RITA GitHub releases page (follow the README for your version). Once installed:

# Import a folder of Zeek logs into a dataset called lab1
rita import --database=lab1 --logs=./zeek_logs

# Explore beacons, long connections, DNS and threat intel hits
rita view lab1

# Or dump results to stdout/CSV for scripting
rita view --stdout lab1 > lab1.csv

RITA ingests Zeek TSV or JSON logs and lets you filter results by severity, IP, beacon score, duration and threat-intel status.

Get good practice data

You need two kinds of data: traffic known to contain malicious activity, and normal traffic to learn what “boring” looks like.

• Active Countermeasures Threat Hunting Labs — the lab exercises used throughout this series, with sample data and step-by-step commands.
• ACM Malware of the Day — 24-hour lab captures of specific C2 frameworks and malware alongside normal Windows traffic, published as PCAPs and as Zeek logs ready for RITA. Perfect for beacon and long-connection practice.
• malware-traffic-analysis.net — Brad Duncan’s long-running archive of real infection traffic, including training exercises with questions and answers.
• Stratosphere Laboratory datasets — Czech Technical University’s malware, normal and mixed captures, including the well-known CTU-13 botnet dataset.
• Netresec’s list of public PCAP files — an index of CTF, malware, and academic datasets.
• Your own home or lab network — an overnight capture of your own traffic is the best way to learn how many legitimate beacons exist (updaters, smart TVs, phones) before you hunt somewhere that matters.

Five hands-on exercises

Each exercise has a goal, the steps, and questions to answer in your notes. Use a 24-hour capture where possible (Malware of the Day is ideal). Resist the urge to read the dataset’s answer key until you have written your own disposition.

Exercise 1 — Baseline before you hunt

Goal: understand what normal looks like in the dataset before chasing anything.

# Which protocols/services are in use?
cat conn.log | zeek-cut proto service | sort | uniq -c | sort -nr

# Who are the internal hosts and how chatty are they?
cat conn.log | zeek-cut id.orig_h | sort | uniq -c | sort -nr | head -20

# Top external destinations by number of distinct internal clients
cat conn.log | zeek-cut id.orig_h id.resp_h | sort -u \
  | cut -f 2 | sort | uniq -c | sort -nr | head -20

Questions: How many internal hosts are there? Which services dominate? Which destinations does every host talk to (likely benign infrastructure) and which ones only one host talks to?

Exercise 2 — Find the long connection

Goal: apply Hunt 1 from Part 2.

1. List the top 10 single connections by duration (TCP and UDP separately).
2. Compute cumulative duration per pair with the awk one-liner from Part 2.
3. Compare the two lists. Which pairs appear only in the cumulative list?
4. Load the same logs into RITA and compare its long-connection view with your manual results.

Questions: Convert the top durations to hours. Which ones can you explain (VPN, chat, sync)? For the ones you cannot, what is the service field, and who owns the destination ASN?

Exercise 3 — Prove a beacon by hand, then at scale

Goal: apply Hunt 2. Pick a pair from RITA’s beacon list with a high score, then verify it yourself so you understand what the score means.

# Replace with your pair
SRC=10.55.100.111
DST=165.227.216.194

# Interval (seconds) between consecutive connections, as a frequency table
cat conn.log | zeek-cut ts id.orig_h id.resp_h \
  | awk -v s=$SRC -v d=$DST '$2==s && $3==d {print $1}' | sort -n \
  | awk 'NR>1 {printf "%d\n", $1-prev} {prev=$1}' \
  | sort -n | uniq -c | sort -nr | head

# Bytes sent per connection, as a frequency table
cat conn.log | zeek-cut id.orig_h id.resp_h orig_bytes \
  | awk -v s=$SRC -v d=$DST '$1==s && $2==d {print $3}' \
  | sort -n | uniq -c | sort -nr | head

Questions: What is the most common interval, and roughly what jitter is applied? How consistent are the sizes? Now take a benign high-scoring beacon (an updater or NTP) and compare: what distinguishes it from the malicious one besides the score?

Exercise 4 — Catch a DNS tunnel

Goal: apply Hunt 3.

1. Run the unique-subdomain count from Part 2 and list the top 10 base domains.
2. Run the query-type distribution. Is TXT, NULL or CNAME unusually high?
3. For the top suspicious domain, find the internal source(s) and check conn.log for any direct connections to the resolved IPs.
4. Compare with RITA’s DNS view.

Questions: How many unique subdomains does the suspicious domain have, and over what time window? What does a typical query label look like (length, character set)? Is the source a client or your internal resolver — and if it is the resolver, which log would you need next?

Stretch goal: in your Level 3 range, run dnscat2 or iodine between two lab VMs for an hour, capture it, and repeat the hunt on traffic you generated.

Exercise 5 — A full hunt, start to disposition

Goal: combine everything. Take a malware-traffic-analysis.net exercise PCAP and run the five-step method end to end.

1. Persistence: long connections and beacons (Exercises 2–3).
2. Protocol: service vs port, rare user-agents in http.log, certificate validation and SNI in ssl.log, JA4 if you have the Zeek package.
3. Internal host: identify it from DHCP (dhcp.log), Kerberos/NTLM logs (hostname, user), and NetBIOS/SMB names.
4. Destination: ASN, domain age, popularity, reputation.
5. Score and disposition: major and minor modifiers, a number, and one of allow-list / collect more / escalate.

Write it up using the template below, then compare with the site’s answers. Where you were wrong is where you learn the most.

Generate your own C2 traffic (Level 3)

Public datasets are great, but nothing teaches like hunting traffic you created and know the ground truth of. In an isolated range you control:

• Open-source C2 frameworks — Sliver (HTTPS, mTLS, WireGuard and DNS implants) and Mythic let you configure sleep and jitter, so you can see exactly how a 60s/10% beacon differs from a 3600s/50% one in RITA.
• DNS tunnelling tools — dnscat2 and iodine for Exercise 4.
• A benign “beacon simulator” — when you just need regular traffic, a loop like this is enough:

# Lab only: check in every 60s with ~±15% jitter and a custom user-agent
while true; do
  curl -s -A "LabUpdater/1.0" http://c2.lab.local/check > /dev/null
  sleep $(( 51 + RANDOM % 19 ))
done

Run the traffic for 24 hours alongside normal user activity (browsing, updates, Teams/Slack), capture it with tcpdump on the mirror port, and hunt it blind a day later. Then change one variable — longer sleep, more jitter, DNS instead of HTTPS, a SaaS-hosted redirector — and see which hunts still catch it.

# Rotating 24h capture on the sensor: new file every hour, keep 48
sudo tcpdump -i eth1 -G 3600 -W 48 -w 'lab-%Y%m%d-%H%M.pcap' -n -s 0

Document every hunt

A hunt that is not written down cannot be repeated, reviewed, or turned into a detection. A lightweight template, loosely following PEAK’s Prepare → Execute → Act phases:

• Hunt ID and title — e.g., NTH-2026–014: HTTPS beacons from server VLAN
• Type — hypothesis / intel-driven / baseline / model-assisted
• Hypothesis — one testable sentence
• ATT&CK techniques — e.g., T1071.001, T1573
• Scope — networks, hosts, time window
• Data sources — conn.log, dns.log, ssl.log, EDR; confirm they exist and cover the scope
• Queries / analytics — the exact commands or SIEM queries used
• Findings — each candidate pair with evidence, score and disposition
• Allow-list changes — what was added and why
• Detections created or improved
• Visibility gaps found
• Time spent and next steps

Turn hunts into detections

The end state of a mature program (HMM4 in Bianco’s model) is that each successful hunt becomes an automated detection, freeing the hunters for the next question. Practical ways to get there:

• Schedule RITA. Import Zeek logs on a schedule (RITA supports rolling databases for continuous import) and alert on new high-score beacons or long connections not on the allow-list.
• SIEM analytics. Translate the one-liners into scheduled queries: unique subdomains per base domain per hour above a threshold; workstations with a positive PCR to a single destination above N MB; first-seen JA4 fingerprints; outbound connections where port and detected service disagree.
• Zeek scripts and Suricata rules. Zeek’s scripting language can compute per-host state in real time (for example, counting NXDOMAINs per host). Suricata can catch known C2 profiles, default certificates and JA4/JA3 hashes.
• Feed CTI back. Infrastructure you confirm (domains, IPs, certificates, JA4 values) goes into your threat-intel platform and blocklists — remembering that the behaviour is the durable detection, not the IOC.

Keep learning

Courses and certifications

• SANS FOR572: Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response — six sections covering packet capture and proxy logs, HTTP and DNS profiling, log aggregation with SOF-ELK, NetFlow, SMB and file-access protocols, Arkime and NetworkMiner, wireless, TLS profiling and protocol reversing, and a capstone that is solved with network evidence only. Includes 20 hands-on labs and maps to the GIAC Network Forensic Analyst (GNFA) certification.
• Active Countermeasures — the Network Threat Hunting training material, free webcasts, blog and Malware of the Day series.
• Hands-on platforms — CyberDefenders, Blue Team Labs Online and TryHackMe all have network forensics and Zeek/Wireshark challenges at beginner to advanced level.

Books

• Richard Bejtlich — The Practice of Network Security Monitoring (No Starch Press)
• Chris Sanders and Jason Smith — Applied Network Security Monitoring (Syngress)
• Chris Sanders — Practical Packet Analysis (No Starch Press)

Free tools and frameworks referenced in this series

• Zeek · RITA · Wireshark/tshark · Zui · Arkime
• Security Onion · Malcolm
• JA4+ · MITRE ATT&CK · PEAK framework

Closing thoughts

Network threat hunting is not about expensive tools. It is about asking a few hard questions of your traffic, every week, and writing down the answers:

• What is talking out, and does it keep coming back?
• Does the protocol match what it claims to be?
• Which internal host, which process, which user?
• Who is on the other end, and why do we talk to them?
• Benign, uncertain, or compromised?

You can hide processes, but you can’t hide packets. Start with a 24-hour capture, a Zeek container and an afternoon. By the end of your tenth hunt you will know your network better than any attacker — and that is the real advantage.

If this series helped, share it with your SOC team, and tell me in the comments which hunt found something interesting in your environment.

References

• Active Countermeasures — How to Threat Hunt Your Network
• Active Countermeasures — Network Threat Hunting training slides (PDF)
• Threat Hunting Labs — Long Connections, Beacons, DNS, Outliers
• Active Countermeasures — Malware of the Day
• PuppyGraph — Network Threat Hunting
• NetWitness — Types of Network Threat Hunting
• SANS — FOR572
• Idaho National Laboratory — Malcolm

Long Live Cyber Defenders!

Hunting on the Wire : A Practical Guide to Network Threat Hunting — Part 3 was originally published in FMI Cyber Security Consulting Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this blog, we will focus on several important Kunai events and how they can be correlated to understand what happened on a Linux host.

For analysis purpose it is more useful to focus on events that help answer these questions:

What was executed?
What files were created or modified?
Was a script involved?
Did the host communicate with an external system?
Was there any persistence activity?
Were any artifacts removed?

For this article, I will focus on six Kunai events that are useful as a starting point for Linux threat analysis:

execve
execve_script
write_config
dns_query
connect
file_unlink

The goal is not to analyze these events independently.

The goal is to correlate them and use the available context to understand what happened on the host.

1. Understanding Kunai Events

Before looking at individual events, it is useful to understand the structure of a Kunai event. Please find the example event log below

{
 "data": "…",
 "info": {
 // Host related information
 "host": {
 // Unique host uuid
 "uuid": "c030b40d-0eab-417b-b33a-22d952357984",
 // Hostname of the host running kunai
 "name": "hal",
 // Container information if any, null otherwise
 "container": {
 // Name of the container
 "name": "ubuntu-kunai-test",
 // Type of container
 "type": "docker"
 }
 },
 // Event related information
 "event": {
 // A string which can be used by external tools to identify kunai's logs
 "source": "kunai",
 // Event type identifier
 "id": 1,
 // Event type name
 "name": "execve",
 // Unique identifier for an event
 "uuid": "87f5cb64–11ca-fd34–26af-b47f84132543",
 // Not relevant, here for diagnosis purposes
 "batch": 131
 },
 // Information about the task generating this event
 "task": {
 // Task name
 "name": "ls",
 // Identifier of the task (process or thread)
 "pid": 1981502,
 // Thread Group ID of the task (same for all threads of a process)
 // When pid == tgid we are in the main thread.
 "tgid": 1981502,
 // A uuid common to all the events generated by the same
 // task group/process (i.e. all threads). You can search by
 // this value in order to see the whole activity of a process
 "guuid": "cd5415c4–7750–0000–7c85–4ef53e3c1e00",
 // Effective uid of the task
 "uid": 1000,
 // Effective gid of the task
 "gid": 1000,
 // Information about Linux namespaces
 "namespaces": {
 // mnt namespace id
 "mnt": 4026531841
 },
 // task_struct flags https://elixir.bootlin.com/linux/v6.6.5/source/include/linux/sched.h#L767
 // combination of process flags https://elixir.bootlin.com/linux/v6.6.5/source/include/linux/sched.h#L1726
 "flags": "0x400000",
 // Indicates whether the task is in a zombie state
 "zombie": true
 },
 // Information about the parent task. This section
 // contains the same kind of information as the task section
 "parent_task": {
 "name": "3",
 "pid": 1981500,
 "tgid": 1981500,
 "guuid": "a679f5c3–7750–0000–7c85–4ef53c3c1e00",
 "uid": 1000,
 "gid": 1000,
 "namespaces": {
 "mnt": 4026531841
 },
 "flags": "0x400000",
 "zombie": false
 },
 // UTC timestamp of the event
 "utc_time": "2024–11–19T09:55:53.138247256Z"
 }
}

Kunai events generally contain an info section and a data section.

The info section contains information that can be useful for identifying and correlating events, such as the event name, timestamp, task information, and parent task.

The data section contains information specific to the event.

For example, an execution event can contain fields related to the command line, executable, parent process, and process ancestry.

Some fields that are useful during analysis include:

info.event
info.task
info.parent_task
info.utc_time

For process-related events, fields such as:

data.command_line
data.parent_command_line
data.parent_exe
data.ancestors
data.exe.path

can provide additional context.

2. execve — Start With Process Execution

One of the most important events to understand is execve.

The event is generated when a process executes a program. This makes it one of the most useful starting points when investigating activity on a Linux system.

For example, consider the following Kunai event:

{
  "data": {
    "ancestors": "/usr/lib/systemd/systemd|/usr/bin/login|/usr/bin/zsh|/usr/bin/bash|/usr/bin/xinit|/usr/bin/i3|/usr/bin/bash|/usr/bin/urxvt|/usr/bin/zsh|/usr/bin/bash|/usr/bin/timeout|/usr/bin/bash",
    "parent_command_line": "bash -ec \"trash=/tmp/trash; mkdir -p $trash; while [ true ]; do t=$(mktemp -d -p $trash); for i in {0..100000}; do echo \\\"AHHHH\\\" > $t/test$i.txt; done && rm -rf $t; done\"",
    "parent_exe": "/usr/bin/bash",
    "command_line": "mktemp -d -p /tmp/trash",
    "exe": {
      "path": "/usr/bin/mktemp",
      "sha256": "f32938cf25ddd6f6800a8e9b406595534d0eb27993587bbdeee2e83dd97d8406"
    }
  },
  "info": {
    "event": {
      "name": "execve"
    },
    "utc_time": "2025-06-10T14:00:42.814301638Z"
  }
}

At first glance, there is nothing particularly suspicious about:

mktemp -d -p /tmp/trash

mktemp is a legitimate Linux utility and is commonly used to create temporary files and directories.

However, the execve event gives us much more context.

The parent_command_line shows that the process was launched as part of:

bash -ec "trash=/tmp/trash; mkdir -p $trash; while [ true ]; do t=$(mktemp -d -p $trash); ..."

This immediately changes the investigation.

The parent process is repeatedly creating temporary directories under:

/tmp/trash

and then generating a large number of files:

for i in {0..100000}; do
    echo "AHHHH" > $t/test$i.txt
done

The directory is subsequently removed:

rm -rf $t

So instead of looking at mktemp in isolation, we can understand the behavior from the surrounding process context:

bash → mktemp → create temporary directory → create many files → rm -rf

This is a good example of why process lineage and command-line context are important during Kunai analysis.

The executable itself is not necessarily suspicious.

The behavior surrounding the executable is what deserves investigation.

What should we check?

When reviewing an execve event, I normally start with:

command_line
parent_command_line
parent_exe
ancestors
exe.path
exe.sha256
utc_time

In this example, command_line tells us:

mktemp -d -p /tmp/trash

but parent_command_line explains why it was executed.

The ancestors field provides even more context:

systemd
 → login
 → zsh
 → bash
 → xinit
 → i3
 → bash
 → urxvt
 → zsh
 → bash
 → timeout
 → bash
 → mktemp

This does not automatically make the activity malicious. Instead, it gives the analyst enough context to continue the investigation.

For example, we could now look for the subsequent file creation and deletion activity associated with the temporary directory.

This is the important lesson when analyzing execve:

Do not judge a process only by its executable name. Look at what executed it, how it was executed, and what happened around it.

3. execve_script — Investigate Script Execution

The next event worth looking at is execve_script.

This event is useful when a process executes a script through an interpreter such as Bash, Python, or another scripting engine.

Consider this Kunai event:

{
  "data": {
    "parent_command_line": "/bin/bash generate-activity.sh",
    "parent_exe": "/usr/bin/bash",
    "command_line": "/bin/bash /tmp/tmp.KsA9Ym95fq_kunai_test.sh",
    "exe": {
      "path": "/tmp/tmp.KsA9Ym95fq_kunai_test.sh",
      "sha256": "cda81b42b75647daf6b70a626380c199fe665d721e63bfe34c96b65da0289627",
      "size": 21
    },
    "interpreter": {
      "path": "/usr/bin/bash",
      "sha256": "68bac453a428796f18114a1bf43420d814e36555808ec98eacb782de565c06eb",
      "size": 1100632
    }
  },
  "info": {
    "event": {
      "name": "execve_script"
    },
    "utc_time": "2025-06-10T14:00:30.925394727Z"
  }
}

The first thing we can see is:

/bin/bash /tmp/tmp.KsA9Ym95fq_kunai_test.sh

This tells us that Bash executed a script located under /tmp.

The event also provides a separate interpreter object:

interpreter.path:
/usr/bin/bash

This is useful because we can distinguish between the script being executed and the program responsible for interpreting it.

In this case:

Script      → /tmp/tmp.KsA9Ym95fq_kunai_test.sh
Interpreter → /usr/bin/bash

We can also see how the script was launched:

parent_command_line:
/bin/bash generate-activity.sh

So the immediate activity can be summarized as:

generate-activity.sh → /tmp/tmp.KsA9Ym95fq_kunai_test.sh

This is already useful during an investigation.

Instead of simply seeing:

bash

we know that Bash was used to execute a specific script from /tmp.

Why does the script location matter?

The location does not automatically make the script malicious.

/tmp is commonly used by legitimate applications and scripts.

However, a script executed from a temporary directory is worth investigating when it appears together with other suspicious activity.

For example:

execve → file creation → execve_script

could indicate that a process created a temporary script and subsequently executed it.

If we then observe network activity:

execve → file creation → execve_script → connect

we now have a stronger reason to investigate the script and the process responsible for it.

The important point is that execve_script gives us additional context that a normal process execution event may not provide.

What should we check?

When reviewing execve_script, focus on:

command_line
parent_command_line
parent_exe
exe.path
exe.sha256
interpreter.path
interpreter.sha256
utc_time

For example:

Script:
 /tmp/tmp.KsA9Ym95fq_kunai_test.sh

Interpreter:
 /usr/bin/bash

Parent:
 /bin/bash generate-activity.sh

This gives us a simple investigation starting point:

What is the script, who executed it, and why was it executed?

A useful correlation

If the script was created shortly before the execve_script event, we can investigate the file creation event.

For example:

file_create → execve_script

If the script then makes an external connection:

file_create → execve_script → dns_query → connect

we can investigate the entire activity rather than treating the script execution as an isolated event.

This is where Kunai becomes useful for analysis: the event tells us what happened, while correlation helps us understand why it happened.

4. write_config — Investigate Configuration Changes

Configuration files are important evidence during an investigation because attackers may modify them to change how a service or application behaves.

The write_config event helps identify when a process writes to a configuration file.

For example, this event was generated when tee wrote to /etc/kunai_test.conf:

{
  "data": {
    "ancestors": "/usr/lib/systemd/systemd|/usr/bin/login|/usr/bin/zsh|/usr/bin/bash|/usr/bin/xinit|/usr/bin/i3|/usr/bin/bash|/usr/bin/urxvt|/usr/bin/zsh|/usr/bin/bash|/usr/bin/sudo|/usr/bin/sudo",
    "command_line": "tee /etc/kunai_test.conf",
    "exe": {
      "path": "/usr/bin/tee"
    },
    "path": "/etc/kunai_test.conf"
  },
  "info": {
    "host": "...",
    "event": {
      "source": "kunai",
      "id": 84,
      "name": "write_config",
      "uuid": "4903ced0-5bad-c3db-9325-5ea6a6c4da90",
      "batch": 877
    },
    "task": "...",
    "parent_task": "...",
    "utc_time": "2024-10-29T12:48:02.474792288Z"
  }
}

The important fields here are:

• command_line — shows how the configuration was written.
• exe.path — shows the program performing the write, in this case /usr/bin/tee.
• path — shows the configuration file that was modified.
• ancestors — provides the process history leading to the activity.
• utc_time — tells us when the modification occurred.

The key detail is:

tee /etc/kunai_test.conf

This tells us that /usr/bin/tee was used to write to /etc/kunai_test.conf.

The process ancestry also shows that the activity came through sudo:

... → bash → sudo → sudo → tee

This is useful because a configuration change should not be analyzed only from the file path. We also want to understand who initiated the change and how the process obtained the privileges required to modify the file.

A configuration write is not automatically malicious. System administrators and applications routinely modify files under /etc. The investigation becomes more interesting when the modified file, process ancestry, command line, or timing is unusual.

For example, an analyst could correlate the event with other activity:

execve → write_config → execve_script

This could indicate that a process was executed, a configuration file was modified, and a script was subsequently executed.

The main question when analyzing write_config is:

What configuration was changed, who changed it, and why?

This makes write_config particularly useful for finding changes that may support persistence, alter application behavior, or modify system configuration.

5. dns_query — Investigate DNS Activity

DNS activity is useful during an investigation because it can show which domains a process tried to resolve before making a network connection.

Kunai’s dns_query event provides information about the DNS query, the response, and the DNS resolver that handled the request. The event is generated for DNS traffic over UDP/53 or TCP/53.

For example, this event was generated when curl accessed a Kunai-related website:

{
  "data": {
    "ancestors": "/usr/lib/systemd/systemd|/usr/bin/login|/usr/bin/zsh|/usr/bin/bash|/usr/bin/xinit|/usr/bin/i3|/usr/bin/bash|/usr/bin/urxvt|/usr/bin/zsh|/usr/bin/bash",
    "command_line": "curl https://why.kunai.rocks",
    "exe": {
      "path": "/usr/bin/curl"
    },
    "socket": {
      "domain": "AF_INET",
      "type": "SOCK_DGRAM",
      "proto": "UDP"
    },
    "src": {
      "ip": "192.168.1.152",
      "port": 13267
    },
    "query": "kunai-project.github.io",
    "response": "185.199.110.153;185.199.111.153;185.199.109.153;185.199.108.153",
    "dns_server": {
      "ip": "192.168.1.1",
      "port": 53,
      "public": false,
      "is_v6": false
    },
    "community_id": "1:XT9OMvFiajrWmMOXr4N3TI+3Etc="
  },
  "info": {
    "host": "...",
    "event": {
      "source": "kunai",
      "id": 61,
      "name": "dns_query",
      "uuid": "ecc87c39-8da3-0b9d-4060-480fdef2efd7",
      "batch": 878
    },
    "task": "...",
    "parent_task": "...",
    "utc_time": "2024-10-29T12:48:02.470834988Z"
  }
}

The first thing to look at is the process that generated the DNS activity:

command_line: curl https://why.kunai.rocks
exe.path: /usr/bin/curl

This gives us context about which program initiated the activity and what it was trying to access.

The actual DNS lookup is shown by:

query: kunai-project.github.io

Kunai also records the returned IP addresses:

response: 185.199.110.153
         185.199.111.153
         185.199.109.153
         185.199.108.153

This is useful because the domain alone does not tell the complete story. During an investigation, we may also want to determine which IP addresses the host received and whether those addresses were subsequently contacted.

The DNS resolver is also recorded:

dns_server:
  ip: 192.168.1.1
  port: 53
  public: false

Here, the host sent the DNS request to the internal resolver 192.168.1.1 over UDP/53.

The important fields to inspect are:

• command_line — what the process was doing.
• exe.path — which executable generated the activity.
• query — the domain being resolved.
• response — IP addresses returned by DNS.
• dns_server — the DNS resolver used by the host.
• utc_time — when the lookup occurred.
• ancestors — how the process was launched.

From a DFIR perspective, the value of dns_query becomes much greater when correlated with process and network events.

For example:

execve → dns_query → connect

This can give us a simple investigation path:

A process was executed → it resolved a domain → it established a network connection.

If the domain is suspicious, we can then go back to the process that generated the lookup and investigate its command line, parent process, executable path, and file activity.

The main question when analyzing dns_query is:

Which process resolved the domain, what did the domain resolve to, and what happened next?

This shifts DNS analysis from simply looking at domains to reconstructing the activity that happened around them.

6. connect — Identify Outbound Connections

After identifying DNS activity, the next question is: did the process actually connect to the resolved IP address?

The connect event is generated when a process attempts to connect to a remote IP address. Kunai can also correlate the destination hostname with a previous dns_query event, making it easier to connect the domain name with the actual network connection.

For example, this event was generated by curl:

{
  "data": {
    "ancestors": "/usr/lib/systemd/systemd|/usr/bin/login|/usr/bin/zsh|/usr/bin/bash|/usr/bin/xinit|/usr/bin/i3|/usr/bin/bash|/usr/bin/urxvt|/usr/bin/zsh|/usr/bin/bash",
    "command_line": "curl -d RCKhLa0Ka70LTYgF4eJiQkAspo9Yevj3dMjuSc0NwpOauPicV3P4bajH1paLQMvYGIILwrHk3cpxgS4FDVAUn5XiT0ucGNoVYd2FAjg6hP1zXSH9KCKJhB3ixUq8APtqSJ1DPVYGPOSyCIaHb9Nh4QOJe0UiYjogNoiFBRYVIL8hFgI607LW0MVxcTQqPdX9Utuw9MXxyEaN6TVcFWmKAxrV5BsgP9YYeXyWwda62Kg5aqsq2cdPy9jm9s6S6Brr https://why.kunai.rocks",
    "exe": {
      "path": "/usr/bin/curl"
    },
    "socket": {
      "domain": "AF_INET",
      "type": "SOCK_DGRAM",
      "proto": "UDP"
    },
    "src": {
      "ip": "192.168.1.152",
      "port": 36749
    },
    "dst": {
      "hostname": "kunai-project.github.io",
      "ip": "185.199.111.153",
      "port": 443,
      "public": true,
      "is_v6": false
    },
    "community_id": "1:Zy0KM8lSsDjFs4mzmfFHjtBZfPI=",
    "connected": true
  },
  "info": {
    "host": "...",
    "event": {
      "source": "kunai",
      "id": 60,
      "name": "connect",
      "uuid": "6c1ab8dc-3e55-cdc9-12ea-b14d15366dba",
      "batch": 877
    },
    "task": "...",
    "parent_task": "...",
    "utc_time": "2024-10-29T12:48:02.472813816Z"
  }
}

The first thing to identify is the process responsible for the connection:

command_line: curl ... https://why.kunai.rocks
exe.path: /usr/bin/curl

This tells us that /usr/bin/curl attempted the network connection.

The destination is shown under dst:

hostname: kunai-project.github.io
ip:       185.199.111.153
port:     443
public:   true

This gives us the complete destination context:

curl → kunai-project.github.io → 185.199.111.153:443

The connected field is also important:

connected: true

In this event, the connection attempt was successful.

This is where connect becomes particularly useful when combined with the previous dns_query event. The earlier DNS event showed that kunai-project.github.io resolved to several IP addresses, including 185.199.111.153. The connect event then shows that the host actually connected to that IP.

We can therefore reconstruct a simple network activity chain:

dns_query → connect

Or, when combined with process execution:

execve → dns_query → connect

This gives the analyst more than just a list of network connections. We can start asking:

• Which process made the connection?
• What domain was involved?
• Which IP address was contacted?
• Which port was used?
• Was the destination public or internal?
• Did the connection succeed?
• What happened immediately before and after the connection?

The command_line is especially important in this example. It contains a large -d argument before the destination URL. That does not automatically make the activity malicious, but it gives the analyst something to investigate further because the process was sending data as part of the request.

The main fields to inspect are:

• command_line — what the process was doing.
• exe.path — which executable made the connection.
• dst.hostname — the destination hostname, when available.
• dst.ip — the remote IP address.
• dst.port — the destination port.
• dst.public — whether the destination is identified as public.
• connected — whether the connection succeeded.
• utc_time — when the connection occurred.
• ancestors — the process ancestry.

From a DFIR perspective, connect helps answer the next question after DNS analysis:

After resolving the domain, did the process actually communicate with the destination?

This makes dns_query and connect especially useful together. One shows the name resolution, while the other shows the network connection attempt.

The investigation can then continue by correlating the connection with file activity, scripts, or other processes to understand what the network communication was part of.

7. file_unlink — Investigate File Deletion

The file_unlink event is generated when a file is deleted from the filesystem.

File deletion can be completely normal. Linux services routinely create and remove temporary files, sockets, runtime files, and other artifacts. However, attackers may also delete files to remove traces after executing malicious activity.

For example, this event shows a file being removed from /run/udev:

{
  "data": {
    "ancestors": "/usr/lib/systemd/systemd|/usr/bin/udevadm",
    "command_line": "/usr/lib/systemd/systemd-udevd",
    "exe": {
      "path": "/usr/bin/udevadm"
    },
    "path": "/run/udev/watch/b43:128",
    "success": true
  },
  "info": {
    "host": "...",
    "event": {
      "source": "kunai",
      "id": 86,
      "name": "file_unlink",
      "uuid": "66d58529-0b24-ef1d-2b27-3e5a5a85d31b",
      "batch": 643
    },
    "task": "...",
    "parent_task": "...",
    "utc_time": "2024-10-29T12:47:59.189301629Z"
  }
}

The most important field is:

path: /run/udev/watch/b43:128

This tells us which file was removed.

We can then look at the process responsible:

command_line: /usr/lib/systemd/systemd-udevd
exe.path:    /usr/bin/udevadm

The process ancestry also gives us additional context:

systemd → udevadm

In this particular example, the deleted file is under /run/udev, and the activity is associated with the system's udev components. This can be consistent with normal system activity rather than malicious file deletion.

The success field tells us whether the unlink operation succeeded:

success: true

This means the file was successfully removed.

The important fields to inspect are:

• path — which file was deleted.
• command_line — what the process was doing.
• exe.path — which executable performed the deletion.
• ancestors — how the process was launched.
• success — whether the deletion succeeded.
• utc_time — when the deletion occurred.

The key point is that a file deletion event by itself does not prove malicious activity.

Instead, look at the surrounding events. For example, if an unusual script creates a file, executes it, communicates externally, and then deletes it, the deletion becomes much more interesting:

file_create → execve_script → dns_query → connect → file_unlink

This sequence could represent a temporary file being created, executed, used for network communication, and then removed.

In contrast, a deletion involving a normal system process and a temporary runtime file may simply be routine Linux activity.

The main question when analyzing file_unlink is:

What was deleted, which process deleted it, and does the deletion make sense in the surrounding activity?

This makes file_unlink particularly useful when investigating cleanup behavior. Rather than treating every deletion as suspicious, use it as another piece of evidence when reconstructing what happened on the host.

8. Putting the Events Together

The real value of Kunai analysis comes from correlation.

For example, imagine we observe:

execve → file_create → execve_script

This tells us that a process executed a command, a file was created, and a script was subsequently executed.

We can then continue the investigation:

execve → file_create → execve_script → dns_query → connect

Now we have execution, file activity, script execution, and network activity occurring in the same investigation window.

If the activity ends with:

file_unlink

we may have:

execve → file_create → execve_script → dns_query → connect → file_unlink

This is much more useful than reviewing six unrelated JSON events.

The analyst can now investigate the sequence as a single activity:

What executed the initial command?

What file was created?

What script was executed?

What domain was queried?

What remote system was contacted?

What file was eventually deleted?

This is the basic approach I would recommend when starting Kunai analysis.

9. A Practical Analysis Workflow

When starting with a Kunai log, I would begin with execve.

Look for unusual commands, unexpected binaries, suspicious locations, and unusual parent-child relationships.

From there, check execve_script if scripts or interpreters are involved.

If the activity creates or modifies files, investigate the corresponding file_create, write, or write_config events.

For network-related activity, correlate dns_query with connect to determine what the process was attempting to reach.

Finally, check file_unlink to determine whether any artifacts were removed after execution.

A simple investigation may therefore look like:

execve → file_create → execve_script → write_config → dns_query → connect → file_unlink

Not every investigation will contain all of these events.

The purpose is to use whichever events are available to build the most complete timeline possible.

10. What Should the Analyst Produce?

The final result of the investigation should not simply be:

Suspicious execve detected.
Suspicious connect detected.
Suspicious file deletion detected.

That does not explain what happened.

Instead, the analyst should be able to describe the activity in context.

For example:

A shell process executed a command that resulted in a script being created and executed from /tmp. The script subsequently generated DNS activity and established an outbound connection to a remote system. The temporary script was later deleted.

Conclusion

Kunai provides a large amount of telemetry that can be used to investigate Linux activity. However, analysts do not need to start by reviewing every event.

For a basic investigation, six events provide a useful starting point:

execve
execve_script
write_config
dns_query
connect
file_unlink

Each event provides a different piece of the investigation.

execve helps us understand process execution.

execve_script provides additional visibility into script execution and interpreters.

write_config helps identify configuration changes.

dns_query and connect provide network context.

file_unlink can help identify cleanup activity.

The important part is how these events are correlated.

Kunai Analysis #1 — Analyzing Linux Activity with Kunai was originally published in FMI Cyber Security Consulting Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is Part 2 of a three-part series. Part 1 covered why the network is the hunter’s ground truth. Part 3 is about building a lab and practising. This part is the technical core.

In Part 1 we settled on a simple principle: start with persistence. An implant that cannot talk to its operator is useless, so the strongest evidence of compromise is a communication channel that keeps coming back. In this part we turn that principle into four concrete hunts you can run against Zeek logs or PCAP today.

All examples use Zeek logs and the open-source tools from Active Countermeasures’ Threat Hunting Labs. Zeek logs are tab-separated, and zeek-cut lets you pick columns by name, which makes them perfect for Unix one-liners.

The method: five steps, highest threat first

ACM’s How to Threat Hunt Your Network gives an ordered workflow. Every hunt in this article plugs into it:

1. Find persistent channels leaving the network (long connections and beacons).
2. Analyse the protocol. Does the application match the port? Is the beaconing normal for this protocol (NTP beacons by design)? Unique user-agent or TLS fingerprint? Self-signed certificate?
3. Evaluate the internal host. What is it, who uses it, what process made the connection?
4. Check the destination. Who owns the IP/ASN? How old is the domain? Is it a known business partner?
5. Disposition. Allow-list with a documented reason, collect more data, or escalate to IR.

A useful habit: work on internal-to-external IP pairs, not individual connections. A single connection tells you little. A pair that has talked 2,000 times over 24 hours at near-identical intervals tells you a lot.

Hunt 1: Long connections

The idea. Some C2 frameworks hold a single session open and push commands down it. Reverse shells, SSH tunnels, some web-socket implants and many RATs behave this way. ACM’s training suggests treating outbound connections that last more than 12–24 hours as worth an explanation.

A quick note on what a “connection” is. TCP connections have a clear start (three-way handshake) and end (FIN/RST). UDP has no session, so tools invent one: most close a UDP “connection” after 30–60 seconds of silence. Zeek identifies each connection by its 5-tuple (source IP, source port, destination IP, destination port, protocol). That matters because a long UDP flow in Zeek means the two hosts never stopped talking for more than that idle window.

Step 1 — the longest single connections. From the long connections lab:

cat conn.log | zeek-cut id.orig_h id.orig_p id.resp_h id.resp_p proto service duration \
  | sort -nrk 7 | head

Column 7 is duration in seconds. Divide by 3600 to get hours. Repeat with grep udp to look at UDP specifically — long UDP sessions to the internet that are not DNS, NTP or a known VPN are unusual.

Step 2 — cumulative time per pair. Smarter malware drops and re-opens the connection to stay under a single-session threshold. So add up the duration for each source/destination/port/protocol tuple:

cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto duration \
  | awk 'BEGIN{ FS="\t" } { arr[$1 FS $2 FS $3 FS $4] += $5 } \
    END{ for (key in arr) printf "%s%s%s\n", key, FS, arr[key] }' \
  | sort -nrk 5 | head

A pair with 86,000 cumulative seconds in a 24-hour capture was connected for essentially the whole day, even if no individual session was long.

Step 3 — let RITA do it at scale. RITA (Real Intelligence Threat Analytics) imports Zeek logs and computes this for every pair. In the lab’s older RITA version the command was rita show-long-connections -H --limit 10 <dataset>; current RITA releases show long connections inside the rita view interface, sortable by duration.

What’s usually benign. Expect to allow-list a handful of things: BGP sessions, site-to-site VPNs, chat and collaboration clients (Teams, Slack), cloud storage sync, remote-management agents, push-notification services and long-polling web apps. Record the business reason when you allow-list — “it’s Microsoft” is not a reason.

What’s suspicious. A workstation or server holding a session for many hours to a VPS or residential IP with no business relationship. A long session on 443 where Zeek’s service column is empty (not TLS). A long SSH session outbound from a host that has no reason to SSH anywhere. Long connections to a cloud IP that is fronting a domain registered last week.

Hunt 2: Beacons

The idea. Most modern C2 does not hold a session open. The implant sleeps, wakes up, opens a short connection to ask for tasks, and goes back to sleep. Cobalt Strike, Sliver, Mythic, Havoc, Brute Ratel and nearly every commodity RAT work this way. The defining property is regularity: the check-ins happen on a schedule, and the check-in packets look alike.

Attackers know this, so they add jitter — a random percentage applied to the sleep time. A 60-second sleep with 20% jitter produces intervals anywhere between 48 and 72 seconds. Jitter makes beacons harder to see by eye, but it does not make them random. Over hours, the intervals still cluster tightly around a centre, and the request and response sizes stay consistent because the “no tasks” response is always the same.

What to measure for each internal→external pair:

• Connection count over the window — beacons generate many connections (60-second sleep = ~1,440 per day).
• Interval regularity — the time delta between consecutive connections. Look at the mode (most common interval), the spread (range, median absolute deviation) and the skew (is the distribution symmetric around the centre?).
• Size regularity — bytes per connection. An idle beacon sends and receives nearly identical payloads every time.
• Duration of the pattern — a pattern that persists across the whole 24 hours, including nights and weekends when users are not active, is much more suspicious than a burst.

ACM’s guidance is to analyse at least 24 hours of data. Short windows let jitter dominate. Longer windows make the statistical centre obvious, and they expose “low and slow” beacons that check in only every few hours.

Doing it by hand with Wireshark / tshark. The beacons lab shows the manual approach. Filter one pair in Wireshark and add a column for frame.time_delta_displayed — the time since the previous displayed packet. Or do the same with tshark:

tshark -r sample.pcap -T fields -e ip.src -e ip.dst -e udp.dstport \
  -e frame.time_delta_displayed \
  'ip.src==192.168.88.2 && ip.dst==165.227.88.15' | head -25

In the lab dataset the packets arrive almost exactly one second apart. Export interval and packet size to CSV and plot them as histograms:

tshark -r sample.pcap -T fields -E separator=, -e ip.len \
  -e frame.time_delta_displayed \
  'ip.src==192.168.88.2 && ip.dst==165.227.88.15' > sample.csv

A human browsing produces a long-tailed, messy histogram. A beacon produces one tall spike (or a narrow hump if jittered) for both interval and size.

Doing it at scale with RITA. By hand you can check one pair; a network has tens of thousands. RITA scores every pair automatically, from 0 to 1, combining several statistics. The lab explains the key fields:

• Score — overall likelihood of beaconing; the closer to 1, the stronger.
• Interval skew / size skew — near 0 means the distribution is symmetric, as you would expect from a timer with jitter.
• Dispersion (MAD) Median Absolute Deviation — near 0 means intervals or sizes cluster tightly around the median.
• Connection count and mode — how many check-ins, and the most common interval and size.

The classic lab command was rita show-beacons <dataset>. In current releases you run rita import on your Zeek logs and browse the beacon results in rita view, sorted by score. Treat anything above roughly 0.8 as a priority, and anything above 0.9 that is not a known updater as a likely finding.

What’s usually benign. NTP (it beacons by design), Windows Update and other software updaters, AV/EDR cloud check-ins, telemetry agents, monitoring (SNMP polls, health checks), mail clients polling IMAP, and some ad or analytics scripts in browser tabs left open overnight. You will allow-list these on your first few hunts and then the list stabilises.

What’s suspicious. A high-score beacon to a destination that only one internal host talks to. A beacon to a recently registered domain or to a bare IP. A beacon over HTTP(S) with a rare user-agent or JA4 fingerprint. A beacon that continues when the user is on leave.

A note on evasion. Very long sleeps (hours), heavy jitter (50%+), domain fronting through CDNs and C2 over legitimate SaaS (Slack, Teams, Graph API, Google Sheets) all make beacon analysis harder. The defence is longer analysis windows, grouping by destination domain (from SNI or DNS) rather than only by IP, and comparing against how many other internal hosts use the same service. A beacon to graph.microsoft.com from every laptop is normal. A beacon to a specific SharePoint tenant from one server is not.

Hunt 3: DNS — C2, tunnelling and abuse

The idea. DNS is the protocol everyone trusts and almost nobody blocks. Even locked-down networks that force web traffic through a proxy usually let internal resolvers forward queries to the internet. That makes DNS a favourite covert channel: tools such as dnscat2, iodine, and the DNS listeners in Cobalt Strike and Sliver encode data in query names and receive tasking in responses (MITRE ATT&CK T1071.004 and T1572).

The weakness attackers cannot avoid. The DNS lab explains it neatly: if the implant asks the same name twice, a resolver will answer from cache and the query never reaches the attacker’s name server. So every request needs a unique subdomain. “The more requests an attacker sends out, the more unique subdomains they need to use.” That gives us a simple, robust metric: unique subdomains per base domain.

Step 1 — count unique subdomains per domain:

cat dns.log | zeek-cut query | sort | uniq \
  | rev | cut -d '.' -f 1-2 | rev \
  | sort | uniq -c | sort -nr | head

This de-duplicates every query, trims each name to its last two labels (the base domain), and counts how many distinct names each base domain had. CDNs such as akamaiedge.net or akadns.net will appear with a few hundred or thousand. In the lab, the malicious domain r-1x.com had 62,468 unique subdomains. ACM's rule of thumb: a domain with more than 1,000 unique FQDNs deserves a look — especially if there are few or no actual connections to the resolved IPs.

Caveat: cut -f 1-2 mishandles multi-part TLDs such as .co.id or .co.uk. For production use, parse with the Public Suffix List (e.g., Python's tldextract) → https://github.com/john-kurkowski/tldextract. RITA's DNS view also counts subdomains at every level, so dnsc.r-1x.com and r-1x.com are shown separately.

Step 2 — look at the queries themselves:

cat dns.log | zeek-cut id.orig_h query qtype_name answers | grep 'r-1x\.com' | head

Red flags: long hexadecimal or base32/base64-looking labels (6dde0175375169c68f.dnsc.r-1x.com), labels near the 63-character limit, high entropy, fixed-length answers, and a steady rate that continues overnight.

Step 3 — who is doing it, and is there a real connection?

cat dns.log | zeek-cut id.orig_h query | grep 'r-1x\.com' | cut -f 1 | sort | uniq -c

If the source is your internal resolver, you need the resolver’s own query logs to find the real client — one reason sensor placement matters. Then extract the answers and check conn.log for direct connections to those IPs. A domain with tens of thousands of lookups and zero follow-on connections is the textbook DNS tunnel.

Step 4 — query-type distribution:

cat dns.log | zeek-cut qtype_name | sort | uniq -c | sort -nr

Normal networks are dominated by A, AAAA, HTTPS/SVCB and some PTR. TXT, NULL and CNAME are favoured by tunnels because they carry more data per response. In the lab, the infected network showed 108,911 TXT queries, compared with around 65 in a clean dataset of similar size.

Other DNS hunts worth running:

• Rogue resolvers. Internal hosts sending DNS directly to an external server instead of your resolver (id.resp_p == 53 to a non-approved IP). A rogue resolver is when a company computer bypasses the corporate DNS and asks some external DNS server directly. If your policy says all DNS must go through the corporate resolver, this is worth investigating. Also look for DNS over HTTPS (DoH) to public providers from hosts that should use the corporate resolver.
• DGA and NXDOMAIN spikes. Malware using domain generation algorithms tries many random names and most fail. Count NXDOMAIN responses per host; a workstation with thousands of NXDOMAINs to random-looking .top, .xyz or similar TLDs is a strong lead.
• Newly registered domains. ACM notes that attackers favour domains less than 7 days old. Enrich your top-talker domains with WHOIS/RDAP creation dates.
• Fast flux. One domain resolving to many IPs across many ASNs with very short TTLs.

Hunt 4: Outliers and protocol anomalies

The idea. The first three hunts look for specific C2 behaviours. Outlier hunting is broader: find the hosts and pairs that are unusually high or low on some measure, then ask why. The technique is stack counting (also called long-tail analysis): count occurrences of a value across the whole environment and look at the extremes. Most of what you find will be benign, but you will learn your network — and occasionally the rare value is the attacker. The outliers lab covers the basics.

4a — Connection count per pair:

cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto \
  | awk 'BEGIN{ FS="\t" } { arr[$1 FS $2 FS $3 FS $4] += 1 } \
    END{ for (key in arr) printf "%s%s%s\n", key, FS, arr[key] }' \
  | sort -nrk 5 | head

The top of this list is often DNS. That itself is interesting: caching should keep legitimate DNS volume to any single external server modest, so a host making tens of thousands of DNS connections to an unknown server is worth a second look.

4b — Bytes transferred (exfiltration):

cat conn.log | zeek-cut id.orig_h id.resp_h orig_bytes \
  | awk 'BEGIN{ FS="\t" } { arr[$1 FS $2] += $3 } \
    END{ for (key in arr) printf "%s%s%s\n", key, FS, arr[key] }' \
  | sort -nrk 3 | head

orig_bytes is what the internal host sent. Workstations are normally consumers, not producers: they download far more than they upload. A useful refinement is the producer–consumer ratio (PCR), (orig_bytes − resp_bytes) / (orig_bytes + resp_bytes), which runs from −1 (pure download) to +1 (pure upload). A workstation that suddenly flips to a strongly positive PCR towards a single external destination — especially a cloud storage provider or VPS, especially outside working hours — is a classic exfiltration lead (ATT&CK T1048, T1567).

4c — Rare HTTP user-agents:

cat http.log | zeek-cut user_agent | sort | uniq -c | sort -n | head

Sorting ascending puts the rarest user-agents at the top. In a well-patched fleet, browser user-agents should be fairly uniform. Rare strings point to unpatched systems, unauthorised software, scripts (python-requests, curl, Go-http-client) or malware with a hard-coded or slightly malformed UA. Then pivot:

cat http.log | zeek-cut id.orig_h id.resp_h host uri user_agent | grep '<UA string>'

Remember that the Host header is attacker-controlled. Cross-check it against dns.log: did this client actually resolve that name to that IP?

4d — Port and protocol mismatch. Zeek identifies protocols by content (Dynamic Protocol Detection), not by port, and records the result in the service field. That lets you find:

• Non-standard ports for standard protocols — SSH on 443, HTTP on 8443 to a residential IP (ATT&CK T1571).
• Standard ports carrying something else — traffic on 443 where service is empty or not ssl, or traffic on 53 that is not DNS.

cat conn.log | zeek-cut id.resp_p proto service | sort | uniq -c | sort -n | head -30

4e — TLS certificates and fingerprints. With most traffic encrypted, metadata is your friend. From ssl.log and x509.log look for:

• Self-signed or untrusted certificates on outbound connections (validation_status in ssl.log). ACM treats a self-signed cert as a minor modifier towards "suspicious" and an Extended Validation cert as a modifier towards "benign".
• Default C2 certificates. Unmodified framework defaults (for example, well-known default Cobalt Strike or Metasploit certificate subjects) still show up in real intrusions.
• Odd certificate attributes — very short or very long validity, random-looking subject names, free CA certs on brand-new domains, missing SNI.
• Rare client fingerprints. JA4+ (successor to JA3) fingerprints TLS clients (JA4), servers (JA4S), HTTP clients (JA4H), certificates (JA4X) and SSH (JA4SSH), and has a Zeek package. Stack-count JA4 values across the fleet: the browser fingerprints are common; a JA4 seen on only one host, talking to one destination, is interesting.

Bonus: east-west and lateral movement

Everything above focuses on egress, because that is where C2 must appear. If you have internal sensors, the same stack-counting approach works for lateral movement (TA0008). Zeek’s smb_files.log, smb_mapping.log, dce_rpc.log, rdp.log, kerberos.log and ntlm.log let you ask:

• Which workstations talk SMB, RDP, WinRM (5985/5986) or SSH to other workstations? In most networks, workstation-to-workstation admin traffic should be near zero.
• Which hosts call remote service or task-scheduler RPC interfaces (svcctl, atsvc, ITaskSchedulerService) — the footprint of PsExec-style execution and remote scheduled tasks?
• Which hosts write to ADMIN$ or C$ shares?
• Which host suddenly requests Kerberos service tickets for many SPNs (Kerberoasting) or DRSUAPI replication from a non-DC (DCSync)?

Pivot: from “suspicious pair” to a verdict

A network finding is a lead, not a conclusion. Steps 3 and 4 of the method turn it into a decision.

Evaluate the internal host.

• Identify it: DHCP lease, asset inventory, AD computer object, owner.
• Find the process: EDR network telemetry or Sysmon Event ID 3 (network connection) and Event ID 22 (DNS query) map the connection to a process, user and parent process.
• Check whether its other behaviour fits: is a printer making HTTPS beacons? Is a database server browsing the web?
• Passive fingerprinting (DHCP and TLS fingerprints, user-agents) helps when the host has no agent.

Evaluate the destination.

• Ownership: IP, ASN, hosting provider. Is it a business partner, a SaaS you use, or a VPS?
• Domain age and registration (WHOIS/RDAP). Under 7 days is a strong indicator.
• Popularity: is it in a top-sites list (e.g., Tranco or Majestic Million)? Note that attackers abuse popular platforms too.
• Reputation: AbuseIPDB, Spamhaus, VirusTotal, abuse.ch feeds, your own CTI. Treat this as a minor modifier: crowdsourced lists contain false positives, and absence from a list proves nothing.
• How many other internal hosts talk to it? One out of 5,000 is very different from 4,000 out of 5,000.

Scoring and disposition

ACM’s training proposes a simple, defensible way to make the call. Score each host from 0 (safe) to 100 (compromised) using two kinds of evidence:

• Major modifiers — strong integrity indicators: a persistent long connection or high-score beacon with no business reason, protocol misuse (tunnelling, port mismatch), DNS tunnelling patterns, large data transfers to a threat-intel-flagged destination.
• Minor modifiers — supporting clues: a rare user-agent or JA4, a self-signed certificate, a newly registered domain, a threat-intel hit on its own, a destination no other host uses.
• Negative modifiers — evidence of legitimacy: an EV certificate, a documented business relationship, a signed and expected process on the host.

Add them up and choose one of three outcomes: allow-list (benign, record the reason), collect more data (uncertain: add PCAP, EDR, longer window), or escalate to incident response. The exact numbers matter less than consistency: two analysts looking at the same evidence should reach the same disposition.

Quick ATT&CK map for network hunts

• Long connections, beacons — T1071 Application Layer Protocol, T1573 Encrypted Channel, T1095 Non-Application Layer Protocol
• DNS C2 and tunnelling — T1071.004 DNS, T1572 Protocol Tunneling
• DGA and fast flux — T1568 Dynamic Resolution
• Port/protocol mismatch — T1571 Non-Standard Port
• C2 via SaaS / CDNs — T1102 Web Service, T1090.004 Domain Fronting
• Large uploads — T1041 Exfiltration Over C2 Channel, T1048, T1567

Coming up in Part 3

Reading commands is one thing; running them is another. In Part 3 we build a free hunting lab (Zeek, tshark, RITA, and full platforms such as Security Onion and Malcolm), pull real malicious traffic from public datasets, and work through five hands-on exercises that mirror the hunts in this article.

References and further reading

• Active Countermeasures — How to Threat Hunt Your Network
• Active Countermeasures — Network Threat Hunting training slides (PDF)
• Threat Hunting Labs — Long Connections, Beacons, DNS, Outliers
• RITA on GitHub
• FoxIO — JA4+ network fingerprinting
• MITRE ATT&CK — Command and Control (TA0011)
• PuppyGraph — Network Threat Hunting
• SANS — FOR572: Advanced Network Forensics

Hunting on the Wire : A Practical Guide to Network Threat Hunting — Part 2 was originally published in FMI Cyber Security Consulting Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you have ever tried to intercept network traffic from a Flutter application on a mobile device, you may know the frustration. You configure your device’s Wi-Fi proxy, set up your Burp Suite, and launch the app, only to watch the app function perfectly while your proxy history remains completely empty. That’s what I experienced when pentesting a Flutter-based mobile application.

The Flutter’s Proxy Frustration

Unlike standard mobile applications, applications built with Flutter use Dart’s HttpClient, which completely ignores system-level proxy settings by default. It reaches out directly to the internet, making traditional Wi-Fi proxy setups useless for developers and security researchers.

This issue has been open since 2019 up to the time I write this, you can check it on https://github.com/flutter/flutter/issues/26359.

You may know of or have even used reFlutter, but I don’t like that solution, and if you don’t like it either, we are the same. If you didn’t know about reFlutter, you can give it a try if you want.

To capture Flutter app traffic, we have to stop fighting the application layer and move down to the network layer.

On Android, it is pretty easy, we can utilize iptables for this.

But what about on iOS? Is there a solution that works on both Android and iOS?

We can utilize a WireGuard VPN. By routing our device through a WireGuard VPN tunnel, we force all device traffic to pass through our Burp Suite at the network layer. For my specific setup, I use a Linux machine because this solution relies heavily on iptables to manipulate the routing rules. It might be possible to achieve this natively on Windows or macOS using their respective networking tools, but I haven't tested it myself, so this article will focus entirely on the Linux approach.

WireGuard Setup for Burp Suite Interception

To force the mobile device’s traffic into our Burp Suite, we need to set up a WireGuard server and manipulate its routing table. The core of this technique lies in the PostUp and PostDown rules within the server's configuration file. These commands execute automatically when the VPN interface is brought up or torn down.

Here is the exact routing configuration required to capture the traffic:

PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -t nat -A POSTROUTING -s 10.13.37.0/24 -o wlan0 -j MASQUERADE
PostUp = iptables -t nat -A PREROUTING -i %i -p udp --dport 53 -j DNAT --to-destination 1.1.1.1
PostUp = iptables -t nat -A PREROUTING -i %i -p tcp --dport 53 -j DNAT --to-destination 1.1.1.1
PostUp = iptables -t nat -A PREROUTING -i %i -p tcp -j REDIRECT --to-port 8083
PostUp = iptables -I FORWARD -i %i -j ACCEPT
PostUp = iptables -I FORWARD -o %i -j ACCEPT

PostDown = iptables -t nat -D POSTROUTING -s 10.13.37.0/24 -o wlan0 -j MASQUERADE
PostDown = iptables -t nat -D PREROUTING -i %i -p udp --dport 53 -j DNAT --to-destination 1.1.1.1
PostDown = iptables -t nat -D PREROUTING -i %i -p tcp --dport 53 -j DNAT --to-destination 1.1.1.1
PostDown = iptables -t nat -D PREROUTING -i %i -p tcp -j REDIRECT --to-port 8083
PostDown = iptables -D FORWARD -i %i -j ACCEPT
PostDown = iptables -D FORWARD -o %i -j ACCEPT
PostDown = sysctl -w net.ipv4.ip_forward=0

Breaking down the firewall rules reveals exactly how the traffic hijacking works across any mobile device connected to the tunnel:

• Enabling IP Forwarding: sysctl -w net.ipv4.ip_forward=1 instructs the Linux kernel to act as a router, allowing it to pass packets between network interfaces.
• Network Address Translation (NAT): The POSTROUTING rule takes traffic originating from the WireGuard subnet (10.13.37.0/24) and masquerades it out through the internet-facing interface (wlan0).
• The Interception Pivot: The REDIRECT --to-port 8083 rule intercepts all TCP traffic entering the WireGuard interface (%i) and forcefully redirects it to local port 8083. This is the port where Burp Suite must be configured to listen as an invisible proxy.
• Permitting Forwarded Traffic: The two FORWARD rules explicitly instruct the firewall to accept traffic flowing into and out of the WireGuard tunnel, ensuring packets are not dropped.
• Forcing Reliable DNS Resolution: The two DNAT rules targeting port 53 ensure that all DNS queries (both UDP and TCP) from the mobile device are forwarded directly to Cloudflare’s 1.1.1.1. This prevents DNS resolution failures or leaks while inside the tunnel.
• Clean Teardown: The PostDown rules reverse all of these changes when you stop the WireGuard server, ensuring your machine does not permanently alter its network behavior.

Generating Your WireGuard Configuration

I built a simple static web app that generates these configurations for you. Just plug in your details, and the config will be automatically generated.

This tool is entirely static, nothing is saved, and no data goes to any database.

You can generate your configs right here: patarisac.github.io/wg-config/

Or, if you prefer to run it locally on your own machine, you can grab the code here: github.com/patarisac/wg-config/

If you find it useful, a star on the GitHub repo would make my day.

Once you apply these configs and connect to the VPN, your device’s traffic will finally start flowing into your Burp Suite.

Wrapping Up

Keep in mind that this WireGuard setup only handles the routing. It forces the traffic into your proxy, but it does not magically bypass SSL pinning. If the Flutter app enforces certificate pinning, you still have to use tools like Frida or Objection on a jailbroken or rooted device to bypass those pinning checks.

Also, treat this method as an alternative that is mainly useful for iOS. While it works perfectly on Android, it is honestly not necessary. If you have a rooted Android phone, it is much easier and faster to just use an adb shell and apply iptables rules directly on the device. But for an iPhone where Dart ignores your proxy and you can't just run local firewall commands, this WireGuard trick gets the job done.

Solving Flutter’s Proxy Issues with WireGuard was originally published in FMI Cyber Security Consulting Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we will explore JWT attacks using the JWT Editor extension for Burp Suite. We will demonstrate these attacks using the following PortSwigger labs:

1. JWT authentication bypass via weak signing key
2. JWT authentication bypass via JWK header injection
3. JWT authentication bypass via algorithm confusion

Each lab provides the credentials wiener:peter, and the objective is to access the /admin endpoint by exploiting JWT vulnerabilities.

JWT Authentication Bypass via Weak Signing Key

In this lab, the application uses a weak, guessable secret key to sign JWTs with the symmetric HS256 algorithm. This allows an attacker to discover the secret through a dictionary attack. Once the secret is recovered, the attacker can modify JWT claims, such as changing the sub claim from wiener to administrator, and re-sign the token to gain access to the admin interface.

After logging in with the wiener:peter credentials and accessing /admin, we receive an unauthorized response: Admin interface only available if logged in as an administrator.

First we need to guess the JWT secret:

1. Send the request to /admin to Repeater, then open the JSON Web Token tab.
2. Select Attack → Weak HMAC Secret.
3. The HMAC secret is successfully recovered: secret1.

Once the secret has been recovered, we need to create a key using that secret in the JWT Editor tab:

1. Select New Symmetric Key.
2. Enter the recovered secret, secret1, in the Specify secret field.
3. Generate the key.
4. Note the generated key ID, ff43e26c-6efc-4a0b-a068-6753c36dc58d, and click OK.

Finally, we can exploit the vulnerability by modifying the JWT claim and signing the token with the recovered secret. Return to the JSON Web Token tab in Repeater:

1. Change the sub claim in the JWT payload from wiener to administrator.
2. Click Sign to sign the modified token using the key we created earlier.
3. Select the signing key with the ID ff43e26c-6efc-4a0b-a068-6753c36dc58d.
4. Select Don’t modify header.
5. Click OK, then send the request to /admin.

The newly signed JWT can now be used to access /admin.

JWT Authentication Bypass via JWK Header Injection

In this lab, the server trusts a public key embedded directly in the JWT header through the JWK parameter. An attacker can generate their own key pair, modify the JWT claims, and sign the token using their private key. If the server fails to verify whether the supplied public key is trusted, the attacker can use the forged JWT to gain access to the admin interface.

After logging in with the wiener:peter credentials and accessing /admin, we receive the following unauthorized response Admin interface only available if logged in as an administrator. To perform a JWK header injection attack, we first need to generate an RSA key in JWT Editor:

1. Select New RSA Key.
2. Select JWK, then click Generate.
3. Note the generated key ID, 08815736-733b-44af-9295-c6e912051972, and click OK.

Return to the JSON Web Token tab in Repeater. We will perform an embedded JWK attack by injecting our public key into the JWT header and signing the modified token with the corresponding private key.

1. Change the sub claim in the JWT payload from wiener to administrator.
2. Select Attack → Embedded JWK.
3. Select the key we generated earlier with the ID 08815736-733b-44af-9295-c6e912051972.
4. Click OK, then send the request.

The Attack → Embedded JWK feature automatically inject our public key, modifies the JWT header, and signs the token using corresponding private key. The resulting JWT can now be used to access /admin.

JWT Authentication Bypass via Algorithm Confusion

In this lab, the server uses the RS256 algorithm to verify JWT signatures. However, it incorrectly handles the RS256 public key as an HMAC secret. This implementation flaw allows an attacker to modify JWT claims and re-sign the token without knowing the server’s private key, potentially gaining access to the admin interface.

After logging in with the wiener:peter credentials and accessing /admin, we receive the following unauthorized response: Admin interface only available if logged in as an administrator. We can retrieve the public key from /jwks.json. The key has the ID b98fa760-e80d-4979-a902-fa2ea91f5344.

Note that we only need to extract the public key object shown below, rather than the entire JSON response:

{
  "kty": "RSA",
  "e": "AQAB",
  "use": "sig",
  "kid": "b98fa760-e80d-4979-a902-fa2ea91f5344",
  "alg": "RS256",
  "n": "st0Wb1r75-noLvBO_F5e1AWQNfrqbA-2InNJVHA1N75bbFtuP6a5VY1k-tIPHRo6A4GqSmfJFk7QyodZ-KuQIfLgqc2YrtmH0R0OwIQIRGpSJGe-C4YDSAeA-tEsD58GZyy7Ksj0nGfg210INLOAP_YMnu59dLnGX8bg6pxA6QDIZ2-6k3phUbF9S0xngqPTRlWfRwLJQxy_G5nLRlOorrE-GqA19Wy00cHZ_hY9AqpWiefR6bs_JuPzEx6mfxNujs3NlRspTiwvJb2087uGGPBrCQJCcqz_J0eSfRyCpwvYkZ8tEGy9unXaWLhB1-pypE0oG9fP8W_ChQRPGJRYgw"
}

We then need to import the public key into JWT Editor:

1. Select New RSA Key.
2. Paste the public key.
3. Confirm that the key ID is b98fa760-e80d-4979-a902-fa2ea91f5344, then click OK.

Return to the JSON Web Token tab for the /admin request in Repeater. After importing the key, we can perform an HMAC key confusion attack by using the public key as the HS256 signing secret.

1. Change the sub claim in the JWT payload from wiener to administrator.
2. Select Attack → HMAC Key Confusion.
3. Select the imported key with the ID b98fa760-e80d-4979-a902-fa2ea91f5344.
4. Keep the default options. If the attack fails, try different options.
5. Click OK, then send the request.

The Attack → HMAC Key Confusion feature automatically signs the modified token using the HS256 algorithm, treating the imported public key as the HMAC secret. The resulting JWT can now be used to access /admin.

Conclusion

These three labs demonstrate how weak signing secrets, improper public key validation, and JWT algorithm confusion can allow attackers to forge tokens and bypass authentication. Using JWT Editor in Burp Suite makes it easier to test these attack scenarios.

To mitigate these vulnerabilities, applications should use strong cryptographic keys, enforce an explicit allowlist of permitted algorithms, validate the source of signing keys, and implement proper server-side authorization checks.

Exploiting JWT Vulnerabilities with Burp Suite JWT Editor was originally published in FMI Cyber Security Consulting Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most detection rules fail silently. They sit in production, green and healthy on the dashboard, and the activity they were written to catch walks straight past them without raising a single alert. No error, no exception, no log line that says I just let that through. The SOC believes it has coverage. It does not.

That gap — between what a rule intends to catch and what it actually catches — is the subject of Adversarial Detection Engineering (ADE) (https://github.com/Adversarial-Detection-Engineering), an open-source framework created by Nikolas Bielski (with co-maintainer Daniel Koifman) that treats the false negative as a first-class engineering defect rather than an accident of tuning. ADE gives that defect a name: a detection-logic bug. And, like any bug class, once you can name it you can hunt it, classify it, test for it, and fix it.

This post is written for the detection engineer, the SOC analyst moving into rule authoring, and the purple teamer who wants a shared vocabulary with the blue team. It covers three things, in order: what the ADE framework actually says and where it fits among the detection-engineering frameworks you already know; how to run it as a repeatable workflow inside a live SOC; and which platforms and tools — Sigma, Atomic Red Team, Caldera, your SIEM, your CI/CD pipeline — you bolt it onto, with the practical mechanics of each.

The mindset shift ADE asks for is small but load-bearing. Stop asking “does my rule detect the technique?” Start asking “what is the full set of things that satisfy my rule’s intent, and which members of that set does my query actually match?” The difference between those two questions is where attackers live.

What ADE actually is: a bug taxonomy for detection logic

The conceptual core is borrowed, deliberately, from software engineering. ADE models a detection rule as a repeatedly-running hypothesis test: it takes a bucket of records and tests each against a set of conditions. The rule has a scope — the human-readable intent, carried in its description and MITRE ATT&CK mappings (“detect PowerShell downloading a file”) — and a detection logic, the machine-interpretable query that is supposed to implement that intent. A detection-logic bug is a mismatch between the two: an attacker behavior that falls squarely inside the rule’s scope, yet does not trip the query. In confusion-matrix terms, a ground-truth true positive the rule reports as negative. A false negative, caused on purpose.

The framework’s contribution is that it stops treating those misses as one undifferentiated blob and sorts them into a taxonomy: four categories, sixteen subcategories, and (at time of writing) thirty-eight worked technique files, each grounded in real public rules from Sigma, Elastic Security and Microsoft Sentinel. The four categories examples below are the load-bearing structure — learn these and you can place almost any miss:

1. ADE1 — Reformatting in Actions. The logged input is reshaped so a string match fails, even though the behavior is unchanged. Substring manipulation, obfuscation, whitespace and delimiter tricks, normalization asymmetry. The classic: a rule keys on the literal .DownloadString(, and the attacker writes $wc.("Download"+"String")(...). Same download, no match.
2. ADE2 — Omit Alternatives. The rule enumerates one member of an equivalence class and misses the rest. A different LOLBin, a renamed binary, a newer API version, an alternate path, a different file type — all in scope, none listed. If your rule anchors on curl.exe, it says nothing about certutil, bitsadmin, BITS jobs, or a .NET WebClient.
3. ADE3 — Context Development. The attacker shapes the surrounding context rather than the primary action: cloning a process name, hijacking an aggregation threshold, spreading activity past a correlation window (low-and-slow), fragmenting one logical action across several events, spoofing parent lineage, or saturating an engine’s join/groupBy limit so the needed record is silently truncated.
4. ADE4 — Logic Manipulation. The Boolean, filter or field logic is itself wrong or invertible: an AND that should be OR, a negated filter on an attacker-controlled field, or a field that doesn't resolve on the deployed backend and so matches nothing — making the rule structurally blind before an attacker even shows up.

Two supporting tools in the repo turn the taxonomy into something you can run. The Bug Likelihood Test is a fast pre-analysis checklist — roughly a dozen yes/no questions (“Is there a process-name string match that could be renamed?” → ADE3–01; “Are there aggregation operators like >=?” → ADE3-02) that triages a rule in minutes and tells you which category to dig into. The ADE False-Negative Checklist applies four lenses to every rule you review: data-source dependency (does the telemetry even reach the rule?), threshold assumptions, scope assumptions, and environment drift.

One point the authors are emphatic about, and so am I: this is a defensive, purple-team framework. Every lens is answered at the level of “would this rule catch the technique, and what must be true for it to fire?” — never “here is the exact recipe to beat rule X.” You describe categories of gap so the blue team can close them. Weaponizing it against systems you aren’t authorized to test is a different activity with a different name.

Where ADE sits in the detection-engineering stack

ADE doesn’t replace the frameworks you already run; it fills a specific hole none of them were built for. It helps to see the whole stack and what each layer answers.

MITRE ATT&CK tells you what to detect — the technique catalog and the common vocabulary everything else maps to. The Pyramid of Pain (David Bianco) tells you how durable a given detection is: hashes and IPs are trivial for an attacker to change, while TTPs are painful, so you should aim your logic high on the pyramid. Palantir’s Alerting and Detection Strategy (ADS) tells you how to document a detection to a quality bar — its template forces a Strategy Abstract, an ATT&CK categorization, and, tellingly, an explicit Blind Spots and Assumptions section where the Detection Engineer records where the alert may not fire. Detection-as-Code tells you how to ship and govern detections: version control, peer review, linting, CI/CD, automated testing.

What none of those does, at the level of query mechanics, is tell you why a specific, reasonable-looking rule won’t fire against an in-scope variant. ADS gives you a box labeled “Blind Spots and Assumptions”; ADE gives you the taxonomy to fill it in rigorously instead of from memory. The Pyramid of Pain tells you to detect behavior rather than strings; ADE1 and ADE2 show you the precise ways a behavior-named-as-a-string still collapses back into a brittle IOC. In the language SpecterOps popularized in Capability Abstraction and On Detection: Tactical to Functional — the idea that a technique has an abstraction chain from tool down to the operation it actually performs — ADE is a structured way to walk down that chain and find which rung your detection accidentally pinned itself to.

It also isn’t alone in treating adversarial review as central. The emerging work on automated detection engineering — for example Mitiga’s FORGE, which runs a generate-then-adversarially-validate pipeline with a separate reviewer agent — is the same instinct ADE formalizes by hand: a detection is not done when it’s written, it’s done when something has actively tried to make it miss and failed.

The table below is the one-glance version.

In short: the other frameworks make detections well-documented, durable and shippable. ADE makes them robust against someone who read them.

Running ADE in a live SOC: the workflow

The framework is only useful if it becomes a habit your team repeats, not a one-off audit. Here is how to operationalize it. Treat it as a loop you run against your detection backlog continuously, and bolt onto every new rule before it ships.

Who does it. This is where ADE gives purple teaming a shared language. The detection engineer owns the rule and the fix. The red/purple teamer owns the emulation that proves the gap is real. An analyst or threat hunter often spots the candidate gap first, from an incident where a rule “should have” fired. The ADE taxonomy is the lingua franca between them — a miss gets a label (ADE3–01), not a shrug.

The loop, step by step:

1. Select the rule and state its scope. Pull one production (or candidate) rule. Write down, in one sentence, what it intends to catch and its ATT&CK mapping. If you can’t state the scope crisply, that’s finding zero — an ambiguous rule can’t be reasoned about.
2. Run the Bug Likelihood Test. Walk the dozen checklist questions. Does it string-match a command line (ADE1–01)? Anchor on one binary or method (ADE2–01)? Use a threshold or time window (ADE3–02/03)? Key on parent process (ADE3–05)? Negate a filter on an attacker-controlled field (ADE4–01)? Each “yes” is a hypothesis about where a false negative lives. This takes minutes and tells you whether the rule is worth a deep review.
3. Apply the four lenses. For each flagged area, ask the checklist’s questions properly. Data-source dependency first — is the telemetry this rule needs actually ingested on the in-scope hosts? A rule that assumes Sysmon EID 1 on a fleet running only Security 4688 (with command-line auditing off by default) contributes zero coverage, silently. Then threshold, scope, and environment-drift assumptions.
4. Form the adversarial hypothesis — at the category level. For each gap, write it as a testable statement: “The same technique performed with an alternative in-scope binary / reformatted command / below the count threshold / spread past the window is predicted to produce no alert.” Note: this is a category of variant, routed to your authorized red-team lead to turn into a concrete test under rules of engagement — not an execution recipe you write into the ticket.
5. Validate in a lab, under authorization. Emulate the variant on a monitored test host and check whether the rule fired. This is the step that converts a suspected bug into a confirmed one. Atomic Red Team and Caldera (next section) are how you do it repeatably.
6. Harden the rule and re-test. Apply the fix — broaden the match, OR in alternatives, switch to an immutable field, add a presence-guard to a negated filter, add a companion “canary” rule for the evasion itself — then re-run the same emulation to prove the gap closed and nothing regressed.
7. Document honestly and record residual blind spots. Update the rule’s ADS-style record: what you tested, what’s now covered, and what you still can’t detect. “Not covered: direct registry modification — needs a separate rule” is a valid, valuable finding. A rule that passes all four lenses gets a one-line note saying so and a reminder to confirm it’s actually enabled.

Cadence. New rules get steps 1–4 as a pre-merge gate (cheap, fast, no lab needed). Existing rules get the full loop on a rotation — prioritize by ATT&CK coverage importance and by Bug Likelihood score. Tie it to your purple-team calendar: each emulation exercise should close its confirmed gaps back into the rule base, so the exercise produces hardened detections, not just a report.

The discipline that makes this work is adversarial review by someone other than the Detection Engineer themselves. You are biased toward the rule you just wrote; you will read your own query and see the technique it catches, not the three it misses. Have a second engineer (or, increasingly, an automated reviewer) run the lenses cold.

The toolchain: what to pair with ADE, and how

ADE is a reasoning framework, not a product. Its value shows up when you wire it into tools you (probably) already run. Here is the practical mapping, in the order you’d use them around the loop.

1. Sigma — the portable rule you reason about

Sigma is the default starting point, and the repo’s own bug-pattern references lean on it. Because a Sigma rule is backend-agnostic YAML that transpiles to most SIEM languages, it’s the cleanest artifact to read “how is this technique usually caught” and to apply the taxonomy to.

How to use it with ADE: Read the detection: block as the hypothesis test. A list under one key is OR; separate keys are AND; |all forces AND across a list. Most ADE4 (logic) bugs are visible right here — the infamous example is a rule that ANDs Net.WebClient with (.DownloadString( OR .DownloadFile(), where the fix is simply condition: 1 of selection_*. Then check the ADE1 reformatting modifiers: is there a |windash for -// prefixes? A |base64offset for encoded commands? An OR onto OriginalFileName to resist renaming? Crucially, transpilation is not lossless — a Sigma rule's real behavior depends on the backend (regex flavor, case sensitivity, null-handling on not filter). Always inspect the compiled query on your actual backend, not the YAML. Field typos (TargetFileName vs the correct TargetFilename) resolve to no column and fail silently — a pure ADE4-04 bug.

2. Your SIEM/EDR — where the bug is real or not

Elastic Security, Microsoft Sentinel, Splunk, and CrowdStrike LogScale each have public rule repos and each has platform-specific traps the ADE bug_patterns/ catalog documents.

How to use it with ADE: map the generic category to the concrete fix for your platform. A few high-leverage examples straight from the framework’s mitigations guidance:

• Elastic threshold rules (ADE3-02): don't count per attacker-controlled field alone; add threshold.cardinality (distinct sources against a target) and a coarser account/tenant bucket so distributing activity across entities doesn't duck under.
• Elastic eql sequence (ADE3-03): set a realistic maxspan, not 5s, or decouple the steps — otherwise a sleep expires the correlation.
• Sentinel aggregation (ADE3–02): avoid per-IPAddress thresholds and Top-N ranking; use cardinality and absolute thresholds, and corroborate with an orthogonal signal.
• Sentinel case sensitivity (ADE1/ADE4): ==, has, in are case-sensitive in KQL and silently miss variants; use =~, in~, has_cs deliberately.
• Process identity everywhere (ADE3–01): anchor on process.executable / hash / code-signature plus args, never process.name alone, which any rename defeats.
• Negated filters everywhere (ADE4–01/04): guard every not filter on an optional field with a presence check (field|exists: true), so an absent field can't invert the rule.

3. Atomic Red Team — cheap, fast variant validation

Atomic Red Team (Red Canary) is a library of small, ATT&CK-mapped tests you run on a host to generate the telemetry a technique produces. It’s the fastest way to execute step 5 of the loop.

How to use it with ADE: pick the atomic test(s) for your technique, run them on a monitored lab host, and confirm the baseline rule fires. Then use the variants — many atomics parameterize the binary, path or arguments, which is exactly ADE2 (alternatives) and ADE2–03 (locations) made executable. Run the canonical form, confirm the alert; run the in-scope variant, check whether the alert disappears. A disappearing alert is a confirmed detection-logic bug. Where no atomic exists for the exact variant, that’s the cue to route it to your red-team lead rather than improvising one in the SOC.

4. Caldera — chained, context-shaping emulation

MITRE Caldera runs autonomous adversary profiles — sequences of abilities, not single atomics. It’s the right tool for the ADE3 (Context Development) category, where the bug only appears across a chain: lineage spoofing, event fragmentation, low-and-slow timing, aggregation across entities.

How to use it with ADE: build (or adapt) an adversary profile that performs the in-scope technique the “ordinary” way, verify your correlation/sequence rules fire, then adjust the profile’s timing or structure to probe an ADE3 hypothesis — e.g. introduce a delay that exceeds a correlation window, or split a piped command so the malicious string never lands in one process-creation event. Caldera’s planners and fact system let you exercise the context an ADE3 rule depends on, which single atomics can’t reach.

5. CI/CD + Detection-as-Code — make it non-optional

The mitigations guidance is explicit: build automated bypass testing into your CI/CD pipeline. This is where ADE stops being an audit and becomes a guardrail.

How to use it with ADE: store detections as code (Sigma YAML or your platform’s native format) in version control. On every pull request, run a pipeline that (a) lints the rule and validates field names against a known schema — catching ADE4–04 silent-field bugs before merge; (b) transpiles and diffs the compiled query; and © in a detection test lab, replays the relevant Atomic Red Team tests, including the variant set, and fails the build if the canonical test fires but a known in-scope variant doesn’t. The Bug Likelihood checklist can even live as a PR template — the Detection Engineer ticks the boxes, the reviewer checks them cold.

6. LLM-assisted review — the newest layer

The ADE repo itself ships a Redamon skill (ade_scoper) that packages the taxonomy for an agent to plan detection-aware emulation; the broader trend (Mitiga's FORGE and similar) points the same way — a generate-then-adversarially-validate loop with a separate reviewer model, precisely because a model, like a human, shouldn't grade its own detection. Used carefully and kept inside authorization and human go/no-go, an LLM is a useful fresh-eyes reviewer for running the four lenses across a large rule base — but it's an accelerant for the workflow above, not a replacement for the lab validation that actually proves a bug exists.

A worked example, end to end

Let’s run one rule through the loop so the abstractions land. Take the real Sigma rule Suspicious PowerShell Download (id: 3236fcd0-...), which the ADE docs themselves dissect.

Step 1 — Scope. Intent: detect a PowerShell script downloading a file. ATT&CK: T1059.001 (Command and Scripting Interpreter: PowerShell).

Step 2 — The hypothesis test. The detection: block requires Data|contains: 'Net.WebClient' AND (Data|contains: '.DownloadString(' OR '.DownloadFile('). In Boolean terms: Hit when A AND (B OR C).

Step 3 — Bug Likelihood Test fires twice. There’s a substring match on an attacker-controllable field → ADE1–01 (Substring Manipulation). And it enumerates only two download methods when PowerShell offers many → ADE2–01 (Method/Binary).

Step 4 — Adversarial hypotheses (category level).

• ADE1–01: the literal .DownloadString( includes the . and (. A script that constructs the method name as a string and invokes it dynamically never produces that exact substring — predicted no match, same download.
• ADE2–01: Net.WebClient is one of several download primitives. A script reaching the same outcome through a different .NET member or reflection isn't enumerated — predicted no match.

Step 5 — Validate. In the lab, run the canonical form (plain WebClient.DownloadString) and confirm the alert fires. Then run the reformatted and alternative-method variants and watch the alert not appear. Both bugs confirmed.

Step 6 — Harden. The root cause is chaining Net.WebClient before the OR. The repo's own fix is to break that dependency:

condition: 1 of selection_*

… so either the WebClient indicator or a download-method indicator alone can trip the rule. That closes the immediate AND trap. But the review isn't done: Net.WebClient and the method names can still be reformatted or swapped, so you layer defenses — add reformatting-tolerant modifiers, OR in additional download primitives, and keep a behavioral companion rule (e.g. a Sysmon EID 15 Zone.Identifier / ZoneId=3 rule that catches the outcome — a file marked as internet-downloaded — regardless of the method used to fetch it). That outcome-based rule is the Pyramid-of-Pain move: it keys on something the attacker can't trivially reshape.

Step 7 — Document. Record the two bugs, the fix, the companion rule, and the residual: exotic download primitives not in the OR list remain uncovered by the string rule; the Sysmon EID 15 rule is the backstop; re-test on next review. That honest blind-spot note is the whole point — the next engineer inherits the truth, not a false sense of coverage.

Two bugs, one afternoon, a hardened rule plus a backstop, and a documented residual. That’s the loop at its most ordinary — and most SOCs have hundreds of rules with exactly this shape waiting to be run through it.

Metrics, and the pitfalls that bite

The hard part of false negatives is that they don’t show up in the usual SOC metrics. Alert volume, mean-time-to-respond, true-positive rate — none of them can see a rule that never fires. So you have to measure the process, not just the outcomes.

Useful signals to track: the share of production rules that have been through an ADE review; the count of confirmed detection-logic bugs found and closed per cycle; rules that have never fired since deployment (a strong smell of an ADE4–04 silent-field or ADE1 data-source bug — the mitigations guide explicitly says to flag these for review); coverage of in-scope ATT&CK techniques validated by emulation rather than just mapped on paper; and the Bug Likelihood score distribution across the rule base, so you can prioritize. On the maturity side, the Detection Engineering Maturity Matrix and the DEBMM give you a program-level benchmark; ADE slots in as the thing that moves you from “we write and map rules” to “we validate rules against an adversary who read them.”

The pitfalls worth naming up front:

• Confusing a rule that exists with coverage that exists. The single most common ADE finding is that the telemetry a rule needs isn’t collected on the hosts in question. Check data-source dependency first, every time.
• Over-fitting the fix to the one tested bypass. Broadening a rule to catch exactly the variant you tested just moves the goalposts by one. Fix the class — switch to an immutable field, invert positive allow-lists into alert-broadly-suppress-trusted — not the single string.
• Grading your own homework. Detection Engineer run ADE reviews catch far less than a second set of eyes. Build adversarial review into the process structurally.
• Letting it drift into offense. Keep every finding at the category level and inside authorization. The framework’s own guardrails are clear: detection rules are generally out of scope for vendor disclosure, so handle examples responsibly, and route anything that starts to look like an execution recipe to the authorized red-team lead.
• One-and-done. Attackers evolve, LOLBins get discovered, APIs get versioned, your environment drifts. A rule that was robust last quarter may not be now. ADE is a loop, not an audit.

Closing: detect like someone is reading your rules

The assumption baked into a lot of detection content is that the attacker doesn’t know how they’re being watched. That assumption has never been true, and ADE is what it looks like to stop pretending otherwise. The framework’s real gift isn’t the sixteen subcategories — it’s the reflex: every rule is a hypothesis, and a motivated adversary gets to pick the test case. Once a team internalizes that, the four categories become second nature and the loop becomes muscle memory.

Start small. Take ten of your highest-priority production rules, run the Bug Likelihood Test on each this week, and pick the worst offender to drive through the full loop with an atomic test. You will almost certainly confirm at least one silent false negative — and that single closed bug is worth more than another dashboard.

Resources

The framework

• ADE Framework docs — the theory, taxonomy, and checklists
• adeskills repository — 38 worked technique files, per-platform bug-pattern catalogs, ruleset search guidance, the Redamon ade_scoper skill

Complementary frameworks

• Palantir Alerting & Detection Strategy (ADS) — the detection documentation template, incl. Blind Spots & Assumptions
• MITRE ATT&CK — the technique catalog everything maps to
• The Pyramid of Pain — David Bianco, on indicator durability
• SpecterOps — Capability Abstraction — the abstraction-chain view of a technique

Tools

• SigmaHQ/sigma — portable detection rules
• Atomic Red Team — ATT&CK-mapped atomic tests
• MITRE Caldera — chained adversary emulation
• Public rule repos to read real logic: Elastic detection-rules, Splunk security_content, Azure-Sentinel, CrowdStrike logscale-community-content

Further reading on the discipline

• What is Detection Engineering (Vectra) — lifecycle and framework comparison
• Automated Detection Engineering: FORGE (Mitiga) — generate-then-adversarially-validate pipelines

Adversarial Detection Engineering in the Real SOC: A Practitioner’s Guide to the ADE Framework was originally published in FMI Cyber Security Consulting Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why the network is the threat hunter’s ground truth — and how to think about hunting before you touch a single log.

This is Part 1 of a three-part series for SOC analysts, threat hunters and DFIR practitioners. Part 1 covers the why and the mindset. Part 2 goes deep on the technical hunts (long connections, lateral movement, beacons, DNS, protocol anomalies, outliers). Part 3 is hands-on: lab setup, tooling, datasets and exercises.

Every incident responder has lived this moment. The EDR console is green. The SIEM has no high-severity alerts. Then a third party calls: your data is on a leak site, or one of your IPs is talking to known infrastructure.

The numbers say this is still common. Mandiant’s M-Trends 2026 reports a global median dwell time of 14 days, up from 11 days the year before. For cyber-espionage intrusions the median was 122 days. One espionage campaign (BRICKSTORM) persisted for nearly 400 days on network appliances — devices that typically run no EDR agent at all. And 48% of intrusions were still first detected by someone outside the victim organization.

That gap — between “nothing is alerting” and “we are compromised” — is exactly where threat hunting lives. And in my experience, the network is the best place to start looking.

What threat hunting is (and what it isn’t)

Threat hunting is the proactive, human-led search for adversary activity that your existing controls did not detect. The key word is proactive: you are not waiting for an alert. You start from the assumption that something may already be inside and go looking for evidence that proves or disproves it.

Active Countermeasures (ACM), the team behind RITA and AC-Hunter, frames it even more sharply in their Network Threat Hunting training: a hunt is a proactive validation of every system connected to the network, executed without assumptions, which produces a compromise assessment for each device. In other words, the output of a good hunt is not “we found nothing”. It is “we checked these hosts against these behaviours, and here is the disposition of each one.”

It helps to separate hunting from its neighbours:

• Detection engineering / SOC monitoring is reactive and automated. A rule fires, an analyst triages. It only catches what someone already wrote a rule for.
• Incident response starts once you know there is an incident. Scope is defined by the alert or the report.
• Threat hunting starts with a question, not an alert. Its outputs feed both of the above: confirmed findings go to IR; repeatable patterns become new detections.

If your “hunting” is re-running yesterday’s SIEM queries and closing the tickets, you are doing monitoring. That is valuable, but it is not hunting.

Why start on the network?

ActiveCounterMeasures (ACM) training uses a line that has stuck with me for years: “you can hide processes, but you can’t hide packets.”

On the endpoint the attacker is on home turf. They can unhook EDR, kill or blind agents with vulnerable drivers, clear event logs, run in memory, or simply live on a device that never had an agent — a VPN concentrator, a firewall, a printer, an OT controller, a hypervisor. Logs on a compromised host are evidence the attacker controls.

The network is different. For an intrusion to be useful, the attacker needs to talk to it:

• They need a command-and-control (C2) channel to send instructions and receive results.
• They need to move laterally to reach the data or the domain controller or to any crown jewel assets.
• They usually need to move data out for performing data exfiltration.

Each of those leaves traffic. A sensor placed off-host, on a SPAN port or TAP, records that traffic independently of the compromised endpoint. The attacker can encrypt the content, but they cannot easily hide that a connection happened, how long it lasted, how often it repeated, how many bytes moved, or which domain was resolved first.

This is also why ACM argues against starting a hunt from raw syslog. Syslog was never designed as a security data source, message formats vary by vendor, and much log review collapses into signature matching — what they call the “1990s anti-virus model”. Network metadata, by contrast, is uniform: every connection has a source, a destination, a port, a protocol, a duration and a byte count, no matter which OS or app produced it.

The C2 lens: focus on persistence first

The most practical idea in ACM’s How to Threat Hunt Your Network is ordering your work by threat. Instead of trying to look at everything, start with the evidence that most strongly indicates compromise: persistent outbound communication.

An implant has two ways to stay in touch with its operator:

1. Long connections — keep one session open for hours or days and push commands down it.
2. Beacons — open short sessions on a schedule, just long enough to check in (“any tasks for me?”), then disconnect.

Either way, the pattern is persistent, and persistence is something you can measure from connection metadata alone. ACM’s five-step method builds on that:

1. Identify persistent communication channels leaving the network.
2. Analyse the protocol being used.
3. Evaluate the internal host originating the traffic.
4. Check the reputation of the destination.
5. Disposition: allow-list as benign, or escalate to incident response.

We will walk through each of these technically in Part 2.

Three (or four) ways to start a hunt

NetWitness’ overview of network threat hunting types groups hunts into three families. Splunk’s PEAK framework adds a fourth. Here is how each looks on the wire:

• Hypothesis-driven. You start from a testable statement. “If an implant is using HTTPS C2 from our server VLAN, we will see regular outbound TLS sessions to a destination no other server talks to.” Precise and efficient, but only as good as the hypothesis.
• Intelligence-driven. You start from external knowledge: a vendor report, an ISAC advisory, a CERT bulletin. “Campaign X uses DNS TXT records for tasking and domains registered in the last week.” Great for distributed environments where threats change faster than rules.
• Anomaly / baseline-driven. You start from what normal looks like and hunt the deviations: the one host talking to a new country, the only user-agent seen once, the server that suddenly uploads 20 GB. This finds novel attacks and insiders, but it needs mature data and analysts who know the environment.
• Model-assisted (M-ATH, from PEAK). You use statistics or machine learning to score behaviour — for example, a beacon score — and humans investigate the top of the list. RITA’s beacon scoring, which we use in Parts 2 and 3, is a simple version of this.

In practice, good hunts mix them. A threat-intel report gives you the hypothesis; a baseline tells you what is abnormal; a model ranks the candidates.

PEAK’s three phases are also a useful wrapper for any hunt: Prepare (pick the topic, research, check that the data exists), Execute (analyse, pivot, investigate) and Act (document, automate the detection, communicate).

Where hunting sits on the maturity curve

Two classic models help explain why network hunting pays off.

The Hunting Maturity Model (David Bianco, originally at Sqrrl) goes from HMM0 (relies on automated alerting only) to HMM4 (most successful hunts are automated into detections). Most teams I work with sit at HMM1–HMM2: they collect data and can search for IOCs, but rarely create new analytics. Network hunting is one of the fastest ways to climb, because the analytics — duration, frequency, volume, rarity — are simple to express and automate.

Bianco’s Pyramid of Pain explains the other half. Blocking an IP or a hash costs the adversary almost nothing. Detecting their behaviour — how their C2 checks in, how their tunnel abuses DNS — is near the top of the pyramid and is expensive for them to change. Beacon timing and DNS subdomain patterns are behavioural. Rotating infrastructure does not make them go away.

What you need to see: network data sources

The PuppyGraph guide to network threat hunting makes a point that is easy to forget: network evidence is only useful when you can connect it to who and what. You need the traffic, plus the context to tie an IP to a host, a user and a process. Here are the main sources and their trade-offs:

• Full packet capture (PCAP) — tcpdump, Arkime, or a commercial recorder. Maximum fidelity: payloads, file carving, protocol reconstruction. Heavy on storage, so retention is often measured in days. Best for deep-dive validation, not for scanning months of history.
• Network security monitoring logs (Zeek) — Zeek turns packets into rich, structured logs: conn.log, dns.log, http.log, ssl.log, x509.log, files.log and more. Roughly 1–2% of the size of the PCAP, so you can keep months. This is the workhorse for most of what follows in this series.
• NetFlow / IPFIX / VPC flow logs — cheap, everywhere, built into routers, switches and cloud platforms. No application layer, and often sampled, so beacon and DNS analysis is limited. Still excellent for volume, rarity and east-west network hunting.
• Firewall and proxy logs — widely available; useful for egress analysis and URL/user-agent hunting. Quality varies by vendor; some firewalls only log session end.
• DNS logs — resolver query logs or passive DNS. Critical for DNS-based C2, DGA and newly-registered-domain hunts.
• Identity and asset context — DHCP leases, VPN sessions, authentication logs, CMDB/asset inventory. Without these, “10.1.4.37” is just a number.
• Endpoint telemetry — EDR network events or Sysmon Event ID 3 tie a connection to the process that made it. This is your pivot target after the network hunt finds something.

Sensor placement matters more than tools

The best analytics fail if the sensor is in the wrong place. A few rules from the field:

• Capture inside the egress firewall, before NAT. Otherwise every outbound connection appears to come from the firewall’s public IP and you lose the internal host.
• Capture before the internal DNS resolver forwards queries, or log on the resolver itself. Otherwise all DNS appears to come from the resolver.
• Do not ignore east-west traffic. Perimeter sensors see C2 and exfiltration, but not lateral movement between internal segments. Core switch SPANs or virtual TAPs in hypervisors and cloud VPCs close that gap.
• Measure your visibility before you hunt. Confirm that the sensor actually sees every egress path, including guest Wi-Fi, OT links, cloud egress and direct internet breakouts at branch offices.

Know the limits

Network hunting is powerful, but it is not magic. Be honest about the blind spots:

• Encryption. TLS 1.3, encrypted ClientHello (ECH) and DNS over HTTPS (DoH) hide content and, increasingly, destination names. You will rely more on metadata: timing, size, certificates, and fingerprints such as JA4+.
• Volume. Unbounded searches across terabytes overwhelm analysts. Scope every hunt.
• Identity ambiguity. DHCP churn, NAT, shared proxies and cloud IPs that change owners make attribution harder.
• Noisy baselines. Software updaters, telemetry agents, chat clients and monitoring tools all beacon. Expect false positives and build an allow-list as you go.

What a successful hunt produces

A hunt that “found nothing” is still a success if it produces outputs. At the end of every hunt you should have:

1. A disposition for every host in scope — benign, suspicious (needs more data), or compromised (escalated to IR).
2. An updated allow-list of known-good long connections and beacons, with the business reason recorded.
3. New or improved detections for anything that can be automated.
4. A list of visibility gaps discovered along the way (missing logs, unmonitored network segments).
5. Documentation of scope, data, queries and findings, so the hunt can be repeated.

Measure the hunting program by those outputs — time-to-disposition, detections created, gaps closed — not by the number of hunts run.

Coming up in Part 2

In Part 2 we get our hands dirty. We will hunt C2 the way an analyst actually does it: finding long connections and beacons in Zeek conn.log, catching DNS tunnels by counting unique subdomains, spotting outliers in bytes, user-agents and certificates, and scoring each finding so you can make a defensible call.

References and further reading

• Active Countermeasures — How to Threat Hunt Your Network
• Active Countermeasures — Network Threat Hunting training slides (PDF)
• PuppyGraph — Network Threat Hunting
• NetWitness — Types of Network Threat Hunting
• Splunk SURGe — The PEAK Threat Hunting Framework
• Mandiant — M-Trends 2026
• SANS — FOR572: Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response

Long Live Cyber Defenders!!!

Hunting on the Wire : A Practical Guide to Network Threat Hunting — Part 1 was originally published in FMI Cyber Security Consulting Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why File Transfer?

Between 2020 and 2025, the same extortion group — Cl0p — executed an identical playbook against four consecutive managed file transfer products: Accellion FTA, Fortra GoAnywhere, Progress MOVEit, and the Cleo product suite. The 2023 MOVEit campaign alone impacted over 2,700 organizations and more than 90 million individuals. Exploitation of the Cleo flaw was still active as late as February 2025.

Note what didn’t happen there. No AES was cracked. No elliptic curve collapsed. What was exploited was SQL injection, authentication bypass, and remote code execution in software sitting at the perimeter — software that held the organizations’ most sensitive data.

This is the first lesson, and it’s worth stating up front so it doesn’t get lost: the strength of your cipher is the easiest part of the problem. The hard parts are protocol design, key handling, and verification discipline.

But there’s another side of the spectrum that’s rarely discussed. At the opposite end from enterprise-grade MFT servers lies a far more resource-constrained class of data transfer: small devices sending data over narrow channels with no supporting infrastructure at all. No TLS, no certificate authority, no internet connection. There, data transfer often happens with no encryption whatsoever — not because nobody cares, but because of the prevailing assumption that cryptography is too expensive for devices that small.

Four Questions, One Primitive.

Every file transfer protocol — from SCP to S3 multipart uploads — must address four aspects:

• Confidentiality — can an intermediary read the contents? This is the one everyone remembers.
• Integrity — large files are split into chunks. If an attacker swaps chunk five with one from another file, reorders chunks, or truncates the transfer mid-way while claiming it’s complete, the received file is corrupted without anyone noticing. This one gets overlooked.
• Authenticity— a valid chunk that’s recorded and replayed remains cryptographically valid unless a sequence number is bound into the authentication.
• Forward secrecy — your keys will eventually leak. The question is how much becomes exposed when they do. With one static key for the system’s whole lifetime, the answer is: everything, including traffic an attacker recorded three years ago.

AEAD addresses the first three all at once:

A stands for associated data: it is unencrypted but is also authenticated. This is where the chunk number, the last chunk marker, and the sender’s ID are placed — plaintext, but cannot be modified without causing the tag verification to fail.

Proper AEAD returns a failure, not garbage plaintext, when the tag doesn’t match. This isn’t an academic detail: when the Ascon-AEAD128 implementation was submitted to OpenSSL, one review finding was that decryption released the plaintext before tag verification completed. Bugs of that class still happen in the most heavily audited project in the world.

Ascon & X25519

On August 13, 2025, NIST finalized SP 800–232, a lightweight cryptography standard built on the Ascon family — including Ascon-AEAD128, Ascon-Hash256, and its XOF variant. Ascon had previously won as the primary lightweight-encryption choice in the CAESAR competition.

What makes it interesting: a sponge/duplex construction with a 320-bit state, no key schedule to expand and store, and no S-box lookup tables in memory — so no cache-timing leakage from lookup tables either. A single permutation handles encryption, hashing, and key derivation, so an entire protocol can be built from one primitive: Ascon-XOF works as a KDF out of the box, no need to import HKDF-SHA256 separately. Library support is moving: wolfSSL added it in April 2025, with OpenSSL support following.

⚠️ Ascon v1.2 ≠ SP 800–232. The final standard changes the initial value, adjusts to little-endian formatting for microcontroller performance, and adds options such as nonce masking. The test vectors differ. I implemented v1.2; if you need interoperability today, target SP 800–232.

For key exchange, X25519 beats NIST P-256 on all three metrics that matter on constrained devices: 523 ms, 47 KB, 55 mW, versus P-256’s 1,582 ms, 64 KB, 103 mW (Tanksale 2024, 48 MHz MCU).

But more important than the choice of curve is its ephemerality. A key pair generated fresh for each session and discarded afterward means a leak today doesn’t unlock yesterday’s recordings. The age file encryption format does exactly this: for every single file, a new ephemeral X25519 key is generated and run through ECDH against the recipient's public key to wrap the file key.

One caveat: raw ECDH is vulnerable to man-in-the-middle (MitM) attacks. Without authentication, an attacker can swap both public keys, establish two separate shared secrets, and read everything in between. ECDH provides confidentiality, not identity.

The Design

Two layers of keys. A static pre-shared key (PSK), provisioned onto both devices in advance, is used only to authenticate the handshake — never to encrypt data. A session key derived via ECDH handles the actual data chunks. This separation is what makes the scheme work: the PSK isn’t repeatedly exposed with every chunk, and a leaked session key doesn’t compromise any other session, past or future.

Four decisions worth highlighting:

• The ephemeral public key is sent encrypted and authenticated under the PSK. This is what closes the MitM hole — an attacker without the PSK can’t inject their own public key, since the handshake packet would fail tag verification.
• The counter doubles as the nonce and lives in the associated data. The receiver reconstructs the nonce without it ever being sent in full, and because the counter is authenticated, it can’t be forged for a replay.
• Verification order: counter first, tag second. Stale packets are rejected with zero cryptographic operations.
• Ephemeral private keys and shared secrets are explicitly zeroed immediately after the session key is derived. Without this step, forward secrecy is a claim on paper, not in practice.

Data frame: ID 2 · counter 8 · timestamp 4 · ciphertext 8 · tag 16 = 38 bytes. Handshake frame: ID 2 · nonce 8 · pubkey 32 · tag 16 = 58 bytes.

For an 8-byte chunk, the cryptographic overhead is nearly four times the size of the data — the worst-case scenario that could be designed. For a 64 KiB chunk, that same overhead becomes 0.05%.

The Result

Before any measurement was taken: X25519 was checked against the RFC 7748 test vectors; Ascon-128 against the reference implementation, including 400 random combinations of AD length and plaintext length; plus negative tests with a corrupted tag, corrupted ciphertext, and corrupted AD. A crypto implementation that runs without errors doesn’t mean it’s correct — broken encryption still produces convincing-looking random bytes.

Hardware: ESP32 at 240 MHz, LoRa SX1276, SF7/BW125. The four schemes were run round-robin so environmental drift would be spread evenly across all of them.

ECDH is practically free. The difference between the second and third rows is 230 cycles and 0.14 KB of RAM, in exchange for forward secrecy and MitM resistance. The handshake itself takes 342.6 ms, but since it happens only once every 100 chunks, it amortizes to 3.43 ms per chunk — 0.17% of the send interval.

Ascon needs about 35% fewer cycles than AES-GCM for decryption (25,273 vs. 38,631 — equivalently, AES-GCM takes roughly 53% more cycles than Ascon), even though the ESP32 has an AES hardware accelerator. The reason: the accelerator handles the AES block cipher, but GHASH still runs in software, and on an 8-byte payload, the GHASH overhead outweighs whatever the accelerator saves.

This finding reverses, though, on 64 KiB chunks on a CPU with AES-NI. AES-GCM’s per-byte cost drops sharply, while Ascon stays bound to a fixed number of permutation rounds per 8-byte block. Ascon’s advantage is an advantage on constrained devices with short messages, not a universal one.

This is why age chose ChaCha20-Poly1305 over AES-GCM: not because AES is weak, but because AES is hard to make fast and safe without hardware support. Pick a primitive based on the platform and message size, not on whichever was standardized most recently.

Five attack scenarios were run against separate attacker nodes. Ascon+ECDH withstood eavesdropping, injection, replay, and MitM-on-handshake. The static-PSK scheme withstood eavesdropping, injection, and replay too — MitM-on-handshake doesn’t apply to it, since it has no ECDH handshake to attack — but it failed the one test that actually matters for key compromise: forward secrecy. I recorded three key-rotation periods, leaked the second period’s session key, and tried decrypting the other two. With static PSK, all three periods were exposed. With Ascon+ECDH, periods 1 and 3 both failed tag verification — rejecting the packets outright rather than handing the application incorrect plaintext.

Now for the part that usually doesn’t make it into articles like this. I flooded the channel with fake chunks:

The cryptographic side works perfectly. Zero forged packets got through, and verification latency stayed flat regardless of attack rate. And availability still dropped to 20%.

Confidentiality, integrity, and authenticity are three properties. Availability is a fourth, and cryptography doesn’t provide it — that’s handled elsewhere, with rate limiting, channel scheduling, and per-identity quotas. Tie that back to MOVEit: those organizations used TLS; their data was encrypted in transit. What failed was authorization and input validation sitting on top of the cryptography.

Limitations

Test conditions were controlled: two nodes, 1-meter distance, line-of-sight. The payload was a fixed 8 bytes, so Ascon’s partial-block code path never executes during application use (though it was verified separately via multi-block test vectors). Performance figures don’t generalize across platforms — 24,624 cycles on the Xtensa LX6 doesn’t map directly onto Cortex-M or x86–64. This is an Ascon v1.2 implementation, not SP 800–232. Side-channel analysis is out of scope; any crypto implementation needs an independent audit before production use. And as shown above, availability under flooding was not addressed by the cryptographic design at all.

Conclusion

Lightweight cryptography is mature enough for serious use now. Ascon has a NIST standard behind it, and on small devices with short messages it beats AES-GCM by a wide margin. Ephemeral key exchange is nearly free — systems still running on a static key for the device’s entire lifetime are carrying technical debt that will eventually come due. Framing details decide everything: chunk numbers and end-markers bound into the associated data are the difference between a secure transfer and an encrypted one that can still be truncated or scrambled. And correct cryptography is a prerequisite, not a guarantee — all four MFT products breached over those four years used sound encryption. The failure was never in the cipher.

Reference: Implementation of Lightweight Cryptography Ascon and Elliptic Curve Diffie-Hellman (ECDH) on LoRa Data Transmission Mechanism

IoT Security: Securing File Transfers Over Untrusted Channels was originally published in FMI Cyber Security Consulting Services on Medium, where people are continuing the conversation by highlighting and responding to this story.