What are the signs that Cactus ransomware is actively encrypting files on a host?

Common signs include new file extensions such as cts0 or cts1, creation of a mutex that limits the malware to one instance, and activity in ProgramData that should not be present. Another clue is a ransom note or unusual log file creation alongside broad file enumeration. These indicators support fast triage before encryption spreads further.

When Cactus ransomware is actively encrypting, the host usually shows a fast shift from normal file activity to broad, repetitive touches across many directories, along with changes in filenames or extensions that match the malware’s encryption routine. The practical challenge is separating early encryption from routine backup, indexing, or batch-processing activity so containment happens before the blast radius expands.

The most useful signal is not a single file change, but a cluster of host-side behaviours that appear together. New or unusual extensions, creation of a single-instance mutex, and unexpected activity in protected locations such as ProgramData point to a live encryption process rather than a dormant payload. A ransom note or fresh log-like artefacts can further confirm that the host is in the active execution phase.

Broad file enumeration is especially important because it shows the process is still discovering targets and often precedes wider impact. On an endpoint, the combination of enumeration, write-heavy file modification, and odd artefact creation is more actionable than any one indicator alone, because encryption campaigns often move quickly once the process starts touching accessible user and shared data.

Why these signs indicate active encryption rather than benign file activity

Ransomware encryption is usually noisy on the host. It has to enumerate files, open them, write new content, rename or append extensions, and often create supporting artefacts such as mutexes or logs to manage execution. That makes the pattern more revealing than a simple hash or one-off file rename, especially during the first minutes of detonation.

In practice, the strongest indicators are behavioural: a burst of file discovery, repeated modifications across many paths, and the appearance of a consistent new extension tied to the malware family. Those signs matter because they help you distinguish an encryption run from ordinary software that may also create files or logs but does not systematically rewrite accessible content across the host.

ProgramData is a useful place to watch because many user applications do not normally create suspicious artefacts there during routine activity. When that location changes at the same time as file enumeration and extension changes, the evidence becomes much stronger that the host is under active ransomware execution.

What to look for in endpoint telemetry and triage data

Endpoint telemetry should be checked for process lineage, file-system bursts, and renaming patterns that line up in time. If the same process is touching many files, creating a mutex, and generating a ransom note or log-like file, you should treat it as an active encryption event until proven otherwise.

Useful triage questions are simple: which process first touched the files, how quickly did the changes spread, and did the activity cluster around user shares, temp paths, or ProgramData? The answer helps determine whether the host is still in the discovery phase, is already encrypting at scale, or has merely staged artefacts without widespread damage yet.

For a family-specific detection approach, pair the extension pattern with broader ransomware hunting methods from MITRE ATT&CK Enterprise Matrix and host containment guidance from CISA cyber threat advisories. If you need broader threat-trend context, ENISA Threat Landscape is useful for understanding how ransomware behaviours commonly present in enterprise environments.

How to interpret the indicators without overcalling them

None of these signs should be treated in isolation. A new extension by itself may be harmless, and a mutex alone does not prove ransomware. The signal becomes materially stronger when file enumeration, unusual ProgramData activity, and ransom-note creation occur together on the same host within a short window.

The best operational judgment is to look for impact progression. If a process is still enumerating files, you may still have a narrow containment window. If encrypted copies and renamed files are already spreading across multiple directories, the priority shifts from detection validation to immediate isolation and scoping of affected systems.

Where the host is already showing a ransomware pattern, the question is no longer whether the process is malicious. It is whether the encryption is still localised enough to stop before it reaches network shares, synced folders, or backup paths that could multiply recovery effort.

Risk and Threat Considerations

Ransomware encryption is a high-velocity failure mode because the attacker’s objective is to convert file access into immediate operational disruption. The risk is not limited to file loss, it also includes service downtime, backup contamination, and lateral spread if shared storage or synchronisation paths are still reachable.

Failure mechanism: The malware enumerates accessible files, rewrites content, and appends family-specific extensions while using execution controls such as a mutex to avoid collisions and maintain a single active instance. That combination can let encryption advance faster than manual response if the host is not isolated quickly.

Impact: Once encryption is underway, every minute can increase the number of affected files, the scope of recovery, and the chance that shared or backed-up data is also touched. Early host-level recognition is therefore critical because it is often the last practical point to limit damage before the blast radius widens.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1486 — Data Encrypted for Impact	Cactus encryption signs map directly to ransomware encryption behavior.
Recommendation — Map the process to T1486 and isolate the host as soon as encryption behavior is confirmed.
CIS Controls v8	CIS-13 — Data Recovery	Active encryption demands fast recovery readiness and verified restore paths.
Recommendation — Validate restore points and recovery readiness before attempting broad remediation.
NIST CSF 2.0	DE.CM-01 — Network and Environment Monitoring	Endpoint signs of active encryption depend on monitored host activity and anomalies.
	RS.MI-01 — Incidents are contained	The host indicators support immediate containment of an ongoing ransomware incident.
Recommendation — Tune monitoring to flag sudden file-enumeration and mass-write patterns. Contain affected hosts immediately once the encryption pattern is verified.

Practitioner Guidance

What to prioritise: Treat the host as actively compromised when the extension pattern, file enumeration, and ProgramData artefacts appear together. Isolate first, then confirm scope, because waiting for perfect certainty often costs the recovery window.

What to verify: Check whether the same process is responsible for the rename activity, log-like artefacts, and ransom note creation. If multiple hosts show the same pattern at once, assume a coordinated campaign rather than a one-off corruption event.

Practitioner takeaway: The most reliable operational signal is the cluster of behaviours, not any single indicator, so containment decisions should be based on the combined host pattern rather than waiting for complete file loss.