Threat hunting in Zeek logs: from a raw IP address to the infrastructure behind it

In short: Zeek turns network traffic into structured records of every connection, DNS query, HTTP request and TLS handshake. Every record still ends in a bare IP address. Add context to each address at ingest (location, network type, owner, and whether it belongs to a VPN, a residential proxy or Tor) and a hunt can start from the infrastructure behind the traffic, not from a list of numbers.

What does Zeek record?

Zeek watches traffic passively and writes one log per protocol, linked by a connection identifier, uid. The logs hunters use most:

• conn.log: every connection, with originator and responder addresses and ports, protocol, service, duration, bytes and connection state.
• dns.log: queries, response codes and answers.
• http.log: method, host, URI, user agent and status code.
• ssl.log: TLS version, cipher, server name and whether the handshake completed.
• x509.log: the certificates seen, with subject, issuer and validity.
• ssh.log: client and server software, and whether authentication appears to have succeeded.
• files.log: files carried by the traffic, with file type and, where hashing is enabled, hashes.

Others cover RDP, SMB, Kerberos and more. Together they record what crossed the wire, whether or not the device at either end logs anything: a printer, an industrial controller or a compromised server that has stopped logging still appears when it talks. They are also far smaller than full packet capture, so they can be kept long enough to hunt back through.

Why is an IP address not enough?

Every Zeek record comes down to addresses: id.orig_h and id.resp_h. On its own, an address does not say where it is, what kind of network it is on, who runs it, or whether the connection was relayed.

Adversaries count on that. They route through commercial VPNs, Tor, residential proxy networks and ORB networks, so their traffic arrives from addresses that look like a home broadband customer or an ordinary business. Researching each address by hand does not scale to millions of records.

What context should you add at ingest?

Context is most useful when it is written into each record at ingest, so every search, aggregation and detection can filter on it. For each address:

• Location: country and city.
• Network: the kind of network, for example cloud, with service and region where known, and the announced range.
• Ownership: the autonomous system number and organisation, and the company behind the network.
• Anonymisation: whether the address belongs to a VPN or proxy provider, or is a Tor relay; which provider; whether it was seen in a residential or datacenter pool; and when it was first and last seen.

Timing matters. An address can be a residential proxy exit one week and an ordinary household the next, so first- and last-seen times show whether a match was current when the connection happened. See residential proxy detection.

Which hunts become possible?

With context on every address, a hunt can start from a proxy provider, an ASN or a fingerprint. Four examples:

• Successful logins through anonymising infrastructure. Filter ssh.log for auth_success true where the originator is a proxy exit, a VPN exit or a Tor relay, then pull conn.log for that originator to see what else it touched. Zeek infers success from the encrypted session, so confirm on the host.
• Servers where users are expected. A VPN gateway or webmail service should see people, on consumer and mobile networks. Logins from cloud and hosting networks stand out once network type and owner are in the record.
• One provider across every log. Take a residential proxy provider from a single alert and list every connection relayed through it across conn, dns, http and ssl logs. Grouped by provider rather than by address, rotation stops hiding the operation.
• An ASN from a threat report. List the internal hosts that talked to the autonomous system a report names, and when, then pivot on the server names and certificates from those sessions.

How do you hunt in encrypted sessions?

The start of a TLS handshake is not encrypted. JA4+ fingerprints describe the software behind a session from how it negotiates TLS, HTTP, SSH and TCP, without decryption. FoxIO, the creators of JA4+, publish a Zeek package that adds JA4 and JA4S to ssl.log, JA4H to http.log and JA4T to conn.log.

With a fingerprint in the record, sessions group by the software that made them: one non-browser client reaching your gateway from hundreds of residential addresses is likely one operation, not hundreds of users. JA4DB tells you what a fingerprint means: depending on the data available, what has been observed with it, an interpretation of its parts, statistics, classifications and history. See JA4+ fingerprints explained.

Aggregate instead of scrolling

At Zeek volumes, hunting means asking for summaries, not reading events:

• Top values: the providers, ASNs or JA4 fingerprints most often seen against a given service this week.
• Unique counts: how many internal hosts talked to an ASN, or how many source addresses share one fingerprint. Many addresses behind one fingerprint is a typical sign of rotation.
• Significant terms: what is unusually frequent in a subset compared with the whole, such as the fingerprints over-represented in connections from one proxy provider.

A histogram over time then shows whether a pattern is new, periodic or constant.

From hunt to detection

A hunt that finds something should leave a detection behind, so the next occurrence raises an alert. In the Webscout Observability Platform, findings become custom rulesets and alerts, signals curated from published threat reporting run against the same data, and results go to your SIEM or MISP over the API or as JSONL or CSV.

A SIEM and Zeek complement each other. The SIEM correlates identity, endpoint and application logs across the estate; Zeek records what crossed the wire, including from devices that log nothing. They share one blind spot: an alert on a raw address says nothing about who is behind it.

Beyond your own sensors

Zeek sees what reaches the networks you instrument, not the proxy networks, Tor relays and covert networks of compromised devices that operations are routed through. For vetted government partners, Webscout’s Covert network flows records traffic inside those networks: more than 1.5 billion events a day, with JA4+ fingerprints and IP context on every connection. Search the flows for your own address ranges to see who reaches them through covert networks, including activity that never shows up in your perimeter logs.

Where Webscout fits

The Webscout Observability Platform ingests your Zeek logs alongside PCAP and flows, searches them with high-speed Lucene queries, and applies context to every IP address in every event: Geo IP & network attribution for location, network type, ASN and owner, and Anonymising IPs for the VPN or proxy provider behind an address, or whether it is a Tor relay, with pool type and first- and last-seen times. JA4+ is supported natively, and JA4DB, with access through FoxIO, returns the context behind a fingerprint. For vetted government partners, Covert network flows sits beside your own logs in the same searches. The platform runs in a sovereign European cloud or on your premises, and air-gapped for select partners in high-side environments. Both datasets are also available over the API and as downloads in mmdb, jsonl, csv or parquet.