How can security teams detect CaddyWiper activity?

How CaddyWiper detection works in practice

Detection starts with recognising that CaddyWiper is not trying to stay quiet, it is trying to destroy evidence and availability. Watch for bursts of file overwrite or deletion activity, unusual use of admin tooling, and process behaviour that touches many local files in a short window. The best detections combine host telemetry, privilege auditing, and fast triage of instability on affected machines.

Because wiper activity can resemble ordinary maintenance or cleanup at first glance, build alerts around behaviour patterns rather than filenames alone. A single suspicious binary is useful, but the stronger signal is a chain of events: privilege escalation or remote admin access, followed by mass file modification, then service failures, boot problems, or sudden corruption across a host. That sequence is what usually separates a routine administrative change from destructive malware.

For deeper context on malware families, destructive tradecraft, and wiper analysis, use Malware Guide alongside your local detection content. It is especially useful when you need to distinguish wiper behaviour from ransomware-like activity, loader activity, or other destructive payloads that may look similar in the early stage.

What telemetry usually exposes CaddyWiper first

The earliest useful signals are usually host-based. File integrity monitoring, EDR, and Sysmon-style process and file events can reveal a spike in writes to many files, suspicious access to system directories, and rapid modification of user data or administrative shares. If the host still has live response capacity, preserve volatile evidence before the wipe reaches broader parts of the system.

Privilege context matters. CaddyWiper is more dangerous when it runs with elevated rights, because administrative access expands the set of files, services, and recovery mechanisms it can damage. Look for execution from privileged accounts, remote administration paths, and script or service execution that does not match the normal work pattern for that host. MITRE ATT&CK Enterprise Matrix is a useful map for tying those observations to privilege escalation, credential access, and destructive follow-on actions.

Network telemetry can help, but it is usually secondary. A wiper may not need sustained command-and-control traffic once it has executed, so a lack of beaconing does not clear the host. Instead, pair network context with local evidence of file tampering, abrupt service disruption, and authentication anomalies around the time of the suspected launch.

What defenders should do once the pattern appears

Once the pattern looks credible, speed matters more than perfect attribution. Isolate the host, preserve memory and key logs if possible, and expand search to neighbouring systems that share credentials, management tooling, or shared storage. If the activity is already widespread, the priority is containment and recovery sequencing, not waiting for a clean signature match.

Teams should also verify whether recovery paths are trustworthy. Wiper campaigns often target backups, shadow copies, recovery tools, or administrative access that could be used to restore systems. Confirm that backup credentials, remote management accounts, and privileged sessions were not exposed during the same window. If they were, assume the attacker could return or interfere with restoration.

For incident handling discipline and coordination, FIRST is a useful reference point for response-team process and coordination, especially when evidence must be preserved quickly and escalation paths need to stay clear under pressure. For broader control alignment, NIST Cybersecurity Framework 2.0 fits the detect, respond, and recover workflow that destructive malware forces in practice.

Risk and Threat Considerations

CaddyWiper is dangerous because it targets the system state itself, not just data confidentiality. The main risk is fast-moving loss of availability, with evidence destruction, service disruption, and recovery impairment all happening together. If an attacker already has privileged execution, the wipe can propagate before defenders have enough time to understand the scope.

Failure mechanism: The malware abuses elevated access to overwrite or delete files and disrupt services faster than manual containment can keep up, while also degrading the logs and recovery artefacts defenders need to investigate.

Impact: Organisations can lose hosts, data, and operational continuity at the same time, and they may also lose the forensic trail needed to determine how the compromise began or whether adjacent systems were touched.

Practitioner Guidance

What to prioritise: Put destructive file activity, privileged execution, and host instability ahead of generic malware hunting. If those three signals line up, treat the event as an active wipe attempt, not a routine endpoint alert.

What to verify: Confirm whether the suspected account had broad local or remote administrative rights, whether backup and recovery credentials were reachable from the same trust boundary, and whether adjacent hosts show the same overwrite pattern. Those checks tell you whether containment should stay local or widen immediately.

Practitioner takeaway: With wipers, the key decision is not whether the sample is novel, it is whether the host can still be trusted long enough to preserve evidence and stop spread before recovery options are damaged.

Related resources from NHI Mgmt Group

• 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?