Inside Pay2Key: Technical Analysis of a Linux Ransomware Variant
Detection stack
- AIDR
- Alert
- ETL
- Query
Summary
Pay2Key is an Iranian-attributed ransomware operation that introduced a Linux variant in late August 2025. The malware runs with root privileges, turns off security protections, and encrypts files with ChaCha20. Its behavior is driven by a configuration file and supports both full-file and partial encryption modes. The analysis emphasizes the operator’s techniques and the growing need for Linux-specific ransomware defenses.
Investigation
Morphisec Threat Labs conducted a reverse-engineering review of the Pay2Key Linux sample. The researchers documented privilege validation, JSON configuration parsing, filesystem discovery through /proc/mounts, service termination, disabling of SELinux and AppArmor, cron-based persistence, and ChaCha20 encryption with per-file keys stored inside an obfuscated metadata block. The sample showed no evidence of network C2 traffic or data exfiltration.
Mitigation
The report advises deploying Linux-focused anti-ransomware tools that can stop execution before encryption starts, support moving target defense, and maintain runtime integrity protections. Reducing the attack surface by disabling unnecessary services and hardening SELinux/AppArmor policies is also recommended. Endpoint protection that tracks abnormal privileged process activity can further improve resilience.
Response
If Pay2Key is detected, isolate the system, stop the malicious process, and delete the cron persistence entry. Confirm file permissions are intact and recover encrypted data from backups. A forensic investigation should then capture relevant IOCs and check the wider environment for related activity.
"graph TB %% Class definitions classDef technique fill:#ffcc99 classDef operator fill:#ff9900 %% Nodes representing each ATT&CK technique persistence_cron["<b>Technique</b> – <b>T1053.003 Scheduled Task/Job: Cron</b><br/>Creates or modifies a cron job to ensure execution after system reboot"] class persistence_cron technique defense_impair["<b>Technique</b> – <b>T1562 Impair Defenses</b><br/>Disables SELinux and AppArmor to weaken host protection mechanisms"] class defense_impair technique indicator_removal["<b>Technique</b> – <b>T1027.005 Indicator Removal from Tools</b><br/>Removes securityu2011tool indicators to evade detection"] class indicator_removal technique discovery_mounts["<b>Technique</b> – <b>T1083 File and Directory Discovery</b><br/>Reads /proc/mounts, filters pseudou2011filesystems and classifies mounts for target selection"] class discovery_mounts technique obfuscation_storage["<b>Technique</b> – <b>T1027 Obfuscated Files or Information</b><br/>Stores encryption metadata using a hardu2011coded string and obfuscates the payload"] class obfuscation_storage technique deobfuscate["<b>Technique</b> – <b>T1140 Deobfuscate/Decode Files or Information</b><br/>Decodes the obfuscated payload during processing"] class deobfuscate technique impact_encryption["<b>Technique</b> – <b>T1486 Data Encrypted for Impact</b><br/>Generates peru2011file ChaCha20 keys and encrypts data, producing ransomu2011demanding files"] class impact_encryption technique %% Flow connections persistence_cron –>|leads_to| defense_impair defense_impair –>|leads_to| indicator_removal indicator_removal –>|leads_to| discovery_mounts discovery_mounts –>|leads_to| obfuscation_storage obfuscation_storage –>|leads_to| deobfuscate deobfuscate –>|leads_to| impact_encryption "
Attack Flow
Simulation Execution
Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.
Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic.
-
Attack Narrative & Commands:
The simulated attacker has already obtained a foothold on the Linux host and wishes to prepare the environment for ransomware deployment. They first verify they are operating with root privileges, then deliberately disable security controls and stop critical services to avoid interruption during encryption. The attacker avoids creating a cron entry during this phase to satisfy the rule’s negation clause.
- Privilege Verification – The attacker runs
id -uand checks for UID 0, which appears in the command line as “root”. - Service Interruption – Using
systemctl stopthe attacker stops thesshservice to prevent remote interference. - Process Disruption – The attacker kills a low‑priority background process (
sleep 300 &) to illustrate thekillpattern. - Defense Disabling – SELinux is set to permissive (
setenforce 0) and AppArmor is disabled (aa-disable).
These steps produce
execveevents that satisfyselection1(contain “root”) andselection2/selection3(contain stop/kill or disable commands) while omittedcrontab, thereby triggering the Sigma rule. - Privilege Verification – The attacker runs
-
Regression Test Script:
#!/usr/bin/env bash set -e echo "[*] Step 1 – Verify root privileges (contains 'root')" id -u | grep ^0 && echo "root privilege confirmed" echo "[*] Step 2 – Stop a service (systemctl stop sshd)" sudo systemctl stop sshd || true echo "[*] Step 3 – Spawn and kill a dummy process" sleep 300 & DUMMY_PID=$! sudo kill -9 $DUMMY_PID || true echo "[*] Step 4 – Disable SELinux and AppArmor" sudo setenforce 0 || true sudo aa-disable || true echo "[+] Simulation complete – detection should have fired." -
Cleanup Commands:
#!/usr/bin/env bash set -e echo "[*] Restoring services" sudo systemctl start sshd || true echo "[*] Re‑enabling SELinux (enforcing) and AppArmor" sudo setenforce 1 || true sudo aa-enable || true echo "[*] Ensuring no stray processes remain" pkill -f "sleep 300" || true echo "[+] Cleanup finished."