Intermediate·350 points·1 solve
Command & Control Beacon Analysis
Learn to find an implant that is invisible to every technique based on where traffic goes or how much of it there is. You will measure the intervals between requests for each source-destination pair, use the coefficient of variation to separate machines from people, and — critically — learn why the most regular traffic in a network is almost never the malicious traffic.
Implanted software has to ask its operator for instructions. Holding a connection open would be obvious, so it checks in on a schedule: connect, ask, take a short answer, disconnect, wait, repeat. Two techniques you have already used are defeated by this on purpose. Volume analysis fails because a check-in is a few hundred bytes, which puts it beneath every update service and telemetry endpoint in the estate. Reputation analysis fails because a competent operator does not register a domain that can be blocked — they abuse a service that is already trusted, already sanctioned, and already used by real people in the business. Both of those are true here. What is left is timing. People are irregular; programs are not. Measure the gaps between consecutive requests for a given pair and take the coefficient of variation — the standard deviation divided by the mean — which is unitless and therefore comparable across schedules of different lengths. Now the part that catches people out. The most regular traffic in this network is not the implant; it is infrastructure. Monitoring agents and update checkers run on a fixed timer and sit at a coefficient of essentially zero, and there are dozens of those pairs here. An implant deliberately adds random jitter to its wait so that it does NOT sit at zero, because matching exact periodicity is the easy rule to write. So the answer is the band in between: far too regular to be a person, not regular enough to be a scheduled task. Confirm it with a second, independent signal — a beacon sends the same structure each time, so its request sizes are identical, whereas a person using the same service sends whatever they are working on. Evidence is in /var/log/soc: incident-brief.md, proxy.log, asset-inventory.csv, and beacon-analysis-reference.md.
Your tasks
1
Confirm the earlier hunts really do fail
Before trying anything new, reproduce what has already been done: rank destinations by total bytes, and check every destination against the sanctioned-services list in asset-inventory.csv. Satisfy yourself that neither surfaces anything — the implant's destination is sanctioned and its traffic is a rounding error. Understanding why these come back clean is the point, because it tells you what kind of signal is left.
2
Measure timing per source-destination PAIR
Do not aggregate by destination alone. One of the sanctioned services is used by several members of staff quite legitimately, so in aggregate it looks exactly like what it is: a tool people use. Group by (hostname, destination) instead, sort each group's timestamps, take the differences between consecutive requests, and compute the mean and standard deviation. The ratio of the two is your ranking metric.
3
Resist the top of the ranking
Sort your pairs by that ratio and look at the lowest values. They are perfectly periodic and there are a lot of them, and every single one is a monitoring agent or an update checker doing exactly what asset-inventory.csv says it does. Identify the service that is the most regular of all — one of the questions asks for it, because being able to name what you correctly ruled out is part of the finding. Then keep going down the list and look for the first pair that is clearly machine-driven but NOT perfectly periodic.
4
Confirm with a second, independent signal
Timing alone should not convict. For your candidate pair, count the distinct values of the outbound-size field and compare that with the same count for the OTHER hosts talking to the same destination. A person produces a wide spread; a program producing the same structure every time produces one value. Record that value, and record how many other hosts use that destination legitimately — the fact that the destination is shared is exactly why it survived the earlier hunts.
5
Scope it and map it
Establish the machine, the destination, the request path the implant uses (it differs from the paths real users hit), roughly how long it waits between check-ins, how many check-ins there are, and when the first one happened. Cross-check the host in asset-inventory.csv — what that machine holds is why the brief mentions contractual notification. Then map the activity to the ATT&CK technique for command and control conducted through a legitimate external web service rather than attacker-owned infrastructure.
Answer the questions
Start the lab, investigate the evidence in the terminal, and answer the questions here.