GCFA Practice Question: Analyzing Volatile and Windows Event Artifacts
You are examining a Windows Server 2019 memory image after a suspected credential-theft incident. You need to identify which process was used to access the LSASS process memory at the time of capture. Which Volatility 3 plugin and artifact combination most directly reveals handles opened to the LSASS process by other processes?
⚠ Common exam trap
The trap here is conflating injected memory inside LSASS with a handle opened to LSASS; malfind finds the former, while the handle table shows the latter.
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
✓
windows.handles, filtering for handles to the lsass.exe process object
Handle tables record which process opened an object and what type it is. Filtering the handle output for the lsass.exe process object pinpoints processes that held a handle to LSASS at capture time, which is strong evidence of memory access. Injected-memory, network, and loaded-module plugins examine other artifacts and do not answer who opened the handle.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
windows.netscan, filtering for connections owned by lsass.exe
Why it's wrong here
windows.netscan enumerates network endpoints and their owning process. LSASS typically does not initiate outbound network connections, and even if it did, that would not reveal which process opened a handle to it. This plugin addresses network activity, not handle-based process-to-process access, so it is irrelevant to the question.
- ✗
windows.dlllist, focusing on unsigned DLLs loaded into lsass.exe
Why it's wrong here
windows.dlllist shows loaded modules and can surface unsigned or unusual DLLs inside a process, which may indicate injection into LSASS. It does not, however, show handles opened by other processes to the LSASS process object, so it cannot identify the accessing process. It is useful for persistence and injection analysis but not for handle-based attribution.
- ✗
windows.malfind, looking for PAGE_EXECUTE_READWRITE regions in lsass.exe
Why it's wrong here
windows.malfind scans for memory regions with suspicious protections such as PAGE_EXECUTE_READWRITE and is excellent for finding injected code. However, it shows injected memory inside a process, not which other process opened a handle to LSASS. It would not directly answer who accessed LSASS memory, only whether LSASS itself contains suspicious regions.
- ✓
windows.handles, filtering for handles to the lsass.exe process object
Why this is correct
windows.handles enumerates the handle table of each process and shows the object type and object name. Filtering for lsass.exe reveals which processes held handles to the LSASS process object, providing direct evidence of access at capture time. This is the most targeted way to identify a process that opened LSASS for memory access.
About these practice questions
Courseiva writes every GCFA question from scratch — 292 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.