The System Service Descriptor Table is a kernel data structure that maps system call numbers to the routines that implement them. In Windows, it is part of syscall dispatch and is relevant to kernel inspection, rootkit detection and tampering analysis because altering it can redirect system service execution.
What the System Service Descriptor Table does
The System Service Descriptor Table, or SSDT, is a kernel dispatch map that associates system call numbers with the routines that handle them. In Windows, that mapping sits at the boundary between user-mode requests and kernel execution, so it is part of how the operating system translates a syscall into the correct privileged service.
Because the table helps direct control flow inside the kernel, it is not just an implementation detail. Changes to the SSDT can affect what code runs when a system service is invoked, which is why defenders and analysts treat it as a high-value inspection point during malware analysis and tampering review.
Why the SSDT matters for kernel integrity
The SSDT matters because it helps define trusted execution paths inside the operating system. If an attacker can alter entries in the table, a legitimate system call may be redirected to malicious or intercepted kernel code instead of the intended routine. That turns a normal operating-system mechanism into a persistence or concealment mechanism.
In practice, this makes the SSDT relevant to rootkit detection and kernel integrity monitoring. Analysts look for unexpected remapping, inline replacement, or other signs that the syscall dispatch path has been modified. The concern is not the table itself, but the trust placed in it as a control point for privileged execution.
How defenders examine SSDT tampering
Exposure analysis usually starts with knowing what should be present in the kernel and what should not. Defenders compare the live dispatch map with expected baselines, review kernel modules and drivers, and look for signs that a security product or system component has been patched in memory. The goal is to distinguish legitimate instrumentation from unauthorized modification.
Because the SSDT sits in kernel space, inspection must be done carefully. A local compromise can hide behind driver activity, alternate hooks, or other kernel-resident techniques, so defenders often correlate SSDT findings with broader integrity signals rather than relying on a single check.
Detection, response, and recovery after compromise
If SSDT tampering is suspected, the priority is to determine whether the system call path has been used to conceal persistence, disable security tooling, or redirect privileged actions. MITRE ATT&CK Enterprise Matrix is useful here because the surrounding behaviors often map to privilege escalation, defense evasion, and credential access patterns that help explain why the kernel modification was made.
Recovery normally requires more than removing a single malicious driver. If the kernel was modified, the endpoint should be treated as potentially untrustworthy until it is rebuilt or validated from a known-good state. CIS Benchmarks are a practical baseline for hardening the host so the conditions that make kernel tampering easier are reduced.
Risk and Threat Considerations
SSDT tampering is dangerous because it can let malware change how the operating system services requests at the kernel layer. That can hide malicious activity, block security controls, or give an attacker a durable foothold that survives ordinary user-mode cleanup.
Failure mechanism: An attacker with kernel-level execution or a vulnerable driver can alter syscall dispatch entries, causing legitimate requests to be routed through malicious code before the intended service runs.
Impact: The result can be stealthy persistence, failed detection, corrupted telemetry, and broader compromise of the affected host.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | SSDT tampering is commonly enabled by kernel exploitation and privilege gain. |
| T1562 — Impair Defenses | SSDT hooks often help attackers hide or weaken endpoint defenses. | |
| Recommendation — Map kernel tampering to T1068 and hunt for privilege escalation paths that enabled SSDT modification. Use T1562 to investigate whether SSDT changes were used to disable or evade security controls. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Kernel tampering is a malware-defense problem because it can conceal or enable malicious code. |
| Recommendation — Harden malware defenses to detect suspicious drivers and kernel-level tampering. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | SSDT integrity directly fits host software and firmware integrity monitoring. |
| AU-2 — Event Logging | SSDT tampering is usually assessed alongside logging and telemetry gaps. | |
| Recommendation — Apply SI-7 to validate kernel integrity and alert on unauthorized SSDT changes. Log kernel-relevant events so SSDT anomalies can be correlated with suspicious activity. | ||
Practitioner Guidance
What to watch for: Treat SSDT changes as a high-signal integrity event, especially when they coincide with unsigned drivers, unexplained kernel hooks, or degraded security-tool visibility. Correlate the table state with driver inventory, memory inspection, and endpoint telemetry rather than relying on a single artifact.
Practitioner takeaway: If the SSDT looks wrong, assume the kernel trust boundary may already be compromised and validate the host from a clean recovery path, not from within the suspect system.
Related resources from NHI Mgmt Group
- Should teams build their own permissions system or use an authorization service?
- Why can a multilingual AI system still fail in international customer service?
- How should security teams respond when a managed desktop service allows local users to escalate to SYSTEM through file handling flaws?
- Who is accountable when a managed service vulnerability allows standard users to gain full SYSTEM access before the fix is applied?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org