VDSO hijacking (MITRE ATT&CK T1055.014) is a Linux sub-technique of Process Injection. MITRE files it under the Stealth and Privilege Escalation tactics. The goal is to run code inside another live process so the activity looks like it belongs to a legitimate program.
How attackers use it
The virtual dynamic shared object, or vdso, is a small piece of code the kernel maps into every process. It holds stubs for system calls. MITRE explains that memory protections can stop an adversary from writing executable code into a process with ptrace system calls. In that case the adversary can hijack those syscall stubs instead, and use them to open and map a malicious shared object.
To trigger the loaded code, the adversary redirects the process by patching address references stored in its global offset table. That table holds the absolute addresses of mapped library functions. Change an entry, and the process jumps somewhere new.
Because the code runs under a trusted process, it can reach that process's memory and network resources, and possibly its privileges.
How to detect it
MITRE's detection strategy for this technique looks for the redirection of syscall execution flow through changes to vdso code stubs or global offset table entries, which then lead to a malicious shared object being loaded through mmap and ptrace.
In practice that means you want visibility into ptrace activity and unexpected memory mapping by processes that have no reason to debug others. Treat a process attaching to a non-child process as a lead worth following.
How to reduce the risk
MITRE lists one mitigation, Behavior Prevention on Endpoint. Some endpoint security tools can block common sequences of behavior that occur during injection. Check that your Linux hosts run one that covers this class of behavior, and that it is in blocking mode rather than only logging.
Because this technique is a fallback when ptrace writes fail, the controls described for ptrace injection are relevant here too.
Quick check
Why would an adversary choose VDSO hijacking over plain ptrace injection?
Memory protections may block writing executable code through ptrace. Hijacking the vdso syscall stubs lets the adversary open and map a malicious shared object without that write.