Baselines built from observed history get poisoned by the intrusion they are meant to catch · numbers from the LANL dataset
Source Reddit Cybersecurity
Discussion
This report discusses the challenge of detecting lateral movement attacks in corporate networks using behavior baselines built from observed history. The key issue is that the baseline can become 'poisoned' by the intrusion itself, causing the attack to blend into what the system considers normal behavior over time. The analysis is based on experiments using synthetic training data and real authentication logs from Los Alamos National Laboratory. The findings highlight limitations of detection methods relying solely on historical baselines and emphasize the need for carefully managed baseline update windows to balance detection accuracy and staleness.
r/cybersecurity (opens in a new tab)u/Best_Particular35520 points0 comments
I spent a couple of days building a lateral-movement detector and measuring it against the LANL auth logs. Two things came out that are about detection in general, not about my particular model, and I think they are worth putting in front of people who run this stuff for real.
1. The counter everyone starts with is defeated by topology.
"Many distinct accounts from one host" sounds like a reasonable signal. Accounts seen per source host in a clean four-hour slice:
| host type | accounts |
|---|---|
| domain controllers | 2996, 2752, 2686, 2590 |
| file servers | 252, 118, 110 |
| workstations | 1, 2, 1 |
| the compromised foothold | 104 |
The foothold sits between the servers and the workstations. Any threshold that catches it also catches half your servers. Same story for destination counts. On the held-out set that counter scores AUC 0.618 - barely better than a coin.
2. A baseline built from observed history is poisoned by the intrusion.
Novelty only means something relative to what a machine has done before. But that history accumulates by observation, so a long-running intrusion enters the machine's own "normal" and stops looking new. By day 12 the foothold "knew" 84 accounts, and 49 of them were the compromised ones that had been travelling through it. 58.3% of its normal history was the intrusion itself. Median novelty on labelled windows fell from 1.00 on day 8 to 0.57 on day 12.
Freezing the baseline fixes that and creates the opposite problem: it goes stale at about 0.25% of machines per day. By day 29, 6.1% of machines were unknown to it, and 39% of all false alarms on the held-out set came from exactly those machines. On day 8 there were none.
Operating point I ended up with: a baseline no younger than a week and no older than two or three.
A corollary worth stating: allow-lists of the form "this host passed a review, exclude it from analysis" are an accelerated version of the same poisoning.
What the detector itself did, for context: trained on generated data only - no labelled incident from any real network - an ensemble of six small LSTMs put 16 real attack windows in the top 23 rows out of 3.6 million, at 7 false alarms. The threshold counter needs roughly 161,000 false alarms to reach the same sixteenth window. It is a triage filter, not an auto-block: half the labelled windows sit in the tail, indistinguishable from noise on hourly features alone.
Full write-up with the measurements, the failures, and the configs: https://habr.com/en/articles/1081090/
The thing I genuinely do not know: how do commercial UEBA products handle the baseline problem? I described it as a measured property of my setup, but it should affect anything that profiles behaviour from observed history without an external check on credentials. If your product solved it, I would like to know how.