Detecting Ransomware on Linux

Ransomware on Linux is no longer limited to edge cases. Modern operators target ESXi hosts, backup servers, NAS systems, CI runners, application servers, and any Linux machine that stores valuable data or can disrupt business operations.

The pattern is familiar: gain access, move laterally, locate high-value data, disable recovery paths, encrypt files, and leave a ransom note behind.

By the time a human notices the ransom note, the damage is already done. Detection has to happen earlier and at the host level.

What ransomware usually does

Even though ransomware families differ in tooling, their behavior is remarkably consistent:

• they rename or rewrite large numbers of files in a short period of time;
• they append a new extension such as .locked, .encrypted, .akira, .lockbit, or .deadbolt;
• they create ransom-note files like HOW_TO_DECRYPT.txt or README_FOR_RESTORE.html;
• they attempt to delete backups or stop backup software before encryption starts.

These actions are much harder to hide than the malware binary itself.

Why ransomware is hard to detect with network-only tools

• Encryption can happen entirely on-host with no outbound traffic required.
• Some families use legitimate admin tools and standard system calls.
• The payload may be custom-packed and invisible to static malware signatures.
• File encryption may start only after the attacker has already disabled logging, backups, or remote access.

That is why ransomware detection on Linux needs file activity, process context, and behavioral rate-based signals from the endpoint itself.

How SecureExec detects ransomware

SecureExec includes a built-in ransomware detection rule.

The Linux agent captures the events that matter most:

• file create events;
• file rename events;
• process creation events with full command line.

On the server, the ransomware built-in rule looks for several strong indicators.

1. File renamed to a known ransomware extension

The rule alerts when a file is renamed to an extension associated with real ransomware families, including:

• .locked
• .encrypted
• .deadbolt
• .akira
• .lockbit
• .cl0p
• .ryuk

This catches the moment the attacker begins transforming user data into encrypted artifacts.

2. Ransom note creation

The rule also alerts when it sees filenames commonly used as ransom notes, such as:

• HOW_TO_DECRYPT
• HOW_TO_RESTORE
• README_FOR_DECRYPT
• README_FOR_RESTORE
• YOUR_FILES_ENCRYPTED

This is a strong post-encryption signal and often the first artifact analysts find during triage.

3. Mass file rename behavior

Many ransomware families touch files rapidly. SecureExec tracks rename activity per process and raises an alert when one process renames large numbers of files within a short time window.

This matters because not every family uses a predictable extension. Some generate random suffixes or rename files in ways that defeat simple filename lists. Rate-based detection covers that gap.

4. Backup and recovery disruption

Before encryption, ransomware often tries to make recovery harder. The rule looks for commands such as:

• vssadmin delete shadows
• wmic shadowcopy delete
• rm -rf /backup
• systemctl stop veeam
• systemctl stop bacula

These are high-value pre-encryption signals that can give your team a chance to contain the host before file loss spreads.

Why this detection is practical

The rule is designed to use strong host-side indicators rather than vague heuristics:

• file-extension matching catches families with predictable naming;
• ransom-note filenames catch the most obvious operator artifact;
• mass rename detection covers families with random extensions;
• backup-wipe commands catch the preparation stage before encryption.

This combination gives you earlier and higher-confidence detection than waiting for a user to report inaccessible files.

What an alert gives you

When SecureExec fires the ransomware rule, you get the process and file context needed to investigate fast:

• the process name responsible for file changes;
• the new encrypted path or ransom-note filename;
• the command line used to stop backup tooling or wipe recovery data;
• correlated events and process lineage for the same host.

That is enough to decide whether to isolate the host immediately and start incident response.

Built in, not bolted on

You do not need to build ransomware detection logic from scratch, maintain filename lists manually, or write your own stateful rename counters first. SecureExec ships this detection as a built-in rule.

If the rule fires, you can investigate immediately and use host isolation to contain the endpoint without leaving the platform.

Try SecureExec

If you want built-in ransomware detection on Linux endpoints with file, process, and behavior-level visibility, SecureExec already includes it.

Try SecureExec to detect ransomware activity early and respond before encryption spreads across your fleet.