GCIH Endpoint Attack and Pivoting Practice Question
An attacker has compromised a Windows host and established a reverse shell using a malicious DLL loaded by a legitimate signed executable via DLL search order hijacking. The incident responder wants to identify the specific DLL that was hijacked and the process that loaded it. Which of the following data sources would provide the MOST direct evidence of the DLL load event and the loading process?
⚠ Common exam trap
It's easy for candidates to confuse process creation events with DLL load events; only dedicated module load telemetry like Sysmon Event ID 7 directly shows which DLL was loaded into which process.
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
✓
Sysmon Event ID 7 (Image loaded)
Sysmon Event ID 7 specifically captures module load events, including the loading process image and the loaded DLL path, along with hashes. This makes it the most direct source to identify the hijacked DLL and the process that loaded it. Other sources either lack DLL load detail or are not guaranteed to log the event.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Sysmon Event ID 7 (Image loaded)
Why this is correct
Sysmon Event ID 7 logs when a module (DLL) is loaded into a process, including the Image (process) and ImageLoaded (DLL path), along with hashes and signature information. This directly shows which process loaded the malicious DLL and the DLL's location, enabling the responder to identify the hijacked DLL and the legitimate executable involved. It is the most direct evidence source for DLL load events.
- ✗
Windows Security event ID 4688 with command line auditing
Why it's wrong here
Event ID 4688 records process creation and, if command line auditing is enabled, the command line used. It does not log DLL loads. While it would show that the legitimate executable started, it would not reveal which DLL was loaded or that a malicious DLL was involved. In this scenario, the attacker used DLL hijacking, so process creation alone does not provide the needed DLL load evidence.
- ✗
Windows Defender Application Control (WDAC) event logs
Why it's wrong here
WDAC event logs record code integrity decisions, such as blocked or allowed images, and can be useful for detecting unsigned or malicious DLLs. However, they do not always log every DLL load, especially if the DLL is signed or allowed. They also may not provide the loading process context in a straightforward way. In this scenario, the attacker's DLL might be signed or evade WDAC, so these logs are not the most direct evidence of the load event.
- ✗
Sysmon Event ID 1 (Process creation)
Why it's wrong here
Sysmon Event ID 1 logs process creation with the Image, command line, and parent process. It does not record DLL loads. In a DLL hijacking scenario, the malicious DLL is loaded by an already running or newly started process, but Event ID 1 would only show the process start, not the DLL. Therefore, it cannot identify the specific DLL or confirm that it was loaded.
About these practice questions
One of 322 original GCIH 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 GCIH 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 GCIH exam.