Practical Labs and Projects in Malware Analysis
Practical Malware Analysis Labs are an important part of learning malware analysis because they help students understand how suspicious files behave, how malware can affect a computer, and how security professionals identify potential threats. Reading about malware is useful, but performing practical exercises makes it easier to understand the techniques used by cybersecurity analysts.
In this module, students will complete twelve practical labs covering file hashes, string extraction, executable file inspection, static analysis, process monitoring, system changes, network traffic, sandbox analysis, YARA rules, memory analysis, malware persistence, and professional reporting.
These labs use simple examples to explain how malware analysts investigate suspicious activity. Beginners should use harmless sample files, simulated activity, or authorized training datasets. Live malware should never be executed on a personal computer or an unprotected network.

Table of Contents
Practical Malware Analysis Labs
Lab 1. Identify Malware Using File Hashes
Introduction
A file hash is a fixed length value generated from the contents of a file using a hashing algorithm. Security professionals use hashes to identify files, compare samples, and check whether a suspicious file has already been reported as malicious.
Common hashing algorithms include MD5, SHA1, and SHA256. SHA256 is generally preferred for reliable file identification because it provides stronger collision resistance than MD5 and SHA1.
A hash does not directly reveal what a file does. It provides a digital fingerprint that can help an analyst investigate the file.
Practical Exercise
Suppose an employee receives an unexpected email attachment named invoice.exe. The employee reports the attachment to the security team because the message claims that an urgent payment is required.
The analyst does not open the file. Instead, the analyst calculates its hash using an approved tool in a safe analysis environment.
On a Linux analysis system, the analyst can use the following command on an authorized sample file.
sha256sum sample.exe
The command returns a SHA256 hash followed by the filename. The analyst records the hash and compares it with trusted threat intelligence sources or an internal malware database.
If the hash matches a known malicious sample, the finding provides useful evidence that the file may be dangerous. If no match is found, the file must not automatically be considered safe because a new or modified malware sample may have a different hash.
Example
A company receives an executable attachment that appears to be an invoice. Its SHA256 hash matches a previously identified ransomware sample in the company’s threat intelligence database. The security team blocks the file and checks whether other employees received the same attachment.
Learning Outcome
Students learn how to calculate file hashes, record sample information, and use hashes as one part of a malware investigation.
Lab 2. Extract Strings From a Suspicious File
Introduction
Strings are readable sequences of characters found inside a file. They may include URLs, filenames, error messages, registry paths, program names, and other useful information.
Malware analysts examine strings to identify clues about a program’s purpose. However, not every suspicious string proves that a file is malicious, and some malware hides its strings through encryption or obfuscation.
Practical Exercise
Suppose a suspicious program contains the following readable text.
login failed
update service
config.dat
http://example.invalid/update
These strings may provide clues about the program’s behavior. The analyst might investigate why the program references an update service or a configuration file.
On Linux, strings can be extracted from an authorized sample using this command.
strings sample.exe
To save the results for later examination, the analyst can use the following command.
strings sample.exe > extracted_strings.txt
The analyst then reviews the output and records potentially relevant filenames, URLs, registry paths, and messages.
The example domain ending in invalid is reserved for illustrative purposes and should not be treated as a real malware command and control server.
Example
A security analyst investigates a suspicious program submitted by an employee. The extracted strings contain the name of an unfamiliar executable and references to a startup directory. These clues help the analyst decide which areas to investigate during further analysis.
The strings alone do not confirm that the program creates a startup entry. That behavior must be verified through additional analysis.
Learning Outcome
Students learn how to extract readable information from files and distinguish preliminary clues from confirmed findings.
Lab 3. Examine a PE File With PEStudio
Introduction
Portable Executable files are commonly used for Windows applications. Executable programs, dynamic link libraries, and several other Windows file types use the PE format.
PEStudio is a tool that helps analysts inspect PE files and identify potentially suspicious characteristics without executing the program.
An analyst may examine file metadata, imported functions, section information, strings, hashes, and digital signatures.
Practical Exercise
Suppose a company receives an unfamiliar Windows executable named document_viewer.exe. The filename suggests that the program opens documents, but the security team wants to verify its characteristics.
The analyst opens an authorized sample in PEStudio and examines its properties.
The analyst checks whether the file has an unexpected name or unusual metadata. The analyst reviews its imported functions and looks for capabilities that may require additional investigation. The analyst also checks the file’s digital signature and records its hash.
For example, a document viewer that imports functions associated with process creation or network communication may deserve closer examination. These functions also appear in legitimate software, so their presence alone is not proof of malicious activity.
Example
An employee downloads a supposed PDF reader from an unfamiliar website. The security analyst examines the executable and discovers that it has no valid publisher signature and contains several unusual characteristics.
The analyst combines these observations with the download source and other evidence before deciding whether the program should be blocked.
Learning Outcome
Students learn how to inspect Windows executable files, examine imported functions, review file metadata, and identify characteristics that require further investigation.
Lab 4. Perform Static Analysis of a Safe Sample
Introduction
Static analysis is the process of examining a program without executing it. Analysts use this approach to understand file structure, identify suspicious code patterns, and collect information that may help explain the program’s purpose.
Static analysis is useful during the early stages of an investigation because it can reveal important details without exposing the analysis system to the program’s runtime behavior.
Practical Exercise
Students receive a harmless training executable prepared for analysis. The file is designed to demonstrate suspicious looking characteristics without performing harmful actions.
The analyst calculates its SHA256 hash and identifies its file type. The analyst then examines its readable strings, metadata, sections, imported functions, and digital signature.
Suppose the file contains a string referring to a temporary directory and imports a function associated with creating processes. These observations are recorded as potential clues.
The analyst does not conclude that the program is malware based on these details alone. Instead, the findings are compared with the expected purpose of the sample and the results of other analysis techniques.
Example
A security team investigates a program advertised as a simple calculator. Static analysis reveals references to network communication and unexpected file locations. The team decides to investigate the program further before allowing it on company computers.
The additional capabilities may have a legitimate explanation, but they do not match the program’s stated purpose and therefore deserve attention.
Learning Outcome
Students learn how to examine a file systematically, document technical observations, and develop an initial assessment without running the sample.
Lab 5. Monitor Process Activity With Process Monitor
Introduction
Process Monitor is a Windows system monitoring tool that records file system activity, registry operations, and process and thread events.
Malware analysts use it to observe changes made by a program during execution. It can help identify which files a process accesses, which registry locations it examines, and whether it attempts operations that require further investigation.
Practical Exercise
Students use a harmless test application in an isolated Windows virtual machine. Before starting the application, they open Process Monitor and configure filters for the test program.
The analyst starts the application and observes the recorded events. The analyst checks which files are opened, whether new files are created, and whether registry keys are accessed or modified.
For example, the test program might read a configuration file and create a log file in a temporary directory. These actions can be observed in Process Monitor.
Students should record the process name, relevant file paths, registry locations, and the time of important events.
Example
An employee reports that a newly installed application creates unfamiliar files. The security analyst uses Process Monitor to identify which process creates those files and where they are stored.
This evidence helps the analyst determine whether the activity is expected application behavior or something that needs further investigation.
Learning Outcome
Students learn how to observe process activity, filter monitoring events, and investigate file and registry operations.
Lab 6. Compare System Changes Using Regshot
Introduction
Regshot is a utility that compares Windows registry snapshots to identify changes between two points in time. Depending on the configuration, it can also help compare file system changes.
This technique is useful when an analyst needs to determine what changed after a program was installed or executed.
Practical Exercise
Students use a clean Windows virtual machine and a harmless training application.
First, the analyst takes an initial snapshot of the registry. The analyst records the current system state and then runs the test application.
After the application finishes, the analyst takes a second snapshot and compares the results.
Suppose the comparison identifies a new registry value associated with the test application’s configuration. The analyst records the registry path and examines whether the change is expected.
Students should remember that normal Windows activity can also produce changes during an experiment. A controlled environment and repeated observations help reduce confusion.
Example
A company investigates an application that starts whenever a user signs in. The security analyst compares registry snapshots taken before and after installing the application.
A newly created startup-related registry entry appears in the comparison. The analyst investigates the entry and confirms which program it launches before determining whether it is legitimate.
Learning Outcome
Students learn how to compare registry snapshots, identify system changes, and investigate potential persistence indicators.
Lab 7. Analyze Network Traffic With Wireshark
Introduction
Wireshark is a network protocol analyzer that allows security professionals to inspect network packets and understand communication between devices.
During malware investigations, network analysis can help reveal suspicious DNS requests, unexpected connections, repeated communication patterns, and attempts to contact external servers.
Encrypted traffic may hide the contents of communications, but analysts can often still examine metadata such as destination addresses, ports, timing, and DNS activity.
Practical Exercise
Students use an isolated training network with harmless simulated traffic. They open Wireshark and select the interface connected to the training environment.
The analyst starts a packet capture and generates ordinary test traffic to an approved training server.
Students examine DNS queries, source and destination IP addresses, transport protocols, connection timing, and the sequence of packets.
For example, a test program might repeatedly contact the same training server at regular intervals. The analyst records this pattern and considers whether it resembles periodic beaconing.
A repeated connection pattern is not sufficient on its own to prove malicious activity. Legitimate applications also communicate regularly with their servers.
Example
A company notices that one workstation repeatedly contacts an unfamiliar external address. A network analyst examines the available packet capture and identifies repeated DNS queries followed by regular connection attempts.
The analyst correlates the network evidence with endpoint logs and the running process to determine which application is responsible.
Learning Outcome
Students learn how to capture network traffic, inspect common protocols, identify unusual communication patterns, and document network indicators.
Lab 8. Perform Automated Analysis Using a Sandbox
Introduction
A malware sandbox is an isolated environment used to observe how a program behaves. Automated sandboxes can execute a sample in a controlled environment and collect information about processes, file changes, registry operations, and network activity.
Sandbox results can speed up an investigation, but they are not always complete. Some malware changes its behavior when it detects virtualization or analysis tools.
Practical Exercise
Students submit an approved harmless training sample to a local sandbox configured for the exercise. If an online analysis service is used, students must follow their institution’s data handling rules and must not upload confidential files without authorization.
The analyst reviews the generated report and examines the observed process tree, file activity, registry changes, and network events.
Suppose the report shows that a program creates a child process and writes a configuration file to a temporary directory. The analyst records these observations and checks whether they match the program’s expected purpose.
Students also examine which activities the sandbox could not observe and avoid treating an absence of suspicious behavior as proof that the sample is safe.
Example
A security team receives a suspicious attachment that has not been classified by its existing security tools. The team uses an approved sandbox to inspect the attachment in isolation.
The report reveals unexpected process creation and attempts to contact an unfamiliar server. These findings help the team decide whether to block the file and investigate related endpoints.
Learning Outcome
Students learn how to interpret sandbox reports, understand the limitations of automated analysis, and combine behavioral observations with other evidence.
Lab 9. Write a Basic YARA Detection Rule
Introduction
YARA is a pattern matching tool used by security researchers and malware analysts to identify files based on strings, byte sequences, and logical conditions.
A YARA rule can search for combinations of characteristics associated with a particular sample or training exercise. The rule should be tested carefully because overly broad patterns may produce false positives.
Practical Exercise
Students create a harmless text file named training_sample.txt containing the following text.
Malware Analysis Training Sample
Sample ID: LAB-2026-01
They then create a YARA rule named training_sample.yar.
rule Malware_Analysis_Training_Sample
{
meta:
description = “Detects a harmless training marker”
author = “Cybersecurity Student”
strings:
$marker = “Malware Analysis Training Sample”
$sample_id = “LAB-2026-01”
condition:
all of them
}
This rule looks for both training strings in the same file. It is a demonstration of YARA syntax and is not a real malware detection signature.
If YARA is installed, students can test the rule against the training file using a command such as:
yara training_sample.yar training_sample.txt
The expected result is a match for the training rule. Students can then test the rule against unrelated harmless files to understand how matching conditions affect detection.
Example
A security team creates a YARA rule to search an authorized collection of suspicious files for a distinctive combination of strings associated with a known malware family.
The rule identifies several matching files. Analysts review the matches and validate them using additional evidence before classifying the files.
Learning Outcome
Students learn the basic structure of a YARA rule, how to define strings and conditions, and why detection rules require testing and validation.
Lab 10. Examine a Memory Dump With Volatility
Introduction
Memory forensics involves examining data collected from a computer’s volatile memory. Memory can contain information about running processes, loaded modules, network connections, and other details that may disappear when the computer shuts down.
Volatility is a memory forensics framework that helps analysts investigate supported memory images. The available commands and plugins depend on the Volatility version, the operating system, and the type of memory image.
Practical Exercise
Students receive an authorized training memory image prepared for forensic analysis. They calculate the image’s hash and preserve the original file.
Using the appropriate Volatility version, the analyst identifies the image information and examines the processes represented in the memory image.
For Volatility 3, a command may look like this:
python3 vol.py -f memory.raw windows.pslist
This example assumes a compatible Windows memory image and a Volatility 3 installation with the required plugin available.
The analyst reviews the process list and looks for unusual parent and child process relationships, unexpected process names, or other anomalies. Further analysis may include examining network connections or loaded modules when the image and available plugins support those operations.
An unfamiliar process name is only a clue. Legitimate system components can have names that are difficult to recognize, and malicious software can imitate legitimate names.
Example
A security team investigates a workstation suspected of running unauthorized software. A memory image collected by the incident response team contains an unexpected process.
The analyst examines the process information and correlates it with endpoint logs, file evidence, and network records to determine whether the process is related to the incident.
Learning Outcome
Students learn how to preserve a memory image, examine process information, and use memory evidence as part of a wider investigation.
Lab 11. Identify Malware Persistence Indicators
Introduction
Persistence refers to techniques that allow a program to remain active or regain execution after events such as a system restart or user sign-in.
Malware may attempt to establish persistence through startup entries, scheduled tasks, services, registry modifications, or other operating system features. Legitimate applications use many of the same mechanisms, so context is essential when investigating them.
Practical Exercise
Students examine a Windows virtual machine containing harmless, preconfigured training artifacts.
They inspect startup entries with Autoruns, review scheduled tasks, examine relevant registry locations, and review installed services.
The analyst records unfamiliar entries and identifies the executable path, publisher, file hash, and associated user account where available.
Suppose an unfamiliar application has created a startup entry that launches a program from an unusual directory. The analyst investigates the file and determines whether the entry belongs to an approved application.
Students should not delete system entries simply because they look unfamiliar. They should document the evidence and follow an authorized investigation or remediation procedure.
Example
A company receives reports that an unknown program returns after a workstation is restarted. An analyst reviews startup entries and scheduled tasks and finds a suspicious entry associated with an unfamiliar executable.
The analyst verifies the file’s identity and correlates the entry with endpoint monitoring records. Once the connection is confirmed, the security team can remove the unauthorized persistence mechanism through its approved response process.
Learning Outcome
Students learn how to recognize potential persistence mechanisms, investigate their associated files, and distinguish suspicious entries from legitimate system components.
Lab 12. Prepare a Complete Malware Analysis Report
Introduction
A malware analysis report presents the results of an investigation in a clear and organized format. It allows security teams, system administrators, and decision makers to understand what was examined, what the analyst discovered, and what actions are recommended.
A useful report separates confirmed facts from assumptions and explains the limitations of the analysis.
Practical Exercise
Students use the findings from the previous labs or a supplied training case to prepare a report.
The report should identify the sample and explain the reason for the investigation. It should record the file name, file type, file size, SHA256 hash, analysis environment, and tools used.
The analyst summarizes the static analysis findings, observed process activity, file and registry changes, network indicators, sandbox results, and relevant memory evidence when available.
The report should also explain whether the findings support a malicious classification, what evidence supports that conclusion, and what remains uncertain.
Finally, the analyst recommends practical defensive actions, such as isolating an affected device when justified, blocking verified malicious indicators, checking for related activity, preserving evidence, and restoring systems through an approved recovery process.
Example Report Summary
Incident summary
An employee received an unexpected executable attachment presented as an invoice. The security team collected the file for investigation and calculated its SHA256 hash.
Analysis findings
Static analysis identified unexpected program characteristics. Behavioral analysis of an authorized training or investigative sample showed unusual file activity and repeated network connection attempts. The findings were reviewed alongside available endpoint and network records.
Risk assessment
The observed behavior was inconsistent with the expected purpose of the application. The file was therefore treated as suspicious while further evidence was reviewed.
Recommended actions
Block the verified file hash where appropriate, investigate whether the file reached other devices, preserve relevant logs, and follow the organization’s incident response procedures.
This example is illustrative. A real report must contain the actual evidence collected during the investigation rather than assumed or invented findings.
Example
A company discovers a suspicious executable on an employee’s workstation. The malware analyst prepares a report containing the file hash, static analysis findings, observed behavior, relevant network indicators, and recommended response actions.
The security team uses the report to investigate other devices, update detection rules, and improve its defenses against similar threats.
Learning Outcome
Students learn how to organize technical evidence, explain findings in clear language, assess risk, and communicate actionable recommendations.
Conclusion
These twelve practical labs introduce the main activities involved in malware analysis, from identifying files through their hashes to examining memory evidence and preparing a professional report.
By completing the exercises, students gain experience with common analysis tools and learn how different types of evidence support an investigation. The most important skill is not simply identifying something unusual. It is collecting reliable evidence, validating observations, understanding uncertainty, and explaining conclusions accurately.
All exercises should be performed with authorized samples in controlled environments, following applicable legal, privacy, and organizational requirements.



