Security Basics Lesson 21 – Malware Types & Analysis | Dataplexa
Section III · Lesson 21

Malware Types & Analysis

Malware analysis is the process of understanding what a malicious program does, how it does it, and what it leaves behind. Knowing the type of malware you're dealing with tells you immediately what to look for, what it's capable of, and how to contain it. This lesson goes deeper than the taxonomy — it covers how each type actually behaves and how analysts examine samples safely.

This lesson covers

Malware types at a technical level → Static vs dynamic analysis → Strings and file inspection → How ransomware encrypts files → Persistence mechanisms → Indicators of Compromise → Analysis tools hands-on

How malware actually behaves

Every piece of malware needs to accomplish four things to be effective: get onto the system, execute, do its job, and survive long enough to do it. The techniques used at each stage are what distinguish malware families from each other — and what analysts look for when investigating a sample.

Delivery

Phishing attachments, malicious downloads, drive-by browser exploits, USB drops, supply chain compromise. The initial vector determines what privileges the malware starts with.

Execution

Running a downloaded binary, macro execution in Office documents, PowerShell scripts, DLL injection into legitimate processes, living-off-the-land using built-in Windows tools.

Persistence

Registry run keys, scheduled tasks, startup folders, cron jobs, systemd services, browser extensions, boot sector infection. Ensures the malware survives a reboot.

Payload

Encrypting files, exfiltrating data, establishing C2 communication, credential harvesting, lateral movement, deploying additional payloads, or simply destroying data.

Static analysis — examining a file without running it

Static analysis means examining a malware sample without executing it. You look at the file's properties, extract readable strings, identify imported functions, and check its hash against known threat databases — all without giving it a chance to run. It's the safe first step in any analysis workflow.

The strings command is one of the most useful tools in a malware analyst's kit. Malware almost always contains readable text — hardcoded URLs, registry keys it plans to modify, error messages, file paths, encryption keys, and sometimes even the attacker's username left in a debug string. Extracting these gives you a map of what the sample intends to do before you run a single line of it.

# Basic file identification — never trust the extension
file suspicious_file.exe

# Get the SHA256 hash for threat intel lookups
sha256sum suspicious_file.exe

# Extract all printable ASCII strings (min length 6 chars)
strings -n 6 suspicious_file.exe

# Extract both ASCII and Unicode strings (Windows malware often uses Unicode)
strings -a -n 6 suspicious_file.exe
strings -e l -n 6 suspicious_file.exe   # UTF-16LE (common in Windows binaries)

# Filter strings for interesting indicators
strings suspicious_file.exe | grep -Ei \
  "http|ftp|cmd|powershell|regedit|HKEY|\\\\AppData|taskkill|netsh|schtasks|CreateRemoteThread"

# Check what the binary imports — reveals capabilities without running it
# objdump works on ELF (Linux), use pestr/pedump for PE (Windows) files
objdump -x suspicious_file | grep "IMPORT\|NEEDED"
# file suspicious_file.exe
suspicious_file.exe: PE32 executable (GUI) Intel 80386, for MS Windows

# sha256sum suspicious_file.exe
a3f91bc2d784e1f0c92a8d3e5b6f7a891234abcd...  suspicious_file.exe

# strings output filtered for indicators
http://185.220.101.47:8080/gate.php
cmd.exe /c schtasks /create /tn "WindowsUpdate" /tr
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
C:\Users\Public\svchost32.exe
powershell -enc JABjAGwAaQBlAG4AdA...
CreateRemoteThread
VirtualAllocEx
WriteProcessMemory
taskkill /f /im MsMpEng.exe

# These strings reveal:
# → C2 server at 185.220.101.47:8080
# → Persistence via scheduled task named "WindowsUpdate"
# → Registry run key for autostart
# → Drops a fake svchost32.exe in Public folder
# → Encoded PowerShell (base64) — likely second stage loader
# → Process injection capability (VirtualAllocEx + WriteProcessMemory)
# → Attempts to kill Windows Defender (MsMpEng.exe)

What just happened

From strings alone — without executing the file — we've identified a C2 server address, two persistence mechanisms (scheduled task + registry run key), a dropper path, an encoded second-stage PowerShell loader, process injection API calls, and an active attempt to disable Windows Defender. That's enough to write detection rules, block the C2 at the firewall, and know exactly what to look for on any other machines on the network. Static analysis often gives you 80% of what you need in the first five minutes.

How ransomware encrypts files

Ransomware is technically straightforward — it's the business model wrapped around encryption that makes it effective. Modern ransomware uses hybrid encryption: a symmetric key (typically AES-256) encrypts the victim's files at speed, then an asymmetric public key (RSA or ECC) encrypts the symmetric key. Only the attacker's private key can decrypt the symmetric key — and they hold that on their infrastructure until payment is confirmed.

The reason files can't be recovered without paying — or without backups — is that the symmetric key is generated fresh on the victim's machine, used to encrypt everything, then itself encrypted with the attacker's public key and either sent to the C2 server or left in a file on disk. Without the matching private key, the symmetric key is unrecoverable and the files stay encrypted.

The attacker's perspective

Modern ransomware groups operate a double extortion model. They don't just encrypt — they exfiltrate first. Before running the encryption routine, they quietly copy sensitive data to their own infrastructure. The ransom demand then has two components: pay to get your files back, and pay to prevent us publishing your data. This means even organisations with perfect backups face the threat of data exposure if they don't pay. The Cl0p ransomware group used this model to extort hundreds of organisations through the MOVEit vulnerability in 2023.

Persistence mechanisms — how malware survives reboots

A piece of malware that disappears on reboot is far less dangerous than one that survives. Establishing persistence is one of the first things most malware does after execution. On Linux, the most common persistence locations are cron jobs, systemd services, shell profile files, and SSH authorized_keys. Knowing where to look is half the detection work.

# Audit common Linux persistence locations

# 1. Cron jobs — check all users and system-level crons
crontab -l
sudo crontab -l
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/

# 2. Systemd services — look for unfamiliar unit files
systemctl list-units --type=service --state=running
ls -la /etc/systemd/system/ | grep -v "^total"
# Inspect any unfamiliar service
sudo systemctl cat suspicious-service-name

# 3. Shell startup files — malware hides here to run on every login
cat ~/.bashrc ~/.bash_profile ~/.profile /etc/profile /etc/bash.bashrc

# 4. SSH authorized_keys — backdoor access via added public keys
cat ~/.ssh/authorized_keys
sudo find /home -name "authorized_keys" -exec cat {} \;

# 5. SUID binaries — files that run with elevated privileges
# Attackers add SUID to shells or custom binaries for privilege escalation
find / -perm -4000 -type f 2>/dev/null | grep -v "^/usr\|^/bin\|^/sbin"

# 6. Recently modified files in sensitive locations
find /etc /usr/bin /usr/sbin /tmp /var/tmp -newer /etc/passwd -type f 2>/dev/null
# crontab -l (suspicious entry found)
* * * * * /tmp/.cache/updater >/dev/null 2>&1

# systemctl list-units — unfamiliar service
systemd-netupdate.service  loaded active running  Network Update Service

# sudo systemctl cat systemd-netupdate.service
[Unit]
Description=Network Update Service
After=network.target

[Service]
ExecStart=/usr/local/bin/.sysupd
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

# cat ~/.ssh/authorized_keys (unexpected key found)
ssh-rsa AAAAB3NzaC1yc2EAAA...XjP attacker@debian

# find SUID outside standard paths
/usr/local/bin/.sysupd   ← hidden binary with SUID bit set

# Recently modified files
/tmp/.cache/updater      ← hidden in /tmp, modified 2 hours ago
/usr/local/bin/.sysupd   ← modified same timestamp as .cache/updater

What just happened

Four persistence mechanisms found on the same compromised system. A cron job running a hidden binary from /tmp/.cache/ every minute. A fake systemd service named to look like a legitimate network utility. An SSH public key added to authorized_keys — giving the attacker direct passwordless access. A SUID binary in /usr/local/bin/ with a dot-prefixed name to hide it from casual ls listings. The matching timestamps on the last two files confirm they were dropped at the same time — part of the same infection. All four need to be removed before the system can be considered clean.

Indicators of Compromise

An Indicator of Compromise (IOC) is a piece of forensic evidence that suggests a system has been compromised. IOCs are the artifacts malware leaves behind — and they're what incident responders and threat intelligence teams use to detect infections, correlate attacks across organisations, and build detection rules.

File-based IOCs

SHA256 hashes of malicious files, file names dropped by the malware, file paths used for persistence, and file sizes. Hashes are the most precise — a single changed byte produces a completely different hash, so matching on hash means you've found an exact copy of a known sample.

Network IOCs

C2 server IP addresses and domains, specific URLs contacted by the malware, unusual port usage, beacon intervals, and DNS queries to known-malicious domains. Network IOCs can be detected and blocked even before the malware is identified on an endpoint.

Host-based IOCs

Registry keys created or modified, scheduled tasks added, new user accounts created, processes spawned from unusual parents, and modifications to system files. Collected from endpoint detection tools, EDR platforms, and manual forensic examination.

Instructor's Note

Never run a suspicious file on your main machine or any machine connected to a production network. If you need to execute malware for dynamic analysis — watching what it actually does at runtime — use an isolated VM with no network access, or an online sandbox like Any.run or Hybrid Analysis. These services execute the sample in an instrumented environment and give you a full behavioural report: network connections attempted, files created, registry modifications, processes spawned. You get the dynamic analysis results without any risk of the malware escaping onto your infrastructure.


Practice Questions

What type of malware analysis examines a file's properties, strings, and imported functions without executing it? (two words)




Modern ransomware groups exfiltrate data before encrypting it, then threaten to publish it if the ransom isn't paid. What is this model called? (two words)




What three-letter abbreviation refers to the forensic artifacts — hashes, IPs, registry keys, domain names — that suggest a system has been compromised?



Quiz

Why can ransomware-encrypted files not be recovered without paying the ransom or having backups?



From the persistence audit output, which finding is the most operationally dangerous for maintaining attacker access?



Why are network-based IOCs particularly valuable for early detection compared to file-based IOCs?


Up Next · Lesson 22

Phishing & Social Engineering

How phishing campaigns are constructed, what makes them convincing, how to analyse a suspicious email header, and the organisational controls that actually reduce click rates.