Detect VDSO Hijacking in Google Chronicle
Adversaries may inject malicious code into processes via VDSO hijacking in order to evade process-based defenses as well as possibly elevate privileges. Virtual dynamic shared object (vdso) hijacking is a method of executing arbitrary code in the address space of a separate live process. VDSO hijacking involves redirecting calls to dynamically linked shared libraries. Memory protections may prevent writing executable code to a process via Ptrace System Calls. However, an adversary may hijack the syscall interface code stubs mapped into a process from the vdso shared object to execute syscalls to open and map a malicious shared object. This code can then be invoked by redirecting the execution flow of the process via patched memory address references stored in a process' global offset table (which store absolute addresses of mapped library functions).
MITRE ATT&CK
- Technique
- T1055 Process Injection
- Sub-technique
- T1055.014 VDSO Hijacking
- Canonical reference
- https://attack.mitre.org/techniques/T1055/014/
YARA-L Detection Query
rule vdso_hijacking_t1055_014 {
meta:
author = "Argus Detection Engineering"
description = "Detects VDSO hijacking indicators: suspicious ptrace PEEK/POKE operations or mprotect/mmap with executable flags on Linux endpoints, excluding known legitimate debuggers."
mitre_attack_tactic = "Defense Evasion, Privilege Escalation"
mitre_attack_technique = "T1055.014"
severity = "HIGH"
confidence = "MEDIUM"
created = "2026-04-18"
platform = "Linux"
events:
$e.metadata.event_type = "PROCESS_OPEN"
$e.target.process.command_line != ""
(
(
re.regex($e.principal.process.file.full_path, `vdso|linux-gate|linux-vdso`) or
re.regex($e.target.process.command_line, `vdso|linux-gate|linux-vdso`)
)
or
(
re.regex($e.target.process.command_line, `ptrace|mprotect|mmap`) and
(
re.regex($e.target.process.command_line, `PROT_EXEC|0x[57]\b`) or
re.regex($e.principal.process.command_line, `a0=[1245]\s`)
)
)
)
not re.regex($e.principal.process.file.full_path, `/(usr/)?(bin|lib)/(gdb|strace|ltrace|valgrind|java|node|dockerd|containerd|ld-linux|libc)`)
not re.regex($e.target.process.file.full_path, `/(usr/)?(bin|lib)/(gdb|strace|ltrace|valgrind|java|node|dockerd|containerd|ld-linux|libc)`)
condition:
$e
}Chronicle YARA-L 2.0 rule detecting VDSO hijacking attempts by monitoring for processes accessing vdso memory regions or executing ptrace PEEK/POKE and mprotect/mmap syscalls with executable flags, which are the primitive operations required to redirect execution via global offset table patching. Excludes known legitimate debugging and runtime tools.
Data Sources
Required Tables
False Positives & Tuning
- Security research and reverse engineering workflows legitimately use ptrace PEEK/POKE to inspect process memory, which will match the HIGH severity indicator in non-production environments
- Build systems and compilers (gcc, clang) with link-time optimization and profile-guided optimization create and modify executable memory mappings that may trigger the mprotect/mmap indicators
- Electron-based applications and Chromium-derived browsers heavily use mprotect with PROT_EXEC for their V8 JIT compiler, generating medium-severity alerts that are expected behavior
Other platforms for T1055.014
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Inspect VDSO Memory Region
Expected signal: auditd: open() on /proc/<pid>/maps. The VDSO mapping shows the address range of the vdso in the target process.
- Test 2Check GOT Entries of Running Process
Expected signal: auditd: readlink and open on /proc/<pid>/exe, execution of readelf. No direct security events from GOT inspection — this is a defensive analysis technique.
- Test 3mprotect Executable Permission Change Detection
Expected signal: Syslog: python3 process execution. No actual mprotect call with PROT_EXEC in this safe test. In a real attack: auditd SYSCALL record with syscall=10 (mprotect) and a2 containing PROT_EXEC flag.
References (5)
- https://attack.mitre.org/techniques/T1055/014/
- https://web.archive.org/web/20210205211142/https://backtrace.io/blog/backtrace/elf-shared-library-injection-forensics/
- https://web.archive.org/web/20150711051625/http://vxer.org/lib/vrn00.html
- https://lwn.net/Articles/604515/
- https://web.archive.org/web/20051013084246/http://www.trilithium.com/johan/2005/08/linux-gate/
Unlock Pro Content
Get the full detection package for T1055.014 including response playbook, investigation guide, and atomic red team tests.