Web shell: cosa sono, perché sono pericolose e come prevenirle

Le web shell sono uno dei segnali più seri di compromissione di un sito web. Possono rimanere nascoste mentre il sito continua a funzionare, permettere accessi non autorizzati al server e trasformare una vulnerabilità applicativa in un problema di sicurezza molto più ampio.

In questa guida vediamo cosa sono le web shell, perché sono pericolose, quali errori le rendono possibili, quali segnali cercare nei log e quali misure adottare per prevenirle. L’obiettivo è difensivo: capire il rischio, migliorare la configurazione e sapere come ragionare se un sito viene compromesso.

Questo articolo chiude la serie iniziata dalle URL e proseguita con DNS, protezione del dominio, TOTP, 2FA e MFA. Dopo aver parlato di identità e accesso utente, qui guardiamo il lato server: cosa succede quando non è l’account a essere il primo problema, ma il sito stesso.

Che cos’è una web shell

Una web shell è un file, uno script o un componente presente su un server web che permette a un attaccante di eseguire azioni non autorizzate tramite richieste HTTP.

Il nome richiama la shell di sistema, cioè l’ambiente usato per inviare comandi a un sistema operativo. Nel caso di una web shell, l’interazione non avviene da un terminale locale, ma attraverso il web: una richiesta verso un file o un endpoint può diventare un modo per leggere file, modificare contenuti, caricare altri strumenti o mantenere accesso al server.

Non serve immaginare scenari cinematografici. Una web shell può essere anche un file apparentemente innocuo depositato in una directory pubblica, un plugin compromesso, un tema modificato o un componente caricato dopo aver sfruttato una vulnerabilità.

In questo articolo non mostro codice di web shell e non descrivo procedure offensive. Per la difesa, però, è essenziale capire il modello: un file che il server tratta come codice può diventare un punto di controllo se viene salvato nel posto sbagliato, con permessi sbagliati o dentro un’applicazione vulnerabile.

Come arriva una web shell su un sito

Una web shell di solito non compare dal nulla. È spesso il risultato di una catena di errori tecnici, configurazioni deboli o credenziali compromesse.

Le strade più comuni sono:

• upload non sicuri, quando un form permette di caricare file senza verifiche robuste;
• CMS, plugin o temi non aggiornati, specialmente in ecosistemi molto diffusi;
• credenziali rubate, riutilizzate o prive di MFA su pannelli amministrativi;
• permessi troppo larghi su file e directory del sito;
• pannelli di gestione esposti senza protezioni adeguate;
• backup, file temporanei o configurazioni lasciati nella web root;
• vulnerabilità note non corrette in framework, librerie o componenti server.

Un caso tipico riguarda l’upload di immagini o documenti. L’utente dovrebbe poter caricare un PDF, una foto o un allegato. Se però l’applicazione controlla solo l’estensione del file, salva il contenuto in una cartella eseguibile e permette di richiamarlo dal browser, un attaccante può provare a trasformare un caricamento in esecuzione di codice.

Il punto chiave è questo: i file caricati dagli utenti devono essere trattati come dati non fidati, mai come codice.

Perché le web shell sono pericolose

Una web shell è pericolosa perché può essere silenziosa. Il sito può continuare a funzionare normalmente: le pagine si aprono, il carrello risponde, il form contatti invia email, il blog pubblica contenuti. Nel frattempo, però, qualcuno potrebbe avere un accesso non autorizzato.

Con quell’accesso, a seconda dei privilegi disponibili, un attaccante potrebbe:

• leggere file applicativi, configurazioni e credenziali;
• modificare pagine, template o contenuti del sito;
• caricare altri file malevoli;
• inviare spam o phishing dal server;
• usare il sito come punto di appoggio per altri attacchi;
• muoversi verso database, servizi interni o altri host;
• cancellare o alterare log per rendere più difficile l’analisi;
• mantenere persistenza anche dopo una pulizia superficiale.

Il defacement, cioè la modifica visibile della home page, è l’impatto più evidente. Non è però sempre il più grave. Se l’obiettivo è rubare dati, usare risorse del server o restare nascosti a lungo, l’attaccante ha interesse a non farsi notare.

Web shell e upload non sicuro

L’upload di file è una delle funzioni più delicate in un’applicazione web. Ogni volta che un sito permette a utenti, clienti, editor o amministratori di caricare contenuti, bisogna progettare quella funzione pensando alla sicurezza.

Le domande fondamentali sono:

• quali tipi di file sono consentiti?
• il controllo avviene solo sull’estensione o anche sul contenuto?
• i MIME type vengono verificati lato server?
• il file viene rinominato con un nome generato dal sistema?
• la directory di upload permette l’esecuzione di script?
• i file sono salvati dentro o fuori dalla web root?
• ci sono limiti di dimensione, numero e frequenza degli upload?
• gli eventi anomali vengono registrati nei log?
• l’accesso ai file caricati è autorizzato o pubblico per chiunque?

Fidarsi solo del nome è un errore. Un file chiamato immagine.jpg non è automaticamente un’immagine valida. Il server deve verificare il contenuto, normalizzare il nome, rimuovere metadati non necessari quando opportuno e salvare il file in un contesto in cui non possa essere interpretato come codice.

Per un upload immagini, una configurazione più robusta prevede di validare davvero il formato, generare un nuovo nome, salvare il file fuori dalla directory eseguibile e servirlo tramite un endpoint controllato o da uno storage configurato per distribuire solo contenuti statici.

CMS, WordPress, plugin e siti piccoli

Molti incidenti non nascono da un attacco mirato contro una singola azienda. Nascono da scansioni automatiche su Internet: bot che cercano versioni vulnerabili di CMS, plugin, temi, pannelli o endpoint noti.

Questo riguarda in particolare strumenti molto diffusi come WordPress, Joomla, Drupal, plugin e-commerce, page builder, file manager web e pannelli di amministrazione. Non perché questi strumenti siano automaticamente insicuri, ma perché la loro diffusione crea incentivo ad automatizzare la ricerca di installazioni non aggiornate.

Un sito piccolo non è invisibile. Se espone una vulnerabilità nota, una password debole o una configurazione standard rischiosa, può essere trovato anche senza che qualcuno conosca il brand o il progetto.

Per questo la sicurezza di un CMS non dipende solo dall’installazione iniziale. Dipende da aggiornamenti, rimozione dei plugin inutilizzati, backup verificati, account amministrativi protetti, permessi corretti e monitoraggio dei log.

Segnali di una possibile web shell

Riconoscere una web shell non è sempre immediato, ma ci sono segnali che meritano attenzione.

Possibili indicatori sono:

• file nuovi o modificati in cartelle dove non dovrebbero esserci;
• file con nomi simili a file legittimi, ma leggermente diversi;
• script dentro directory che dovrebbero contenere solo immagini, PDF o asset statici;
• richieste HTTP anomale verso cartelle di upload;
• processi inattesi avviati dall’utente del web server;
• connessioni in uscita non previste;
• picchi improvvisi di traffico, CPU o invio email;
• errori ripetuti nei log applicativi;
• log mancanti, troncati o modificati;
• nuovi utenti amministratori o modifiche non autorizzate ai permessi.

Nessuno di questi segnali, da solo, prova automaticamente la presenza di una web shell. Insieme, però, aiutano a costruire una diagnosi e a decidere se avviare una risposta all’incidente.

Controlli difensivi da terminale

Senza fare attività offensive, ci sono controlli utili per orientarsi su un server Linux. I percorsi cambiano in base alla distribuzione e alla configurazione, ma il principio resta lo stesso: cercare modifiche recenti, file sospetti, permessi e accessi anomali.

Per vedere file modificati di recente nella web root:

find /var/www -type f -mtime -2

Per cercare file PHP in una cartella che dovrebbe contenere solo upload statici:

find /var/www/uploads -type f -name "*.php"

Per individuare file o directory scrivibili da tutti:

find /var/www -type f -perm -o+w
find /var/www -type d -perm -o+w

Per leggere gli ultimi log del web server:

sudo tail -n 100 /var/log/nginx/access.log
sudo tail -n 100 /var/log/apache2/access.log

Per cercare richieste verso una directory di upload:

grep "/uploads/" /var/log/nginx/access.log
grep "/uploads/" /var/log/apache2/access.log

Questi comandi non bastano per una diagnosi completa e non sostituiscono un’analisi forense. Servono però a fare domande migliori: quali file sono cambiati, quali URL sono state chiamate, quali permessi sono eccessivi, quali eventi non tornano.

Come prevenire le web shell

La prevenzione delle web shell richiede più livelli. Non esiste un singolo controllo che risolve tutto.

Le misure più importanti sono:

• validare gli upload lato server, controllando contenuto, formato, dimensione e tipo consentito;
• disabilitare l’esecuzione di script nelle directory di upload;
• salvare i file caricati fuori dalla web root quando possibile;
• rinominare i file con identificatori generati dal server;
• applicare il principio del minimo privilegio su utenti, processi, file e directory;
• aggiornare CMS, plugin, temi, framework e runtime;
• rimuovere componenti inutilizzati, perché ciò che non serve aumenta solo la superficie d’attacco;
• proteggere account amministrativi con MFA, soprattutto su hosting, CMS, DNS, repository e cloud;
• monitorare log e integrità dei file;
• verificare i backup e i ripristini, non solo la loro esistenza;
• separare ambienti e responsabilità, evitando che un’applicazione compromessa abbia accesso a tutto.

Un Web Application Firewall può aiutare a bloccare pattern noti e richieste sospette, ma non deve diventare una scusa per lasciare vulnerabile l’applicazione. Il WAF è un livello in più, non un sostituto di codice sicuro, aggiornamenti e configurazione corretta.

Cosa fare se sospetti una web shell

Se sospetti una web shell, la risposta non dovrebbe essere soltanto: “cancello il file strano”.

Rimuovere il file può essere necessario, ma non basta. Bisogna capire come è entrato, cosa ha fatto e se ha lasciato altri accessi. Altrimenti si rischia di eliminare il sintomo lasciando aperta la causa.

Le domande da porsi sono:

• quale vulnerabilità o credenziale ha permesso l’accesso?
• da quanto tempo il file era presente?
• quali richieste lo hanno usato?
• quali file sono stati letti o modificati?
• sono stati creati nuovi utenti o token?
• ci sono cron job, servizi o processi inattesi?
• sono state esfiltrate credenziali, database o configurazioni?
• i backup precedenti sono puliti e ripristinabili?

In un contesto professionale, la risposta deve includere preservazione dei log, rotazione delle credenziali, aggiornamento dei componenti vulnerabili, verifica degli account, controllo delle connessioni in uscita e documentazione dell’incidente.

Il collegamento con URL, DNS, 2FA e MFA

Questo episodio chiude il percorso della serie perché mette insieme i livelli precedenti.

Una URL sospetta può portare a un pannello falso. Un DNS compromesso può mandare utenti e amministratori verso il posto sbagliato. Un account senza MFA può dare accesso al pannello di gestione. Un plugin non aggiornato può permettere un upload malevolo. Una configurazione debole può trasformare quell’upload in esecuzione di codice.

La sicurezza web non è un singolo muro. È una sequenza di livelli: dominio, DNS, TLS, identità, autenticazione, autorizzazioni, applicazione, server, permessi, log, backup e procedure.

Ogni livello può ridurre il rischio. Ogni livello trascurato può diventare il punto da cui parte l’attacco successivo.

FAQ sulle web shell

Una web shell è sempre un malware?

Nel contesto di un sito compromesso, una web shell è da trattare come codice malevolo o non autorizzato. Il punto non è solo il file in sé, ma l’accesso che abilita e le azioni che potrebbe permettere.

Una web shell può colpire anche WordPress?

Sì. WordPress, come qualunque CMS, può essere esposto se plugin, temi o core non sono aggiornati, se gli account amministrativi sono deboli, se i permessi sono sbagliati o se una funzione di upload è configurata male.

Basta cancellare la web shell per risolvere?

No. Cancellare il file può rimuovere un sintomo, ma bisogna individuare la causa: vulnerabilità sfruttata, credenziali usate, file modificati, eventuale persistenza e dati coinvolti.

Come posso ridurre il rischio negli upload?

Valida il contenuto lato server, limita i formati ammessi, rinomina i file, salva gli upload fuori dalla web root quando possibile, disabilita l’esecuzione di script nelle directory di upload e registra eventi anomali.

Un WAF protegge dalle web shell?

Un WAF può aiutare, ma non basta. La protezione efficace richiede codice sicuro, aggiornamenti, permessi minimi, monitoraggio dei log, MFA sugli account amministrativi e procedure di backup verificate.

Conclusione

All’inizio della serie una URL sembrava solo un indirizzo. Ora sappiamo che dietro quella riga ci sono protocolli, domini, DNS, cifratura, identità, autenticazione, applicazioni, server, configurazioni e responsabilità operative.

Le web shell mostrano cosa succede quando più livelli vengono trascurati. Un upload validato male, un plugin non aggiornato, un account senza MFA, una directory eseguibile, un log mai guardato: dettagli apparentemente separati possono sommarsi fino a diventare compromissione.

La buona notizia è che vale anche il contrario. Leggere le URL, proteggere DNS e account, usare 2FA o MFA adeguate, aggiornare software, limitare permessi, monitorare file e log, verificare i backup e documentare le procedure crea resilienza.

Questa non è paranoia. È manutenzione responsabile.

Un sito non viene protetto nel momento dell’incidente. Viene protetto nei mesi prima, con scelte tecniche solide, controlli continui e attenzione ai dettagli che nessuno vede quando tutto funziona.

Capitoli

• 00:04 LINK episodio 1
• 00:16 LINK ep2
• 00:28 LINK ep3
• 00:38 LINK ep4 e 5
• 01:00 La domanda dell’episodio
• 01:21 Che cos’è una web shell?
• 01:32 Una strada possibile: upload debole
• 02:10 Altre vie di ingresso
• 02:33 Il sito può sembrare normale
• 03:25 Impatti possibili
• 03:57 Domande per ogni upload
• 04:31 Dati, non codice
• 04:55 Controlli difensivi: file recenti
• 05:37 Controlli difensivi: permessi
• 05:57 Un sito piccolo non è invisibile
• 06:45 Configurazione debole
• 07:09 Barriere pratiche
• 07:52 Segnali da investigare
• 08:21 Guardare i log
• 08:39 Anche systemd può aiutare
• 09:02 WAF: un livello, non una scusa
• 09:16 Non basta cancellare il file
• 09:43 La catena della serie
• 10:18 Domande dopo l’incidente
• 11:45 Misure pratiche
• 12:38 Dietro una URL
• 13:03 Resilienza
• 13:31 La sicurezza vera