Courseiva

GCFA Introduction to Memory Forensics Practice Question

A forensic examiner is analyzing a memory image from a Windows 7 system that is suspected of being compromised by a sophisticated rootkit. The examiner runs the Volatility 2 plugin 'ssdt' and notices that several system service dispatch table (SSDT) entries point to addresses within a kernel module that is not signed by Microsoft and is not present in the loaded module list. Which of the following best describes the rootkit technique that is most likely in use?

⚠ Common exam trap

Test-takers frequently confuse SSDT hooking with inline hooking; SSDT hooking changes the function pointers in the table, while inline hooking patches the function code itself, leaving the table intact.

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

✓

SSDT hooking, where the rootkit replaces the function pointers in the SSDT to redirect system calls to its own malicious functions.

The SSDT contains pointers to kernel functions for system services. If entries point to an unsigned module not in the loaded module list, it indicates that the SSDT has been hooked—modified to redirect system calls to malicious code. This is a classic rootkit technique to intercept and manipulate system calls, allowing the rootkit to hide its presence and activities. Inline hooking and IAT hooking affect different structures, and DKOM does not apply to the SSDT in this manner.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Import Address Table (IAT) hooking, where the rootkit modifies the IAT of user-mode processes to redirect API calls to its own code.

    Why it's wrong here

    IAT hooking occurs in user-mode processes and affects API calls made by those processes, not kernel system calls. The SSDT is a kernel structure, so IAT hooking would not alter SSDT entries. The scenario describes kernel-level redirection, making IAT hooking irrelevant. Confusing user-mode and kernel-mode hooking techniques is a common mistake in rootkit analysis.

  • ✓

    SSDT hooking, where the rootkit replaces the function pointers in the SSDT to redirect system calls to its own malicious functions.

    Why this is correct

    SSDT hooking involves modifying the SSDT so that system service calls are redirected to malicious code. The SSDT normally contains pointers to legitimate kernel functions. If entries point to an unsigned module not in the loaded module list, it indicates that the table has been tampered with. This is a classic rootkit technique to intercept system calls and hide its activities, and it matches the observed evidence.

  • ✗

    Inline hooking of the SSDT functions, where the rootkit overwrites the first bytes of the legitimate functions with a jump to its own code.

    Why it's wrong here

    Inline hooking modifies the code of legitimate functions, not the SSDT entries themselves. In this scenario, the SSDT entries point to an unsigned module, indicating that the table itself has been altered to redirect system calls. Inline hooking would leave the SSDT entries pointing to the original functions, but the function prologues would be patched. Thus, this option does not match the observed SSDT redirection.

  • ✗

    DKOM on the SSDT, where the rootkit unlinks the SSDT from the kernel's list of service tables to hide its modifications.

    Why it's wrong here

    DKOM typically involves manipulating kernel objects like EPROCESS or ETHREAD, not hiding the SSDT from a list. The SSDT is a fixed structure referenced by the kernel, and there is no standard list of service tables that can be unlinked. The observed redirection of SSDT entries is due to hooking, not DKOM. This option inaccurately applies DKOM concepts to the SSDT.

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 →

How Courseiva writes practice questions · Editorial policy

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.