Lab 1.2 - Network Beacon Detection with RITA

1. Stage 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.

2. Import 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/

3. Open 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.

4. Confirm 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.

5. Cross-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

6. Tune 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

7. Confirm 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.

8. Wire 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.

9. Delete 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

10. Re-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.

11. Pivot 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

12. Read 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

13. Enumerate 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