FTP banner dead drop: analisi di E4del e PINHOLE RAT

Un FTP banner dead drop è una tecnica di command and control in cui un malware legge il messaggio di benvenuto restituito da un server FTP e lo interpreta come contenuto operativo, invece di usare il server solo per trasferire file. Il banner, normalmente visualizzato dopo la connessione alla porta 21, diventa così un canale di ricezione per comandi, configurazioni o indicatori che l’implant cerca periodicamente.

La tecnica associata a malware come E4del e PINHOLE RAT è interessante perché sfrutta un elemento previsto dal protocollo FTP e può confondersi con il traffico di amministrazione o trasferimento file. Non richiede necessariamente un pannello web dedicato né una risposta HTTP con un formato evidente. Per l’analista, il punto centrale è osservare la relazione tra connessioni FTP, contenuto del banner, frequenza delle richieste e comportamento dell’endpoint.

Come funziona il meccanismo

Quando un client apre una sessione FTP, il server invia normalmente una risposta simile a questa:

220 ftp.example.net FTP server ready

Il codice 220 indica che il servizio è pronto ad accettare una nuova connessione. In una configurazione legittima il testo successivo contiene informazioni descrittive, come il nome del prodotto o un messaggio amministrativo.

Un implant può invece:

aprire una connessione verso un server FTP;
leggere la risposta iniziale;
estrarre il testo del banner;
verificare un prefisso, un delimitatore o una firma;
interpretare il contenuto come comando o configurazione;
inviare un eventuale risultato attraverso una seconda connessione o un meccanismo distinto.

In questo schema il server FTP svolge il ruolo di dead drop: pubblica un contenuto che il malware può leggere, mentre il gestore dell’infrastruttura modifica il banner per distribuire nuovi dati agli endpoint compromessi.

Il canale può essere implementato in forme diverse. Il comando può essere inserito direttamente nel testo del banner, codificato in Base64 oppure preceduto da una stringa che permette al malware di distinguere un banner malevolo da una risposta ordinaria. Non è però corretto assumere che ogni testo insolito rappresenti automaticamente un comando: la conferma richiede correlazione con il processo che ha aperto la sessione e con il comportamento successivo.

E4del e PINHOLE RAT

Nelle analisi pubbliche di E4del e PINHOLE RAT, l’uso di FTP come infrastruttura di comunicazione mostra un aspetto importante: il contenuto utile per il malware può trovarsi nella risposta del server, non in un file scaricato con RETR.

Questo cambia la strategia di detection. Un controllo basato soltanto su:

upload di file sospetti;
download di eseguibili;
nomi di file noti;
comandi FTP come STOR e RETR;

può perdere una sessione in cui l’implant legge soltanto il banner iniziale.

Gli elementi da correlare sono invece:

Elemento	Osservazione utile
Connessione	destinazione esterna, porta 21 o porta FTP alternativa
Banner	testo non coerente con il servizio dichiarato, stringhe codificate o delimitatori ricorrenti
Frequenza	connessioni brevi e periodiche, spesso con intervalli regolari
Endpoint	processo che normalmente non dovrebbe usare FTP
Sequenza	connessione FTP seguita da esecuzione, modifica di configurazioni o accesso a credenziali
Risposta	uso successivo di canali DNS, HTTP o HTTPS per l’egress dei risultati

La presenza del banner non dimostra da sola una compromissione. Un apparato legacy o un servizio di laboratorio può usare messaggi personalizzati. Il valore dell’indicatore cresce quando il testo è stabile, codificato e associato a un client non autorizzato.

Indicatori di compromissione

Gli indicatori possono essere classificati in tre gruppi.

Indicatori di rete

Nei log firewall e nei flussi NetFlow cercare:

connessioni in uscita verso server FTP pubblici non presenti nell’inventario;
sessioni dalla rete server o da workstation che non hanno un requisito operativo per FTP;
connessioni con durata ridotta e intervallo regolare;
destinazioni risolte tramite domini creati di recente;
traffico FTP non cifrato verso Internet.

Il banner deve essere conservato nei log di sessione, quando il sensore o il proxy lo supporta. Un semplice log con indirizzo IP e porta non è sufficiente per analizzare la parte applicativa.

Indicatori sull’endpoint

Un client FTP non interattivo può essere legittimo, ma va associato al processo responsabile. Sono rilevanti:

processi sconosciuti che aprono socket verso la porta 21;
binari eseguiti da directory temporanee o profili utente;
task schedulati che avviano un programma con accesso alla rete;
nuove chiavi di persistenza e servizi inattesi;
processo che effettua una connessione FTP senza usare un client aziendale approvato.

Su Linux è possibile osservare le connessioni attive con:

ss -tpn | grep ':21'

Per un’indagine puntuale, è preferibile acquisire anche il percorso del binario e l’albero dei processi con strumenti EDR o con:

ps -eo pid,ppid,user,cmd --forest

Indicatori nel contenuto

Nel banner possono comparire:

stringhe Base64 o hex prive di una motivazione operativa;
lunghe sequenze senza spazi;
delimitatori ripetuti;
nomi di comando non riconducibili al prodotto FTP;
valori che cambiano in modo sincronizzato tra più endpoint.

La codifica non equivale alla cifratura. Un contenuto Base64 può essere decodificato per verificare se contiene comandi, identificativi o configurazioni. L’analisi deve essere svolta su una copia del PCAP o del log, senza inviare il contenuto a servizi esterni.

Analisi di un PCAP con Wireshark

In un ambiente di incident response, il primo filtro Wireshark può limitare la vista alle sessioni FTP:

ftp || tcp.port == 21

Per individuare la risposta iniziale del server, cercare pacchetti FTP con codice 220. Un filtro utile è:

ftp.response.code == 220

Se il dissector non identifica correttamente il traffico, si può seguire la conversazione TCP con il comando contestuale Follow > TCP Stream. Il banner apparirà generalmente all’inizio del flusso, prima della sequenza di autenticazione.

Per estrarre rapidamente gli endpoint e le risposte FTP con tshark:

tshark -r sospetto.pcapng \
  -Y 'ftp.response.code == 220' \
  -T fields \
  -e frame.time \
  -e ip.src \
  -e ip.dst \
  -e tcp.dstport \
  -e ftp.response.arg

Il campo disponibile può variare in base alla versione di Wireshark e al tipo di traffico. Per questo è utile confrontare l’output con la vista dettagliata del pacchetto.

Durante l’analisi conviene verificare:

se lo stesso banner viene restituito a più indirizzi interni;
se il testo cambia tra connessioni successive;
se la risposta contiene caratteri non stampabili o codificati;
se dopo il 220 il client invia subito QUIT, USER oppure una sequenza anomala;
se l’endpoint apre altre connessioni dopo aver letto il banner.

Un PCAP contiene dati potenzialmente sensibili. Va conservato con controlli di accesso, hash di integrità e una catena di custodia coerente con le procedure interne.

Detection con Suricata

Una regola Suricata può segnalare una stringa specifica nel banner quando esiste un indicatore confermato:

alert tcp $EXTERNAL_NET 21 -> $HOME_NET any (
    msg:"FTP banner associato a possibile dead drop";
    flow:to_client,established;
    content:"220 ";
    content:"E4D";
    distance:0;
    within:80;
    classtype:trojan-activity;
    sid:4200101;
    rev:1;
)

La firma è soltanto un esempio. Un valore come E4D può generare falsi positivi se compare in banner legittimi. In produzione è preferibile sostituirlo con una stringa osservata nell’infrastruttura analizzata, aggiungere l’IP o il dominio della destinazione solo se stabile e documentare il motivo della scelta.

Per rilevare un formato codificato non basta cercare una singola parola. Una regola più generica può individuare banner insolitamente lunghi, ma deve essere calibrata sul traffico reale:

alert tcp $EXTERNAL_NET 21 -> $HOME_NET any (
    msg:"FTP banner con possibile contenuto codificato";
    flow:to_client,established;
    content:"220 ";
    pcre:"/^220\s+[A-Za-z0-9+\/]{40,}={0,2}\r?\n/m";
    classtype:trojan-activity;
    sid:4200102;
    rev:1;
)

Questa detection non identifica Base64 con certezza e non deve essere usata come unico criterio di blocco. È più adatta a generare eventi da correlare con asset, processo e destinazione.

Contromisure per server FTP

La prima misura consiste nel rimuovere FTP dove non è necessario. Per trasferimenti amministrativi, SFTP basato su SSH o HTTPS con autenticazione forte offrono controllo e visibilità migliori. Se FTP deve restare attivo, il banner non dovrebbe contenere informazioni operative, credenziali, token o dati dinamici.

Un banner minimale riduce il contenuto disponibile a un eventuale dead drop:

220 File transfer service ready

Il testo non costituisce una difesa sufficiente, perché il malware può interpretare qualsiasi risposta. Sono necessarie misure complementari:

consentire connessioni soltanto da indirizzi o reti autorizzate;
bloccare l’accesso FTP in uscita dai client che non ne hanno bisogno;
usare FTPS quando il prodotto e l’architettura lo supportano;
disabilitare account anonimi;
applicare password uniche e autenticazione forte dove disponibile;
limitare i permessi delle directory FTP;
registrare banner, autenticazioni, comandi e indirizzi client;
aggiornare il demone FTP e rimuovere componenti inutilizzati;
monitorare modifiche alla configurazione del servizio;
separare il server FTP dalla rete interna con firewall e VLAN.

Il controllo dell’egress è particolarmente utile: un endpoint compromesso non dovrebbe poter raggiungere liberamente server FTP Internet. Le eccezioni devono essere esplicite, con destinazioni e orari documentati.

Checklist operativa per gli amministratori

Prima di considerare conclusa la revisione, verificare:

il servizio FTP è censito e ha un proprietario;
esiste una motivazione documentata per mantenerlo;
il banner non espone dati sensibili o variabili;
l’accesso anonimo è disabilitato;
le connessioni in uscita alla porta 21 sono filtrate;
i log includono client, destinazione, autenticazione e comandi;
Suricata o un sensore equivalente analizza le risposte 220;
gli alert sono correlati con telemetria EDR;
le credenziali FTP vengono ruotate dopo un sospetto incidente;
il server è aggiornato e isolato dagli asset non necessari;
esiste una procedura per acquisire e analizzare un PCAP;
i domini e gli IP sospetti sono presenti nei sistemi di threat intelligence interni.

Testing controllato

Per validare la detection si può usare un server FTP di laboratorio configurato con un banner chiaramente identificabile, senza inserire comandi reali o payload:

220 LAB-DETECTION-TEST-001

Da un host di test si apre una connessione autorizzata e si acquisisce il traffico con Wireshark o tcpdump. L’obiettivo è verificare che:

il sensore riconosca il codice 220;
il contenuto del banner venga registrato;
la regola Suricata generi un alert;
l’evento contenga asset e destinazione corretti;
l’alert non blocchi il traffico FTP legittimo non correlato.

È utile ripetere il test con banner normali, stringhe lunghe e dati codificati per misurare i falsi positivi. Il test deve rimanere confinato a sistemi controllati e non richiede l’esecuzione di E4del, PINHOLE RAT o altri malware.

Risorse

Il banner FTP è quindi un dettaglio applicativo con un possibile ruolo di C2. La detection più efficace nasce dall’unione di contenuto della risposta, periodicità delle connessioni, identità del processo e policy di egress. Ridurre la superficie FTP e mantenere telemetria sulle risposte del server rende più difficile usare il servizio come dead drop senza introdurre controlli invasivi sul traffico legittimo.