# T1055.014 - VDSO Hijacking > [!danger] Técnica de Alta Complexidade > VDSO Hijacking é uma técnica avançada exclusiva de Linux que permite injeção de código sem chamar `ptrace()`, contornando muitos sistemas de detecção baseados em syscalls diretas. Requer acesso de gravação à memória do processo-alvo, tipicamente obtido após exploração inicial. ## Descrição **VDSO Hijacking** (T1055.014) é uma sub-técnica de [[t1055-process-injection|T1055 - Process Injection]] que abusa do mecanismo **virtual dynamic shared object (vDSO)** do kernel Linux para injetar e executar código arbitrário no espaço de endereços de um processo em execução, sem depender das chamadas de sistema tradicionais monitoradas por ferramentas de segurança. O **vDSO** é um pequeno objeto compartilhado mapeado automaticamente pelo kernel Linux em todo processo em execução. Seu objetivo legítimo é permitir que chamadas de sistema frequentes - como `gettimeofday()`, `clock_gettime()` e `getcpu()` - sejam executadas no espaço de usuário sem o custo de uma transição completa para o kernel. O vDSO é exposto via a variável de ambiente `AT_SYSINFO_EHDR` e pode ser localizado inspecionando `/proc/<pid>/maps`. A técnica explora dois componentes fundamentais da arquitetura de binários ELF em Linux: - **vDSO stub code**: Os stubs de syscall mapeados do vDSO no espaço de endereços do processo - **GOT (Global Offset Table)**: Tabela que armazena os endereços absolutos das funções de biblioteca mapeadas dinâmicamente Ao redirecionar as entradas da GOT para apontar para código malicioso injetado via stubs vDSO, o adversário executa shellcode toda vez que o processo-alvo invocar uma syscall roteada por aquela entrada da tabela. **Técnica pai:** [[t1055-process-injection|T1055 - Process Injection]] --- ## Como Funciona O ataque ocorre em quatro fases distintas: ### Fase 1 - Localização do vDSO no Processo-Alvo O adversário com capacidade de leitura da memória do processo (via `/proc/<pid>/mem` ou `ptrace`) localiza o mapeamento vDSO inspecionando `/proc/<pid>/maps`. O vDSO aparece como uma região anônima com permissões `r-xp`. ### Fase 2 - Leitura dos Stubs de Syscall Os stubs de syscall dentro do vDSO contêm instruções de entrada/saída do kernel (`syscall`, `int 0x80` ou `sysenter` dependendo da arquitetura). O adversário lê esse código para identificar os pontos de entrada manipuláveis. ### Fase 3 - Injeção via GOT Overwrite Diferente de outras sub-técnicas como [[t1055-008-ptrace-system-calls|T1055.008 - Ptrace System Calls]], que escrevem diretamente na memória executável do processo, o VDSO Hijacking opera através da **GOT**. A proteção de memória pode impedir escrita em regiões `.text`, mas as entradas da GOT em regiões `.data` ou `.bss` normalmente não possuem a flag `RELRO` completa (`Full RELRO`), tornando-as graváveis. O adversário sobrescreve ponteiros na GOT que referenciam funções roteadas através do vDSO com o endereço do shellcode malicioso. ### Fase 4 - Execução Transparente Quando o processo-alvo realizar a próxima chamada a uma função cujo ponteiro GOT foi comprometido, o fluxo de execução é redirecionado para o shellcode do adversário - que pode ser um backdoor, loader de segundo estágio ou [[t1059-command-and-scripting-interpreter|intérprete de comandos]]. > [!info] Por que é difícil detectar? > Como a execução ocorre dentro de um processo legítimo e utiliza a interface de syscall já mapeada pelo kernel, ferramentas que monitoram apenas `ptrace()` ou `execve()` não capturam essa técnica. O código malicioso "parece" parte normal do processo-alvo. --- ## Attack Flow ```mermaid graph TB A([Adversário com acesso inicial]) --> B[Acesso ao processo-alvo<br/>/proc/PID/mem ou ptrace] B --> C{Verificar proteções\nde memória} C -->|Full RELRO ativo| D([Técnica bloqueada<br/>GOT somente-leitura]) C -->|Partial RELRO ou sem RELRO| E[Localizar vDSO<br/>em /proc/PID/maps] E --> F[Mapear AT_SYSINFO_EHDR<br/>e identificar stubs de syscall] F --> G[Identificar entrada GOT<br/>alvo na biblioteca dinâmica] G --> H[Injetar shellcode via<br/>stubs vDSO] H --> I[Sobrescrever ponteiro GOT<br/>com endereço do shellcode] I --> J{Processo-alvo\ninvoca a função?} J -->|Sim| K([Shellcode executado<br/>no contexto do processo]) K --> L[Acesso à memória do processo<br/>recursos de rede e sistema] L --> M[Persistência / Escalação<br/>de Privilégios] J -->|Não ainda| J ``` --- ## Exemplos de Uso Embora o VDSO Hijacking sejá documentado principalmente em pesquisas ofensivas e frameworks de exploração, a técnica tem sido observada em contextos de malware Linux sofisticado e campanhas de espionagem. ### Grupos e Contextos Relevantes | Ator / Ferramenta | Contexto | Observação | |-------------------|----------|------------| | Pesquisadores ofensivos | POC acadêmico | Demonstrado em conferências de segurança como DEF CON e Black Hat | | Implantes de espionagem em Linux | Campanhas APT não atribuídas | Observado em servidores comprometidos em ambientes governamentais | | Rootkits de kernel modernos | Pós-exploração em servidores Linux | Frequentemente combinado com [[t1014-rootkit\|T1014 - Rootkit]] | > [!warning] Uso em LATAM > Infraestruturas críticas brasileiras - especialmente servidores Linux em setores de [[_sectors|energia]], [[_sectors|financeiro]] e [[_sectors|governo]] - são alvos potenciais de atores que utilizam técnicas de injeção avançadas em Linux. Grupos como [[g0032-lazarus-group|Lazarus Group]] e [[g0016-apt29|APT29]] possuem capacidade técnica documentada para desenvolver implantes Linux sofisticados. ### Combinação Típica com Outras Técnicas Esta técnica frequentemente aparece em cadeia com: 1. [[t1068-exploitation-for-privilege-escalation|T1068 - Exploração para Escalação de Privilégios]] - para obter acesso de escrita ao processo 2. [[t1055-008-ptrace-system-calls|T1055.008 - Ptrace System Calls]] - como técnica alternativa quando o vDSO não é viável 3. [[t1070-indicator-removal|T1070 - Indicator Removal]] - para limpar rastros após injeção 4. [[t1014-rootkit|T1014 - Rootkit]] - para ocultar o processo comprometido do sistema operacional --- ## Detecção ### Indicadores de Comprometimento | Indicador | Tipo | Descrição | |-----------|------|-----------| | Acesso a `/proc/<pid>/maps` por processo não-root | Comportamento | Leitura do mapa de memória de outro processo | | Escrita em `/proc/<pid>/mem` | Syscall | Modificação direta da memória de processo externo | | `mmap()` com flags `PROT_EXEC` em região anônima | Syscall | Mapeamento de memória executável não associado a arquivo | | GOT entries apontando para regiões fora do segmento `.text` | Memória | Entradas da tabela de offsets globais comprometidas | | Discrepância entre `/proc/<pid>/maps` e bibliotecas carregadas | Auditoria | Mapeamentos anômalos no espaço de endereços | ### Regra Sigma ```yaml title: Possible VDSO Hijacking via GOT Overwrite on Linux id: 7a3e9f21-bc45-4d82-a891-f2c3d56b8e04 status: experimental description: > Detecta acesso de escrita à memória de outro processo via /proc/PID/mem combinado com mapeamento de região executável anônima - padrão associado a VDSO Hijacking (T1055.014). references: - https://attack.mitre.org/techniques/T1055/014/ author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.privilege_escalation - attack.t1055.014 logsource: product: linux category: process_creation detection: selection_proc_mem_write: syscall: 'pwrite64' filepath|contains: '/proc/' filepath|endswith: '/mem' selection_mmap_exec: syscall: 'mmap' mmap_prot|contains|all: - 'PROT_EXEC' - 'PROT_WRITE' mmap_flags: 'MAP_ANONYMOUS' condition: selection_proc_mem_write or selection_mmap_exec falsepositives: - Debuggers legítimos (gdb, lldb) - Ferramentas de profiling (perf, valgrind) - Agentes de APM em modo de instrumentação level: high ``` ### Fontes de Dados para Monitoramento | Fonte | O que monitorar | |-------|----------------| | Linux Audit (`auditd`) | Syscalls `ptrace`, `process_vm_writev`, `pwrite64` com destino em `/proc/*/mem` | | eBPF / Falco | Hooks em `mmap`, `mprotect`, acesso a `/proc` de processos externos | | `/proc/<pid>/maps` polling | Variações de mapeamento anômalo em processos críticos | | EDR em Linux | Injeção de código, GOT tampering, modificação de regiões `.text` | --- ## Mitigação | ID | Mitigação | Descrição | Efetividade | |----|-----------|-----------|-------------| | [[m1040-behavior-prevention-on-endpoint\|M1040]] | Behavior Prevention on Endpoint | EDRs com suporte Linux e hooks de kernel via eBPF/LKM podem detectar a modificação da GOT e o acesso anômalo ao `/proc/<pid>/mem` | Alta | | Hardening de compilação | Full RELRO | Compilar binários com `-Wl,-z,relro,-z,now` torna a GOT somente-leitura, bloqueando a técnica diretamente | Muito Alta | | SELinux / AppArmor | Mandatory Access Control | Políticas MAC restringem quais processos podem acessar `/proc/<pid>/mem` de outros processos | Alta | | Namespaces Linux | Isolamento de PID namespace | Contêineres com PID namespaces separados impedem visibilidade entre processos de namespaces distintos | Média | | Kernel hardening | `CONFIG_STRICT_DEVMEM` e `ptrace_scope` | Limitar o escopo de `ptrace` via `/proc/sys/kernel/yama/ptrace_scope=1` restringe acesso entre processos não relacionados | Alta | --- ## Contexto Brasil/LATAM O ambiente Linux no Brasil abrange um espectro crítico de infraestruturas: **servidores de aplicação financeira**, **sistemas SCADA em usinas hidrelétricas**, **plataformas de e-gov** e **ambientes de telecomunicação**. A maioria desses ambientes opera com kernels Linux desatualizados ou sem hardening de compilação, tornando-os suscetíveis a técnicas como VDSO Hijacking. ### Ameaças Relevantes ao Contexto > [!example] Vetores de Exposição no Brasil > - **Setor financeiro**: Grandes bancos brasileiros (Bradesco, Itaú, Caixa Econômica Federal) operam infraestruturas críticas em Linux. Implantes persistentes em processos de servidor podem ser ativados via VDSO Hijacking após comprometimento inicial por [[t1190-exploit-public-facing-application|T1190]]. > - **Setor de energia**: A ANEEL e operadoras como Eletrobras possuem sistemas SCADA em Linux. Atores de ameaça com capacidade de APT - incluindo grupos vinculados a estados-nação com histórico de ataques a infraestrutura crítica - têm motivação para usar técnicas avançadas de injeção. > - **Governo federal**: Sistemas em produção no SERPRO e outros órgãos federais frequentemente rodam distribuições Linux sem políticas obrigatórias de hardening de compilação. ### Recomendações Específicas para o Contexto Brasileiro 1. **Auditar flags de compilação** de binários críticos - verificar se Full RELRO está ativo 2. **Implementar Falco** em ambientes de contêiner e Kubernetes, com regras específicas para acesso a `/proc` 3. **Habilitar `ptrace_scope=1`** em todos os servidores de produção via `/proc/sys/kernel/yama/ptrace_scope` 4. **Monitorar chamadas `process_vm_writev`** no `auditd` - raramente legítimas em servidores de produção 5. **Revisar políticas SELinux/AppArmor** para garantir restrição de acesso entre processos não relacionados --- ## Referências - [MITRE ATT&CK - T1055.014: VDSO Hijacking](https://attack.mitre.org/techniques/T1055/014/) - [MITRE ATT&CK - T1055: Process Injection](https://attack.mitre.org/techniques/T1055/) - [The vDSO on Linux - Kernel Documentation](https://www.kernel.org/doc/html/latest/virt/kvm/x86/msr.html) - [Linux Process Injection - DEF CON Research](https://defcon.org/) - [Yama - Linux kernel ptrace scope](https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html) - [[m1040-behavior-prevention-on-endpoint|M1040 - Behavior Prevention on Endpoint]] - [[t1055-process-injection|T1055 - Process Injection]] - [[t1055-008-ptrace-system-calls|T1055.008 - Ptrace System Calls]] - [[t1014-rootkit|T1014 - Rootkit]] --- *Fonte: [MITRE ATT&CK - T1055.014](https://attack.mitre.org/techniques/T1055/014)*