GCFA Introduction to Memory Forensics Practice Question
An incident responder is analyzing a memory image from a Windows 10 system that is suspected of being infected with a fileless malware. The responder runs the Volatility 3 windows.malfind plugin and observes several memory regions with PAGE_EXECUTE_READWRITE protection and a MZ header. However, the responder notices that some of these regions are backed by a file on disk, while others are not. Which of the following conclusions is most appropriate regarding the unbacked regions?
⚠ Common exam trap
The trap here is assuming that unbacked RWX regions are benign due to memory management quirks like paging, when they are actually a primary indicator of code injection in fileless attacks.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The unbacked regions are indicative of injected code or shellcode, as they do not correspond to any file on disk and have suspicious permissions.
In memory forensics, unbacked memory regions with PAGE_EXECUTE_READWRITE protection and executable content such as an MZ header strongly suggest injected code or shellcode. Legitimate code is typically backed by a file on disk via a mapped section. The lack of file backing means the code was likely written directly into the process's address space by an injection technique, a common characteristic of fileless malware. This finding should prompt further extraction and analysis of the injected payload.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The unbacked regions are likely legitimate DLLs loaded from disk but with modified permissions due to process hardening.
Why it's wrong here
Legitimate DLLs loaded from disk are typically backed by the file and mapped as image sections. Their permissions are usually PAGE_EXECUTE_READ or PAGE_READONLY, not PAGE_EXECUTE_READWRITE. Process hardening mechanisms like Control Flow Guard do not change page permissions to RWX for image-backed sections. Unbacked RWX regions with MZ headers are more consistent with injected code than with legitimate DLLs.
- ✓
The unbacked regions are indicative of injected code or shellcode, as they do not correspond to any file on disk and have suspicious permissions.
Why this is correct
Unbacked memory regions with PAGE_EXECUTE_READWRITE and MZ headers are classic signs of code injection. Legitimate executables and DLLs are backed by files on disk. The absence of a file mapping indicates the code was placed directly into memory, often by process injection techniques. This is a key finding in fileless malware investigations and warrants further analysis of the injected content.
- ✗
The unbacked regions are artifacts of the Volatility plugin itself, which may incorrectly report memory as unbacked due to parsing errors.
Why it's wrong here
Volatility's malfind plugin uses the process's VAD tree to determine if a memory region is backed by a file. While parsing errors can occur, they are not the norm, and multiple unbacked RWX regions with MZ headers are unlikely to be false positives. Dismissing these findings as plugin artifacts without further verification, such as dumping the memory and analyzing it, would be a serious investigative error.
- ✗
The unbacked regions are likely due to memory compression or paging, where the file backing was temporarily removed from the working set.
Why it's wrong here
Windows memory compression and paging do not remove the file backing from a mapped image; they may move pages to the pagefile or compressed store, but the section object still references the file. Unbacked regions in malfind are determined by the lack of a file-backed section, not by transient paging. This explanation misconstrues memory management behavior and could lead an analyst to dismiss a critical indicator of compromise.
About these practice questions
One of 292 original GCFA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GCFA practice question is part of Courseiva's free GIAC certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCFA exam.