Backdoor web: controlli rapidi e bonifica iniziale

Diagnosi probabile

Una backdoor web è spesso il punto di ingresso o di persistenza dopo un compromesso di WordPress, di un altro CMS, di un hosting condiviso o di un server applicativo. Il codice malevolo può essere nascosto in file PHP, inclusioni sospette in temi e plugin, upload apparentemente innocui, cron job, account amministrativi creati di nascosto, regole di rewrite alterate o configurazioni che eseguono codice all’avvio.

La causa più comune non è un singolo “exploit misterioso”, ma una combinazione di credenziali deboli, componenti non aggiornati, plugin o temi vulnerabili, permessi eccessivi sui file, assenza di monitoraggio e mancata segmentazione dei privilegi. Se il sito mostra redirect anomali, spam SEO, file nuovi in cartelle insolite o processi che ricompaiono dopo la cancellazione, la probabilità di una backdoor è alta.

Se il problema è in produzione, la priorità non è solo pulire: bisogna prima stabilizzare, limitare la diffusione e raccogliere evidenze utili per capire come è entrato l’attaccante.

Verifiche immediate

1. Controlla i sintomi più tipici: redirect verso domini sconosciuti, pagine bianche solo in alcune aree, contenuti spam, email inviate senza autorizzazione, nuovi utenti admin, file modificati di recente. Se almeno due segnali coincidono, tratta il caso come una compromissione reale.
2. Verifica i cambi recenti nel filesystem: cerca file PHP nuovi o modificati in directory insolite come uploads, cache, cartelle temporanee, root del sito e sottocartelle di plugin. Un esito sospetto è la presenza di file con nomi casuali, timestamp recenti o codice offuscato con funzioni come base64_decode, gzinflate, str_rot13, eval, assert, shell_exec, system o passthru.
3. Controlla i log del web server e dell’applicazione per richieste anomale: POST verso file insoliti, user agent strani, accessi ripetuti a script sconosciuti, errori 403 o 404 seguiti da tentativi su file nuovi. L’obiettivo è trovare il vettore iniziale o almeno il punto di persistenza.
4. Se hai accesso al pannello hosting, verifica anche task pianificati, account FTP/SFTP, utenti CMS e regole di sicurezza attive. Un controllo rapido su questi punti spesso fa emergere la persistenza prima ancora di toccare i file.

Soluzione consigliata passo-passo

1. Isola il problema senza distruggere evidenze: metti il sito in manutenzione se possibile, limita l’accesso in scrittura alle sole attività indispensabili e disabilita temporaneamente account o chiavi non necessarie. Se lavori su hosting condiviso, avvisa il provider prima di rimuovere file sospetti, così da conservare log e snapshot.
2. Fai una copia di sicurezza prima di modificare qualsiasi cosa: archivia l’intera root del sito, il database, i log disponibili e la configurazione del virtual host o del pannello. Se possibile, crea anche uno snapshot o un backup esterno. Questa è la base per il rollback e per eventuali analisi successive.
3. Esegui una ricerca mirata dei pattern più comuni. Da terminale, partendo dalla root del sito, puoi usare un controllo prudente come il seguente per individuare funzioni sospette e file modificati di recente. Il risultato atteso è una lista ristretta di file da ispezionare manualmente, non una cancellazione automatica.

find . -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.inc' \) -mtime -30 -print
grep -RIn --exclude-dir=node_modules --exclude-dir=vendor -E 'base64_decode|gzinflate|str_rot13|shell_exec|system\(|passthru\(|eval\(|assert\(' .

Se la ricerca restituisce file in cartelle di upload, cache o path non coerenti con il CMS, considera quei file altamente sospetti e aprili prima di intervenire.

1. Confronta i file core con versioni pulite. Per WordPress, Joomla, Drupal o altri CMS, verifica l’hash o reinstalla solo i file core da sorgente ufficiale, mantenendo intatti contenuti e configurazioni. Il criterio corretto è questo: i file core devono tornare identici a quelli originali, mentre temi e plugin vanno controllati singolarmente.
2. Esamina i punti di persistenza. Controlla con attenzione .htaccess, wp-config.php, file di bootstrap, cron del sistema, task pianificati del pannello, funzioni di auto-prepend PHP, mu-plugin, plugin custom e regole nel web server. Se trovi riferimenti a script esterni, redirect condizionati o chiamate a domini sconosciuti, mettili in quarantena prima di eliminarli.
3. Bonifica in modo graduale: invece di cancellare tutto subito, sposta i file sospetti in una directory di quarantena fuori dal webroot, disabilita plugin o temi compromessi rinominando le cartelle e ripristina i file puliti da backup verificato o da pacchetto ufficiale. Dopo ogni blocco di modifica, riapri il sito e controlla che il comportamento anomalo sia sparito.
4. Ruota subito le credenziali. Cambia password di pannello hosting, FTP/SFTP, SSH, database, admin CMS, email collegate e API key usate dal sito. Se disponibili, revoca le sessioni attive e rigenera i secret del CMS. Questa operazione è fondamentale perché una backdoor spesso convive con accessi ancora validi.
5. Chiudi il vettore iniziale. Aggiorna CMS, plugin, temi, librerie e runtime PHP; rimuovi componenti non usati; limita i permessi dei file; disabilita l’upload di eseguibili dove non serve; verifica che l’utente del processo web non abbia privilegi inutili. Se il sito è in WordPress, controlla anche utenti admin sconosciuti, cron WordPress sospetti e plugin installati ma inattivi.
6. Se il sito usa cache o sistemi di deploy, svuota e ricostruisci la cache solo dopo aver verificato che i file puliti siano già in produzione. In caso contrario rischi di reintrodurre codice alterato o di nascondere la persistenza dietro contenuti statici vecchi.

Controlli finali / rollback

1. Verifica il successo della bonifica con un test concreto: nessun nuovo file sospetto creato dopo il riavvio dei servizi, nessun redirect anomalo, nessuna richiesta verso domini esterni non autorizzati, nessun utente admin sconosciuto, nessun codice offuscato residuo nei file controllati.
2. Confronta i log prima e dopo l’intervento: il traffico malevolo deve cessare o ridursi drasticamente e non devono comparire nuovi errori legati ai file ripristinati. Se il problema ricompare, il rollback corretto è ripristinare il backup pulito precedente alla bonifica e cambiare di nuovo le credenziali, perché la persistenza non è stata rimossa.
3. Se la pulizia è stabile per almeno un ciclo di controllo completo, documenta il vettore sospetto, i file toccati, le credenziali ruotate e le misure preventive applicate. Questo rende più semplice un audit successivo e riduce il rischio di reinfezione.
4. Se hai un dubbio su un file, preferisci quarantena e verifica manuale invece di cancellazione immediata: è una scelta più sicura e reversibile, soprattutto quando i log o i backup non sono ancora completi.

Assunzione operativa: il caso riguarda un sito o server web con accesso a file, log e almeno un backup recente.

Checklist rapida

• Identificare i file sospetti senza cancellarli subito
• Mettere in sicurezza backup, log e credenziali
• Ripristinare core e componenti puliti da fonte ufficiale
• Ruotare password, sessioni e chiavi
• Verificare che la persistenza non ricompaia