How can security teams detect AcidPour?

What AcidPour looks like in telemetry

AcidPour is best detected as a destructive campaign, not as a single signature. The practical signal is a cluster of storage-layer tampering, loss of access, and rapid system degradation on Linux hosts. Watch for commands or processes that enumerate disks, modify partitions, interfere with filesystems, or trigger unexpected unmounting, formatting, or device resets.

Because wiper activity often happens quickly, one alert is rarely enough. The strongest early clue is correlation across host events, storage telemetry, and administrative actions that do not fit the normal change window. That combination helps separate deliberate destruction from a routine outage or a badly behaved script.

How to confirm exposure without waiting for total loss

Once suspicious activity appears, validate whether the host is actually being manipulated at the storage and firmware boundary. Check for process trees, shell history, scheduled tasks, remote administration sessions, and any evidence that a privileged user or script touched block devices, partition tables, boot paths, or firmware-adjacent components.

If you can still access the system, capture volatile evidence first. Preserve command output, logs, running processes, and relevant storage metadata before rebooting or rebuilding. In a destructive event, the rebuild decision can erase the very artifacts needed to determine scope, timing, and whether the activity spread across multiple Linux systems.

Detection engineering for destructive Linux activity

Build detections around behaviour rather than filenames. A useful pattern is a sequence that includes disk discovery, privileged execution, partition changes, abnormal I/O, and abrupt service disruption. On its own, any one of those may be legitimate maintenance; together, they are much more indicative of destructive intent.

Correlate endpoint telemetry with identity and administrative context. The most useful questions are who initiated the action, from where, with what privilege, and whether that activity aligns with the expected operator population. The MITRE ATT&CK Enterprise Matrix is a useful way to map destructive steps to detection logic, while SANS Security Resources is a practical reference for incident-handling workflows and detection engineering patterns.

Risk and Threat Considerations

AcidPour-style activity is dangerous because it targets the parts of Linux that make recovery possible. Once partitions, disks, or related firmware paths are altered, defenders can lose not only availability but also forensic evidence, which complicates both containment and attribution.

Failure mechanism: The malware or destructive process uses elevated access to overwrite, corrupt, or disable storage structures faster than defenders can triage, and may also interfere with reboot or recovery paths.

Impact: Systems can become unrecoverable without rebuilding, surrounding assets may be contaminated by shared administration paths, and the organisation may lose the evidence needed to understand blast radius or dwell time.

Practitioner Guidance

What to prioritise: Treat confirmed storage tampering as a containment event, not a normal malware cleanup. Isolate the host, preserve evidence, and determine whether the same administrative path can reach other Linux servers before you spend time on eradication.

What to verify: Confirm whether the observed activity came from an approved change, a trusted automation job, or an unexpected privileged session. If those answers are weak or absent, assume the destructive sequence may still be in progress elsewhere.

Practitioner takeaway: For AcidPour, the key judgement is speed versus evidence, because the most valuable forensic artifacts may disappear as soon as recovery starts.

Related resources from NHI Mgmt Group

• Guide: Malware Guide
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?