Teaching role and scope
I served as an instructor for INTERPOL Malware Analysis Training, supported by Trend Micro, during February 1–5, 2021. The work belongs to malware-analysis training as a whole. Malware installation and persistence were subjects within the available Day 02 material, rather than the name of the training program.
The material connects Windows process analysis with suspicious files, dropped components, registry changes, and mechanisms that allow a program to run again. The teaching objective is to build an evidence-based explanation of what a program changed and how those changes relate to its behavior.
- Inspect the process
Examine the executable path, parent relationship, command line, and relevant context.
- Locate components
Relate running code to dropped files and other observed changes.
- Trace persistence
Identify the startup entry or service and the executable it references.
- Explain the relationship
Correlate observations before deciding which components belong to the unwanted behavior.
Windows analysis subjects
The available module discusses Process Explorer, Registry Editor, MSConfig, and Autoruns as tools for inspecting system state. Its persistence coverage includes startup folders, Run and RunOnce keys, Winlogon configuration, shell associations, AppInit DLLs, Browser Helper Objects, Active Setup, and Windows services.
These mechanisms should be understood in their historical and operating-system context. An entry is a place to investigate, not automatic proof of malware; legitimate software also uses startup and service mechanisms. Support and behavior can vary by Windows version and configuration.
Relating observations instead of collecting screenshots
A useful process observation records more than a name. The executable path, parent, command line, and timing help distinguish unrelated programs that happen to share a filename. A startup entry becomes more meaningful when its target matches a component that the analysis has already identified.
| Artifact | Investigative question |
|---|---|
| Running process | What launched it, from where, and with which arguments? |
| Dropped file | Which process created it, and was it subsequently used? |
| Startup or registry entry | What does it reference, and what causes that reference to run? |
| Windows service | Which executable and account does the service configuration specify? |
The relationships between these observations support a behavioral account. They also identify missing evidence: a registry entry may survive after its file has been removed, while a running process may not have any persistent startup mechanism.
A benign correlation exercise
This synthetic example compares two already-collected observations. It does not inspect or modify the reader’s system and is not original course code.
process = {'image': 'C:/Demo/example.exe', 'pid': 42}
startup = {'target': 'C:/Demo/example.exe', 'name': 'DemoEntry'}
same_target = process['image'] == startup['target']
assert same_targetHere, the exact strings match, so the two records may refer to the same target. Real analysis must also resolve paths and command-line arguments, handle case and aliases appropriately, and establish timing. Even a confirmed association would not make the program malicious by itself.
From instruction to investigation
The training brings together malware behavior, Windows internals, and the discipline of documenting evidence. A clear explanation distinguishes an observed component from a suspected relationship, and a persistence capability from an observed relaunch. This public account describes the teaching scope without inventing participant scores, detection rates, or operational outcomes.
Related work includes my Threat Experts University instruction and malware-analysis methodology.