Unit 1: Introduction and Static Malware Analysis

1. Introduction: The Malware Threat Landscape and Cyber Defence

In modern cybersecurity operations, Malware (malicious software) represents one of the most versatile and destructive instruments utilized by threat actors, ranging from petty cybercriminals and ransomware syndicates to advanced persistent threat (APT) state-sponsored units. Malware is software deliberately designed to compromise the confidentiality, integrity, or availability of computer systems, networks, or digital assets without the informed consent of the system owner.

CODECopy Code
+----------------------------------------------------------------------------------------------------+
|                                    THE MALWARE ANALYSIS PYRAMID                                    |
|                                                                                                    |
|                                      / \                                                           |
|                                     /   \                                                          |
|                                    / ADV \    Level 4: Advanced Dynamic Analysis (Kernel/User Dbg) |
|                                   / DYNAM \   - Stepping through execution, unpacking memory       |
|                                  /─────────\                                                       |
|                                 /  ADVANCED \  Level 3: Advanced Static Analysis (Disassembly)     |
|                                /   STATIC    \ - IDA Pro, Ghidra, decompilation, control flow      |
|                               /───────────────\                                                    |
|                              /  BASIC DYNAMIC  \  Level 2: Basic Dynamic Analysis (Sandboxing)     |
|                             /     ANALYSIS      \ - Process Explorer, ProcMon, Wireshark, Regshot  |
|                            /─────────────────────\                                                 |
|                           /     BASIC STATIC      \  Level 1: Basic Static Analysis (Inspection)   |
|                          /        ANALYSIS         \ - Hashes, PE headers, Strings, Entropy, YARA  |
|                         +───────────────────────────+                                              |
+----------------------------------------------------------------------------------------------------+

Objectives of Malware Analysis

Security Operations Center (SOC) analysts, Incident Responders, and Threat Intelligence teams perform malware analysis to accomplish four mission-critical goals:

1. Extraction of Indicators of Compromise (IOCs): Uncovering atomic indicators (file hashes, command-and-control C2 IP addresses, domain names, URI paths, mutex names, registry run keys) to deploy network blocks and host endpoint detection rules.
2. Determining Scope and Impact: Ascertaining what actions the binary took or was capable of taking: did it exfiltrate credentials, encrypt data volumes, establish persistence, or move laterally across the subnet?
3. Attribution and Threat Actor Profiling: Identifying technical overlaps in code structure, compilation environments, cryptographic keys, and operational tactics that connect the sample to known threat groups (e.g., APT28, Lazarus, FIN7).
4. Remediation and Signature Authoring: Developing precise detection logic—such as YARA rules, Suricata/Snort network signatures, and Sigma host rules—to inoculate the enterprise against future variants.

2. Taxonomy of Malicious Software

Malware is categorized based on its propagation mechanisms, payload actions, and operational architecture:

CODECopy Code
+------------------+--------------------------------------------------------------------------------+
| Malware Type     | Primary Characteristics and Operational Vectors                                |
+------------------+--------------------------------------------------------------------------------+
| Virus            | Self-replicating code that attaches itself to legitimate host executables       |
|                  | (e.g., prepending, appending, cavity injection) and requires human execution.  |
+------------------+--------------------------------------------------------------------------------+
| Worm             | Standalone autonomous malware that self-propagates across computer networks by |
|                  | weaponizing software vulnerabilities (e.g., EternalBlue/MS17-010) without user |
|                  | interaction.                                                                   |
+------------------+--------------------------------------------------------------------------------+
| Trojan Horse     | Disguises its malicious payload beneath the guise of desirable, legitimate      |
|                  | utility software (e.g., a pirated game, PDF viewer, or system utility update).  |
+------------------+--------------------------------------------------------------------------------+
| Ransomware       | Leverages asymmetric/symmetric cryptography to encrypt user files or master     |
|                  | boot records (MBR), demanding ransom payments for private decryption keys.     |
+------------------+--------------------------------------------------------------------------------+
| Rootkit          | Operates with privileged kernel-mode access (Ring 0) or user-mode hooks to     |
|                  | actively subvert OS APIs, concealing processes, network ports, and files.      |
+------------------+--------------------------------------------------------------------------------+
| Botnet Agent     | Converts the host into a remotely controllable 'zombie' node responding to C2  |
|                  | directives to launch Distributed Denial of Service (DDoS) or spam campaigns.   |
+------------------+--------------------------------------------------------------------------------+
| Backdoor / RAT   | Remote Access Trojan providing covert administrative access, shell execution,  |
|                  | screen capture, audio eavesdropping, and file exfiltration capabilities.       |
+------------------+--------------------------------------------------------------------------------+
| Spyware/Keylogger| Passively monitors keystrokes, clipboard buffers, and browser credentials,      |
|                  | transmitting harvested telemetry to unauthorized adversary servers.           |
+------------------+--------------------------------------------------------------------------------+
| Wiper            | Destructive malware designed purely for data sabotage, overwriting partition   |
|                  | tables and raw disk sectors with zeros or garbage data with zero recovery path.|
+------------------+--------------------------------------------------------------------------------+
| Fileless Malware | Executes directly inside volatile memory (RAM) utilizing native OS management   |
|                  | binaries ('Living Off The Land' - LotL, e.g., PowerShell, WMI, mshta.exe).     |
+------------------+--------------------------------------------------------------------------------+

3. The Four Tiers of Malware Analysis

Professional malware analysis progresses along a structured, four-tiered continuum:

Tier 1: Basic Static Analysis

• Involves inspecting the artifact without executing its code.
• Techniques include calculating cryptographic hashes, examining strings, identifying packers, inspecting Portable Executable (PE) headers, and evaluating imports/exports.
• Advantages: Fast, safe, establishes a triage baseline, and extracts immediate network/host IOCs.
• Limitations: Blind to obfuscated, encrypted, or packed payloads; cannot confirm dynamic runtime behaviors.

Tier 2: Basic Dynamic Analysis

• Involves executing the malware inside an isolated, instrumented sandbox environment (e.g., Cuckoo Sandbox, CAPE, Any.run) while monitoring system interactions.
• Observers track spawned processes, modified registry keys, network DNS queries, and dropped filesystem artifacts using tools like Process Monitor, Process Hacker, Regshot, and Wireshark.
• Advantages: Reveals actual execution behavior and network C2 communications without complex reverse engineering.
• Limitations: Sophisticated malware detects virtualized sandboxes (anti-VM/anti-analysis checks) and remains dormant, concealing its true payload.

Tier 3: Advanced Static Analysis

• Involves loading the binary into disassemblers and decompilers (IDA Pro, Ghidra, Binary Ninja) to reverse engineer the compiled machine instructions into x86/x64 assembly or pseudo-C code.
• Analysts map control flow graphs, reconstruct algorithms, and analyze cryptographic routines.
• Advantages: Provides comprehensive, exhaustive visibility into every logical branch and dormant capability of the program.
• Limitations: Demands advanced technical skill in assembly language, system architecture, and requires substantial time investment.

Tier 4: Advanced Dynamic Analysis

• Involves running the binary inside an interactive debugger (x64dbg, OllyDbg, WinDbg) to control execution flow.
• Analysts set software/hardware breakpoints, step through instructions (Single Step / Step Over), modify register values, dump decrypted payloads directly from memory buffers, and bypass anti-analysis checks at runtime.
• Advantages: Breaks through complex runtime packing and armor, allowing decryption routines to execute naturally before analyzing payload memory dumps.

4. Safe Analysis Environments and Operational Security (OPSEC)

Malicious binaries must never be analyzed on production workstations or connected corporate networks. A single accidental execution can trigger lateral movement or data destruction.

CODECopy Code
+----------------------------------------------------------------------------------------------------+
|                                    ISOLATED MALWARE ANALYSIS LAB                                   |
|                                                                                                    |
|   +───────────────────────────────+               +────────────────────────────────────────────+   |
|   |   HOST OPERATING SYSTEM       |               |            GUEST ANALYSIS VM               |   |
|   |   (Hardened Linux / Windows)  |               |  (Windows 10/11 x64 Enterprise Sandbox)    |   |
|   +───────────────────────────────+               +────────────────────────────────────────────+   |
|                  │                                                      │                          |
|                  ▼                                                      ▼                          |
|   +───────────────────────────────+               +────────────────────────────────────────────+   |
|   |   TYPE-2 HYPERVISOR           |               | INetSim / FakeNet-NG / Wireshark           |   |
|   |   (VMware Workstation / VBox) | <-----------> | - Simulates DNS, HTTP, HTTPS, SMTP, FTP    |   |
|   +───────────────────────────────+               | - Isolates guest on Host-Only Network      |   |
|                  │                                +────────────────────────────────────────────+   |
|                  ▼                                                      │                          |
|   [ Clean Immutable Baseline Snapshot ] <───────────────────────────────+                          |
|   (Reverted after every analysis run)                                                              |
+----------------------------------------------------------------------------------------------------+

Essential Lab Security Rules

1. Network Isolation: Analysis VMs must be placed on isolated 'Host-Only' or internal virtual networks. They must never route traffic directly out to the open Internet.
2. Network Simulation: Utilize services like INetSim (Internet Network Simulator) or FakeNet-NG to emulate common network services (DNS, HTTP, HTTPS, SMTP, NTP). When malware queries api.malicious-c2.com, INetSim provides a synthetic 200 OK response, prompting the binary to proceed to its next operational stage without exposing external infrastructure.
3. Immutable Golden Snapshots: Prior to introducing any malware sample, capture a clean VM snapshot. Following analysis, the VM is instantly reverted to the clean state, purging all dropped files, registry alterations, and persistence mechanisms.
4. Disabling Shared Folders & Guest Additions: Disable shared clipboard, drag-and-drop, and shared folders between host and guest to prevent VM-escape exploits from bridging the hypervisor boundary.
5. VirusTotal OPSEC Consideration: While multi-engine scanners like VirusTotal provide invaluable detection intelligence, uploading proprietary internal files, targeted spear-phishing attachments, or suspected zero-day state-sponsored implants leaks the file to international security researchers and the threat actor, burning the investigation.

5. Basic Static Analysis Techniques

Basic static analysis provides rapid triage, generating initial hypotheses regarding the file's nature and capabilities without triggering execution.

A. Determining File Type via Magic Numbers

Adversaries frequently employ double file extensions (e.g., invoice.pdf.exe or contract.docx.scr) or manipulate Windows file associations to deceive users. File extensions are purely arbitrary string labels; operating systems and analysis engines identify the true underlying file format by examining the Magic Number (file signature) located at the very beginning (offset 0x00) of the file.

Analysts verify signatures using command-line utilities such as the Linux file command:

bashCopy Code
$ file suspicious_doc.pdf
suspicious_doc.pdf: PE32 executable (GUI) Intel 80386, for MS Windows

In this example, despite bearing a .pdf extension, the magic number confirms it is an Intel x86 Windows Portable Executable.

B. Cryptographic Fingerprinting and Fuzzy Hashing

Cryptographic hashes uniquely fingerprint a binary file:

• MD5 (128-bit) & SHA-1 (160-bit): Historically popular, but prone to cryptographic collisions. Still widely referenced in legacy threat intelligence feeds.
• SHA-256 (256-bit): The current industry gold standard for unique, collision-resistant cryptographic identification.

The Fragility of Cryptographic Hashes

Cryptographic hash functions possess the avalanche effect: altering a single bit in a 10-megabyte file completely scrambles the resulting SHA-256 hash. Malware authors exploit this by appending random junk bytes, recompiling with minor timestamp variations, or using automated crypters, rendering traditional hash lookups useless against new variants.

Context-Triggered Piecewise Hashing (CTPH / SSDEEP)

To overcome the avalanche effect, analysts utilize fuzzy hashing (such as SSDEEP):

• SSDEEP breaks a file into smaller sequential blocks using a rolling hash, computing traditional hashes for each block, and concatenating the results into a single signature string.
• By comparing two SSDEEP strings, analysts calculate a similarity score between $0\%$ (completely unrelated) and $100\%$ (near-identical).
• This enables automatic clustering of malware samples belonging to the same developmental family, even when recompiled or slightly modified.

Import Hashing (IMPHASH)

• IMPHASH calculates the MD5 hash of a binary's imported library functions and their order of invocation within the Import Address Table (IAT).
• Because developers and automated builder tools (such as Cobalt Strike or Metasploit stagers) typically link external API functions in identical sequences, different malware payloads built from the same development framework share identical IMPHASH values, regardless of payload code variations.

C. Extracting and Analyzing Strings

A binary contains human-readable character sequences embedded within its compiled code and data sections. Extracting strings provides immediate visibility into:

• Command-and-Control (C2) domains, IP addresses, and URLs.
• Internal error messages, debugging paths (PDB paths revealing author usernames).
• Targeted registry keys (e.g., Software\Microsoft\Windows\CurrentVersion\Run).
• Windows API functions invoked dynamically.
• Ransom note text and cryptocurrency wallet addresses.

String Encodings

The standard strings utility searches for sequences of printable characters of a minimum length (default 4):

1. ASCII (1-byte per character): Standard English alphanumeric characters encoded in 8 bits.
2. Unicode (UTF-16LE, 2-bytes per character): Modern Windows NT operating systems represent internal strings as two bytes per character (e.g., the letter 'A' is stored as 0x41 0x00).

bashCopy Code
# Extracting ASCII strings
$ strings -n 6 sample.exe

# Extracting 16-bit little-endian Unicode strings
$ strings -e l -n 6 sample.exe

FLOSS (FireEye Labs Obfuscated String Solver)

Modern malware authors obfuscate critical strings using simple XOR operations, RC4 encryption, or stack construction (pushing single characters onto the CPU stack one instruction at a time). Standard strings commands miss these obfuscated sequences entirely.

• FLOSS automates static reverse engineering heuristics: it disassembles the binary, identifies de-obfuscation and decryption routines, simulates their execution inside a lightweight CPU emulator, and extracts the unmasked strings from memory.

D. Detecting File Packing and Shannon Entropy

Malware authors frequently compress, encrypt, or protect their binaries using Packers (e.g., UPX, Themida, VMProtect, ASPack).

CODECopy Code
+──────────────────────────────────────────────────────────────────────────────────────────────────+
|                                    PACKED VS. UNPACKED EXECUTABLES                                |
+──────────────────────────────────────────────────────────────────────────────────────────────────+
| UNPACKED PE FILE:                                                                                |
| [ PE Headers ] [ .text: Plain assembly ] [ .data: Plain variables ] [ Full Import Table: 150 APIs]|
|                                                                                                  |
| PACKED PE FILE:                                                                                  |
| [ PE Headers ] [ Encrypted/Compressed Payload Data Section ] [ Stub: Decryption Code ] [ 2 APIs ] |
+──────────────────────────────────────────────────────────────────────────────────────────────────+

Anatomy of a Packed Binary

When an executable is packed:

1. The original compiled code and data sections are compressed or encrypted and stored as raw data inside an atypical section.
2. The original Import Address Table (IAT) is wiped, replaced by minimal imports (often just LoadLibraryA and GetProcAddress).
3. An Unpacking Stub is prepended to the file. When executed, the unpacking stub executes first, allocates memory, decrypts the compressed payload into RAM, resolves API addresses dynamically, and redirects the CPU instruction pointer to the Original Entry Point (OEP).

Shannon Entropy Analysis

Entropy measures the degree of randomness or unpredictability in a dataset, calculated on a scale from $0.0$ to $8.0$ (representing 8 bits per byte):

• Plain Text / Standard Code: Highly structured, low randomness, typical entropy between $3.0\text{ and }5.5$.
• Compressed or Encrypted Data: Maximum randomness, uniform byte distribution, typical entropy between $7.2\text{ and }8.0$.
• If an executable displays sections with Shannon entropy approaching $8.0$, it is almost certainly encrypted or packed.

Section Discrepancy Indicators

In standard unpacked binaries, the Virtual Size (space occupied in RAM) and the Size of Raw Data (space occupied on disk) of a section are approximately equal.

• In packed binaries, the unpacking stub creates sections where $\text{Virtual Size} \gg \text{Size of Raw Data}$. For example, a section might occupy only $1\text{ KB}$ on disk but reserve $500\text{ KB}$ of virtual memory in RAM, indicating that encrypted payload data will be expanded into memory at runtime.

6. The Portable Executable (PE) Format Anatomy

Virtually all 32-bit and 64-bit Windows executables (.exe, .dll, .sys, .ocx) conform to the Portable Executable (PE) specification, derived from the Unix Common Object File Format (COFF).

CODECopy Code
+----------------------------------------------------------------------------------------------------+
|                                    PORTABLE EXECUTABLE (PE) ARCHITECTURE                           |
+----------------------------------------------------------------------------------------------------+
|  DOS Header (IMAGE_DOS_HEADER)                                                                     |
|  - e_magic: 0x5A4D ('MZ')                                                                          |
|  - e_lfanew: Pointer offset to PE Header (e.g., 0x000000E8)                                        |
+----------------------------------------------------------------------------------------------------+
|  DOS Stub ("This program cannot be run in DOS mode.")                                              |
+----------------------------------------------------------------------------------------------------+
|  PE File Header (IMAGE_NT_HEADERS)                                                                 |
|  - Signature: 0x00004550 ('PE\0\0')                                                                |
|  +-- File Header (IMAGE_FILE_HEADER): Machine (x86/x64), NumberOfSections, TimeDateStamp           |
|  +-- Optional Header (IMAGE_OPTIONAL_HEADER):                                                      |
|       - AddressOfEntryPoint (RVA of OEP)                                                           |
|       - ImageBase (Preferred loading address, e.g., 0x00400000 or 0x00007FF7...)                   |
|       - Subsystem (GUI vs CUI Console)                                                             |
|       - DataDirectory[16]: Array pointing to Export, Import, Resource, Relocation Tables           |
+----------------------------------------------------------------------------------------------------+
|  Section Table (Array of IMAGE_SECTION_HEADER)                                                     |
|  - .text (Executable machine instructions)                                                         |
|  - .rdata / .idata (Read-only data, Import Address Table)                                          |
|  - .data (Global initialized variables)                                                            |
|  - .rsrc (Resources: icons, dialogs, embedded payloads)                                            |
|  - .reloc (Base relocation fix-ups)                                                                |
+----------------------------------------------------------------------------------------------------+
|  Section Raw Data Bodies (.text, .data, .rsrc...)                                                  |
+----------------------------------------------------------------------------------------------------+

Key PE Data Structures

1. IMAGE_DOS_HEADER:
   • Legacy structure from 16-bit MS-DOS.
   • e_magic: Must equal 0x5A4D (MZ). If this value is absent, the Windows loader terminates execution with an error.
   • e_lfanew: Located at offset 0x3C; contains the 4-byte file offset pointing directly to the start of the modern IMAGE_NT_HEADERS.
2. IMAGE_FILE_HEADER:
   • Machine: Identifies target CPU architecture (0x014C for x86 32-bit; 0x8664 for x64 64-bit).
   • NumberOfSections: Total count of section headers in the section table.
   • TimeDateStamp: 32-bit Unix epoch time when the compiler built the binary. Threat actors frequently 'timestomp' this field to misleading past or future dates.
3. IMAGE_OPTIONAL_HEADER:
   • Not optional in executables; contains vital loader parameters:
   • AddressOfEntryPoint: Relative Virtual Address (RVA) where the CPU begins executing instructions once the image is mapped into RAM.
   • ImageBase: Preferred memory address where the application wishes to be loaded (defaults to 0x00400000 on 32-bit Windows). Modern systems randomize this using Address Space Layout Randomization (ASLR).
   • Subsystem: Indicates user interface requirements (2 for Windows GUI; 3 for Windows Console CUI).
   • DataDirectory: An array of 16 structures pointing to critical subsystems, most notably the Import Table (Directory 1) and Export Table (Directory 0).

7. Import Address Table (IAT) Analysis and Suspicious APIs

The Import Address Table (IAT) lists the dynamic-link libraries (DLLs) and specific API functions that the binary requests from the Windows operating system at runtime. Analyzing imports reveals malware capabilities before execution.

Common Windows Dynamic Link Libraries

• kernel32.dll: Core operating system services: memory manipulation, process creation, file I/O, hardware access.
• advapi32.dll: Advanced Windows APIs: security management, access control, Windows Registry manipulation, service management.
• user32.dll: Graphical user interface components: windows, menus, message handling, mouse/keyboard hooks.
• ws2_32.dll / wsock32.dll: Windows Sockets API: network socket creation, TCP/IP connections, data transmission.
• wininet.dll / urlmon.dll: High-level networking: HTTP, HTTPS, FTP protocols, direct URL file downloading.

High-Risk Suspicious API Patterns

CODECopy Code
+──────────────────────────+────────────────────────────────────────────────────────────────────────+
| Functional Category      | Suspicious Windows API Functions                                       |
+──────────────────────────+────────────────────────────────────────────────────────────────────────+
| Code Injection / Process | VirtualAllocEx, WriteProcessMemory, CreateRemoteThread,                |
| Hollowing                | NtQueueApcThread, SetThreadContext, ResumeThread                       |
+──────────────────────────+────────────────────────────────────────────────────────────────────────+
| Dynamic API Resolution   | LoadLibraryA, LoadLibraryW, GetProcAddress, LdrLoadDll                 |
| (Used by Packers)        | (Allows binary to invoke unlisted functions covertly)                   |
+──────────────────────────+────────────────────────────────────────────────────────────────────────+
| Persistence Establishment| RegCreateKeyEx, RegSetValueEx, RegOpenKeyEx, CreateService,             |
|                          | OpenSCManager, StartService                                            |
+──────────────────────────+────────────────────────────────────────────────────────────────────────+
| Keylogging & Surveillance| SetWindowsHookExA, GetAsyncKeyState, GetKeyState, RegisterHotKey,       |
|                          | BitBlt (Screen Capture), GetDC                                         |
+──────────────────────────+────────────────────────────────────────────────────────────────────────+
| Defensive Evasion /      | IsDebuggerPresent, CheckRemoteDebuggerPresent, OutputDebugStringA,     |
| Anti-Debugging           | NtQueryInformationProcess (ProcessDebugPort)                           |
+──────────────────────────+────────────────────────────────────────────────────────────────────────+
| Network Communication    | InternetOpenA, InternetConnectA, HttpOpenRequestA, HttpSendRequestA,   |
|                          | URLDownloadToFile, WSAStartup, connect, send, recv                     |
+──────────────────────────+────────────────────────────────────────────────────────────────────────+

8. Malware Classification and YARA Rules

YARA is the de facto pattern-matching swiss army knife utilized by malware analysts to identify and classify malware samples based on textual and binary patterns.

Structure of a YARA Rule

A standard YARA rule comprises three sections: meta, strings, and condition.

yaraCopy Code
rule Trojan_Generic_Downloader {
    meta:
        description = "Detects generic dropper establishing persistence via Registry Run key"
        author = "Antigravity SOC Analyst"
        date = "2026-10-23"
        threat_level = "High"

    strings:
        // Plain text ASCII strings
        $str_reg = "Software\\Microsoft\\Windows\\CurrentVersion\\Run" ascii nocase
        $str_c2  = "http://malicious-command-node.com/payload.bin" ascii
        
        // Wide Unicode string
        $str_err = "Failed to establish backdoor beacon" wide
        
        // Hexadecimal byte pattern representing shellcode or unique opcode sequence
        $hex_pattern = { 6A 40 68 00 10 00 00 68 00 00 40 00 50 E8 [4] 85 C0 }

    condition:
        // Enforce PE file type via magic number 'MZ'
        uint16(0) == 0x5A4D and
        
        // Match registry key AND (either the C2 URL OR the hex sequence)
        $str_reg and ($str_c2 or $hex_pattern) and
        
        // Restrict file size to under 500 KB to optimize scanning performance
        filesize < 500KB
}

9. Common Pitfalls & Exam Tips

• Pitfall 1: Trusting File Extensions: Never rely on the extension shown in Windows Explorer. Attackers routinely append .pdf or .docx to PE executables, relying on default Windows settings that hide extensions for known file types.
• Pitfall 2: Trusting TimeDateStamp for Attribution: The compile timestamp in IMAGE_FILE_HEADER is easily modified by automated timestomping tools. A binary displaying a compile date of 1995 or 2038 has been timestomped.
• Pitfall 3: Failing to Recognize Packing: Beginners often spend hours reverse-engineering an unpacked stub, finding only two imports (LoadLibraryA, GetProcAddress) and high entropy, failing to realize the true payload is encrypted.
• Pitfall 4: OPSEC Breaches via Public Multi-Scanners: Uploading confidential corporate documents or zero-day malware samples to public multiscanners (like free VirusTotal tiers) immediately distributes the file to competitors and threat actors.
• Exam Tip: When analyzing an unknown executable, always identify the Magic Number (0x5A4D), check Section Entropy (> 7.2 indicates packing), compare VirtualSize vs SizeOfRawData, and inspect the Import Address Table for suspicious API combinations (e.g., VirtualAllocEx + WriteProcessMemory + CreateRemoteThread).

10. Quick Revision Summary

• Malware encompasses viruses, worms, trojans, ransomware, rootkits, backdoors, wipers, and fileless threats designed to compromise digital environments.
• The Four Tiers of Analysis: Basic Static (fast triage, no execution), Basic Dynamic (sandbox behavioral logging), Advanced Static (reverse engineering disassembly/decompilation), and Advanced Dynamic (interactive debugging).
• Safe Lab Protocols: Analysis VMs must be strictly isolated on Host-Only networks, supported by network simulators (INetSim/FakeNet-NG) and clean immutable snapshot rollbacks.
• File Type Identification: Relies on initial magic numbers (e.g., 0x5A4D for Windows PE, 0x7F454C46 for Linux ELF) rather than superficial file extensions.
• Fingerprinting: SHA-256 provides exact cryptographic uniqueness; SSDEEP provides fuzzy similarity clustering; IMPHASH groups binaries by dynamic library import call sequences.
• String Analysis: Extracts plain ASCII and UTF-16LE Unicode strings; FLOSS automatically emulates decryption routines to recover obfuscated/stack strings.
• Packers and Entropy: Packed binaries feature minimal imports, high Shannon entropy ($\ge 7.2$), and section headers where $\text{Virtual Size} \gg \text{Size of Raw Data}$.
• PE Architecture: Key headers include IMAGE_DOS_HEADER (MZ, e_lfanew), IMAGE_FILE_HEADER (Machine, NumberOfSections, TimeDateStamp), and IMAGE_OPTIONAL_HEADER (AddressOfEntryPoint, ImageBase, DataDirectory).
• Import Analysis: High-risk API imports reveal intent: process injection (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread), persistence (RegSetValueEx), and keylogging (SetWindowsHookEx).
• YARA: Provides rule-based pattern matching (meta, strings, condition) to identify, classify, and hunt malware families across endpoints.