Remote Access Hardware: Remote Access Hardware (T1219.003)

Dal punto di vista offensivo, un KVM su IP è un impianto hardware che si interpone tra la macchina bersaglio e le sue periferiche, esponendo tastiera, video e mouse attraverso un'interfaccia di rete raggiungibile dall'operatore. Progetti come PiKVM e TinyPilot (entrambi open source) girano su un Raspberry Pi con una scheda di cattura HDMI e un'interfaccia USB gadget che emula tastiera e mouse verso l'host.

In un esercizio red team lab-safe la catena è semplice: dopo aver ottenuto accesso fisico alla postazione, si collega il dispositivo tra la porta USB dell'host e le periferiche, più il cavo HDMI in ingresso alla scheda di cattura. L'host vede comparire una HID composita (tastiera/mouse) legittima, mentre l'operatore controlla tutto via browser dalla rete. Il vantaggio operativo è che l'input arriva a livello hardware: si può interagire con la schermata di login pre-boot, con il menu UEFI/BIOS e con il sistema anche quando l'agente EDR non è ancora caricato.

Sul lato host, per verificare l'enumerazione del dispositivo durante il test:

• Windows: Get-PnpDevice -Class HIDClass | Format-Table FriendlyName,InstanceId,Status per elencare le periferiche HID e leggere VendorID/ProductID dall'InstanceId.
• Linux: lsusb mostra i dispositivi USB con vendor/product ID, mentre dmesg | grep -i usb rivela l'evento di attach in tempo reale.
• macOS: system_profiler SPUSBDataType elenca i dispositivi USB con metadata, serial e classe.

Per configurare l'impianto nel laboratorio si usa l'immagine ufficiale di PiKVM (open source) oppure il pacchetto TinyPilot (freemium: community edition gratuita, versione Pro a pagamento). Entrambi espongono una console web con streaming del framebuffer e input injection.

Alcune considerazioni tattiche per la simulazione. Il KVM emula spesso un gadget USB Ethernet o mass storage aggiuntivo per il proprio management: questo genera artefatti utili al blue team, che vanno documentati nel report. Per rendere lo scenario realistico si può testare lo spoofing del descrittore USB, impostando VendorID e stringhe che imitino una tastiera comune. Nel report finale evidenzia che il canale hardware resta operativo anche disattivando servizi di remote access software, dimostrando così il valore del controllo fisico e delle policy sull'installazione hardware come contromisura.

Il rilevamento di questa tecnica ruota attorno all'enumerazione delle periferiche: quando un KVM su IP viene collegato, l'host registra l'attach di nuove interfacce HID, seriali o di rete USB, con VendorID, ProductID e stringhe descrittive potenzialmente riconoscibili. La detection MITRE DET0159 copre esattamente questo scenario su tre piattaforme.

Su Windows (analitica AN0446) la fonte primaria è WinEventLog:System: monitora gli eventi di Device Setup Manager, in particolare l'Event ID 20001, che registra l'installazione di driver e dispositivi con relativo identificativo hardware. Correla la comparsa di identificatori di vendor insoliti o di annunci EDID anomali provenienti dalla scheda di cattura video. La mitigazione M1034 suggerisce inoltre di abilitare il logging degli eventi di installazione hardware e di alimentare un SIEM come Splunk o Elastic Stack (entrambi freemium) per correlare questi eventi.

Su Linux (analitica AN0447) la telemetria arriva da auditd:SYSCALL: imposta regole audit sulle syscall di mount e sugli accessi a path prevedibili come /opt/tinypilot o /opt/tinypilot-privileged, e osserva la registrazione di dispositivi con friendly name tipo tinypilot. Questi nomi sono mutabili, quindi vanno espansi per coprire impianti custom.

Su macOS (analitica AN0448) la sorgente è macos:unifiedlog: intercetta l'attach di dispositivi HID o seriali con metadata identificabili, correlando i serial number attraverso inserzioni multiple per ridurre il rumore.

Il principale nodo dei falsi positivi è la natura legittima di questi apparati: tastiere, mouse e KVM autorizzati generano eventi identici. Per questo il tuning suggerito da MITRE insiste su tre parametri: le stringhe VendorID, i SerialNumber (che variano per campagna e vanno ampliati) e la TimeWindow di enumerazione, da calibrare sugli orari operativi dell'ambiente. Un attach di periferica fuori orario, su una postazione critica, è un segnale molto più forte.

Sul fronte preventivo, i controlli di device control valgono quanto la detection. Le Windows Device Installation Policies permettono di autorizzare solo i dispositivi con serial number approvati, mentre soluzioni come Microsoft Defender for Endpoint (a pagamento), Symantec Endpoint Protection (a pagamento) o l'IDS host-based OSSEC (open source) monitorano e bloccano hardware non approvato. Disabilitare via GPO le porte USB non necessarie e imporre password BIOS/UEFI con Secure Boot riduce ulteriormente la superficie sfruttabile da un impianto fisico.

L'analisi forense di un impianto KVM su IP parte dagli artefatti di enumerazione USB lasciati dal sistema operativo al momento del collegamento fisico. Questi apparati emulano interfacce HID, seriali o di rete e, così facendo, scrivono tracce persistenti nei registri di dispositivo.

Su Windows l'analista ricostruisce la timeline partendo dalla chiave di registro HKLM\SYSTEM\CurrentControlSet\Enum\USB e da USBSTOR, che conservano VendorID, ProductID, stringhe descrittive e serial number di ogni dispositivo collegato. Le sottochiavi Properties espongono i timestamp di primo e ultimo collegamento (first install, last connected, last removed). In parallelo, il log WinEventLog:System con l'Event ID 20001 di Device Setup Manager data l'installazione del driver associato, mentre setupapi.dev.log nella cartella di Windows registra in chiaro l'intera sequenza di enumerazione con marca temporale, utile per correlare l'attach a una specifica finestra oraria.

Su Linux le prove risiedono nei log di auditd, dove le regole sulle syscall catturano gli eventi di mount e la comparsa del dispositivo. Il ring buffer del kernel, consultabile con journalctl -k o dai file in /var/log, registra l'attach USB con vendor/product ID e nome del dispositivo. Vanno cercati path di staging come /opt/tinypilot e nomi friendly riconducibili all'impianto, tenendo presente che sono personalizzabili tra distribuzioni. La persistenza del KVM può inoltre lasciare unit systemd o script di avvio da acquisire.

Su macOS l'artefatto chiave è la unified log, interrogabile con log show --predicate 'subsystem == "com.apple.iokit"' --last 24h, che mostra l'attach di dispositivi HID e seriali con classe, metadata e serial number. Anche il file system.log e i database di IOKit conservano l'enumerazione. La correlazione dei serial across inserzioni multiple aiuta a distinguere un impianto ricorrente da periferiche occasionali.

Sul piano fisico, poiché la tecnica richiede accesso alla postazione, l'analista integra la timeline digitale con evidenze ambientali: log dei controlli di accesso, registrazioni di videosorveglianza e ispezione hardware diretta della macchina, dove il KVM appare come un dongle interposto tra host e periferiche. La combinazione di artefatti di registro, timestamp di setupapi e serial number ricorrenti permette di stabilire quando l'impianto è stato collegato e per quanto è rimasto operativo, elemento cruciale perché questo canale hardware sopravvive alla disinstallazione del software malevolo.

I dati MITRE ATT&CK per T1219.003 non associano a questa sotto-tecnica alcun gruppo APT, software o campagna documentata: le statistiche indicano zero gruppi, zero software e zero campagne. In coerenza con il vincolo di usare esclusivamente i dati forniti, non è possibile tracciare profili di attori specifici, pattern geografici o sovrapposizioni di tooling attribuibili a questo comportamento. Segnalarlo è parte dell'analisi: si tratta di una tecnica di recente formalizzazione nel catalogo, per la quale il framework non ha ancora consolidato attribuzioni pubbliche.

Dal punto di vista dell'intelligence, questa assenza è essa stessa un dato interpretabile. L'uso di hardware KVM su IP come canale di comando e controllo richiede accesso fisico al bersaglio, un requisito che restringe drasticamente il novero degli attori capaci di impiegarlo su scala. Storicamente questo tipo di impianto si colloca nel repertorio di operazioni dove la prossimità fisica è possibile: minacce interne (insider), attori con capacità di intrusione fisica nelle sedi bersaglio e operazioni di penetrazione mirate ad alto valore. È un vettore che privilegia la profondità del controllo sulla scalabilità, opposto rispetto ai canali C2 puramente software distribuibili via phishing.

La collocazione in TA0011 (Command and Control) inquadra la finalità: stabilire un canale interattivo che imiti il traffico atteso e resista alle contromisure software. Il valore strategico per un attaccante è la ridondanza: un impianto hardware fornisce accesso alternativo che sopravvive a bonifica del malware, reinstallazione dell'agente EDR e rotazione delle credenziali, perché opera a livello elettrico sotto lo stack software. Questo lo rende attraente per operazioni che puntano a persistenza di lungo periodo su asset critici, dove il costo dell'accesso fisico è giustificato dal ritorno informativo.

Sul piano dei trend, la crescente disponibilità commerciale e open source di apparati come TinyPilot e PiKVM abbassa la barriera d'ingresso: strumenti nati per l'amministrazione IT legittima diventano dual-use. Un analista di threat intelligence dovrebbe monitorare l'evoluzione di questa tecnica come indicatore di maturazione delle capacità fisiche degli avversari, integrando la sorveglianza dei dispositivi periferici nelle valutazioni di rischio per infrastrutture sensibili, data center e ambienti air-gapped dove il canale di rete tradizionale è assente e l'impianto hardware diventa l'unica via di controllo interattivo.

MITRE ATT&CK: tecnica T1219.003 (Remote Access Hardware), tattica TA0011. Mitigazione M1034 (Limit Hardware Installation). Detection DET0159 con analitiche AN0446 (Windows), AN0447 (Linux), AN0448 (macOS). Progetti citati: PiKVM e TinyPilot (documentazione ufficiale). Tool di detection e device control: Microsoft Defender for Endpoint, Symantec Endpoint Protection, OSSEC, Splunk, Elastic Stack. Parte dei comandi operativi e degli artefatti forensi deriva da conoscenza professionale di cybersecurity, non dai dati MITRE forniti.