Malware Detection,
Analysis & Containment.

A malware sandbox is an isolated, controlled system where potentially harmful software can be executed and observed without risking damage to production infrastructure. Two predominant, freely available environments are described below. You are, however, free to use any equivalent platform you discover through your own research — be creative.

Step-by-Step: Creating Your Sandbox VM

1. Download and install a hypervisor (VMware Workstation Player or VirtualBox) if not already present.
2. Obtain the base operating system ISO or OVA image required by your chosen platform. For FlareVM, a licensed Windows 10/11 ISO is required. For REMnux, a free Ubuntu-based OVA is available directly from the official REMnux website.
3. Create a new virtual machine. Allocate at minimum: 2 CPU cores, 4 GB RAM, 60 GB dynamically allocated virtual disk.
4. Follow the installation guide for your chosen platform (FlareVM or REMnux). The FlareVM installation script can take 30 – 90 minutes depending on internet speed. Consider pre-downloading before the lab session.
5. Critical: After the environment is fully installed and configured, take a clean VM snapshot. Name it clearly, for example: CLEAN_BASELINE_DO_NOT_DELETE. This snapshot will be your restore point between analyses and between lab sessions.

One of the most critical — and most commonly overlooked — aspects of malware analysis is network isolation. A malware specimen that establishes a live network connection can beacon to its Command & Control (C2) server, potentially exposing your real-world IP address or enabling further payload delivery. The following steps are non-negotiable:

• Set the VM network adapter to Host-Only or Internal Network mode. This prevents the VM from routing traffic to the physical network or the internet.
• Optionally, deploy FakeNet-NG (pre-installed on FlareVM) or INetSim to simulate network services (DNS, HTTP, SMTP) within the sandbox. This allows malware to "believe" it has network connectivity while actually communicating only with controlled local services.
• Disable any shared folders between your host operating system and the guest VM. Malware capable of detecting virtualisation environments may attempt to traverse shared directories.
• Disable clipboard sharing between host and guest.
• Ensure Windows Defender or equivalent antivirus is disabled within the sandbox (FlareVM handles this automatically). Antivirus interference will disrupt both static and dynamic analysis.

Before proceeding to Part 2, you must document your environment configuration in your report. Verification demonstrates that your findings are reproducible and your methodology is sound.

Before any analysis can begin, you need a specimen. You must use only legitimate, authorised sources. The following repositories are widely used by professional malware analysts and security researchers:

• MalwareBazaar (Abuse.ch) — Free, publicly accessible repository of malware samples, each with associated metadata and community tags. Search by file type or malware family.
• VirusShare — Requires a free account. Hosts a very large collection of hashed malware samples for research use.
• theZoo (GitHub) — A curated collection of live malware samples intentionally made available for educational and research purposes. Read the repository's disclaimer carefully.
• Use the EICAR Anti-Malware Test File as a completely safe, non-malicious test string that is detected by all major antivirus engines — ideal for initial environment verification without any actual risk.

Static analysis is the examination of a malware file without running it. This approach is low-risk and often reveals significant information about the file's origin, functionality, and intent. Work through the following sub-tasks sequentially, documenting your findings at each step.

2.2.1 — File Identification & Hashing

Your first step is to positively identify what kind of file you are dealing with and generate cryptographic hashes that uniquely fingerprint it. These hashes allow you to cross-reference the sample against threat intelligence databases.

• Compute the file's cryptographic hash values: MD5, SHA-1, and SHA-256. On REMnux, use the md5sum, sha1sum, and sha256sum command-line utilities. On Windows (FlareVM), use PowerShell's Get-FileHash cmdlet or a tool like HashMyFiles. Record all three hash values in your report.
• Use the file command on Linux (REMnux) to determine the true file type, regardless of extension. On Windows, use the PEiD tool or Detect It Easy (DIE) to identify the executable packer, compiler, or obfuscation method used.
• Note the file size, creation date, and modification date from the file system metadata. Discrepancies between claimed dates and internal timestamps are a common indicator of tampering.

2.2.2 — String Extraction & Analysis

Embedded strings are one of the richest sources of intelligence in a malware binary. Strings can reveal hardcoded IP addresses, domain names, registry keys, file paths, error messages, encryption keys, or even fragments of code comments left by the author. Use the FLOSS (FLARE Obfuscated String Solver) tool from Mandiant — pre-installed on FlareVM — or the standard strings utility on REMnux:

• Run FLOSS or strings -n 6 (minimum 6-character strings) against your sample and redirect the output to a text file for review.
• Search the output for: IP addresses and domain names (potential C2 infrastructure), file paths and registry keys (potential persistence mechanisms), URLs (potential download locations), and any readable error or status messages (which often reveal the malware's internal logic).
• Highlight and document a minimum of 10 significant strings in your report, with a brief explanation of what each string might indicate about the malware's behaviour or purpose.

Illustrative output (your sample's strings will differ):

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• http://malicious-c2.example/beacon
• %APPDATA%\Microsoft\svchost.exe
• cmd.exe /c whoami /priv
• kernel32.dll : VirtualAlloc

2.2.3 — PE (Portable Executable) Header Analysis

Most Windows malware is packaged as a PE (Portable Executable) file. The PE file format contains a wealth of structural metadata that can be read without executing the file. Use PE Studio (Windows), pefile (Python library, cross-platform), or Cutter to examine:

• Import Address Table (IAT): Which Windows API (Application Programming Interface) functions does the malware import? Functions like CreateRemoteThread, WriteProcessMemory, VirtualAlloc, RegSetValueEx, or InternetOpen are strong behavioural indicators.
• Section headers: Standard PE sections include .text (code), .data (initialised data), .rdata (read-only data), .rsrc (resources). Unusual sections, very high entropy values (above 7.0 suggesting compression or encryption), or sections with mismatched names and permissions are red flags.
• Compilation timestamp: Record the linker timestamp from the PE header. Note whether this date appears plausible given the malware's known first-seen date (if available).
• Rich Header: If present, this header reveals information about the development environment — compiler version, build tool identifiers. This can help attribute the malware to a specific development kit or threat actor toolchain.

Dynamic analysis involves executing the malware in a controlled environment and systematically monitoring all changes it makes to the system. Set up your monitoring tools BEFORE launching the sample.

2.3.1 — System Monitoring Setup

The goal is to capture a complete "before and after" picture of the system state. Set up the following monitoring layers before executing the malware:

• Process monitoring: Launch Process Monitor (ProcMon) from Sysinternals — pre-installed on FlareVM — BEFORE launching the sample. Set filters to capture only events related to the target process name. On REMnux, use strace for system call tracing.
• Registry monitoring: Use Regshot to take a "first shot" of the registry BEFORE execution. After the malware runs, take a "second shot" and compare to reveal all registry changes made.
• Network monitoring: Start Wireshark or Tcpdump and begin packet capture on all interfaces BEFORE execution. If using FakeNet-NG, start it first to intercept and log simulated network connections.
• File system monitoring: Note the current directory listing of key system locations (\Temp, \AppData, \Windows\System32, \Startup) before execution.

2.3.2 — Execute & Observe

1. Execute the malware sample within the sandboxed VM. Allow it to run for a minimum of 3 to 5 minutes. Some malware has sleep timers or logic to delay its primary payload.
2. Observe the process tree. Did the malware spawn child processes? Did it inject code into a legitimate system process (a technique known as process injection or process hollowing)? Screenshot and annotate the process tree.
3. After the observation window, stop execution (do NOT restart the VM yet). Take the Regshot "second shot" and generate the comparison report.
4. Review ProcMon for file system reads/writes, registry access, and network connections. Filter by process name to focus on the sample's activity.
5. Examine the Wireshark/FakeNet-NG capture for DNS queries, HTTP/HTTPS connections, and any unusual protocol usage.

2.3.3 — Document Behavioural Indicators (IOCs)

From your dynamic analysis session, compile a comprehensive list of Indicators of Compromise (IOCs). These are forensic artefacts that, once identified, can be used to detect the same malware across an entire organisation's infrastructure.

Minimum required IOCs for your report:

VirusTotal (VT) is a free online service operated by Google that aggregates scan results from over 70 different antivirus engines, URL scanners, and sandboxes. Submitting a file hash (NOT the actual sample for sensitive cases) allows you to quickly determine whether the malware is already known to the security community and by what names different vendors classify it.

• Submit your sample's SHA-256 hash to VirusTotal. Screenshot the detection summary (number of engines detecting vs. total engines).
• Note the detection names assigned by at least three different antivirus engines. Do the names suggest a common malware family? Is there significant disagreement between vendors?
• Examine the "Details" tab for additional metadata — first submission date, file size confirmation, additional hashes, and any SSDEEP (fuzzy hash) value.
• Review the "Behaviour" tab if a dynamic analysis report is available. Cross-reference the network indicators and file system artefacts against your own dynamic analysis findings from Task 2.3. Note any discrepancies and investigate their cause.

Cuckoo Sandbox is an open-source automated malware analysis system that can execute samples in an isolated environment and produce detailed JSON and HTML reports covering network traffic, API calls, file system modifications, memory dumps, and screenshots of the malware's execution. A managed public instance is available at Malware.City and similar services. Alternatively, REMnux includes Cuckoo's components for local deployment.

If deploying Cuckoo locally, this is an advanced configuration exercise. The instructor will provide guidance if time permits. If using a public submission service:

• Submit your sample (or hash) to a Cuckoo-based submission service. Review the generated analysis report.
• Identify and document the following from the Cuckoo report: process tree summary, list of accessed registry keys, network connections established, API (Application Programming Interface) calls of interest, and any MITRE ATT&CK (Adversarial Tactics, Techniques & Common Knowledge) technique identifiers referenced in the report.
• Map at least 3 observed behaviours to specific MITRE ATT&CK technique IDs. Include these mappings in your report.

Common technique IDs you may encounter:

YARA (a recursive acronym: Yet Another Ridiculous Acronym — created by Victor Alvarez at VirusTotal) is the de facto standard language for malware identification and classification. A YARA rule describes a pattern — byte sequences, strings, structural characteristics — that uniquely identifies a malware specimen or family. Documentation: virustotal.github.io/yara.

Using the strings, PE imports, and file characteristics you identified in Part 2, write at least one custom YARA rule that would detect the malware sample you analysed. Your rule must include at minimum:

• A meta section with author (use a handle or your student ID — do not use your full name in the rule), description, date, and sample SHA-256 hash.
• A strings section defining at least 3 detection strings or byte patterns. Use a combination of full text strings, hex byte patterns, and optionally regular expressions to demonstrate varied rule types.
• A condition section specifying when the rule should fire (e.g., any of them, 2 of ($str*) and uint16(0) == 0x5A4D to require at least 2 string matches and a valid PE header).

Example YARA rule structure:

rule Detect_SampleMalware_001 {
    meta:
        author      = "StudentHandle_2026"
        description = "Detects Sample XYZ — C2 beacon stub"
        date        = "2026-04-29"
        sha256      = "<insert_hash_here>"
    strings:
        $s1 = "MaliciousString" nocase
        $h1 = { 4D 5A 90 00 03 00 00 00 }  // MZ header
        $r1 = /[a-z]{8}\.(ru|cn|tk)/ wide ascii
    condition:
        uint16(0) == 0x5A4D and 2 of them
}

Test your YARA rule against the sample using the YARA command-line tool: yara -r your_rule.yar /path/to/sample. Screenshot the result showing whether the rule fires (detects) the sample. If it does not fire, debug your rule — this is a normal and valuable part of the process. Explain your debugging steps in the report.