What are the signs that ransomware is still active during incident response?

Why Ransomware Activity Can Continue After First Containment

When ransomware is still active during incident response, the issue is no longer limited to encryption noise on one endpoint. It can mean the operator still has access, a scheduled task or service is relaunching the malware, or the payload is spreading to other systems. For response teams, the practical question is not whether the first infected host looks bad, but whether the intrusion path has been closed and the adversary can still act.

That is why persistent encryption, repeated ransom note creation, fresh process spawning, or continued beaconing should be treated as active compromise rather than residual damage. Guidance from the ENISA Threat Landscape is useful here because it frames ransomware as an intrusion pattern with operational stages, not a single event. In practice, many security teams discover the malware is still live only after they begin recovery and see new encryption or new host-to-host activity reappear.

How Incident Responders Confirm the Threat Is Still Running

The main test is whether the malicious activity has stopped across the environment, not just on the first reported machine. Responders should look for repeated encryption events, newly modified file extensions, fresh ransom notes, active suspicious processes, and outbound connections that match known attacker infrastructure. Disk and CPU spikes matter because they can reflect ongoing encryption or credential harvesting, but they only become meaningful when tied to repeated malicious behaviour rather than normal recovery noise.

Network evidence is often decisive. If a host continues to contact command-and-control infrastructure, reaches out to unusual internal peers, or attempts authentication in patterns that do not fit the user or system role, the incident may still be unfolding. File server telemetry, endpoint logs, and identity signals should be reviewed together so responders can distinguish one infected device from a broader campaign. That is especially important when ransomware operators have used remote management tools or stolen credentials to move laterally before detonation.

• Check whether the same encryption pattern appears on more than one endpoint after containment.
• Confirm whether new ransom notes or new file changes are still being created.
• Validate that suspicious processes, services, tasks, or scripts are no longer restarting the payload.
• Review east-west traffic for signs that the attacker still has an internal foothold.
• Correlate endpoint alerts with authentication and remote access logs to confirm the path has been cut off.

Where these signals disagree, responders should assume the environment is not yet stable and delay restoration until the active mechanism is identified and removed. Anthropic’s report on AI-orchestrated cyber espionage is not ransomware guidance, but it is relevant as an example of how automated operator workflows can sustain malicious activity across multiple steps when defenders miss the real control point.

Where this guidance breaks down is in heavily encrypted, poorly instrumented environments where responders cannot separate post-attack recovery activity from true malicious persistence.

Common False Positives and Recovery Edge Cases

Tighter containment often creates more operational noise, requiring teams to balance speed of isolation against the risk of mistaking recovery actions for continued compromise. A rebuild, restore job, or log-forwarding backlog can mimic parts of the original ransomware pattern, so the team needs a clear line between normal remediation work and fresh hostile behaviour.

One common edge case is when encryption has stopped but the attacker still has access through a second host, remote tool, or stolen account. Another is when a dormant payload is present but not yet reactivated, which can look like a clean endpoint until a scheduled task or service wakes it again. There is still some debate in the field about how much telemetry is enough to declare ransomware fully eradicated, but there is broad agreement that a single clean scan is not sufficient on its own.

Operationally, responders should treat resumed file changes, repeated outbound beacons, or reappearance of the same note and extension patterns as a restart of the incident, not a minor recovery artefact. In practice, the highest-risk mistake is restoring systems before proving that the attacker’s persistence mechanism and lateral movement path have been removed.

Practitioner Guidance

What to prioritise: Confirm whether the ransomware is still executing, not just whether the original victim machine is offline. If the same file activity or network pattern reappears after containment, treat that as an active-response problem, not a recovery problem.

What to verify: Correlate endpoint, authentication, and network telemetry before you trust a containment decision. The key verification is that the malicious process, its restart mechanism, and any internal spread path have all stopped at the same time.

Decision rule: If you cannot rule out lateral movement or a surviving remote access path, do not begin restoration from shared sources or gold images that may be re-infected on reconnect.

Practitioner takeaway: The safest declaration is not “the malware is gone,” but “we have evidence that the attacker can no longer continue the behaviour we observed.”

Related resources from NHI Mgmt Group

• What is the difference between protecting Active Directory and protecting individual endpoints during a ransomware incident?
• How should security teams use data context during a ransomware incident?
• Why do incident response plans often fail during real cyber crises?
• Why do NHI and privileged access controls matter during incident response?