Source: Juni_2026_Exams/Advance_Forensics/solutions/exam-2025-complete-solution.md

Malware Analysis Exam 2025 — Complete Detailed Solution

Exam Context

VM credentials

Scoring

Delivery: PDF named Exams2025_<YourName>.pdf. Every answer must include at least one screenshot showing the tool used and the result visible.

Lab safety rule: Restore a clean VM snapshot before executing the sample. Never execute the sample outside the isolated VM.

Pre-Exam Setup Checklist

Before touching the sample:

1. Boot the VM and confirm you are logged in as ieuser.
2. Open VirtualBox settings → Devices → Shared Clipboard → set to Disabled.
3. Take a fresh snapshot: Machine → Take Snapshot → "Clean baseline".
4. Confirm C:\Temp\sample.exe exists. Do not execute it yet.
5. Open ProcMon, CFF Explorer, DiE, PEiD, APIMiner in advance so they are ready.
6. Open Notepad++ for reading APIMiner trace files.

Question 1: File Type and Packing (2 marks)

Question text

What is the file type? Is it packed?

Theory background

A Portable Executable (PE) file is the binary format used by Windows for .exe, .dll, and .sys files. PE32 = 32-bit executable; PE32+ = 64-bit executable. This is recorded in the Machine field of the File Header and the Magic field of the Optional Header.

Packing is a compression/encryption technique used by malware to hide its real code and evade static detection. A packed file has its real code compressed or encrypted; a small stub unpacks it into memory at runtime. Packed files have these characteristics:

• Very high entropy (randomness measure approaching 8.0 out of 8.0)
• Few meaningful imports in the Import Directory (the stub only needs a handful)
• Section names associated with known packers (UPX0, UPX1, .packed, .MPRESS1)
• Raw size of packed sections much smaller than Virtual size
• Sections flagged as packed or Executable + Writable simultaneously (unusual)

Tool 1: CFF Explorer — Identify file type

Steps:

1. From the desktop, open CFF Explorer VIII.
2. File → Open → browse to C:\Temp\sample.exe.
3. In the left tree click Nt Headers → File Header.
4. Read the Machine value.

What to look for:

1. Click Nt Headers → Optional Header.
2. Read Magic: 010B = PE32 (32-bit). 020B would mean PE32+ (64-bit).

Also record from the file overview panel (top right):

Screenshot needed: CFF Explorer main window showing File Type = "Portable Executable 32" highlighted.

Tool 2: Detect It Easy (DiE) — Confirm type and detect packing

Steps:

1. Open Detect It Easy v3.04 from desktop.
2. Drag C:\Temp\sample.exe onto the DiE window (or File → Open).
3. Let it scan (the scan bar reaches 100%).

What to read from the DiE main panel:

The S ? marker next to the signature means the packer signature was not matched in the signature database — but entropy confirms packing.

1. Click the Entropy button (top right panel).

What to read from the Entropy view:

Total entropy: 7.99488 — Status: packed (99%)

An entropy of 8.0 is the theoretical maximum (pure random data). Values above ~7.2 are strongly indicative of compression or encryption. A value of 7.99 means the packed section is essentially random data — consistent with a UPX-compressed payload.

1. Note also:

• Section named UPX1 is the primary indicator of UPX packing.
• Section named .rsrc is the resource section — it is NOT packed (low entropy), which makes sense because UPX does not always compress resources.

Screenshot needed: DiE Entropy window showing Total = 7.99488, Status = packed(99%), with section breakdown visible.

Tool 3: PEiD — Cross-verification

Steps:

1. Open PEiD v0.95 from desktop.
2. ... button → browse to C:\Temp\sample.exe → Open.
3. Click Multi Scan.
4. Then click Options → Extra Information (or the >> button).

What to read:

The UPX1 section name combined with entropy 8.0 is strong evidence of UPX packing. PEiD explicitly reports "Packed" in its EP Check.

Screenshot needed: PEiD Extra Information popup showing Entropy: 8.00 (Packed) and EP Check: Packed.

Supporting evidence: Import directory sparseness

Return to CFF Explorer → Import Directory.

A packed binary typically shows very few imports because the stub resolves imports dynamically at runtime. Check whether the import table is nearly empty compared to a typical executable of the same size. This is secondary evidence supporting packing.

Final Answer — Q1

File type: Portable Executable 32 (PE32) — a 32-bit Windows executable.

Is it packed? YES. Evidence:

Conclusion: sample.exe is a 32-bit Portable Executable (PE32) that is packed with UPX (or a UPX-like packer). High entropy approaching 8.0, the UPX1 section name at the entry point, and direct confirmation from PEiD all support this conclusion. The packing hides the real malicious code from static analysis tools and antivirus scanners.

Marks strategy for Q1

• State the file type explicitly: "PE32 / 32-bit Portable Executable" = 1 mark.
• State it is packed with at least two supporting pieces of evidence = 1 mark.
• Do NOT just say "the entropy is high" — connect high entropy (7.99) to the meaning (nearly maximum = strong indicator of compression/encryption).

Question 2: Files Created in C:\Temp (2 marks)

Question text

Which files are created on the C:\temp directory when executed?

Theory background

ProcMon (Process Monitor) is a Sysinternals tool that logs every filesystem, registry, process, and network event in real time. When malware runs, it reveals:

• Files it creates, reads, writes, renames, or deletes
• Registry keys it reads or modifies
• Processes/threads it creates

The CreateFile operation in ProcMon does NOT mean "only newly-created files." It is the Windows API call CreateFile() which can open existing files OR create new ones. The Result column (SUCCESS, FILE EXISTS, NAME NOT FOUND) distinguishes the two. We focus on SUCCESS results with a path under C:\Temp.

Self-deletion / transient files: Malware often creates helper files, does its work, then deletes them immediately to reduce forensic evidence. ProcMon catches these even if they are gone before we look at the disk. The SetDispositionInformationFile operation (or SetRenameInformationFile) is used to mark a file for deletion.

Step-by-step procedure

Step 1 — Restore clean snapshot

In VirtualBox: Machine → Restore Snapshot → "Clean baseline" → Restore. This ensures ProcMon captures from a known-clean state with no residual artifacts from a previous run.

Step 2 — Open ProcMon and configure filters

1. Double-click ProcMon.exe on the desktop (or run from Sysinternals folder).
2. ProcMon starts capturing immediately. Press Ctrl+E to stop capture.
3. Press Ctrl+X to clear all existing events.
4. Open the filter dialog: Filter → Filter… (or Ctrl+L).

Add these filters in this order:

You will also want a Thread filter for Q4: add Operation contains Thread as a third Include filter. Configure all filters before running the sample so you capture everything in one pass.

1. Click OK.

Step 3 — Start capture and execute the sample

1. Press Ctrl+E to start capture in ProcMon.
2. Open an elevated Command Prompt (right-click → Run as Administrator).
3. Execute the sample:

cd /d C:\Temp
sample.exe

1. Wait for the sample to finish all visible activity (a few seconds to a minute).
2. Press Ctrl+E again to stop capture.
3. Save the trace: File → Save → All events → PML file → C:\Temp\trace.pml. Save before changing filters so you never lose data.

Step 4 — Identify created files

With the filters active (Process Name = sample.exe, Operation = CreateFile, Path contains C:\Temp), read the results.

Observed results from 2025 exam:

Two PIDs are visible: 2272 (the original sample.exe process) and 2824 (a spawned child process). This is already a signal of process-related activity.

Files created (non-self-referential entries):

All of these artifacts are deleted almost immediately after creation. This is classic malware self-cleanup behavior — the sample extracts, uses, then removes its components to hinder post-mortem disk analysis.

Why do they still appear in ProcMon? ProcMon captures events at the kernel level in real time, including files that are created and deleted within milliseconds. Even if the file is gone from disk by the time the capture stops, ProcMon already logged the CreateFile (creation) and the SetDispositionInformationFile (deletion) events.

Screenshot needed: ProcMon window with filters active showing the file list. Ensure columns visible include: Time of Day, Process Name, PID, Operation, Path. Highlight the rows showing old_sample.exe, ui\SwDRM.dll, IPHLPAPI.DLL, WINNSI.DLL, powrprof.dll, config.json.

What each artifact tells us

The presence of IPHLPAPI.DLL and WINNSI.DLL in C:\Temp (rather than System32) strongly suggests DLL search-order hijacking or DLL side-loading — the malware drops its own versions of legitimate-looking DLLs so that when a process loads them, it loads the malicious version instead.

Final Answer — Q2

Files created in C:\Temp when sample.exe is executed:

1. C:\Temp\old_sample.exe — renamed copy of the original
2. C:\Temp\ui\ — newly created subdirectory
3. C:\Temp\ui\SwDRM.dll
4. C:\Temp\IPHLPAPI.DLL
5. C:\Temp\WINNSI.DLL
6. C:\Temp\powrprof.dll
7. C:\Temp\config.json

All artifacts are deleted almost immediately after creation. Evidence captured via ProcMon CreateFile filter with Process Name = sample.exe and Path contains C:\Temp.

Marks strategy for Q2

• Full list of files = 1 mark.
• Note that they are deleted almost immediately (shows understanding of transient artifacts) = 1 mark.
• Don't forget old_sample.exe — students commonly miss it.
• Include the ui\ directory as well as its contents.

Question 3: Code Injection — 4 API Stages (4 marks)

Question text

Does it perform code injection? Verify the 4 steps of code injection with API usage (which APIs are used).

Theory background

Process injection is a technique where malicious code is loaded and executed inside the address space of a legitimate process (e.g., explorer.exe, svchost.exe). Benefits for the attacker:

• The malicious code runs under a trusted process name, evading task-manager inspection.
• The injected code inherits the target process's permissions and security context.
• Many security tools whitelist legitimate processes by name.

The four canonical stages of process injection:

The 2025 sample uses section-mapping injection (Stage 3) rather than the classic WriteProcessMemory technique. This is more evasive because it avoids the commonly-monitored WriteProcessMemory call.

Tool: APIMiner

APIMiner hooks all API calls made by a process and records them to text files. Unlike ProcMon (which shows filesystem/registry/process events), APIMiner records every Windows API function call with its arguments.

Command (run from elevated cmd.exe in C:\Temp):

C:\Users\IEUser\Desktop\APIMiner.lnk --app C:\Temp\sample.exe

Or equivalently via the shortcut directly:

cd /d C:\Temp
"C:\Users\IEUser\Desktop\APIMiner.lnk" --app C:\Temp\sample.exe

APIMiner creates trace files in C:\Temp:

C:\Temp\apiminer_traces.293906.pid_4092.txt   (process 1 trace)
C:\Temp\apiminer_traces.293906.pid_1432.txt   (process 2 trace)

The run ID (293906) and PIDs will differ each time. There are two trace files because the sample spawns a child process — each process gets its own trace.

Open both files with Notepad++: File → Open → select both files. Use Search → Find in Files (Ctrl+Shift+F) to search across both traces simultaneously.

Screenshot needed for the command: The cmd.exe window showing the command and the C:\Temp directory afterwards with the two .txt files visible.

Stage 1: Target Discovery / Process Opening

What we're looking for: APIs that enumerate running processes and open a handle to a target.

Search in Notepad++: CreateToolhelp32Snapshot then OpenProcess

APIs found in the 2025 exam:

Trace evidence:

Line 212: <system>-<0,0x00000000> LdrGetProcedureAddress(... "CreateToolhelp32Snapshot", ...)

Line 185: <system>-<0,0x00000000> LdrGetProcedureAddress(... "OpenProcessToken", ...)
Line 277: <system>-<0,0x00000000> LdrGetProcedureAddress(... "OpenProcess", ...)

LdrGetProcedureAddress is how the unpacked payload resolves API addresses dynamically at runtime (equivalent to GetProcAddress). Seeing it look up injection-related APIs is itself an indicator that these APIs are being used deliberately.

Why this is evidence of injection and not normal behavior: A legitimate application (e.g., a game or a text editor) does not need to enumerate all running processes and open handles to them. The only common legitimate use case is antivirus or process monitoring software — which this sample is clearly not.

Screenshot needed: Notepad++ search results showing CreateToolhelp32Snapshot found in the trace, and separately OpenProcess found.

Stage 2: Privilege Escalation and Memory Allocation

What we're looking for: APIs that elevate privileges to ensure cross-process access, and APIs that reserve memory in the target process.

Search in Notepad++: privile (matches both AdjustTokenPrivileges and LookupPrivilegeValueW)

APIs found in the 2025 exam:

Trace evidence:

Search "privile" (2 hits in 1 file of 2 searched)
C:\Temp\apiminer_traces.293906.pid_1432.txt (2 hits)
  Line 25: LdrGetProcedureAddress(... "AdjustTokenPrivileges", ...)
  Line 181: LdrGetProcedureAddress(... "LookupPrivilegeValueW", ...)

Also found (Virtual search):

Search "Virtual" (94 hits in 2 files of 2 searched)
C:\Temp\apiminer_traces.293500.pid_4092.txt (28 hits)
  Line 3:  LdrGetProcedureAddress(... "VirtualAlloc", ...)
  ...
  Line 19: NtAllocateVirtualMemory([process_handle]0xFFFFFFFF, ...)
  Line 123: NtProtectVirtualMemory([process_handle]0xFFFFFFFF, ...)

Note: process_handle = 0xFFFFFFFF is the pseudo-handle for the current process — this is the injector allocating memory in its own space. Later entries with a different handle value indicate cross-process memory operations.

Why SeDebugPrivilege matters: By default, even an administrator-level process cannot open a handle to another user's process or a system process like lsass.exe. SeDebugPrivilege bypasses this restriction. Malware requesting this privilege is a major red flag.

Screenshot needed: Notepad++ showing AdjustTokenPrivileges and LookupPrivilegeValueW in search results. Second screenshot showing VirtualAlloc/VirtualProtect results.

Stage 3: Payload Mapping into Target Memory

What we're looking for: APIs that map a shared memory section into the target process's address space.

This sample uses the section-mapping technique, which is more evasive than WriteProcessMemory because:

• WriteProcessMemory is heavily monitored by EDR/AV tools.
• Section mapping uses legitimate OS mechanisms for shared memory — the same used by DLLs loading into multiple processes.

Search in Notepad++: NtCreateSection, NtMapViewOfSection, NtUnmapViewOfSection

APIs found in the 2025 exam:

Trace evidence:

Search "NtMapViewOfSection" (7 hits in 1 file of 2 searched)
C:\Temp\apiminer_traces.293906.pid_1432.txt (7 hits)
  Line 585: <process>-<0,0x00000000> NtMapViewOfSection([section_handle]...)
  Line 592: <process>-<0,0x00000000> NtMapViewOfSection([section_handle]...)
  Line 599: <process>-<0,0x00000000> NtMapViewOfSection([section_handle]...)
  Line 606: <process>-<-1073741827,0x40000003> NtMapViewOfSection([sec...
  Line 613: <process>-<-1073741827,0x40000003> NtMapViewOfSection([sec...
  Line 620: <process>-<-1073741827,0x40000003> NtMapViewOfSection([sec...
  Line 627: <process>-<-1073741827,0x40000003> NtMapViewOfSection([sec...

Search "NtUnmapViewOfSection" (10 hits in 2 files of 2 searched)
C:\Temp\apiminer_traces.293500.pid_4092.txt (1 hit)
  Line 20: <process>-<0,0x00000000> NtUnmapViewOfSection([process_handle]0xFFFFFFFF...)
C:\Temp\apiminer_traces.293906.pid_1432.txt (9 hits)
  Line 20, 149, 588, 595, 602, 609, 616, 623, 631: ...NtUnmapViewOfSection(...)

Search "NtCreateSection" (7 hits in 1 file of 2 searched)
C:\Temp\apiminer_traces.293906.pid_1432.txt (7 hits)
  Lines 584, 591, 598, 605, 612, 619, 626: NtCreateSection([section_handle]...)

The negative process handle value (-1073741827, 0x40000003) in some NtMapViewOfSection calls indicates cross-process mapping — the section is being mapped into a different process. This is the injection event.

Screenshot needed: Notepad++ search results for each of the three section APIs. Three separate screenshots recommended (one per API).

Stage 4: Execution via Thread Manipulation

What we're looking for: APIs that hijack or create a thread in the target process to execute the injected payload.

This sample uses GetThreadContext / SetThreadContext — an older but effective technique where the injector:

1. Suspends a thread in the target process.
2. Gets the thread's CPU register state (GetThreadContext).
3. Modifies the instruction pointer (EIP/RIP) to point to the injected payload.
4. Restores the context (SetThreadContext), so the thread will jump to the payload when resumed.

Search in Notepad++: Thread (matches all thread-related APIs)

APIs found in the 2025 exam:

Also seen (related thread APIs in the trace):

Trace evidence:

Search "Thread" (34 hits in 2 files of 2 searched)
C:\Temp\apiminer_traces.293500.pid_4092.txt (11 hits)
  Line 13:  LdrGetProcedureAddress(... "CreateThread", ...)
  Line 36:  LdrGetProcedureAddress(... "GetCurrentThreadId", ...)
  Line 57:  LdrGetProcedureAddress(... "CreateThread", ...)
  Line 58:  LdrGetProcedureAddress(... "ExitThread", ...)
  Line 61:  LdrGetProcedureAddress(... "TerminateThread", ...)
  Line 63:  LdrGetProcedureAddress(... "SuspendThread", ...)
  Line 65:  LdrGetProcedureAddress(... "ResumeThread", ...)
  Line 67:  LdrGetProcedureAddress(... "SetThreadPriority", ...)
  Line 177: <process>-<1,0x00000001> CreateProcessInternalW([command_line]"C:\Temp\sample.exe", ...)

Search "GetThreadContext" (1 hit in 1 file of 2 searched)
C:\Temp\apiminer_traces.293906.pid_1432.txt (1 hit)
  Line 261: <system>-<0,0x00000000> LdrGetProcedureAddress(... "GetThreadContext", ...)

Search "SetThreadContext" (1 hit in 1 file of 2 searched)
C:\Temp\apiminer_traces.293906.pid_1432.txt (1 hit)
  Line 317: <system>-<0,0x00000000> LdrGetProcedureAddress(... "SetThreadContext", ...)

Screenshot needed: Notepad++ search results for "Thread" (showing the 34-hit summary), plus separate screenshots for GetThreadContext and SetThreadContext.

Why this API sequence proves code injection

A single API in isolation could be legitimate. The sequence and cross-process context is what proves injection:

1. CreateToolhelp32Snapshot + OpenProcess   → attacker gains handle to victim process
2. LookupPrivilegeValueW + AdjustTokenPrivileges → attacker enables SeDebugPrivilege
   VirtualAlloc + VirtualProtect            → memory prepared (RWX) for payload
3. NtCreateSection                          → shared memory section created
   NtMapViewOfSection (cross-process)       → payload mapped into victim's memory
   NtUnmapViewOfSection                     → section unmapped from attacker's space
4. GetThreadContext + SetThreadContext       → victim thread's EIP redirected to payload
   ResumeThread                             → victim thread executes payload

This is a complete injection chain. The cross-process NtMapViewOfSection call (evidenced by the non-self process handle) is the moment the payload enters the victim process.

Final Answer — Q3

YES, sample.exe performs process injection (specifically, section-mapping injection using NtCreateSection / NtMapViewOfSection).

Evidence from APIMiner traces (apiminer_traces.*.pid_1432.txt):

Conclusion: The API sequence is consistent with and specific to process injection. No legitimate application uses this combination in this order.

Marks strategy for Q3

This question is worth 40% of the exam (4 marks). Each stage = 1 mark.

• Do NOT just list APIs — briefly explain what each API does in the injection context.
• Identify the technique (section-mapping) to show you understand the difference from classic WriteProcessMemory injection.
• The LookupPrivilegeValueW + AdjustTokenPrivileges pair belongs in Stage 2 (privilege), not a separate stage.
• For Stage 3, emphasize that NtMapViewOfSection is the key call that places the payload into the target process.
• For Stage 4, emphasize that SetThreadContext modifies the EIP register to redirect execution.

Question 4: Created Thread IDs (2 marks)

Question text

Which threads were created with which IDs?

Theory background

A thread is the unit of execution within a process. A process can have many threads running concurrently. Each thread gets a unique Thread ID (TID), assigned by the OS at creation time.

ProcMon logs Thread Create and Thread Exit events. The Detail column of a Thread Create event shows the new thread's ID. Thread IDs are not stable across runs — re-running the sample will produce different TIDs.

Procedure

1. Return to the saved ProcMon trace (C:\Temp\trace.pml).
2. Modify filters:

• Keep: Process Name is sample.exe → Include
• Remove the CreateFile filter (or disable it)
• Add: Operation contains Thread → Include

1. Click Apply or OK.

Alternatively, add a direct filter for the event type:

1. Look at the Thread Create rows in the Operation column.
2. Read the Detail column for each Thread Create event.

Results observed in the 2025 exam

Four distinct threads were created:

Key observation: Two different PIDs create threads — PID 2272 (the original sample.exe) and PID 2824 (a spawned process, confirmed by CreateProcessInternalW in the APIMiner trace). This is consistent with the injection activity observed in Q3: the injected code running under PID 2824 creates threads as part of its payload.

Screenshot needed: ProcMon window with Thread filter active, showing the 4 Thread Create events with their Thread IDs visible in the Detail column.

Note on TID reproducibility

The exact TID values (3608, 3424, 1176, 2684) are specific to this execution run. If you re-run the sample, you will see different TID numbers. This is expected — thread IDs are dynamically assigned. When answering this question in the exam:

• Report the IDs from your own execution run.
• The number of threads created (4) is the more reliable indicator — the TIDs will vary.

Final Answer — Q4

Four threads were created when sample.exe was executed:

Evidence: ProcMon trace with filter Operation contains Thread, showing 4 Thread Create events with SUCCESS result. Detail column records the assigned Thread ID for each.

Marks strategy for Q4

• List all 4 IDs (from your own run, your IDs will differ but there should be 4) = 1 mark.
• Mention that TIDs come from two different PIDs, connecting this back to the injection activity = 1 mark.
• If your run produces a different number of threads, report what you see — don't fake the answer.

Complete Marks Summary

Common Mistakes to Avoid

Tool Quick Reference

Cross-References to Lecture Material

See also:

• notes/13-lecture-exercises-step-by-step.md — exercises 41-47 (injection techniques)
• notes/01-tooling-overview.md — complete tool reference
• checklists/malware-analysis-exam-checklist.md — exam day workflow

Source documents: reference_pdfs/Exams2025_Malware_Analysis-2.pdf (questions) and reference_pdfs/Exams2025_Malware_Analysis_Answers.pdf (official answer screenshots). Last verified: June 2026.