// introduction
Detection Rules Encode a Detectable Floor
Rate-based detection logic, rules that fire when an event count exceeds a threshold within a time window, is one of the most common patterns in enterprise SIEM deployments. Brute force, lateral movement, reconnaissance, and exfiltration detection all rely heavily on it. The structural problem: every threshold and every time window is a parameter the attacker can read.
Published detection rules, vendor documentation, public Sigma repositories, and behavioral patterns inferred from probe activity all expose the detection floor. SUNBURST made this operational: the implant implemented a dormancy period of up to two weeks post-installation and limited DNS beacon rates specifically to avoid triggering anomaly detection thresholds. The parameters were engineered against known detection patterns. This is not a theoretical evasion, it is production malware tradecraft.
// foundation
The Three Window Types and Their Bypass Properties
The basic structure: COUNT(event_type) > N WITHIN WINDOW(T). Both parameters define a detection floor. Three window implementations, each with distinct bypass properties:
- Tumbling window: fixed non-overlapping intervals. Bypass: straddle the window boundary, N-1 events in the last second of window 1, N-1 events in the first second of window 2. Total activity: 2(N-1). Alerts fired: zero.
- Sliding window: a rolling window that moves with each event. Harder to exploit than tumbling, but the maximum sustained rate below threshold is still calculable and maintainable indefinitely.
- Session/entity window: groups events within an inactivity timeout. Bypass: pause activity long enough to reset the session window, then resume with a fresh count.
Threshold parameters are not kept secret. The SigmaHQ repository publishes specific count and window values for common detection use cases. Vendor default rules are documented in product knowledge bases. Attackers who probe at varying rates and observe when defensive responses occur can infer thresholds empirically, analogous to fuzzing a network service.
// threat catalog
Six Threshold and Time-Window Abuse Patterns
Distribute activity precisely across the boundary of a tumbling detection window. Round clock boundaries (rules starting at :00, :05, :10) make window start times inferrable without probing.
Tumbling window: 5-min buckets. Threshold: 10 events.
Window 1 [00:00–04:59]: 9 events → no alert
Window 2 [05:00–09:59]: 9 events → no alert
Total events in 10 minutes: 18. Alerts fired: 0.Replace tumbling windows with sliding windows for high-value detection use cases. Accept the computational cost as a security investment.
Distribute attempts across extended time periods or across a large population of source IPs, one attempt per 20 minutes from a rotating /24 block keeps per-source per-window count permanently below any per-IP threshold. This is now the dominant credential attack pattern against enterprise authentication.
Rule: 10 failures from same IP in 5 minutes → alert
Attacker: 1 attempt per 20 min from rotating /24
Per-IP per-window count: 1. Rule fires: never.Shift detection anchor from source IP to target account, N failed attempts against the same account from any source within T. Supplement with population-level global failed authentication rate anomaly detection.
Introduce deliberate delays between actions, random jitter, minimum inter-event gaps, or scheduled activity windows, to ensure no sliding window ever accumulates enough events to breach a threshold. SUNBURST randomized C2 beacon intervals and implemented a post-installation dormancy of up to two weeks specifically to defeat time-window-based anomaly detection.
Rule: 5 DNS queries to new domains in 10 minutes → alert
SUNBURST: 1 DNS query per 60–120 minutes (randomized)
Per-window count: 1. Rule fires: never.
Dormancy period: up to 14 days post-install.Shift from rate analysis to periodicity analysis, detecting the statistical regularity of inter-event intervals regardless of rate. A process making one connection every 3,600 ± 120 seconds is not normal even if it never exceeds a count threshold.
Distribute activity across multiple source entities, accounts, IPs, hosts. Port scanning distributed across a /16 range, lateral movement using a different compromised account per hop, exfiltration across multiple user sessions. Each entity stays below threshold; aggregate activity is substantial.
Rule: same source IP contacts >50 internal hosts in 1 hr
Attacker: 100 source IPs, each contacts 5 hosts
Per-IP count: 5. Rule fires: never.
Total hosts contacted: 500.Cross-entity aggregation rules, detect when the population-level rate of an activity type exceeds baseline regardless of which entities are involved. Group by activity type rather than entity identity as the primary detection anchor.
Deliberately pause activity to reset the session window, then resume with a fresh count. Particularly relevant for UEBA rules that track session-level anomaly scores, a pause of sufficient length resets accumulated anomaly scoring.
Rule: >5 sensitive file accesses in one session
Inactivity timeout: 15 minutes
Attacker: 4 files, pause 16 min, 4 more files
Session 1: 4 accesses. Session 2: 4 accesses.
Alert fires: never. Total accessed: 8.Cross-session aggregation within a longer look-back window, count events across all sessions for a given entity in a rolling 24-hour window. Session boundaries should not reset the cumulative count for high-sensitivity event types.
Send N authentication failures and observe whether a lockout or defensive response occurs. Gradually increment until a response is observed, then operate at N-1. The probing sequence looks identical to normal failed authentication noise, it is detection reconnaissance, treating the detection system as an oracle that reveals its own parameters.
Probe: 3, 5, 8 auth failures → no response
Probe: 10 auth failures → account lockout observed
Operational pattern: 9 failures maximum per session.Probing activity is below the detection threshold by design. Detection of the probing pattern itself, an incrementing failure sequence stopping just below lockout, requires meta-detection: alerting on behavior that looks like threshold discovery rather than just threshold exceeding.
// self-assessment
Rule Design Audit: Evaluating Your Own Detection Logic
Every threshold-based rule should be evaluated against four bypass questions before production, and periodically reviewed as techniques evolve:
- Can the activity be distributed across entities such that no single entity exceeds the threshold?
- Can the activity be spread across time windows such that no single window contains enough events to trigger?
- Can the activity be paused and resumed in a pattern that resets the detection window without changing total volume?
- Are the threshold parameters inferrable from public sources, Sigma repositories, vendor docs, or probe-based discovery?
If the answer to any question is yes, the rule has a known bypass and should be supplemented with additional detection logic.
COUNT(failed_auth) > 10
WHERE source_ip = $src
WITHIN 5min tumbling window
Bypassed by: distributed sources, tumbling boundary straddle, slow-and-low rate
COUNT(failed_auth) > 5
WHERE target_account = $acct
WITHIN 30min sliding window
UNION
STDDEV(hourly_fail_count) > 3σ
WHERE global_population = true
Requires: account-anchored + population-level anomaly. Much harder to operate beneath both simultaneously.
// remediation
Five Engineering Responses That Reduce Threshold Exploitability
Shift detection anchor from source to target
Anchor counts on the target entity (account, resource being accessed) rather than the source. An attacker distributing attempts across 1,000 source IPs is still targeting the same accounts, source-distributed attacks are invisible to source-anchored rules and fully visible to target-anchored rules.
Replace rate detection with periodicity detection for C2
Beaconing at low rate evades count thresholds but cannot easily disguise statistical regularity. Compute inter-event interval standard deviation for long-running outbound connections by process, a coefficient of variation near zero is anomalous for process-initiated traffic. Requires Sysmon EID 3 or EDR network telemetry with process correlation.
Population-level baseline detection as a threshold complement
Per-entity threshold rules are blind to distributed activity. Population-level detection measures whether the aggregate rate of an activity type across the entire monitored population exceeds historical baseline, regardless of which entities are involved. A 40% increase in DNS queries to newly registered domains is detectable even if no single host exceeds a per-host threshold.
Extended look-back windows for low-and-slow patterns
Activities individually unremarkable but cumulatively significant require look-back windows measured in hours or days, not minutes. A user accessing 5 sensitive files per session over 20 sessions in a week has accessed 100 files, invisible to session-level rules, visible to a weekly cumulative threshold. Accept the storage cost as a security investment.
Sequence detection as a threshold-independent signal
Some patterns are significant not because of rate but because of ordering. A reconnaissance event followed by credential access followed by lateral movement is a kill chain, each event below any threshold individually, but the sequence is the signal. Sequence-based detection operates orthogonally to threshold-based detection and is not exploitable by rate reduction.
// conclusion
Know Your Floor and Be Honest About What Is Below It
Threshold-based detection is a commodity attacker filter, not a sophisticated attacker filter. It reliably catches activity that ignores the detection floor, automated scanners, commodity malware, unsophisticated intrusion attempts. Against an actor who has read your detection rules, it catches nothing. A detection program that relies primarily on threshold-based rules has calibrated itself for the wrong threat level.
The closing test: take your three most important threshold-based rules. Run each at N-1 events in T-plus-one minutes, distributed across two source entities. If none of that activity appears anywhere in your SIEM, not in alerts, not in search results, not in any analyst queue, you have documented your detection floor. The question is whether anyone in your organization knows it exists.
SUNBURST/SOLORIGATE technical analysis (FireEye/Mandiant, 2020); SigmaHQ rule repository as illustration of publicly available threshold parameters; Palantir ADS framework on detection coverage claims; MITRE ATT&CK T1110 (Brute Force) sub-techniques.