Companies have filled their networks with security tools, but many still fail to detect what’s happening inside in a timely manner. EDR, SIEM, firewalls, EPP, managed providers, and automatic alerts don’t guarantee visibility if nobody verifies that telemetry is arriving, that the rules are still effective, and that weak signals are investigated before the attacker gains ground.
The latest report from Kaspersky Compromise Assessment, based on evaluations conducted in 2025, quantifies this problem. 30.8% of discovered incidents had historical activity older than three months, and 52% of high-severity compromises were only identified after more than 90 days of undetected activity. The oldest case found had been hidden in an organization’s network for four years.
The takeaway for tech and security teams is clear: the breach isn’t always due to a lack of tools, but rather how they are operated. According to the report, 20% of detected incidents were found manually, and 60% went unnoticed because existing tools didn’t generate high-confidence alerts. Kaspersky describes this as a common weakness in many organizations: controls installed but poorly tuned, insufficiently monitored, or without ongoing review routines.
Purchased security doesn’t equal operated security
For years, many organizations measured their defensive posture by their deployed solutions inventory. Having EDR on endpoints, centralized SIEM, forwarded logs, next-generation antivirus, or a contracted MSSP seemed sufficient to reduce risk. The report questions this comfort.
Kaspersky finds that the lack of continuous monitoring increased the proportion of medium or high severity incidents to 86%. Without structured threat hunting, that figure was 84%. The difference between seeing and not seeing doesn’t depend solely on the tool but on having a team—internal or external—that validates alerts, reviews low-confidence signals, correlates patterns, and proactively searches for anomalous activity.
A case cited in the report illustrates this well. A company had invested in security controls and assumed its environment was protected. Historical log review revealed activity related to Impacket, Cobalt Strike deployment, and presence of Mimikatz on critical servers, including domain controllers. The activity went undetected for three months because effective 24/7 monitoring was lacking.
| Detected Issue | Operational Impact |
|---|---|
| Alerts without human validation | Weak signals never investigated |
| Misconfigured EDR/EPP | Sensors present but ineffective detection |
| No threat hunting | Persistence and lateral movement persisted for weeks |
| Backups not inspected | Web shells reintroduced after restores |
| Incomplete inventory | Servers out of scope for scans and monitoring |
| Rigid playbooks | Limited response to initial symptoms |
| Poor communication | Delays in confirmations, escalations, and decisions |
The report also nuances the role of managed services. Having an MSSP can improve defensive capacity but doesn’t eliminate the need for internal governance. In projects with a managed provider, Kaspersky observed incidents not identified due to low detection coverage and basic gaps in Windows auditing, such as unlogged events or disabled audit policies. Outsourcing helps when expectations, metrics, and responsibilities are clear, but it’s not a substitute for internal ownership of security.
Backups, inventory, and persistence: the areas least scrutinized
One of the most practical findings concerns backups. 40% of web shells discovered by Kaspersky were stored in backups. This means an organization can clean a server, close an incident, and then restore a seemingly clean backup that reintroduces the backdoor.
Backups are typically treated as recovery guarantees, but during an intrusion, they can also act as malware reservoirs. If backups are not scanned, compared with baselines, or validated before restoration, they can keep alive an access point that the response team believed had been eliminated.
The problem worsens with incomplete inventories. Kaspersky found inventory gaps in 25% of cases, such as Linux cloud servers not joined to Active Directory and excluded from routine scans. An attacker can plant a web shell on such an asset and remain hidden for a long time, especially if the server is automatically backed up but not included in standard security tools.
In another case, a web shell was found inside a .rar compressed file stored on an internal file server. It originated from a server that was disconnected during the assessment and was not properly included in the inventory. Post-investigation, a backdoor was detected spanning multiple Windows servers through password modifications of the local administrator account.
LOLBins and remote tools: the noise that masks the attacker
The report emphasizes a known pattern among SOC teams: attackers increasingly use legitimate tools. All detected compromises involved non-standard remote administration utilities and LOLBins—system binaries or tools that can be used for administrative tasks, lateral movement, persistence, or exfiltration.
A simple rule doesn’t suffice here. PsExec, AnyDesk, TeamViewer, VNC, certutil, bitsadmin, regsvr32, or wmic can all be legitimate. They can also be part of an intrusion. The key is context: who executes the tool, from which endpoint, when, with what arguments, targeting what destination, and whether that activity aligns with normal organizational operations.
Kaspersky recommends explicit policies on remote administration tools, log forwarding to a centralized platform, software audits, hashing and categorization, and rules to detect common abuse patterns of LOLBins. The goal isn’t to block everything suspicious by default but to establish a realistic baseline and identify deviations.
This work is less glamorous than buying another console but often makes the difference. When analysts don’t understand the normal environment activity, every alert prompts debate. When a baseline is established, investigations focus on anomalies.
Responding to an incident isn’t following a canned recipe
Kaspersky also highlights a gap in incident response: 39% of assessed compromises required plan updates mid-investigation, and 59% needed forensic traffic analysis. The reason is simple: real incidents evolve as new evidence emerges.
An organization could contain the first infected server but still leave persistence mechanisms elsewhere. The report cites a case where, after an initial effective response, subsequent assessment uncovered multiple backdoors outside the original scope: a scheduled task recreating a web shell, an active reverse shell, persistence via Windows registry, and a malicious WMI consumer.
Incident response must be a living process. Each new artifact can shift priorities, scope, and removal sequence. A fixed playbook that treats response as a checklist risks halting visible damage but leaving other entry points untouched.
Communication also matters. 32% of the projects reviewed experienced internal issues affecting response: unclear confirmations, slow validation from system owners, potentially compromised channels, or knowledge loss due to staff turnover. In serious incidents, technique is important, but coordination largely determines the outcome.
Generative AI is now part of corporate risk
The report includes an example directly linked to new working models. In one assessment, Kaspersky identified a macOS station running Claude Code as an extension of VS Code. The tool captured system snapshots to enrich prompts, including directory listings and absolute paths to Excel files containing internal confidential data.
This isn’t a blanket accusation against AI development assistants. It’s a warning about policyless adoption. AI tools are already in the workplace—developing code, managing systems, and boosting productivity. Without clear policies on data exposure, authorized providers, excluded folders, and controls, AI can create another shadow zone.
Security teams need to broaden their perspective. The attack surface isn’t limited to endpoints, email, identity, cloud, and web apps anymore. It also includes extensions, code assistants, local agents, prompts, snapshots, connectors, and automation—elements that can access internal data without passing traditional security controls.
What should tech and security teams do?
The report offers a fundamental recommendation: treat detection as a living function, not a purchase. Start with a health check of detection engines: active sensors, updated rules, complete telemetry, enabled critical logs, endpoint coverage, and relevant alerts. A lack of signals shouldn’t be mistaken for no attack until system visibility is confirmed.
Next, focus on operational routines: review low-confidence alerts, establish threat hunting cycles, set baseline configurations for remote tools and LOLBins, audit asset inventories, verify backups before restoring, and update playbooks based on new findings.
It’s also wise to strengthen internal digital forensics and malware analysis capabilities. Kaspersky notes that organizations capable of analyzing forensic artifacts internally experienced fewer high-severity incidents, and having reverse engineering resources correlated with lower severity in the studied sample.
The conclusion isn’t that all companies must handle everything internally. Instead, even when delegating, someone must oversee it. Security isn’t just deploying a tool and waiting for alerts. It’s ensuring every day that the system listens, understands, and acts appropriately in time.
Frequently Asked Questions
What is a compromise assessment?
An independent evaluation to determine whether a network is compromised or has been compromised in the past. It combines threat intelligence, endpoint scans, log reviews, traffic analysis, and digital forensics if necessary.
Why don’t security tools detect some attacks?
Because they can be misconfigured, outdated, lack sufficient telemetry, or lack analysts reviewing low-confidence signals. The problem mostly lies in operation, not technology alone.
Why are infected backups dangerous?
Because they can reintroduce web shells, malicious scripts, or persistence mechanisms after initial cleanup, reopening the backdoor.
What are LOLBins?
Legitimate system binaries or common tools that attackers reuse to execute malicious actions without deploying obvious malware.
What should a company review first?
The health of sensors and rules, log integrity, asset inventory, low-confidence alert review, backup inspection, and actual update of response playbooks based on new evidence.
Source: Open Security
