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

Security News
1 Reply 755 Views

Khushal

Level 16
Verified
Top Poster
Well-known
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
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top