Malware Analysis — Part 4: Safe Sample Acquisition, Triage, and Permissions

Previous: Part 3 — Setting Up REMnux and INetSim

Before You Touch Any Sample

Every step in this part happens before you analyze a single file. This is not optional preparation — it is the analysis. Samples have been accidentally detonated on analysis machines, host systems, and entire corporate networks because an analyst skipped the safety steps and double-clicked a file to "see what it was."

The safety steps covered in this part are:

1. Configuring Windows folder permissions to prevent accidental execution
2. Understanding where samples come from and how to get them legally
3. Verifying file integrity with hashes
4. Checking the hash against threat intelligence (VirusTotal)
5. Safely transferring the sample to the analysis VM
6. Initial triage before running anything

Part 1 — Preventing Accidental Execution with AppLocker

The single most dangerous moment in malware analysis is when a file you think is safe turns out not to be, and you've double-clicked it on your host machine or an unprotected folder.

We use AppLocker to create a Windows policy that prevents any executable from running from a specific folder — your samples folder. Even if you double-click a malware sample by accident, Windows will block the execution.

What is AppLocker?

AppLocker is a Windows feature (available on Windows 10/11 Pro and Enterprise) that allows you to control which applications, scripts, and executables are allowed to run, based on rules you define. Unlike a simple "block this folder" setting, AppLocker operates at the kernel level — it intercepts every execution request before it reaches the process creation stage.

AppLocker rules can be based on:

• Publisher — code signing certificates
• Path — file location
• File hash — specific file fingerprint

For our purposes, we'll use path rules to block execution from our samples folder.

Configuring AppLocker on the Analysis VM

This configuration is done on the Windows Analysis VM (FLARE-VM) before taking your baseline snapshot.

Step 1 — Create the samples folder

# Create a dedicated samples directory
New-Item -ItemType Directory -Path "C:\MalwareSamples"
New-Item -ItemType Directory -Path "C:\MalwareSamples\Incoming"
New-Item -ItemType Directory -Path "C:\MalwareSamples\Working"
New-Item -ItemType Directory -Path "C:\MalwareSamples\Archive"

Step 2 — Open Local Group Policy Editor

Press Win+R, type gpedit.msc, press Enter.

Navigate to:

Computer Configuration
└── Windows Settings
    └── Security Settings
        └── Application Control Policies
            └── AppLocker

Step 3 — Configure Executable Rules

Right-click Executable Rules → Create New Rule

The wizard will appear. Set:

• Action: Deny
• User or group: Everyone
• Conditions: Path
• Path: C:\MalwareSamples\*

Click Next through the exceptions screen (no exceptions needed) and Create.

AppLocker will prompt you to also create default rules — click Yes. These default rules allow Windows system files and Program Files to run normally, ensuring Windows continues to function.

Step 4 — Create rules for Scripts and Windows Installer

Repeat the same process for Script Rules and Windows Installer Rules under AppLocker, creating Deny rules for C:\MalwareSamples\* in each. This prevents script-based malware (PowerShell, VBScript, batch files) and installer-based malware from executing from the samples folder.

Step 5 — Enable the Application Identity Service

AppLocker requires the Application Identity service to be running:

# Start the service
Start-Service -Name AppIDSvc

# Set it to start automatically
Set-Service -Name AppIDSvc -StartupType Automatic

Step 6 — Test the policy

Copy a benign executable (like notepad.exe) to C:\MalwareSamples\ and try to run it. You should see a policy error blocking execution.

Software Restriction Policies (Alternative for Home Edition)

If you're not on Windows Pro or Enterprise, use Software Restriction Policies (SRP) instead. SRP is available on all Windows editions.

In Group Policy Editor, navigate to:

Computer Configuration
└── Windows Settings
    └── Security Settings
        └── Software Restriction Policies

Right-click → New Software Restriction Policies

Under Additional Rules, right-click → New Path Rule:

• Path: C:\MalwareSamples\*
• Security level: Disallowed

Part 2 — Where Malware Samples Come From

Malware analysts need samples to analyze. Where do they come from? Here are the legitimate, legal sources:

Malware Repositories (Public, Free)

MalwareBazaar — bazaar.abuse.ch

The best starting point for beginners. Operated by abuse.ch, a Switzerland-based non-profit. Accepts malware submissions from security researchers worldwide and makes samples freely available for download. Samples are tagged by malware family and have VirusTotal results, download counts, and community comments. Requires a (free) account for downloading.

Download samples by tag:

# Using the MalwareBazaar API (on REMnux or your host)
curl "https://mb-api.abuse.ch/api/v1/" \
  -d "query=get_taginfo&tag=Emotet&limit=10"

VirusShare — virusshare.com

A large repository of malware samples accessible by application. Registration required and approval is needed — takes a few days. Contains over 50 million samples. More oriented toward researchers who need large quantities of samples.

theZoo — github.com/ytisf/theZoo

A GitHub repository of historical, well-known malware samples for educational purposes. Samples are stored in password-protected ZIP files with the password infected. Contains famous historical samples like WannaCry, Petya, Zeus. Excellent for study because these samples are extensively documented.

ANY.RUN Public Submissions — app.any.run

An online interactive sandbox where you can watch malware execute in a browser. All public submissions are browsable — you can download samples from public analyses. Also provides analysis results you can study.

Hybrid Analysis — hybrid-analysis.com

Automated sandbox with a large public database of analyzed samples. Samples can be downloaded after registration. Excellent analysis reports to learn from.

Samples Found in the Wild

In professional environments, analysts receive samples from:

• Endpoint detection systems (EDR/XDR) that flag a suspicious file
• Email security gateways that quarantine attachments
• Incident response engagements — files found on compromised systems
• Threat intelligence feeds — IoCs that lead to sample discovery
• Honeypots — systems deliberately set up to attract attacks

For this series, we use samples from MalwareBazaar and, for the Part 13 walkthrough, a purpose-built safe sample (a crackme — see Part 13 for details).

Part 3 — Understanding File Hashes

A hash is a fixed-length fingerprint of a file produced by running the file through a mathematical algorithm. The same file always produces the same hash. A different file — even one differing by a single byte — produces a completely different hash.

For malware analysis, hashes serve three critical purposes:

1. Identity — A hash uniquely identifies a specific file. When analysts share information about malware, they share the hash rather than the file itself. If you have a hash, you can verify whether a file you've found is the same sample others have analyzed.

2. Integrity verification — When you download a sample from MalwareBazaar, you verify the hash matches what the repository claims. This confirms the file wasn't corrupted in transit and that you have the sample you think you have.

3. Threat intelligence lookup — You can submit a hash to VirusTotal and other threat intelligence platforms to see whether the file has been seen before, whether it's been identified as malicious, and what analysis others have done on it.

Hash Algorithms Used in Malware Analysis

Computing Hashes on Windows

# SHA-256 (recommended)
Get-FileHash -Algorithm SHA256 "C:\MalwareSamples\sample.exe"

# MD5
Get-FileHash -Algorithm MD5 "C:\MalwareSamples\sample.exe"

# SHA-1
Get-FileHash -Algorithm SHA1 "C:\MalwareSamples\sample.exe"

Computing Hashes on Linux (REMnux)

# SHA-256
sha256sum sample.exe

# MD5
md5sum sample.exe

# SHA-1
sha1sum sample.exe

# All three at once (useful script)
echo "MD5:    $(md5sum sample.exe | cut -d' ' -f1)"
echo "SHA1:   $(sha1sum sample.exe | cut -d' ' -f1)"
echo "SHA256: $(sha256sum sample.exe | cut -d' ' -f1)"

Fuzzy Hashing with ssdeep

Traditional hashes (MD5, SHA-256) produce completely different output for even a single byte change. This is a problem when malware authors repackage or slightly modify their tools to evade hash-based detection.

ssdeep solves this with fuzzy hashing — it produces a hash that measures similarity rather than identity. Two samples with 80% similarity would produce ssdeep hashes that compare to give a similarity score of ~80.

# Compute ssdeep hash
ssdeep sample.exe

# Compare two samples for similarity
ssdeep -m sample1.exe sample2.exe

A similarity score above 50 often indicates samples from the same malware family or the same developer.

Part 4 — Using VirusTotal

VirusTotal (virustotal.com) is a free service owned by Google that allows you to submit files or hashes for analysis against 70+ antivirus engines and security tools simultaneously. It is one of the most important triage tools in a malware analyst's workflow.

How to Check a Hash (Not a File)

When you have a new sample, check the hash before submitting the file. Why? Submitting a file to VirusTotal makes it publicly available to VirusTotal's subscribers — including threat intelligence companies, other security researchers, and potentially adversaries monitoring for specific samples. If your organization found a new, previously unknown piece of malware, submitting the file would tip off the adversary that you've found it. Submitting the hash reveals nothing about the file itself.

1. Compute the SHA-256 hash of your sample
2. Go to virustotal.com
3. Click the Search tab
4. Paste the hash and press Enter

If VirusTotal returns results: The file has been seen before. You'll see how many antivirus engines detect it and what they call it. This gives you a starting point for research.

If VirusTotal returns no results: The file hasn't been seen before — or VirusTotal hasn't seen it. This could mean it's a new sample, a targeted attack, or a benign file. Absence of detection is not absence of malice.

Reading a VirusTotal Report

A VirusTotal report has several important tabs:

Detection tab:

• Shows how many of 70+ engines detect the file as malicious
• Shows the name each engine assigns to it
• Note: different engines often give different names to the same malware family. "Trojan.GenericKD.46152938" and "Win32:Evo-gen" might be the same sample detected by different engines using different naming conventions

Details tab:

• File type, size, magic bytes
• Compilation timestamp (can be faked by malware authors)
• Import hash, section hashes
• TLS/certificate information

Relations tab:

• Files this sample contacted
• URLs it connected to
• IP addresses
• Files it dropped
• Certificates

Behavior tab:

• Sandbox execution results from multiple sandboxes
• Process creation, file modifications, registry changes, network activity

Community tab:

• Comments from security researchers who've analyzed the sample
• Links to public reports

What VirusTotal Cannot Tell You

• 0 detections does not mean safe. Ransomware groups deliberately test their tools against VirusTotal before deployment and iterate until they achieve 0 detections. A file with 0 detections might be the newest version of a well-known ransomware family.
• High detection count does not mean dangerous. Legitimate security tools, penetration testing utilities, and even some commercial software trigger false positives on multiple engines.
• VirusTotal tells you what happened, not what will happen. Historical detection means past analysis found it malicious. A novel sample with zero detections today might get 40 detections tomorrow when engines update.

Using the VirusTotal API

For analysts who process many samples, the VirusTotal API allows programmatic lookups:

import requests

API_KEY = "your_virustotal_api_key"
hash_value = "sha256_hash_of_your_sample"

url = f"https://www.virustotal.com/api/v3/files/{hash_value}"
headers = {"x-apikey": API_KEY}

response = requests.get(url, headers=headers)
data = response.json()

# Extract key info
stats = data['data']['attributes']['last_analysis_stats']
print(f"Malicious: {stats['malicious']}")
print(f"Suspicious: {stats['suspicious']}")
print(f"Harmless: {stats['harmless']}")
print(f"Undetected: {stats['undetected']}")

Free VirusTotal accounts have a rate limit of 4 lookups per minute and 500 per day. The API key is found in your VirusTotal profile.

Other Threat Intelligence Platforms

VirusTotal is not the only option. Cross-reference important samples:

MalwareBazaar — bazaar.abuse.ch Good for malware-specific context — family tags, download counts, submission timestamps.

URLhaus — urlhaus.abuse.ch For URLs found in malware — checks whether a URL is known malicious and what malware it distributes.

ThreatFox — threatfox.abuse.ch IoC database — check IPs, domains, and file hashes against known threat actor indicators.

Hybrid Analysis — hybrid-analysis.com Another automated sandbox with public results. Often has analysis of the same samples as VirusTotal with different behavioral detail.

Part 5 — Safe File Transfer to the Analysis VM

You've found a sample, checked the hash, reviewed the VirusTotal report. Now you need to get the file into your Windows Analysis VM. This must be done carefully.

Option 1 — Download Directly on the Analysis VM (Easiest)

If you have temporary internet access configured on your analysis VM (via pfSense, for the purpose of downloading samples only):

1. Open a browser on the Windows Analysis VM
2. Navigate to MalwareBazaar or your repository
3. Download the sample directly to C:\MalwareSamples\Incoming

The sample lands in the AppLocker-protected folder — even if you accidentally double-click it while navigating to it, Windows blocks execution.

Before proceeding to analysis, disable the temporary internet access in pfSense.

Option 2 — ISO Mount (Most Secure)

Download the sample on your host machine, create an ISO containing it, and mount the ISO in the VM as a read-only virtual DVD.

On the Windows host:

1. Download the sample to C:\AnalysisSamples\ on your host
2. Use CDBurnerXP (free) or PowerShell to create an ISO:

# Using oscdimg (part of Windows ADK, free from Microsoft)
oscdimg -n "C:\AnalysisSamples\" "C:\sample_transfer.iso"

3. In Hyper-V Manager → VM Settings → DVD Drive → Image File → browse to C:\sample_transfer.iso
4. In the VM, the ISO appears as a DVD drive (read-only)
5. Copy the file from the virtual DVD to C:\MalwareSamples\Incoming
6. Unmount the ISO before executing the sample

Option 3 — Network Share on Management Switch

Set up a read-only Windows share on your host machine, accessible via the Management switch. The analysis VM uses this share only for file transfer, never during active analysis.

On the Windows host:

1. Create C:\AnalysisShared and share it (read-only)
2. In the analysis VM, map a network drive to the host's Management switch IP:

   net use Z: \\10.0.0.1\AnalysisShared /user:hostusername

   ⎘
3. Copy from Z: to C:\MalwareSamples\Incoming
4. Disconnect the mapped drive before analysis

Part 6 — Initial Triage

Initial triage is the process of gathering quick, high-level information about a sample before committing to deep analysis. The goal is to answer five questions in under 10 minutes:

1. What type of file is this?
2. Has it been seen before?
3. Is it packed or obfuscated?
4. What does it appear to do (at a high level)?
5. What should I focus on during deeper analysis?

Step 1 — Verify File Type

Never trust the file extension. Malware frequently uses misleading extensions — a file named invoice.pdf might actually be a Windows executable. Check the actual file type from magic bytes:

On REMnux:

file suspicious_file.exe

On Windows (FLARE-VM):

# Using CFF Explorer or HxD to check first bytes
# Or use Get-Item for basic info
Get-Item "C:\MalwareSamples\Incoming\sample.exe" | Select-Object *

Common magic bytes to recognize:

4D 5A          → Windows PE executable (MZ header)
50 4B 03 04    → ZIP archive
25 50 44 46    → PDF (%PDF)
D0 CF 11 E0    → Microsoft Office OLE format (.doc, .xls)
50 4B (varies) → Office XML format (.docx, .xlsx)
7F 45 4C 46    → Linux ELF executable

Step 2 — Compute and Check Hashes

# On REMnux
sha256sum sample.exe
md5sum sample.exe

Check the SHA-256 on VirusTotal (hash only — not the file).

Step 3 — Quick Static Pass with PEStudio

Open the sample in PEStudio on the Windows Analysis VM. In 60 seconds you'll know:

• File type confirmed
• Import table (what Windows APIs it uses)
• Strings (any obvious URLs, filenames, registry keys)
• Whether it's signed
• Section entropy (high entropy = likely packed)
• VirusTotal detection count

Step 4 — Packer Detection with DIE

Open the sample in Detect-It-Easy:

• If it shows a packer (UPX, MPRESS, Themida), static analysis will be limited — you'll need to unpack it first
• If no packer is detected, proceed with full static analysis
• Note the compiler/linker — Visual C++, GCC, Delphi, .NET all have different analysis approaches

Step 5 — Quick Capability Check with capa

On REMnux:

capa sample.exe

capa analyzes the binary and maps its capabilities to MITRE ATT&CK techniques. Even without deep analysis, capa will tell you if the sample:

• Attempts process injection
• Modifies registry run keys (persistence)
• Establishes network connections
• Drops additional files
• Contains anti-analysis techniques

Step 6 — Document Your Initial Findings

Before doing anything else, start your analysis notes. A template:

## Sample Analysis — [Date]

### Sample Information
- Filename: sample.exe
- MD5: [hash]
- SHA256: [hash]
- File size: X bytes
- File type: PE32 executable (Windows x86)

### VirusTotal
- Detection: 42/72 engines
- Common family name: Emotet
- First seen: [date]

### Initial Triage
- Packer: UPX detected (need to unpack before static analysis)
- Compiler: Visual C++
- Imports: Notable - WSAStartup, CreateThread, RegSetValueEx
- High-level capabilities (capa): Network communication, registry persistence, process injection

### Analysis Plan
1. Unpack with x64dbg
2. Static analysis of unpacked binary (PEStudio, FLOSS, Ghidra)
3. Dynamic analysis with Procmon and Wireshark
4. Memory dump and Volatility analysis

This template becomes the foundation of your final analysis report.

The Right Mindset for Sample Handling

Before we close Part 4, some principles that professional analysts internalize:

Every file is dangerous until proven otherwise. Not just obvious .exe files — PDFs, Office documents, scripts, DLLs, and even image files can be weaponized. Treat every unknown file as potentially hostile.

The hash is the identity, not the filename. Malware authors rename files constantly. The same Emotet sample might appear as invoice.exe, order_confirmation.exe, or adobe_update.exe. The hash doesn't change.

Absence of detection is not safety. A VirusTotal score of 0/72 means no engine has a signature for this exact file. It says nothing about whether the file is malicious.

Document before you do anything. Record the hash, the VirusTotal results, and your initial observations before you run a single tool. Once you start analysis, you may modify the environment in ways that affect what you see later.

Verification Checklist

• AppLocker (or SRP) configured to block execution from C:\MalwareSamples\
• Application Identity service enabled and running
• Tested AppLocker by trying to run a file from the blocked folder
• Sample folders created: Incoming, Working, Archive
• VirusTotal account created (free)
• Practice hash lookup on a benign file (e.g., calc.exe SHA-256)
• MalwareBazaar account created (free)
• File transfer method tested (ISO or network share)
• Initial triage checklist understood and documented

Previous: Part 3 — Setting Up REMnux and INetSim Next: Part 5 — Static Analysis Part 1: File Identification and PE Structure