Baselines built from observed history get poisoned by the intrusion they are meant to catch - numbers from the LANL dataset
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.
AI Analysis
Technical Summary
The analysis focuses on detecting lateral movement attacks, where attackers move through a network using legitimate credentials, making detection difficult. A neural network trained solely on synthetic data was tested against real LANL authentication logs, successfully ranking real attack windows highly with few false alarms. However, a significant problem was identified: baselines built from observed history become poisoned by the intrusion itself, as the attack activity becomes part of the 'normal' profile. This reduces the novelty signal over time, degrading detection performance. Freezing the baseline avoids poisoning but causes it to become stale, leading to false alarms from legitimate changes. The optimal approach found was to maintain a baseline no younger than one week and no older than two to three weeks. The report questions how commercial UEBA products address this inherent baseline poisoning problem.
Potential Impact
The poisoning of behavior baselines by ongoing intrusions reduces the effectiveness of anomaly-based detection systems, allowing attackers to evade detection as their actions become normalized in the system's profile. This can lead to prolonged undetected lateral movement within large corporate networks, increasing the risk of data breaches and system compromise. Additionally, freezing baselines to prevent poisoning introduces false positives due to legitimate changes, complicating incident response.
Mitigation Recommendations
The report suggests maintaining behavior baselines with a controlled age window—no younger than one week and no older than two to three weeks—to balance between poisoning and staleness. It also warns against allow-lists that exclude hosts from analysis, as they can accelerate baseline poisoning. Since this is a measured property of detection methods relying on observed history, defenders should evaluate their UEBA or anomaly detection solutions for baseline management strategies. No official patch or fix applies, as this is a detection methodology limitation rather than a software vulnerability.
Baselines built from observed history get poisoned by the intrusion they are meant to catch - numbers from the LANL dataset
Description
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.
Reddit Discussion
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.
Links cited in this discussion
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The analysis focuses on detecting lateral movement attacks, where attackers move through a network using legitimate credentials, making detection difficult. A neural network trained solely on synthetic data was tested against real LANL authentication logs, successfully ranking real attack windows highly with few false alarms. However, a significant problem was identified: baselines built from observed history become poisoned by the intrusion itself, as the attack activity becomes part of the 'normal' profile. This reduces the novelty signal over time, degrading detection performance. Freezing the baseline avoids poisoning but causes it to become stale, leading to false alarms from legitimate changes. The optimal approach found was to maintain a baseline no younger than one week and no older than two to three weeks. The report questions how commercial UEBA products address this inherent baseline poisoning problem.
Potential Impact
The poisoning of behavior baselines by ongoing intrusions reduces the effectiveness of anomaly-based detection systems, allowing attackers to evade detection as their actions become normalized in the system's profile. This can lead to prolonged undetected lateral movement within large corporate networks, increasing the risk of data breaches and system compromise. Additionally, freezing baselines to prevent poisoning introduces false positives due to legitimate changes, complicating incident response.
Defensive Guidance
The report suggests maintaining behavior baselines with a controlled age window—no younger than one week and no older than two to three weeks—to balance between poisoning and staleness. It also warns against allow-lists that exclude hosts from analysis, as they can accelerate baseline poisoning. Since this is a measured property of detection methods relying on observed history, defenders should evaluate their UEBA or anomaly detection solutions for baseline management strategies. No official patch or fix applies, as this is a detection methodology limitation rather than a software vulnerability.
Technical Details
- Source Type
- Subreddit
- cybersecurity
- Reddit Score
- 0
- Discussion Level
- minimal
- Content Source
- reddit_link_post
- Post Type
- link
- Newsworthiness Assessment
- {"score":27,"reasons":["external_link","established_author","very_recent"],"isNewsworthy":true}
- Has External Source
- true
- Trusted Domain
- false
Threat ID: 6aac00cb55bf5e2cf5881c4b
Added to database: 09/17/2026, 15:01:31 UTC
Last enriched: 09/17/2026, 15:01:37 UTC
Last updated: 09/18/2026, 02:01:32 UTC
Views: 8
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.