SEC504 - Hacker Tools, Techniques, and Incident Handling

Lab 1.2 - Network Beacon Detection with RITA

Solo, Lab

Print command sheet

Focus: Threat Hunting

Level: SEC504

Date: May 2026

Artifacts: Sanitized RITA UI, Zeek log, and config.hjson screenshots from the SEC504 falsimentis dataset

TL;DR

•Imported a week of falsimentis Zeek logs into RITA, triaged a 98.60% beacon to a Canonical NTP server as a false positive
•Tuned config.hjson with a CIDR safelist and an external threat-intel feed (malwaresum), then re-imported the dataset
•Surfaced three HIGH severity C2 beacons to 167.172.201.123 disguised as www1-google-analytics.com, and identified four compromised internal hosts via an awk pivot on access.log

Skills demonstrated

Zeek log triage (conn.log, dns.log, http.log, ssl.log)Beacon detection with RITAThreat-intel feed integrationFalse-positive tuning via CIDR safelistSquid/Zeek access.log pivoting with grep and awk

Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.

Why this matters

Modern adversaries blend C2 into legitimate-looking DNS names and ride low-rate beacons that human eyes miss. RITA's beacon score plus a tuned safelist plus a threat-intel feed is the open-source recipe for finding that traffic in a real Zeek pipeline. The skill is not running the tool — it is recognizing which 'high severity' findings are noise and which are the real thing, and knowing how to tune the pipeline to demote the noise without burying the signal.

Context

This lab demonstrates the SEC504 network-threat-hunting workflow with RITA (Real Intelligence Threat Analytics) by Active Countermeasures. Import a week of Zeek logs from the falsimentis dataset, triage RITA's beacon-scored output, tune false positives via the CIDR safelist, wire in a threat-intel feed, then re-import to surface real C2 traffic disguised as Google Analytics.

Tools used

RITAZeekClickHouseMalwareSumawkgrep

Steps taken

1Stage the falsimentis dataset

The SEC504 falsimentis dataset is a multi-day capture pre-converted to Zeek logs. Listed the logs directory to confirm the standard Zeek stack is present: conn.log, dns.log, http.log, ssl.log, files.log, x509.log, weird.log. Zeek's tab-separated format is what RITA expects on import.

2Import Zeek logs into RITA

Ran ./rita.sh import -l log/ ~/labs/falsimentis/. RITA stood up its three containers (clickhouse, syslog-ng, rita-rita-1), ingested the logs, built the connection summary, ran beacon scoring, then ran HTTP, SSL, and DNS analytics. ClickHouse is the column store under the hood; the import is fast because it is bulk-loading into a columnar engine, not parsing on read.

$ ./rita.sh import -l log/ ~/labs/falsimentis/

-ltell RITA the input is Zeek log format

log/subdirectory holding the logs

falsimentisdataset name (becomes the database)

3Open the RITA UI and read the beacon column

RITA's TUI ranks connections by severity. One HIGH severity row: 172.16.42.20 → 91.189.89.198 with a 98.60% beacon score, 3-second duration, 0 subdomains, prevalence 1/9 (11%). A high beacon score plus low prevalence is exactly the signature analysts are told to chase, but high score alone is not enough. The next step is to verify the destination.

4Confirm or refute on MalwareSum

Looked up 91.189.89.198 on MalwareSum. The reputation report identified the IP as belonging to AS41231 Canonical Group Limited, network 91.189.88.0/21, range 91.189.88.0 – 91.189.95.255. Score 623 upvotes / 1 downvote, with comments confirming it is the Canonical NTP server. A 98.60% beacon to NTP is exactly the behavior NTP is supposed to exhibit, so this is a textbook false positive. The signal is real, but the verdict is benign.

5Cross-check with dns.log

While in the logs directory, grepped dns.log for lolcats.org, another low-severity destination that surfaced in the RITA report. The query returned a single A-record lookup from 172.16.42.2 → 138.68.44.115, NOERROR, type A. Notable but not the priority lead — confirms RITA's prevalence column is sensible.

$ cd ~/labs/falsimentis/logs/
$ grep lolcats.org dns.log | head -1

6Tune config.hjson - safelist Canonical NTP

Ran ./rita.sh view falsimentis to load the dataset, then opened config.hjson in gedit. The config ships with a CIDR safelist for common false-positive sources (Microsoft, Mozilla, AWS, Verizon CDN, etc.). Added "91.189.89.198/24" so future imports do not waste analyst time on the Canonical NTP traffic.

$ ./rita.sh view falsimentis
$ gedit config.hjson

Tune config.hjson - safelist Canonical NTP

7Confirm the safelist entry

Highlighted the new "91.189.89.198/24" entry inside the // array of CIDRs block. CIDR scoping is intentional: covering the /24 prevents tomorrow's NTP traffic from a sibling Canonical IP from producing the same false positive.

8Wire in a threat-intel feed

Set threat_intel.online_feeds to ["http://malwaresum.sunsetisp.com/threatfeed"]. Threat-intel feeds are how RITA marks a destination as 'known bad' without depending on the analyst's recall. The next import will tag matching destinations with the Threat Intel icon in the UI.

9Delete and re-import so the new config applies

Ran ./rita.sh delete -ni falsimentis to drop the dataset, then re-imported with the same import command. Config changes apply at import time, not at view time, so the delete-and-reimport step is mandatory whenever the safelist or threat-intel block changes.

$ ./rita.sh delete -ni falsimentis

-ninon-interactive (do not prompt)

Delete and re-import so the new config applies

10Re-read the RITA UI after tuning

The Canonical NTP entry is gone (safelisted). Three new HIGH severity rows appear: 172.16.42.108, 172.16.42.3, and 172.16.42.2 all beaconing to 167.172.201.123 with 0% beacon score (suggesting a long-lived session rather than periodic beacon), durations of 1h04m to 1h49m, prevalence 7/9 (78%), and the red Threat Intel marker matched against the malwaresum feed. 78% of monitored internal IPs talking to the same external destination, with three of them maintaining hour-plus sessions, is operator-level C2 traffic.

11Pivot to access.log - DNS-spoofed C2

Greped access.log for www1-google-analytics.com (one of the destinations listed by RITA as Low severity in the same UI). One hit: 172.16.42.107 sent a POST to http://www1-google-analytics.com/collect, but the proxy logged ORIGINAL_DST/167.172.201.123. The hostname is a typosquat of www.google-analytics.com and the real destination is the same C2 server flagged HIGH severity by the threat-intel feed. The attacker proxied C2 through a fake-analytics name to blend in with normal web traffic.

$ grep www1-google-analytics.com access.log | head -1

12Read the full proxied request

Expanded the same grep to show full request lines. Multiple POSTs to /collect from internal hosts, all proxied to ORIGINAL_DST 167.172.201.123, all with text/html response bodies. /collect is the legitimate Google Analytics measurement endpoint, which is what makes the cover convincing. The HTML response (instead of the expected gif or 204) is the tell.

$ grep www1-google-analytics.com access.log

13Enumerate every compromised internal host

Used awk to pull column 3 (source IP) from every access.log row matching www1-google-analytics.com, then sort -u to dedupe. Four hosts surfaced: 172.16.42.103, 172.16.42.105, 172.16.42.107, 172.16.42.109. Combined with the three hosts already flagged by RITA (172.16.42.2, .3, .108) the scope is at least seven internal endpoints touching the same C2 destination. That is the containment list for the next phase of the response.

$ awk '/www1-google-analytics.com/ {print $3}' access.log | sort -u

/regex/pattern to match against each line

{print $3}emit field 3 (source IP in Zeek/Squid access.log)

sort -udeduplicate

Enumerate every compromised internal host

Key findings

RITA initial scan: 98.60% beacon score from 172.16.42.20 → 91.189.89.198 (refuted as Canonical NTP via MalwareSum)

Tuned config: added 91.189.89.198/24 to CIDR safelist; added malwaresum threat-intel feed

RITA post-tune: three HIGH severity beacons to 167.172.201.123 with Threat Intel hit, prevalence 7/9 internal hosts

C2 channel disguised as www1-google-analytics.com (typosquat), proxied to ORIGINAL_DST/167.172.201.123

Total compromised internal hosts identified: 172.16.42.2, .3, .103, .105, .107, .108, .109

Outcome / Lessons learned

Drove the full RITA tuning loop on a real Zeek capture: imported, triaged, refuted a high-score false positive against IP reputation, edited the CIDR safelist and threat-intel block in config.hjson, re-imported, and ended with three RITA-flagged plus four awk-pivoted internal hosts (seven total) confirmed to be communicating with 167.172.201.123, a C2 destination disguised behind a www1-google-analytics.com hostname.

Schedule the RITA import job nightly on rolling Zeek logs and wire the resulting HIGH severity rows into the SIEM as an enrichment source, not a primary alert (RITA shines as a triage layer, not a paging layer). Maintain the CIDR safelist as code in version control so safelist drift is reviewable. Replace the lab's single online_feed with the org's actual threat-intel pipeline (MISP, OTX, commercial). For the immediate finding, isolate 172.16.42.2/3/103/105/107/108/109, pull EDR data on each, and block 167.172.201.123 plus the www1-google-analytics.com hostname at the proxy.

Security controls relevant

Zeek as the always-on protocol decoder for east-west and north-south traffic
RITA (or similar beacon-detection layer) as a triage overlay on top of Zeek
Curated CIDR safelist for known-benign high-frequency destinations
Threat-intel feed integration for known-malicious destinations
DNS filtering / proxy logging to catch typosquats like www1-google-analytics.com
Egress segmentation so workstation subnets cannot reach arbitrary external IPs

What I took away from this

Beacon score is a lead, not a verdict. The 98.60% score against the Canonical NTP server was a textbook false positive, and any team that pages on raw beacon score will burn out fast. RITA is at its best when it is part of a workflow that ends in MalwareSum / VirusTotal / your internal allow-list, not when it is the alert source itself.

The www1-google-analytics.com typosquat is the lesson of this lab. Operators have figured out that defenders skim hostnames for plausibility, so they pick names that survive a one-second glance. The defense is mechanical: proxy logs every host, you grep the proxy logs, the typosquat shows up because no legitimate Google Analytics traffic ever resolves through a www1-google-analytics.com endpoint. Detection by mechanical comparison beats detection by human recognition.

Tuning RITA's config.hjson is the most important thirty minutes of the workflow. Out of the box, a busy enterprise dataset produces hundreds of high-score rows that are all NTP, CDN, software-update, or telemetry traffic. The CIDR safelist plus a real threat-intel feed is what compresses that pile into the five rows an analyst actually wants to see. Without the tuning step the tool is unusable; with the tuning step it is one of the highest-signal pieces of open-source defensive tooling available.