The Beacon That Only Fires on Tuesdays
Your threat-intel platform pushes an indicator feed. One entry is a domain, cdn-sync-update.net, tagged "C2, high confidence" with a first-seen date 14 months ago. Your proxy logs show three internal hosts resolving and connecting to it every Tuesday between 02:00 and 02:15, roughly 40 KB each time, TLS to port 443. The feed's source is a vendor with a mixed historical accuracy record. VirusTotal shows the domain clean at present; passive DNS shows it previously resolved to a bulletproof host. The three hosts are in the finance VLAN. No other detections fired. Your manager asks whether to isolate the hosts tonight.
1. Assess the confidence of this indicator. What makes it stronger and what makes it weaker, and how does that shape your response?
Read the worked answer
Strengtheners: the domain is observed in your own telemetry, not just a feed; the timing is machine-regular (weekly, same window, consistent volume) which is atypical of human browsing; the passive-DNS history ties it to a bulletproof host; the hosts sit in a sensitive VLAN.
Weakeners: the feed vendor has a mixed record; VirusTotal currently shows clean, which is weak evidence either way because C2 domains are often clean by design; the tag is "high confidence" but that is the vendor's confidence in the indicator's history, not in its relevance to your environment; no other detection corroborates.
The judgement: an indicator matched in your own logs is far more actionable than an unmatched feed entry. Weekly beaconing to a domain with a bad hosting history is enough to act, but "isolate tonight" is a heavy response to a single uncorroborated signal. A proportionate first step is to collect volatile data and packet capture from one host, review what process owns the connection, and check whether the 40 KB payloads are consistent. If the process is unexplained, isolate. Document that the decision rests on behavioural regularity plus hosting history, not on the feed's label alone.
2. The feed's first-seen date is 14 months old but your proxy only retains 90 days of logs. How do you reason about the gap, and what does it mean for scoping?
Read the worked answer
The gap is a visibility limit, not evidence of absence. Two hypotheses fit the data:
- The beacon has run longer than 90 days and you simply cannot see its start. The Tuesday cadence and steady volume support a long-lived implant.
- The activity began within the retention window and the domain's age is coincidental.
You cannot distinguish these from proxy logs alone. To narrow it, look at sources with different retention: DHCP leases, endpoint EDR process history, DNS server logs if retained longer, firewall flow records, and authentication logs for the three hosts. Look for the earliest timestamp any source shows a connection, and for a process or scheduled task that predates it.
For scoping, treat the 90-day window as a floor on dwell time, not a ceiling. That means: assume possible long-term compromise when assessing data exposure, check whether the finance hosts touched payment systems, and widen the hunt to any host that ever resolved the domain. State the retention limit explicitly in your report so decision-makers understand why the timeline has a hard left edge.