Who is accountable when attackers erase logs or persistence artifacts?

Why This Matters for Security Teams

When attackers erase logs or persistence artifacts, the problem is not just loss of evidence. It becomes a control failure across endpoint hardening, logging governance, and identity lifecycle management. Security teams need enough traceability to determine what ran, which account executed it, and whether privilege was granted legitimately. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that auditability, configuration management, and accountability are core security functions, not optional forensic extras.

The hard part is that log deletion and persistence cleanup often happen after initial access has already been established. If local admin rights, service creation, scheduled task creation, or log clearing are not tightly governed, then the organisation may only discover the compromise when downstream systems behave strangely or when indicators are missing entirely. In practice, many security teams encounter the accountability gap only after a containment exercise has failed to reconstruct the attacker path, rather than through intentional evidence preservation.

How It Works in Practice

Accountability for erased logs or persistence artifacts is shared, but not diffuse. Endpoint operations typically own telemetry collection, retention, and tamper resistance. Detection engineering owns the rules, alerts, and correlation logic that should reveal suspicious changes. Identity governance owns the legitimacy of accounts, privilege elevation, and lifecycle controls that let a user, admin, or service account create persistence in the first place.

A workable control model usually includes four layers:

• Immutable or protected logging, with forwarding to a separate security domain before local compromise can destroy evidence.
• Monitoring for log clearing, service creation, scheduled task changes, registry run keys, and other persistence techniques mapped in the MITRE ATT&CK Enterprise Matrix.
• Identity controls that distinguish human admins from service accounts and require review for privileged changes, especially where a local account can be created silently.
• Incident response procedures that preserve volatile evidence quickly, because waiting for full forensic certainty often means losing the trail.

This is also where attacker tradecraft is changing. Public reporting such as the Anthropic — first AI-orchestrated cyber espionage campaign report shows how AI-assisted operations can accelerate reconnaissance, privilege use, and cleanup, which raises the bar for detection latency. Security teams should therefore treat evidence preservation as an operational control, not a post-incident investigation task. These controls tend to break down when endpoint logging is local-only and privileged access can be created or removed without external approval, because the attacker can both act and erase the proof on the same host.

Common Variations and Edge Cases

Tighter evidence controls often increase operational overhead, requiring organisations to balance forensic certainty against endpoint performance, storage cost, and administrative friction. That tradeoff becomes more visible in high-change environments, where engineering teams want fast access and frequent automation.

Current guidance suggests that the accountability answer shifts with architecture. In cloud-heavy environments, logs may be protected centrally, but short-lived compute, ephemeral containers, and automated scaling can still destroy local context before correlation completes. In managed service environments, the service provider may hold part of the logging duty, yet the customer still owns identity governance, alert triage, and incident response decisions. There is no universal standard for exactly how much local evidence must be retained on every system, but best practice is to ensure the security team can reconstruct privileged activity without trusting the compromised host.

Questions also arise with agentic workflows and AI-enabled operations. The MITRE ATLAS adversarial AI threat matrix is relevant where AI systems are used to assist defenders or attackers, because prompt manipulation, tool misuse, or automated cleanup can complicate attribution. For defensive teams, the practical rule is simple: if an identity, agent, or automation can modify logs, it should be treated as a high-risk control point and tightly governed. The accountability gap is most visible in hybrid estates where local admin rights, legacy audit settings, and automation accounts all overlap, because ownership boundaries are hardest to prove there.

Related resources from NHI Mgmt Group

• Who is accountable when authentication logs are not enterprise-ready?
• Who is accountable when shared credentials distort audit logs and usage metrics?
• Who is accountable when privileged access logs are incomplete?
• Who is accountable when logs are incomplete during an incident?