Occultamento via Bind Mount: Bind Mounts (T1564.013)

In un contesto di red teaming o purple team, la simulazione di Bind Mounts richiede un ambiente Linux controllato (una VM Ubuntu, Debian o RHEL) con privilegi root. La catena operativa base è breve ma didatticamente ricca.

Dopo aver ottenuto un impianto residente — per esempio un semplice binario che apre una reverse shell — si identifica il suo PID e si sceglie un processo benigno di sistema come veicolo di occultamento, tipicamente qualcosa di longevo come systemd (PID 1) o kthreadd (PID 2). Il comando operativo è:

mount --bind /proc/1 /proc/$(pidof impianto)

In alternativa, per un occultamento più aggressivo che nasconde qualsiasi metadato:

mkdir /tmp/empty && mount -o bind /tmp/empty /proc/$(pidof impianto)

Dopo il mount, ps aux | grep impianto non restituirà più il processo, e ls /proc/ mostrerà il contenuto della directory sostitutiva. Il processo continua a girare, visibile solo tramite chiamate dirette al kernel (es. iterando su task_struct via eBPF) o consultando /proc/<pid>/status di processi figli.

Per un esercizio più realistico, si può concatenare la tecnica con la cancellazione dei file su disco dopo l'esecuzione — pattern esatto osservato in C0035 — usando unlink sul binario da /tmp/ mentre il processo resta in memoria. Il file descriptor rimane accessibile via /proc/<pid>/exe, ma se anche quella entry è nascosta dal bind mount, il recovery diventa estremamente arduo.

Gli strumenti utili al laboratorio includono Atomic Red Team (open source), che fornisce test atomici mappati a T1564 utili come baseline, Sysmon for Linux (open source, repository SysinternalsEBPF) per generare telemetria da correlare, e auditd (open source, incluso in tutte le distro maggiori) configurato con regole -a always,exit -F arch=b64 -S mount.

Per la verifica dell'efficacia si consiglia di eseguire in parallelo tool di enumerazione alternativi come osquery (open source) con query sulla tabella processes e process_open_files, e confrontare i risultati con quelli di ps. Divergenze significative indicano che la tecnica ha funzionato. Chiudere sempre l'esercizio con umount /proc/ per ripristinare la visibilità e documentare i log audit generati.

La detection di Bind Mounts ruota attorno alla strategia DET0428 e alla regola analitica AN1196, che identifica la catena comportamentale: esecuzione di mount con flag -o bind o -B, modifica di entry sotto /proc incoerenti con la lineage di processo attesa, e attività anomala successiva da processi i cui metadati non corrispondono al contesto di esecuzione.

Le fonti di log primarie sono tre. La prima è auditd:SYSCALL, dove una regola come -a always,exit -F arch=b64 -S mount -k bindmount_watch cattura ogni invocazione della syscall mount(), esponendo argomenti, UID chiamante e comm del processo. La seconda è auditd:PATH, che arricchisce l'evento con il path sorgente e destinazione, permettendo di isolare i mount che hanno come target /proc/*. La terza è osquery con query periodiche sulla tabella mounts, filtrando per righe dove path inizia con /proc/ e type è none o bind.

Una regola di correlazione efficace osserva: syscall mount con destination path che matcha la regex ^/proc/[0-9]+, eseguita da un UID diverso da quello di runtime di container (Docker, Podman) o processi di orchestrazione legittimi. I contenitori infatti generano bind mount su /proc in modo prolifico ma quasi sempre con path destinazione /proc/self o all'interno di namespace mount separati, distinguibili tramite il campo mnt_ns raccolto da Sysmon for Linux (open source) o da sensori eBPF come Falco (open source, CNCF).

I parametri di tuning della strategia sono espliciti nei dati MITRE: BindMountFlags (varia tra distribuzioni), WatchedProcPaths (per ridurre rumore da container e chroot legittimi), e CorrelationWindow — la finestra temporale entro cui correlare la creazione del bind mount con attività anomala successiva. Una finestra di 5-15 minuti bilancia sensibilità e volume di alert.

I falsi positivi principali derivano da runtime di container (containerd, CRI-O), tool di sandbox come Firejail (open source) e Bubblewrap (open source), sistemi di build isolati come Docker BuildKit, e configurazioni di systemd che usano BindPaths= nelle unit file. Una whitelist basata sul parent process (systemd, dockerd, containerd-shim) elimina il rumore dominante.

Dal punto di vista D3FEND, i controlli hardening applicabili includono restrizioni via AppArmor o SELinux (entrambi open source) che neghino la capability CAP_SYS_ADMIN a processi utente non privilegiati, e monitoraggio continuo delle mount unit con systemd-mount review periodiche.

L'analisi forense di un sistema compromesso con Bind Mounts richiede di uscire dai tool standard, perché ps, top e la maggior parte degli agent EDR leggono /proc — esattamente il piano di attacco della tecnica. L'artefatto primario e più immediato è il file /proc/mounts (e il suo omologo più dettagliato /proc/self/mountinfo), che elenca tutti i mount attivi. Righe con target sotto /proc/<pid> e tipo none con opzione bind sono altamente sospette in assenza di container legittimi.

La timeline di risposta parte da qui:

• cat /proc/self/mountinfo | grep '/proc/[0-9]' per isolare bind mount su directory di processo
• findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS per una vista tabellare (findmnt è parte di util-linux, open source)
• Cross-check con lsns -t mnt per identificare mount namespace anomali

Sul fronte log persistenti, i record auditd in /var/log/audit/audit.log contengono le syscall mount storiche se il subsystem era configurato con regole appropriate. Il comando ausearch -k bindmount_watch -ts recent estrae rapidamente gli eventi. In assenza di auditd, il journal di systemd (journalctl -k) può conservare messaggi kernel su mount operation, e /var/log/syslog o /var/log/messages contengono tracce a seconda della distribuzione.

Per identificare il processo nascosto senza fidarsi di /proc, esistono percorsi alternativi. Il kernel espone la lista completa dei task tramite task_struct accessibile via debugger kernel (crash utility, open source, di Red Hat) o via Volatility 3 (open source) su un memory dump acquisito con AVML (open source, Microsoft) o LiME (open source). Il plugin linux.pslist di Volatility enumera i processi direttamente dalle strutture kernel, bypassando completamente il bind mount.

Un altro trucco operativo è confrontare l'output di ls /proc | grep '^[0-9]' con quello di ss -tnp e lsof -i: connessioni di rete attive attribuite a PID che non appaiono nell'enumerazione di ps sono un indicatore fortissimo di occultamento.

Nel contesto della campagna C0035 (KV Botnet Activity), i forensic analyst hanno documentato che il malware combinava il bind mount su /proc/ con la cancellazione dei propri file dalla directory /tmp/. La reconstruction del binario originale in questi casi richiede il recupero via /proc/<pid>/exe (accessibile se si conosce il PID reale ottenuto da memoria kernel) e il dump dei segmenti mappati tramite gcore o l'estrazione da memory image. Gli artefatti di rete residui, log firewall e telemetria NetFlow diventano fonti critiche per ricostruire la timeline di C2.

Il panorama di threat intelligence su Bind Mounts è al momento dominato da un singolo caso di riferimento di altissimo profilo: la campagna C0035 (KV Botnet Activity), attiva da ottobre 2022 a gennaio 2024 e attribuita nell'ecosistema pubblico al cluster Volt Typhoon. La campagna ha sfruttato apparati SOHO end-of-life di Cisco, NETGEAR e DrayTek come nodi di offuscamento, costruendo un tessuto di relay difficilmente attribuibili per mascherare la connettività verso vittime finali in segmenti critici — energia, telecomunicazioni e infrastrutture nel territorio statunitense di Guam.

L'uso specifico della tecnica T1564.013 nella campagna è documentato con precisione: l'impianto eseguiva un bind mount su /proc/ per associarsi a un path di sistema, e successivamente cancellava i propri file da /tmp/. Questo pattern combinato — occultamento dei metadati di processo più rimozione dei binari on-disk — riflette una maturità operativa orientata alla persistenza silente di lunga durata, coerente con obiettivi di pre-positioning strategico più che di monetizzazione immediata. La segnalazione pubblica indica anche una sovrapposizione con un secondo cluster botnet denominato JDY, suggerendo un'infrastruttura condivisa o riutilizzata.

La disruption di KV Botnet condotta dalle autorità federali statunitensi all'inizio del 2024 ha rappresentato uno dei più significativi takedown mirati a infrastrutture di stato-nazione degli ultimi anni, ma la tecnica di bind mount rimane pienamente valida e a basso costo di implementazione, rendendo probabile la sua adozione da parte di altri attori.

Dal punto di vista di threat modeling, la scelta di T1564.013 segnala tre caratteristiche dell'avversario. Primo, presenza consolidata su target Linux (la tecnica non esiste su Windows), coerente con l'ecosistema di router, gateway, appliance di rete e server di infrastruttura critica. Secondo, accesso root già ottenuto — la tecnica è post-exploitation, non un vettore di ingresso, quindi presuppone una kill chain già avanzata. Terzo, obiettivo di persistenza di lungo periodo su target monitorati da personale IT, dove l'occultamento da tool nativi come ps è sufficiente a evadere il monitoraggio di routine.

Il trend attendibile per i prossimi cicli è un'adozione crescente della tecnica da parte di attori che operano su infrastrutture edge Linux, dove gli agent EDR sono spesso assenti o limitati. Gruppi con focus su critical infrastructure, ISP e telco sono i candidati naturali. La tecnica si integra bene con impianti scritti in Go o C statico, e con l'uso di apparati embedded come pivot — un modello operativo già visto e destinato a proliferare in ambienti dove l'inventario dei dispositivi è parziale o obsoleto.

MITRE ATT&CK: T1564.013 (Bind Mounts), tattica TA0005 (Defense Evasion). Campagna citata: C0035 (KV Botnet Activity). Strategia di detection: DET0428 con regola analitica AN1196. Riferimenti difensivi: MITRE D3FEND per hardening e detection su artefatti Linux mount. Alcune indicazioni operative su tool (auditd, osquery, Sysmon for Linux, Falco, Volatility 3, AVML, LiME, Atomic Red Team, AppArmor, SELinux) derivano da conoscenza professionale di cybersecurity verificabile su repository pubblici e documentazione ufficiale dei rispettivi progetti.