Malware — Types, Behavior, and How It Spreads

Malware is not a monolith. The word describes hundreds of distinct families with different goals, different evasion techniques, and different detection profiles. A ransomware operator wants to encrypt files and collect a ransom. A RAT operator wants persistent, stealthy access for espionage. A rootkit developer wants to be invisible to the OS itself. A worm developer wants to spread as fast as possible. Understanding each family's behavior model is what allows defenders to detect them — because a hash-based signature only catches known samples, but behavioral detection catches unknown variants doing the same things.

This module goes inside each major malware family. You'll see how ransomware's encryption works and why it's hard to recover from. You'll understand how rootkits operate below the operating system's visibility. You'll trace a RAT's C2 communication and see why firewalls don't stop it. And you'll understand the behavioral signatures that modern EDR (Endpoint Detection and Response) tools use to catch each family even without a prior sample.

Malware Taxonomy — A Map of the Families

Modern malware rarely belongs to exactly one family. Emotet started as a banking trojan, evolved into a dropper for other malware, and acted as a botnet agent spreading via email. LockBit ransomware includes a worm module for lateral movement, a credential stealer, and an exfiltration tool before the encryption payload runs. The taxonomy is useful for understanding behavior, but production malware is a Swiss Army knife.

Ransomware — How the Encryption Works

Ransomware's goal is to make files unrecoverable without the decryption key — and to make that key available only after payment. Modern ransomware uses hybrid encryption: symmetric encryption (AES-256) for speed, and asymmetric encryption (RSA-2048 or ECC) to protect the symmetric key. This design is intentional: symmetric encryption of a large file takes milliseconds; RSA encryption of the same file would take hours.

Ransomware encryption model:

Before infection:
  Attacker generates: RSA-2048 keypair (public_key, private_key)
  private_key stays on attacker's server — victim never sees it

During infection (on victim's machine):
  1. Ransomware generates random AES-256 key (unique per file or per machine)
  2. Encrypts each file with AES-256 (fast — GBs per minute)
  3. Encrypts the AES key with attacker's RSA public key
  4. Stores encrypted AES key alongside encrypted file
     (e.g., document.docx → document.docx.locked + document.docx.locked.key)
  5. Deletes original files + overwrites free space to prevent recovery
  6. Displays ransom note

After payment:
  Attacker sends RSA private key (or a decryptor tool)
  Victim uses private key to decrypt AES key
  Victim uses AES key to decrypt files

Why this design is secure:
  - AES key is random per file — no pattern to exploit
  - RSA private key never touches victim's machine
  - Without private key, brute-forcing AES-256 takes ~10^50 years
  - Attacker controls payment by controlling private key release

Double extortion is now standard for professional ransomware groups. Before encrypting, they exfiltrate a copy of sensitive data. If the victim refuses to pay, they threaten to publish the data on their "leak site" on the dark web. This creates leverage even against organizations that have backups, since backup restoration doesn't prevent data exposure.

Ransomware execution timeline (typical enterprise attack):

Week -6 to -2: Initial access
  - Phishing email with malicious attachment drops loader
  - Loader fetches Cobalt Strike beacon
  - Attacker has C2 access to one workstation

Week -2 to -1: Reconnaissance and lateral movement
  - Enumerate AD: BloodHound maps trust paths to Domain Admin
  - Steal credentials: mimikatz, Kerberoasting
  - Move laterally: PsExec, WMI, scheduled tasks
  - Reach Domain Controller

Day -3 to -1: Pre-ransomware preparation
  - Disable backup software (VSS, Veeam, backup agents)
  - Delete shadow copies: vssadmin delete shadows /all /quiet
  - Disable Windows Defender: Set-MpPreference -DisableRealtimeMonitoring $true
  - Stage ransomware binary on file server
  - Exfiltrate sensitive data (double extortion)

Day 0: Ransomware deployment
  - Deploy via Group Policy or PsExec to all domain machines simultaneously
  - Encryption begins: 10,000 machines encrypting simultaneously
  - Network shares encrypted first (most business impact)
  - Ransom note dropped on desktop and every folder
  - Attack visible: SOC overwhelmed with alerts

Recovery without payment (if prepared):
  - Isolated backups (offline or immutable) restore data
  - Active Directory rebuild from known-good snapshot
  - Full wipe and reimage of all endpoints (faster than triage)
  - Timeline: 2-4 weeks even with good preparation

Rootkits — Hiding Below the OS

A rootkit's purpose is concealment. Unlike ransomware that wants to be noticed (after encryption), a rootkit wants to be invisible — to the OS, to security tools, and to the analyst. It achieves this by operating at a privilege level that security software can't monitor.

Kernel-mode rootkit technique: DKOM (Direct Kernel Object Manipulation)

Windows maintains a doubly-linked list of running processes in the kernel:
  EPROCESS structure for each process, linked via ActiveProcessLinks

Rootkit action:
  1. Locate EPROCESS structure of the process to hide (e.g., malware.exe)
  2. Unlink it from the ActiveProcessLinks list:
     evil_process->prev->next = evil_process->next
     evil_process->next->prev = evil_process->prev
  3. Process continues running but is invisible to:
     - Task Manager (reads ActiveProcessLinks via NtQuerySystemInformation)
     - Process Explorer
     - EDR products that enumerate processes the normal way

Detection:
  - Cross-view comparison: Compare kernel process list with ETW (Event Tracing)
    or hardware performance counters — discrepancy reveals hidden processes
  - Memory forensics: Volatility plugin 'psxview' compares 7 process listing
    sources and flags any that appear in some but not others
  - Hypervisor-based EDR: Run security checks from Ring -1 where rootkit
    can't tamper with the view

Bootkit mechanics (pre-OS persistence):

Legacy MBR bootkit:
  Normal boot: BIOS → MBR → bootloader → OS kernel → Windows
  Bootkit:     BIOS → Modified MBR (bootkit code) → Original MBR → OS
  Bootkit code loads before OS, patches kernel in memory

UEFI bootkit (modern threat, e.g., CosmicStrand, ESPecter):
  Target: EFI System Partition (ESP) — unencrypted even with BitLocker
  Modify a legitimate bootloader (e.g., grubx64.efi)
  UEFI executes modified bootloader → installs hooks → loads OS
  Survives: OS reinstall, hard drive wipe (if UEFI firmware not re-flashed)

Detection of UEFI bootkits:
  - Secure Boot: Firmware validates bootloader signature before executing
                 Modified bootloader fails signature check → boot blocked
  - UEFI Secure Boot with custom keys: Only your signed bootloaders execute
  - Firmware integrity monitoring: Read UEFI firmware, compare against known-good hash
  - BootGuard (Intel): Hardware root of trust — UEFI firmware itself is verified

Remote Access Trojans (RATs) — C2 Channels and Persistence

A RAT gives an attacker interactive remote control of a compromised machine. The attacker can execute commands, upload/download files, activate the webcam, log keystrokes, and pivot to other systems. The challenge for the RAT is maintaining a communication channel without being blocked by firewalls, and maintaining persistence without being removed by security tools.

RAT C2 (Command and Control) communication patterns:

Problem: Victim is behind a corporate firewall
  - Inbound connections blocked (firewall denies unsolicited inbound)
  - Outbound connections allowed (users need internet access)

Solution: Victim CALLS OUT to attacker (beacon model)
  Victim → attacker's C2 server: "Ready for commands"
  Attacker → C2 server → Victim: "Run: ipconfig /all"
  Victim → C2 server → Attacker: "Result: ..."

C2 transport options:
  HTTP/HTTPS:  Blend into normal web traffic
               Requests look like normal browsing
               HTTPS encrypts content from firewall inspection
               Best for bypassing corporate proxies

  DNS:         Encode commands/data in DNS query subdomains
               data-chunk.c2server.com (exfiltration)
               Very hard to block — DNS must work for everything
               Used by DNScat2, IodineC2

  Social media: Twitter DMs, GitHub issues, Slack channels as C2
               Impossible to block without blocking the platform

Cobalt Strike beacon communication (widely used by red teams and APTs):
  Default: HTTPS to attacker's team server
  Malleable C2 profile: Disguise traffic as specific websites (Amazon, Google)
  Jitter: Variable sleep interval (30s ± 30%) to avoid pattern detection
  Staging: Tiny initial stager downloads full beacon payload in-memory

RAT persistence mechanisms (Windows):

Registry Run keys:
  HKCUSoftwareMicrosoftWindowsCurrentVersionRun
  HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun
  Simple, detectable, survives reboots

Scheduled Tasks:
  schtasks /create /tn "WindowsUpdate" /tr "C:UsersPublic
at.exe" /sc onlogon
  Persists across reboots, blends with legitimate tasks

WMI Event Subscription:
  Event filter: "OnSystemStart" → runs arbitrary command
  Stored in WMI repository — no file needed, harder to find

DLL hijacking:
  Place malicious DLL in application's search path
  Legitimate application loads malicious DLL on startup

Service installation:
  sc create "WindowsAudio2" binpath="C:WindowsTempsvc.exe" start=auto
  Runs as SYSTEM, harder to detect

COM hijacking:
  Override COM object registration in HKCU (user-writable)
  When legitimate application invokes COM object → executes attacker code

Detection signals for RAT persistence:
  - New registry Run key entries (especially HKCU — no admin needed)
  - Scheduled tasks created by non-standard processes
  - Unusual parent-child process relationships (Word spawning cmd.exe)
  - Network connections from unexpected processes (Calculator.exe → internet)
  - Unsigned binaries in temp folders (C:UsersPublic, C:Temp)

Worms — Self-Propagation Mechanics

A worm spreads without human interaction. Unlike a trojan (which requires a user to run it) or ransomware spread by an operator (which requires manual lateral movement), a worm carries its own propagation engine. The WannaCry ransomware worm of 2017 infected 230,000 machines in 150 countries in a single day — because it spread automatically via the EternalBlue exploit against SMBv1.

WannaCry propagation model (2017):

Exploit used: EternalBlue (CVE-2017-0144)
  - SMBv1 protocol buffer overflow, allows unauthenticated RCE
  - Developed by NSA (codenamed EternalBlue), leaked by Shadow Brokers
  - Microsoft patched March 2017, WannaCry deployed May 2017

Propagation loop (runs on every infected machine):
  1. Generate random IP addresses
  2. Attempt TCP connection to port 445 (SMB)
  3. If port 445 open → run EternalBlue exploit
  4. If exploit succeeds → upload WannaCry payload via DoublePulsar backdoor
  5. New machine infected → repeat from step 1

Speed:
  - Each infected machine begins scanning immediately
  - Exponential spread: 1 → 10 → 100 → 10,000 within hours
  - 230,000 machines infected in ~24 hours

Kill switch (accidental):
  WannaCry checked if a specific domain was registered before encrypting
  Security researcher Marcus Hutchins registered the domain ($10.69)
  All existing infections checked → domain resolves → stopped encrypting
  New infections still spread but didn't trigger encryption
  Domain was a sandboxing detection mechanism, not intentional kill switch

Worm propagation vectors:

Network vulnerability exploitation:
  - SMBv1 (EternalBlue → WannaCry, NotPetya)
  - SSH brute force (scan /24, try admin/password)
  - Log4Shell RCE on any accessible Java service
  - Unpatched RDP (BlueKeep CVE-2019-0708)

Email self-propagation:
  - Worm reads address book → sends copies of itself to all contacts
  - Appears to come from known sender (infected friend)
  - ILOVEYOU worm (2000): spread to 50M machines in 10 days

USB/Removable media:
  - Autorun.inf exploitation (patched in Windows 7)
  - Stuxnet: spread via USB to reach air-gapped networks
  - LNK file exploitation

File share propagation:
  - Write copy to every accessible network share
  - Mapped drives, UNC paths, SYSVOL (if Domain Admin)

Defence against worm propagation:
  - Patch quickly (EternalBlue patch was 59 days before WannaCry)
  - Network segmentation: Limit which machines can reach port 445
  - Firewall rules: Block SMB (445) outbound and between segments
  - Disable unused services: SMBv1 disabled by default since Windows 10 1709

Infostealers — Credential Harvesting at Scale

Infostealers are purpose-built malware for harvesting credentials, browser-saved passwords, session cookies, cryptocurrency wallets, and VPN credentials. They are often deployed as MaaS (Malware-as-a-Service) — anyone can subscribe to RedLine Stealer or Raccoon Stealer for ~$200/month and receive a dashboard of stolen credentials.

What infostealers target (RedLine/Raccoon behavior):

Browser credentials:
  Chrome, Edge, Firefox store passwords in SQLite databases
  Chrome: %LOCALAPPDATA%GoogleChromeUser DataDefaultLogin Data
  SQLite DB is encrypted with DPAPI (Windows Data Protection API)
  DPAPI key is tied to the Windows user account — accessible when logged in
  Stealer runs as the user → decrypts passwords → exfiltrates plaintext

Session cookies:
  Browser session cookies in: %LOCALAPPDATA%GoogleChromeUser DataDefaultCookies
  Same DPAPI encryption, same attack
  Stolen cookie → import into attacker's browser → authenticated as victim
  Bypasses MFA entirely (cookie was issued AFTER MFA was passed)
  This is how "2FA bypass" breaches happen without phishing for TOTP codes

Crypto wallets:
  MetaMask: %APPDATA%MetaMask (browser extension)
  Exodus: %APPDATA%Exodusexodus.wallet
  Contains encrypted wallet data — offline crack or real-time theft if unlocked

VPN credentials:
  NordVPN, ExpressVPN: credentials stored in config files
  Corporate VPN certificates

Discord tokens:
  %APPDATA%discordLocal Storageleveldb
  Token = API key for the account — full access without password

Exfiltration:
  Compress all stolen data → POST to attacker's server (port 80/443)
  Takes <30 seconds total
  Logs sent to attacker dashboard: stealer-as-a-service portal

Behavioral Detection — How EDR Catches Unknown Malware

Traditional antivirus relies on signature matching — comparing files against a database of known malware hashes. Attackers defeat this by recompiling the malware (changing the hash) or using obfuscators that transform the binary. Modern Endpoint Detection and Response (EDR) tools use behavioral detection instead — monitoring what processes do, not what they look like.

Behavioral detection signals used by EDR:

Process anomalies:
  - Office application (winword.exe) spawning cmd.exe or powershell.exe
    → Word macro execution (98% of Word-spawned shells are malicious)
  - Browser spawning cmd.exe or wscript.exe
    → Drive-by download execution
  - Process injecting into other processes (CreateRemoteThread API)
    → Process hollowing, injection techniques

Memory anomalies:
  - Code executing from memory regions not backed by a file on disk
    → Reflective DLL injection, shellcode execution
  - Unsigned code in signed process's memory space
    → Process injection into legitimate process (explorer.exe, svchost.exe)

File system anomalies:
  - Mass file modifications in short time period (ransomware)
    → Detect: >100 files changed in 60 seconds → alert + suspend process
  - Dropping executables in temp folders (%TEMP%, C:UsersPublic)
  - Creating files with double extension (document.pdf.exe)

Registry anomalies:
  - New Run key created by non-standard process
  - COM object registration in HKCU pointing to temp folder

Network anomalies:
  - Process that doesn't normally make network connections → connecting out
    (Calculator.exe, Notepad.exe connecting to external IP)
  - DNS queries with high entropy subdomains (DNS tunneling)
  - Beaconing: regular intervals of outbound connections (C2 heartbeat)

Credential access anomalies:
  - LSASS memory access (mimikatz pattern: OpenProcess + ReadProcessMemory on lsass)
  - Volume Shadow Copy deletion (ransomware preparation)
  - SAM/SECURITY registry hive access

EDR response options:
  - Alert only (detection mode)
  - Kill process immediately (prevention mode)
  - Network isolate host (quarantine mode)
  - Collect memory dump for forensics

Malware Analysis — Static and Dynamic Techniques

When security teams receive a suspicious file, they analyze it to understand its capabilities, indicators of compromise (IOCs), and MITRE ATT&CK mapping. Analysis falls into two categories: static analysis (examine the file without running it) and dynamic analysis (run it in a controlled environment and observe behavior).

Static analysis workflow:

1. File identification
   file malware.exe              # identify file type (PE, ELF, script)
   md5sum malware.exe            # compute hash
   sha256sum malware.exe         # submit to VirusTotal

2. String extraction
   strings malware.exe           # extract printable strings
   strings -el malware.exe       # extract Unicode strings (Windows binaries)
   Look for: URLs, IPs, registry keys, API names, error messages

3. PE analysis (Windows executables)
   pe-bear / CFF Explorer / Detect-It-Easy
   Check: imported DLLs and functions (imports reveal capability)
   WININET.dll → makes HTTP requests
   ADVAPI32.dll → accesses registry, creates services
   Check: section names and entropy
   High entropy (>7.0) → packed/encrypted → needs unpacking

4. Signature matching
   clamav --detect-pua malware.exe
   YARA rules: pattern matching on bytes and strings

5. Disassembly
   IDA Free / Ghidra (NSA's open-source reverse engineering tool)
   Binary Ninja
   Identify: main function, anti-analysis checks, crypto operations

Dynamic analysis:
  Safe environment: VM with snapshots (VMware, VirtualBox)
  Isolated network: Fake DNS, HTTP server (FakeNet-NG, INetSim)
  Tools:
    Process Monitor (ProcMon): File, registry, process activity
    Wireshark: Network traffic
    Regshot: Registry before/after snapshot diff
    x64dbg: Interactive debugger for stepping through execution

  Run → observe → document IOCs:
    C2 domains/IPs, mutex names, registry keys created,
    files dropped, child processes spawned, user agents

VirusTotal submission workflow:

1. Compute SHA-256 hash: sha256sum suspicious.exe
2. Search hash on VirusTotal.com first
   (uploading a file tips off the malware author if they monitor VT)
3. If not found → upload file (accept that file becomes public)
4. Check detection rate: 0/72 = likely clean or new; 50+/72 = confirmed malware
5. Behavior tab: dynamic analysis results from sandboxes
6. Relations tab: connected domains, IPs, related samples
7. Community tab: threat intel from other analysts

Sandbox services:
  any.run:      Interactive online sandbox (see execution in real-time)
  Joe Sandbox:  Detailed behavioral report
  Cuckoo:       Open-source sandbox, self-hosted
  Hybrid Analysis: Free, uses Falcon Intelligence sandbox

Workplace Scenario — Ransomware Outbreak Investigation

A hospital's SOC receives calls at 06:47 AM that workstations are showing ransom notes. File servers are inaccessible. The EDR console shows 847 endpoints with "Mass File Modification" alerts triggered at 06:43 AM.

Incident response — first 60 minutes:

06:47 — Initial call: "Files replaced with .locked extension, ransom note on desktop"
06:48 — SOC checks EDR: 847 "Mass File Modification" alerts, all at 06:43:00
         All suppressed at 06:43:31 → EDR killed ransomware process on most endpoints
         23 endpoints: no EDR (EOL Windows 7 machines in radiology)

06:50 — Identify patient zero
         EDR telemetry: ransomware process first appeared at 06:41:17 on
         HOSTNAME: BILLING-PC-14
         Parent process: outlook.exe → cmd.exe → powershell.exe → ransomware.exe
         → Malicious email attachment opened by billing staff

06:52 — Network isolation: BILLING-PC-14 isolated via EDR remote command
         Also isolate 23 unprotected endpoints: physically unplug (no remote EDR)

06:55 — Assess backup status
         Call backup admin: Last good backup 11:00 PM prior night
         Backup server: separate domain, separate credentials → NOT encrypted
         Recovery window: 7.5 hours of data loss

07:00 — Scope assessment
         EDR: 847 endpoints tried to encrypt, all stopped by EDR kill
         24 endpoints encrypted (patient zero + 23 unmanaged)
         File servers: checked shadow copies → ransomware deleted VSS before 06:43
         → File server data from 06:00 PM prior day (when VSS ran) + backup

07:15 — Initiate recovery
         Restore file servers from backup: ETA 4 hours
         Wipe and reimage 24 encrypted endpoints: ETA 6 hours
         Update EDR policies: block office apps spawning cmd.exe

Lessons:
  - EDR saved 847 endpoints because behavioral rule (mass file mod) triggered fast
  - 23 unmanaged endpoints were the weak link — eliminate Windows 7
  - Backup server separation (different domain) was critical — common mistake is
    using domain admin to access backup server (ransomware gets it too)
  - Response time from 06:43 detection to isolation: 9 minutes → acceptable

Interview Questions

Error Library — Common Mistakes

In Module 12, you go deep on credential attacks. How Pass-the-Hash lets attackers authenticate with stolen NTLM hashes without knowing the password. How Kerberoasting extracts service account password hashes from Active Directory for offline cracking. How credential stuffing works at industrial scale. And what defences actually stop these techniques versus which ones only slow them down.