Lion Cipher Lab
Hunt in a Zeek conn.log: spot beaconing, exfiltration, and odd ports
- SOC Analyst / Blue Team
- Intermediate
- ~40 min
- Free · no account required
Why it matters
conn.log is the backbone of network security monitoring: one tidy record per connection, for every flow that crossed the wire — encrypted or not. A SOC analyst lives in this file. The whole job of network threat hunting is reading connection metadata and asking 'is this shape normal?' — because the three most common signs of an intrusion (a beacon calling home to a command-and-control server, a big pull of data leaving to somewhere it shouldn't, and a service on a port that has no business being there) all show up as a recognisable shape in conn.log long before anyone decrypts a payload. This…
What you'll learn
- reading the Zeek conn.log schema field by field
- decoding conn_state (S0, SF, REJ, RSTO) and the history string
- spotting beaconing from regular-interval, similar-size connections
- spotting data exfiltration from a large orig_bytes flow to an external host
- flagging an unusual service/port pair
- ranking hosts by connection count and by bytes
- pivoting from a suspicious conn.log row to dns.log / http.log / ssl.log to confirm
- judgment: when conn.log is the right lens vs when you need an alerting tool like Suricata
Steps in this lab
- What conn.log is, and WHEN it's the right lens
- The conn.log schema, field by field
- Decode conn_state and the history string
- Here is your conn.log — read it before you hunt
- Hunt 1 — the beacon (regular interval, similar size)
- Hunt 2 — the exfiltration (huge orig_bytes outbound)
- Hunt 3 — the odd service/port pair
- Rank hosts by connection count and by bytes
- Confirm before you raise it — pivot to dns/http/ssl
- The judgment: conn.log vs Suricata, and how to do it better