Movimento Laterale via RDP: Remote Desktop Protocol (T1021.001)

La simulazione di un attacco RDP in laboratorio richiede due fasi distinte: la ricognizione dei servizi esposti e l'accesso effettivo con credenziali compromesse. Il punto di partenza è sempre l'enumerazione: bisogna sapere quali host hanno la porta 3389 aperta e quali accettano connessioni.

Per la scansione iniziale, Nmap (open source) è lo strumento naturale. Un comando mirato sulla porta RDP restituisce rapidamente lo stato del servizio:

nmap -p 3389 --open -sV 192.168.1.0/24

Il flag -sV identifica la versione del servizio, utile per capire se NLA (Network Level Authentication) è abilitato. Se la scansione rivela host con RDP attivo, il passo successivo è testare le credenziali disponibili.

Con credenziali valide già ottenute (simulando una fase di Credential Access), il client nativo di Windows è sufficiente:

mstsc.exe /v:192.168.1.50

Questo è esattamente il comando documentato nelle operazioni di Medusa Group, che lo utilizzava per le sessioni RDP laterali. Per un approccio da linea di comando senza GUI, xfreerdp (open source), parte del progetto FreeRDP, permette connessioni scriptabili:

xfreerdp /u:admin /p:Password123 /v:192.168.1.50 /cert:ignore

In un esercizio red team più avanzato, vale la pena replicare la tecnica di tunneling usata da Agrius e OilRig: incapsulare RDP dentro un tunnel SSH o attraverso web shell. Plink (open source), il client SSH a riga di comando di PuTTY, crea un tunnel locale che mappa una porta arbitraria verso la 3389 del target:

plink.exe -ssh -L 13389:10.0.0.5:3389 user@pivot-host

Una volta stabilito il tunnel, basta puntare mstsc.exe verso localhost:13389 per raggiungere il target attraverso il pivot. Questa tecnica riproduce esattamente l'approccio documentato per Agrius, che tunnelizzava traffico RDP attraverso web shell deployate nell'ambiente vittima.

Per testare scenari di hijacking di sessioni RDP già attive — una tecnica particolarmente insidiosa — il comando nativo tscon.exe consente, con privilegi SYSTEM, di agganciare una sessione disconnessa senza conoscere la password dell'utente:

tscon <session_id> /dest:console

L'ID di sessione si ottiene con query user o qwinsta. Questo scenario dimostra perché le sessioni disconnesse rappresentino un rischio concreto, ed è direttamente collegato alla mitigazione che raccomanda timeout aggressivi sulle sessioni RDS.

Per ambienti dove si vuole simulare l'abilitazione remota di RDP (come faceva APT3 per la persistenza), il registro di sistema si modifica con:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

seguito dall'apertura della porta nel firewall locale:

netsh advfirewall firewall set rule group="Remote Desktop" new enable=yes

La detection dell'abuso di RDP è un esercizio di correlazione, non di singolo evento. Un logon RDP legittimo è identico a uno malevolo — la differenza sta nel contesto: chi si collega, da dove, verso quale sistema, e cosa fa nei minuti successivi.

La strategia di rilevamento multi-evento documentata (DET0327) è il punto di partenza corretto. L'idea è correlare un logon RDP con l'attività post-accesso entro una finestra temporale ristretta, tipicamente 5 minuti. I log essenziali sono due: WinEventLog:Security e WinEventLog:Sysmon.

Sul fronte Security, gli eventi cardine sono EventCode 4624 con Logon Type 10 (RemoteInteractive), che segna l'inizio della sessione, e EventCode 4625 per i tentativi falliti. Il campo Source Network Address in questi eventi rivela l'IP sorgente del client RDP. Un alert efficace confronta questa coppia (utente + IP sorgente) con una baseline di connessioni note. Quando la campagna C0018 (AvosLocker) utilizzava porte non standard come 28035, 32467, 41578 e 46892 per le connessioni RDP, un monitoraggio del traffico di rete su porte anomale con protocollo RDP avrebbe immediatamente generato un segnale.

Per la correlazione post-login, Sysmon offre la granularità necessaria. EventCode 1 (Process Create) cattura l'esecuzione di processi sospetti avviati durante la sessione RDP. La lista da monitorare include cmd.exe, powershell.exe e certutil.exe, come indicato nel tuning della detection. Quando Wizard Spider accedeva via RDP per deployare ransomware interattivamente, la sequenza logon RDP → esecuzione di tool di cifratura era il pattern da intercettare.

Il tuning dei falsi positivi richiede attenzione su tre dimensioni. La prima è il contesto utente: gli account di servizio e gli amministratori di sistema che usano RDP quotidianamente vanno inseriti in whitelist per host specifici, non in blanket. La seconda è il pattern di accesso host-to-host: una connessione RDP da una workstation a un domain controller, come quelle operate da Volt Typhoon, dovrebbe avere una soglia di alerting molto bassa. La terza riguarda la frequenza temporale: burst di connessioni RDP verso più host in rapida successione sono indicativi di lateral movement automatizzato.

Sul piano dei controlli preventivi, il log Microsoft-Windows-TerminalServices-LocalSessionManager/Operational registra gli eventi EventCode 21 (logon riuscito) e EventCode 25 (reconnessione), completando la visibilità sulle sessioni. Per le connessioni in uscita, EventCode 1024 nel log Microsoft-Windows-TerminalServices-RDPClient/Operational registra ogni tentativo di connessione dal client, rivelando anche i target che un attaccante sta esplorando.

Un controllo SIEM pratico combina questi elementi: alert quando un utente non presente nel gruppo Remote Desktop Users effettua un logon Type 10, oppure quando un account privilegiato esegue sessioni RDP verso più di tre host distinti in un'ora.

L'analisi forense di un'intrusione basata su RDP beneficia di una ricchezza di artefatti che pochi altri protocolli di lateral movement lasciano. Il sistema operativo Windows registra le sessioni RDP su entrambi i lati — sorgente e destinazione — fornendo una mappa navigabile dei movimenti dell'attaccante.

Sul sistema destinazione, la prima fonte è il registro Security con EventCode 4624 Logon Type 10. Ogni record contiene il nome utente, il dominio, l'IP sorgente e il timestamp preciso. Incrociando questi dati con EventCode 4634 (logoff) o EventCode 4779 (session disconnect), si ricostruisce la durata esatta di ogni sessione. Il log TerminalServices-LocalSessionManager aggiunge dettaglio con EventCode 21 (Session logon succeeded) e EventCode 24 (Session has been disconnected), dove quest'ultimo è particolarmente rilevante: sessioni disconnesse ma non terminate possono essere ri-agganciate senza autenticazione se non sono configurati timeout adeguati.

Il registro di Windows conserva traccia anche nella chiave HKCU\Software\Microsoft\Terminal Server Client\Servers, che elenca i target RDP a cui il sistema si è connesso, con l'ultimo username utilizzato per ciascuno. Sul sistema sorgente, questa chiave è una miniera: se un attaccante ha usato una workstation compromessa come pivot (come nella SolarWinds Compromise, dove APT29 usava RDP da sistemi pubblici verso server interni), la chiave contiene l'elenco dei server raggiunti.

Un secondo artefatto critico è il file Bitmap Cache di RDP, posizionato in %LOCALAPPDATA%\Microsoft\Terminal Server Client\Cache. Questi file (bcache*.bmc e cache*.bin) contengono frammenti di screenshot delle sessioni remote. Tool come bmc-tools (open source) di ANSSI decodificano questi file in immagini navigabili, ricostruendo visivamente ciò che l'attaccante ha visto e operato durante la sessione. In un caso come quello di Blue Mockingbird, che copiava manualmente file attraverso sessioni RDP, la bitmap cache potrebbe rivelare esattamente quali file sono stati trasferiti.

Per la timeline, la sequenza forense tipica di un lateral movement RDP è:

1. EventCode 4624 Type 10 sul target — marca il momento di ingresso
2. EventCode 1 Sysmon sul target — processi avviati nella sessione (il campo LogonId correla processo e sessione)
3. EventCode 5156 Security — connessione di rete sulla porta 3389 con dettagli IP/porta
4. Prefetch files sul target — mstsc.exe e qualsiasi tool eseguito durante la sessione
5. EventCode 4779/4634 — disconnessione o logoff

Nella campagna HomeLand Justice, dove RDP era il metodo primario di lateral movement per 14 mesi, questa sequenza ripetuta su decine di host avrebbe rivelato il pattern di espansione degli attaccanti iraniani. L'analisi degli ShimCache e AmCache per mstsc.exe sui sistemi sorgente aggiunge un'ulteriore conferma temporale dell'attività.

Per ambienti Linux dove xrdp è in uso, i log si trovano in /var/log/xrdp.log e /var/log/xrdp-sesman.log, con autenticazione registrata anche in /var/log/auth.log.

Con 35 gruppi documentati, T1021.001 è una delle tecniche più trasversali dell'intero framework. La sua adozione attraversa confini geografici, motivazioni e livelli di sofisticazione, ma emergono pattern analitici significativi.

Volt Typhoon (G1017) rappresenta il paradigma dell'attore nation-state che privilegia le tecniche living-off-the-land. Il suo uso di RDP per raggiungere il Domain Controller con credenziali di domain admin evidenzia un approccio chirurgico: non disperde movimenti laterali, ma punta direttamente all'asset più critico. Questo pattern è coerente con le operazioni di pre-posizionamento su infrastrutture critiche attribuite ad attori cinesi, dove l'obiettivo è mantenere accesso persistente senza generare rumore.

Sul fronte iraniano, tre gruppi mostrano un uso evoluto di RDP. OilRig (G0049) non si limita a connettersi: tunnelizza il traffico RDP per superare segmentazioni di rete, indicando una maturità operativa elevata. Agrius (G1030) porta il concetto oltre, incapsulando RDP attraverso web shell e usando Plink per tunnel SSH — una catena di strumenti che rivela pianificazione pre-operativa. Fox Kitten (G0117) completa il trittico iraniano, combinando il targeting di credenziali RDP con il lateral movement, un approccio che suggerisce playbook condivisi tra gli attori di Teheran. Il pattern è chiaro: gli attori iraniani investono nel tunneling perché operano spesso in ambienti con segmentazione di rete più matura.

Il cluster ransomware merita un'analisi separata. Wizard Spider (G0102), Akira (G1024), BlackByte (G1043), e INC Ransom (G1032) usano tutti RDP come vettore primario di lateral movement. La differenza rispetto agli attori statali è la velocità: il ransomware richiede espansione rapida prima della detonazione. Wizard Spider in particolare è documentato nell'uso di RDP per il deployment interattivo del payload, un modus operandi che implica operatori umani alla tastiera, non automazione.

I gruppi FIN (FIN6, FIN7, FIN8, FIN10, FIN13) mostrano una concentrazione notevole su questa tecnica, con cinque dei gruppi FIN catalogati. Essendo attori motivati finanziariamente, il pattern suggerisce che RDP sia percepito come il metodo a minor costo operativo per muoversi in reti enterprise, dove è quasi sempre abilitato.

Le 7 campagne documentate coprono un arco che va da operazioni supply chain sofisticate (SolarWinds Compromise, C0024, dove APT29 usava RDP da sistemi pubblici verso l'interno) a intrusioni ransomware dirette (C0015 con il playbook Conti, C0018 con AvosLocker su porte non standard). La APT28 Nearest Neighbor Campaign (C0051) aggiunge una dimensione inedita: l'uso di reti Wi-Fi adiacenti per raggiungere l'ambiente target prima di procedere con RDP per il lateral movement, dimostrando che anche attori altamente sofisticati considerano RDP il metodo più affidabile una volta dentro la rete.

Il trend proiettivo indica che RDP rimarrà un pilastro del lateral movement. La crescita del tunneling (documentata per almeno 3 gruppi) suggerisce che le difese perimetrali vengono bypassate incapsulando il protocollo in canali legittimi — un'evoluzione che sposta la detection dalla rete all'endpoint.

Framework MITRE ATT&CK: T1021.001, TA0008. Campagne: C0024 (SolarWinds Compromise), C0018, C0029 (Cutting Edge), C0032, C0038 (HomeLand Justice), C0051 (APT28 Nearest Neighbor Campaign), C0015. Detection: DET0327, AN0931. Integrato con conoscenza professionale per tool e procedure operative.