Malware News Kaspersky's 2025 compromise assessment data reveals a systemic detection failure: 60% of incidents were missed entirely by existing tools.

Khushal

Level 16
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
729
4,874
1,469
52% of high-severity compromises went undetected for over 90 days, and one incident had persisted for four years.



Key findings:



- Dwell time drives severity. Incidents detected within 30 days show balanced severity distribution. By 60-90 days, 71% are high-severity. Beyond 90 days, 52% are still high-severity. The four-year case involved NSABuffMiner crypto-mining on domain controllers via EternalBlue (MS17-010), with malicious files hidden in C:\Windows\Fonts\Mysql and persistence via services named MicrosoftMysql and MicrosoftFonts, plus scheduled tasks At1 and At2.



- Post-IR checkups produced the highest proportion of high-severity findings (40.7%), exposing what contained IR misses. One case found a cron job re-downloading a PHP web shell from GitHub, a live bash reverse shell running as the apache user, a ClipBanker variant persisting under HKU\...\Run\9Er6IIp, and a WMI event consumer aliasing Invoke-Expression as "Kaspersky."



- 40% of discovered web shells lived in backups. Asset inventory gaps (25% of engagements) meant cloud Linux servers outside AD never got scanned, and backup restores reintroduced the threat repeatedly.



- Without 24/7 monitoring or threat hunting, 84-86% of incidents were medium or high severity.
 
This aligns with a long-standing incident-response reality: the longer an intruder stays, the more likely the outcome shifts from “contained” to “high-severity,” and the harder it becomes to be confident you actually removed everything.

What the findings practically mean
  • “Dwell time drives severity” is usually less about “stealthy malware” and more about gaps in visibility and process: missing telemetry, limited log retention, no continuous triage, and incomplete asset coverage.
  • The “post-IR checkup” point is important: many IR engagements focus on stopping the bleeding quickly, but full eradication and confirmation often requires a second phase with fresh eyes and additional data sources.
  • Web shells in backups and repeated reinfection after restore is a classic failure mode: if backups aren’t scanned/validated (and the root cause isn’t fixed), you can reintroduce the same compromise indefinitely.
  • Asset inventory gaps (especially cloud workloads outside AD) are a major reason compromises persist: security monitoring tied only to the domain misses entire classes of systems.

Key defensive takeaways (what reduces 90+ day dwell time)</B>
1) Monitoring and log retention (baseline requirement)</B>
  • Centralize logs (SIEM or managed service) and retain enough history to investigate “slow burns” (often 90+ days).
  • Make sure you’re collecting the basics: authentication logs, PowerShell/script logs where applicable, endpoint security telemetry, and server/web logs for internet-facing systems.
  • If 24/7 staffing isn’t realistic, consider a reputable MDR (managed detection and response) to cover off-hours.

2) Asset inventory and coverage (close the “unknown hosts” problem)</B>
  • Maintain an authoritative inventory for on-prem and cloud (including Linux instances, external-facing VPS, and “temporary” servers).
  • Continuously reconcile: what exists vs. what is monitored/scanned. Anything not covered becomes a persistence hiding place.

3) Backup hygiene (prevent “restore = reinfection”)</B>
  • Treat backups as potentially contaminated until proven otherwise; scan restored systems before putting them back into production.
  • Harden backup infrastructure (separate admin identities, MFA, immutability where possible, restricted network paths).
  • Keep “clean room” restoration procedures so you can validate systems before they reconnect to the main environment.

4) Patch and exposure management (the EternalBlue example is a warning sign)</B>
  • If MS17-010/EternalBlue appears in 2025 cases, that’s less about “new attacker tradecraft” and more about unpatched or poorly segmented legacy exposure.
  • Prioritize patching and isolation of domain controllers and SMB exposure; enforce segmentation so a single foothold can’t easily reach DCs.

5) Post-incident verification should be a standard phase, not an optional add-on</B>
  • After containment/eradication, do a separate validation pass: search for persistence (services, scheduled tasks/cron, WMI event consumers), web shells, rogue admin accounts/SSH keys, and suspicious autoruns.
  • Specifically include “things IR might miss under time pressure”: secondary backdoors, re-downloaders, and backup-resident artifacts.

Detection ideas suggested by the examples (high-level, not vendor-specific)</B>
  • Alert on suspicious persistence names that mimic system components (services/tasks/users named like “Microsoft*” but not signed/legitimate).
  • Monitor unusual directories for executables/scripts on servers (attackers often pick “boring” paths to blend in; the Windows Fonts path example highlights that).
  • On web servers: alert on outbound connections from the web server user, unexpected cron changes, and new/modified files in web root or upload/temp paths.
  • Regularly hunt for “living off the land” patterns: PowerShell abuse, WMI persistence, scheduled task anomalies, and suspicious network beacons.

Bottom line</B>
The thread’s key message is operational: without complete visibility (inventory + telemetry) and continuous detection/validation (24/7 monitoring or MDR + post-IR checkups), long dwell times become normal—and long dwell times correlate strongly with high-severity outcomes. Implementing coverage, retention, and repeatable verification steps is what most reliably shifts incidents back into the “detected early, contained early” category.

Sources