The Detection Gap Nobody Wants to Own
In late 2024, credentials for over 73,000 Fortinet VPN devices were exposed in what became known as the FortiBleed leak. Security teams worldwide scrambled to assess exposure, rotate credentials, and patch vulnerable endpoints. What made the incident particularly uncomfortable for many organizations was not the vulnerability itself — it was the silence from their intrusion detection systems during the period when those credentials were actively being harvested.
Intrusion detection systems were supposed to catch exactly this kind of lateral movement and credential abuse. Yet across thousands of environments, IDS deployments either missed the initial harvesting activity, flagged it too late, or generated so much ambient noise that the relevant alerts were buried. That outcome is not a technology failure. It is a deployment and operational failure, and it is repeatable across almost any organization that has not deliberately engineered its IDS posture around real attacker behavior.
This article is written for cybersecurity professionals and IT administrators who already have IDS infrastructure in place and need to close the operational gaps that let incidents like FortiBleed, the EvilTokens phishing campaign, and the recent wave of ransomware attacks pass through undetected. The focus is practical: what you can do today, what needs a week of focused effort, and what your quarter should look like if you are serious about making detection actually work.
Why Most IDS Deployments Drift Into Noise Machines
A freshly deployed IDS with default rule sets will generate a predictable pattern: high alert volume in the first weeks, gradual tuning fatigue among analysts, increasing alert suppression to preserve operational sanity, and eventual configuration drift that leaves detection logic misaligned with the actual threat landscape. This is not a hypothetical progression. It is the documented trajectory of IDS deployments across organizations of every size.
The core problem is that default signatures are built for breadth, not depth. They are designed to catch known attack patterns across the widest possible range of environments, which means they fire on legitimate traffic in most specific environments. Analysts learn quickly that suppressing the noise is faster than investigating it. Over time, suppression rules accumulate, and the IDS becomes a record of what analysts decided not to look at rather than a detector of what attackers are actually doing.
The Fortinet credential harvesting incidents illustrate this clearly. The initial access vector involved authentication requests that, individually, looked like normal VPN login attempts. The signal was in the pattern: elevated login rates from unusual source ASNs, authentication attempts against accounts that had not logged in for months, and credential submissions with anomalous timing distributions. These patterns require behavioral baselines and correlation logic that default IDS signatures do not provide. Organizations relying on signature-only detection missed them entirely.
Building a Detection Posture That Reflects Current Threats
The first step in rebuilding IDS effectiveness is accepting that signature coverage and detection coverage are different things. A system with 50,000 active signatures covering last year's CVEs provides less operational value than a system with 200 carefully tuned rules that reflect how attackers are currently operating in environments like yours.
Current attacker tradecraft, as evidenced by recent campaigns, focuses heavily on credential abuse, token manipulation, and living-off-the-land techniques. The EvilTokens phishing campaign demonstrated a shift away from password theft toward session token harvesting — attackers bypass authentication entirely by stealing authenticated session tokens, making password-based detections irrelevant. The Meta AI support bot hijacking campaign used legitimate platform APIs to compromise Instagram accounts, again bypassing traditional credential-based detection models.
These campaigns share a characteristic: they abuse legitimate functionality. Your IDS needs to be tuned for behavioral anomalies rather than purely malicious signatures, because the malicious actions are increasingly indistinguishable from legitimate ones at the individual event level.
Immediate Actions for This Week
Start with a detection coverage audit. Pull your active IDS rule set and map each rule to a current threat category. The MITRE ATT&CK framework provides a practical taxonomy. For each tactic and technique in ATT&CK that is relevant to your environment, identify whether you have active detection logic, whether that logic is generating validated true positives, and where you have no coverage at all. Most teams doing this audit for the first time discover significant gaps in the initial access, credential access, and lateral movement categories — exactly where modern attacks operate.
Next, pull alert volume statistics for the past 90 days. Identify the top ten rules by alert volume and validate how many of those alerts represent true positives versus false positives. In most environments, 80 to 90 percent of alert volume comes from 10 to 15 rules, the majority of which are generating noise. Suppressing or tuning these rules does not reduce security coverage — it recovers analyst capacity for investigating alerts that matter.
Review your IDS placement architecture. Network-based IDS sensors positioned only at the perimeter provide limited visibility into lateral movement. If your sensors are not monitoring east-west traffic within your network segments, attacker activity after initial access is invisible to detection. This is not a configuration that can be fixed this week, but identifying the gap is the starting point for addressing it.
Tuning for Credential Abuse and Session Token Theft
Given the current threat landscape, credential abuse detection deserves dedicated tuning attention. The FortiBleed aftermath, the 30,000-device credential harvesting campaign, and the broader pattern of credential-based attacks all point to the same detection requirement: you need behavioral baselines for authentication activity, not just signature matching against known malicious patterns.
Configure your IDS or supporting SIEM to establish baselines for authentication volume per user, per source IP, and per time window. Deviations from these baselines — not just absolute thresholds — are the signal. An account that normally authenticates from a single geographic region generating authentication attempts from multiple ASNs within a short window is a behavioral anomaly worth investigating, even if each individual attempt looks technically valid.
For session token theft scenarios like EvilTokens, detection logic needs to focus on post-authentication behavior rather than the authentication event itself. Indicators include session tokens being used from IP addresses that differ significantly from the IP address that completed the authentication flow, session activity occurring outside the user's established behavioral pattern, and rapid sequential actions that differ from the user's typical interaction cadence. These detections require integration between your IDS, authentication infrastructure, and web application logs — a correlation that many teams have not built.
The Role of Network Segmentation in IDS Effectiveness
IDS detection logic can only catch what the sensors see. In flat or poorly segmented networks, a single compromised endpoint provides an attacker with broad lateral movement capability that generates minimal additional network traffic — and therefore minimal additional IDS alerts. The Netherlands operation that seized 800 servers and arrested operators for facilitating cyberattacks highlighted how extensively attackers rely on compromised infrastructure for multi-hop movement, specifically because it generates traffic that blends into legitimate patterns.
Network segmentation serves IDS deployment in two ways. First, it creates natural chokepoints where sensor placement generates high-fidelity visibility into inter-segment traffic. Any traffic crossing a segment boundary can be inspected with rules tuned specifically for the types of communication that should occur between those segments. Unexpected protocols, unusual port usage, or communication patterns between segments that should have no operational relationship become clear anomalies rather than noise.
Second, segmentation reduces the lateral movement surface that an attacker can traverse before triggering detection. An attacker who gains initial access to a workstation in a segmented environment must generate traffic through a monitored chokepoint to reach sensitive systems. This creates forced detection opportunities that flat network architectures do not provide.
For the quarter ahead, map your current segmentation against your IDS sensor placement. Identify high-value asset zones — credential stores, backup infrastructure, administrative systems — and verify that traffic to and from these zones passes through a monitored chokepoint. If it does not, sensor placement or segmentation changes belong on your roadmap.
Encrypted Traffic and the Visibility Problem
The widespread adoption of TLS encryption across internal and external traffic has progressively reduced the signature-based detection capability of network IDS. An IDS sensor that cannot inspect payload content is limited to metadata-based detection: connection timing, packet size distributions, connection frequency, and protocol behavior. This is sufficient for some attack patterns but inadequate for many others.
Organizations have several options for addressing this gap. TLS inspection infrastructure, deployed at appropriate points in the network architecture, restores payload visibility at the cost of operational complexity and potential privacy or compliance implications. For environments where TLS inspection is not feasible, metadata-based behavioral analytics becomes more important. JA3 and JA3S fingerprinting, which characterize TLS handshake behavior without decrypting content, can identify unusual client or server behavior that correlates with known attacker tooling. Many IDS platforms support JA3 detection out of the box but require deliberate configuration to deploy effectively.
DNS-based detection provides another visibility layer that does not require TLS inspection. Command-and-control infrastructure, phishing domains, and malware distribution networks typically have DNS behavioral signatures — high-entropy domain names, newly registered domains, domains with anomalous TTL configurations, or domains associated with known malicious infrastructure. Monitoring DNS query logs through your IDS or a dedicated DNS security layer catches attacker infrastructure communication even when the subsequent HTTP or HTTPS traffic is encrypted.
Container environments introduce additional complexity. As Kaspersky's analysis of container security highlighted, containerized workloads have attack surfaces that traditional network IDS is poorly positioned to monitor. Container-native security tooling, integrated with your broader IDS architecture, is required to extend visibility into workload behavior within container orchestration platforms.
Integrating Threat Intelligence Into Detection Rules
Static IDS rule sets degrade in value over time as attacker infrastructure rotates. Threat intelligence integration — specifically, the operational kind that translates into active detection logic rather than reports — is what separates organizations that detect current attacks from those that detect last year's attacks.
Actionable threat intelligence for IDS purposes means IOCs with operational shelf lives that your team tracks, TTP descriptions that map to specific detection rules, and a process for retiring stale indicators before they contribute to noise. Recorded Future's proprietary collection engine, for instance, generates infrastructure intelligence that can feed directly into IDS blocklists and detection rules — but only if the ingestion pipeline and rule maintenance process exist on the consuming end.
For teams building this capability, start with a structured IOC feed that your IDS can consume automatically. Configure automatic ingestion of IP reputation data, malicious domain lists, and known command-and-control infrastructure indicators. Set expiration windows on ingested IOCs — indicators older than 30 days should be reviewed for continued relevance rather than persisting indefinitely. Stale IOCs contribute to false positives and alert fatigue without providing current detection value.
Map your threat intelligence sources to the specific attack patterns relevant to your industry and infrastructure. Maritime organizations facing sanctions evasion campaigns, as seen in recent cyber-enabled maritime sanctions evasion incidents, have different threat intelligence requirements than healthcare organizations or financial services firms. Generic intelligence feeds provide broad coverage; sector-specific intelligence provides depth where it matters.
Alert Triage and Escalation Process Design
Detection capability means nothing without an operational process for acting on what is detected. Alert triage is where IDS value is either realized or lost, and it is the area where most teams have the most room to improve without changing any technology.
Design your triage process around alert priority tiers with defined response time commitments. A tier-one alert — active exploitation of a critical system, confirmed malicious activity in progress — requires immediate human investigation. A tier-two alert — suspicious behavioral pattern, anomalous traffic from a known-bad IP range — requires investigation within a defined window. A tier-three alert — informational, pattern of interest requiring context before action — can be batched for analysis.
The critical discipline is maintaining the integrity of these tiers. When analyst capacity is constrained, the temptation is to let tier-two alerts age into tier-three treatment. This is where attackers who establish a foothold and then go quiet — a common technique for reducing detection risk during the dwell period before ransomware deployment — avoid detection. Define escalation triggers that override capacity constraints for specific alert combinations.
Document your false positive rate per rule, per analyst, and per environment segment. False positive rates that are increasing over time indicate that the environment has changed and the rules have not. False positive rates that differ significantly between analysts indicate inconsistent triage judgment that training or process documentation can address. Both are solvable problems if the data is being collected.
A Quarterly Plan for Meaningful IDS Improvement
The following phased approach provides a structured path from the current state to a materially more effective IDS posture over a 90-day period.
Days One Through Thirty
Conduct the detection coverage audit described earlier. Produce a gap map against MITRE ATT&CK. Identify the top alert volume sources and validate true positive rates. Suppress or tune the highest-volume false positive generators. Deploy or validate behavioral baseline monitoring for authentication activity. Review sensor placement against your network topology and document visibility gaps.
Days Thirty Through Sixty
Address the highest-priority detection gaps identified in the audit. Implement or improve threat intelligence feed integration with defined IOC expiration policies. Establish or formalize alert triage tiers with documented response time commitments. If east-west traffic monitoring is absent, begin the network change process to address it. Conduct a tabletop exercise using a current attack scenario — credential harvesting followed by lateral movement is appropriate given the threat landscape — and trace the detection path through your current IDS posture.
Days Sixty Through Ninety
Measure improvement: compare alert volume, true positive rate, and mean time to detection against the pre-improvement baseline. Conduct a red team or purple team exercise focused on the ATT&CK techniques where your gap map showed the weakest coverage. Review container and cloud workload visibility and identify tooling gaps. Establish a recurring quarterly rule review process so that detection logic stays aligned with the current threat environment rather than drifting back toward the state you started from.
The Operational Reality
The FortiBleed credential exposure, the sweeping credential-harvesting campaigns, and the ransomware surge all share a common thread: they operated in environments where IDS deployments existed but were not positioned to detect the specific techniques in use. The technology was present. The operational and configuration work that would have made it effective was not.
Improving IDS effectiveness is an ongoing operational discipline, not a deployment milestone. The threat landscape that produced the incidents referenced in this article will continue evolving. Detection logic tuned for today's attacker behavior will need revision as techniques shift. The organizations that maintain effective detection are those that treat IDS as a living system requiring continuous attention rather than a product that was deployed and can now be left to run.
The practical starting point is the audit. Pull your current rule coverage, map it to current threats, measure your false positive rate, and identify where your sensors have no visibility. The gaps will be specific to your environment, and addressing them specifically is what produces detection capability. Generic improvements to a generic IDS posture produce generic results — which is to say, the kind of silence that characterized too many environments during the Fortinet incidents.
