Dirottamento Sessioni Remote: Remote Service Session Hijacking (T1563)

Nell'ambito di un esercizio red team autorizzato, il dirottamento di sessione richiede privilegi elevati sull'host bersaglio. Su Windows il vettore storico è RDP session hijacking tramite il comando nativo tscon.exe, che consente a un processo SYSTEM di collegarsi a una sessione RDP disconnessa senza richiedere password. La catena tipica prevede l'enumerazione delle sessioni con query user (o qwinsta), l'ottenimento di un contesto SYSTEM tramite PsExec (open source, Sysinternals) con il flag -s -i, e il collegamento alla sessione target con tscon /dest:<current_session>.

Un'alternativa consiste nel creare un servizio che esegua tscon come SYSTEM, tecnica documentata pubblicamente da Alexander Korznikov. Framework come Impacket (open source) e CrackMapExec/NetExec (open source) permettono di orchestrare l'enumerazione delle sessioni attive via WMI e RPC. Su ambienti di dominio, BloodHound (open source) evidenzia i path in cui un utente compromesso può raggiungere un host dove è connesso un Domain Admin, rendendo il session hijacking uno step di privilege escalation di fatto.

Su Linux la tecnica principale sfrutta screen e tmux: se un utente ha una sessione screen attiva con permessi permissivi, un attaccante con l'utenza corrispondente (o con root) può attaccarsi via screen -x .. o tmux attach -t . Con privilegi root è possibile intercettare direttamente i pseudo-terminali leggendo /dev/pts/N o utilizzando strace -p -e read,write sul processo shell della vittima per catturare input/output in tempo reale. Il tool injectso e la tecnica di ptrace injection consentono di iniettare comandi in shell SSH già stabilite, mentre il riuso di socket di ssh -M con ControlMaster attivo permette di piggyback su connessioni multiplexate senza credenziali (ssh -S <control_path> user@target).

Su macOS scenari analoghi si presentano con sessioni VNC (Screen Sharing) e SSH multiplexate. In laboratorio è utile validare la tecnica in un range isolato con host Windows Server 2019+, workstation Linux con screen/tmux preinstallati e endpoint macOS con Screen Sharing abilitato, misurando quali eventi di logging vengono effettivamente generati (spoiler: molti meno di quanto ci si aspetti).

La detection del session hijacking è comportamentale più che signature-based, perché gli strumenti utilizzati (tscon, screen, tmux, ssh) sono binari legittimi e ampiamente presenti negli ambienti enterprise. Il principio guida è la discrepanza tra evento di autenticazione e attività di sessione: comandi eseguiti in un contesto utente senza un corrispondente logon recente, oppure prosecuzione improvvisa di sessioni dormienti.

Su Windows, le fonti primarie sono WinEventLog:Security e WinEventLog:Sysmon. Un pattern ad alta fedeltà per tscon abuse è la sequenza EventID 7045 (installazione servizio) o 4697 con binary path contenente tscon.exe, seguita da EventID 4778 (Session reconnected) senza un precedente EventID 4624 con logon type 10 (RemoteInteractive) per lo stesso utente target. Sysmon Event ID 1 (Process Create) con ParentImage services.exe e CommandLine contenente tscon è un indicatore quasi deterministico. Va monitorata anche l'attivazione di RDP Shadowing (chiavi di registro sotto HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services e uso di mstsc.exe /shadow), che se attivata senza consenso dell'utente costituisce un chiaro segnale di takeover.

Su Linux le fonti chiave sono auditd:SYSCALL e i log di sessione. Correlare auth.log (o /var/log/secure) con l'output di who/w e con syscall ptrace, open su */dev/pts/**, e execve generate da PID di sessioni preesistenti permette di individuare attach anomali. Un alert efficace scatta quando processi con parent screen o tmux eseguono comandi con UID diverso da quello del proprietario originale della sessione. NSM:Flow e NSM:Connections aiutano a identificare traffico SSH con pattern anomali, come sessioni ControlMaster riutilizzate da host non previsti.

Su macOS macos:unifiedlog con subsystem com.apple.screensharing e com.apple.sessionagent espone eventi di takeover VNC. Un parametro di tuning cruciale è SessionIdleThreshold: sessioni idle per ore che riprendono attività di comando ad alto volume sono candidate prioritarie per triage.

I falsi positivi più comuni derivano da amministratori che usano legittimamente RDP Shadowing per supporto, tool di monitoring che si agganciano a sessioni tmux condivise, e sessioni di screen multi-utente in ambienti DevOps. Una whitelist basata su ExpectedUserSessionMap (mapping utente-host previsti) e su finestre temporali di attività lecita riduce sensibilmente il rumore.

L'analisi forense di un session hijacking richiede la ricostruzione precisa della timeline di sessione, perché l'artefatto principale è un'assenza: manca un evento di autenticazione dove ci si aspetterebbe di trovarlo. Su Windows la triade fondamentale è Security.evtx, Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.evtx e Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational.evtx. Gli EventID rilevanti sono 21 (session logon), 22 (shell start), 24 (session disconnected), 25 (session reconnection) e 4778/4779 per riconnessione e disconnessione di sessioni via Winstation. La discrepanza tra un EventID 25 privo di un corrispondente EventID 21 recente indica takeover.

È essenziale acquisire anche il Registry hive SYSTEM per estrarre servizi creati temporaneamente (ControlSet\Services), spesso residui della tecnica tscon-as-SYSTEM. Strumenti come KAPE (gratuito per uso non commerciale), Velociraptor (open source) e EricZimmermanTools (open source, in particolare EvtxECmd e RegistryExplorer) permettono un triage rapido. Il file NTUSER.DAT dell'utente vittima può rivelare comandi eseguiti tramite UserAssist e RecentDocs in orari incompatibili con la sua presenza fisica.

Su Linux gli artefatti chiave sono /var/log/auth.log, /var/log/wtmp e /var/log/btmp (letti con last, lastb, utmpdump), il file ~/.bash_history con timestamp abilitati (HISTTIMEFORMAT), e i socket screen in /var/run/screen/S-/ o tmux in /tmp/tmux-/. La presenza di socket ControlMaster SSH in ~/.ssh/ (path definito da ControlPath) suggerisce potenziali punti di piggyback. Log auditd configurati con regole su syscall ptrace forniscono evidenza diretta di injection in processi shell.

Su macOS il Unified Logging System (log show --predicate) è la fonte primaria. Sottosistemi come com.apple.SessionAgent, com.apple.loginwindow e com.apple.screensharing registrano eventi di connessione VNC. Artefatti supplementari includono /var/log/asl/ (deprecato ma ancora presente su versioni legacy), /var/db/diagnostics/ e il database FSEvents per attività filesystem contestuali.

La timeline deve correlare eventi di rete (NSM:Flow, netflow, log del firewall) con eventi endpoint. Sessioni RDP/SSH senza il corrispondente TCP handshake nell'intervallo di autenticazione previsto sono red flag. Preservare memoria RAM con WinPmem/LiME (entrambi open source) è cruciale: token di sessione, handle a winsta0 e strutture tty residenti in memoria possono confermare il takeover anche quando i log sono stati manomessi.

Non essendo presenti gruppi APT, software o campagne mappati nei dati MITRE forniti per questa tecnica, l'analisi di threat intelligence si concentra su considerazioni strutturali derivate dalle mitigazioni e dalle logiche di detection documentate.

Remote Service Session Hijacking è una tecnica ad alta maturità operativa: richiede accesso privilegiato preesistente sull'host che ospita la sessione bersaglio, il che la colloca in fasi avanzate della kill chain, tipicamente dopo credential access e privilege escalation. Questo profilo è coerente con attori che operano con obiettivi di lateral movement stealth, dove l'esigenza primaria è evitare la generazione di nuovi eventi di autenticazione che potrebbero attivare controlli MFA o alert su logon anomali.

Dal punto di vista dell'esposizione, gli ambienti a più alto rischio sono quelli che concentrano sessioni privilegiate su un numero limitato di host: jump server, Privileged Access Workstation (PAW) mal configurate, terminal server condivisi da amministratori di dominio, bastion host cloud. Un attaccante che compromette uno di questi nodi può ereditare in cascata privilegi di più identità senza mai possedere le relative credenziali. Il pattern è particolarmente rilevante in contesti di managed service provider e outsourcing IT, dove operatori esterni mantengono sessioni RDP/SSH persistenti verso multipli clienti.

La tecnica ha rilevanza strategica in scenari di ransomware operator che, dopo compromissione iniziale via phishing o exploit perimetrale, cercano il percorso più rapido verso Domain Admin. L'osservazione di tscon eseguito da SYSTEM su un jump server è un indicatore predittivo di imminente escalation a livello di dominio. In ambienti OT/ICS il rischio si estende a sessioni verso HMI e engineering workstation, con potenziali impatti safety.

Le cinque mitigazioni MITRE convergono su un principio: ridurre la superficie di sessioni ereditabili. M1030 (Network Segmentation) limita gli host da cui è possibile raggiungere target sensibili; M1042 (Disable or Remove Feature) suggerisce di disabilitare RDP/SSH dove non strettamente necessari; M1026 (Privileged Account Management) raccomanda di non usare account privilegiati per accesso remoto se non indispensabile; M1018 (User Account Management) e M1027 (Password Policies) rafforzano l'igiene identity generale.

Il trend difensivo verso soluzioni PAM con session brokering (CyberArk, BeyondTrust, Thycotic — tutti a pagamento) e Just-In-Time access (Azure PIM, AWS IAM session constraints) risponde direttamente a questa minaccia: se le sessioni privilegiate esistono solo per la durata strettamente necessaria e sono mediate da un broker che registra ogni comando, la finestra di opportunità per il hijacking si riduce drasticamente. L'adozione di Zero Trust Network Access con re-autenticazione continua rappresenta l'evoluzione naturale della difesa contro questa classe di attacchi.

MITRE ATT&CK: T1563 (Remote Service Session Hijacking), tattica TA0008. Mitigazioni M1018, M1026, M1027, M1030, M1042. Detection DET0079 con analitiche AN0216 (Windows), AN0217 (Linux), AN0218 (macOS). MITRE D3FEND per mapping tecniche difensive. Il contenuto integra conoscenza professionale di cybersecurity per comandi operativi, tool di detection/forensics e procedure di laboratorio, nel rispetto delle regole di verificabilità e citazione dei tool reali con relativo modello di licenza.