Recupero Drupal compromesso
Recupero di un progetto Drupal compromesso.
Analisi di codice gestito con Composer, moduli contrib e custom, temi, configurazione, utenti, file pubblici e privati, database, Drush e infrastruttura.
La risposta in breve
Quando serve: File modificati, account o ruoli sospetti, redirect, avvisi di sicurezza, moduli vulnerabili o reinfezione dopo il deploy.
Cosa valuto: Repository e composer.lock, core e moduli, codice custom, settings, configurazione attiva, utenti e ruoli, public/private files, cron, database e log.
Come iniziare: Conserva una copia tecnica e indica versione Drupal, workflow di deploy, repository disponibile, moduli recenti, sintomi e data del primo indicatore.
In Drupal il repository può aiutare a distinguere il codice atteso dalle modifiche sul server
Il confronto con Git e Composer è utile, ma non copre automaticamente files, database, configurazione attiva, credenziali, servizi esterni e altre applicazioni sullo stesso ambiente.
È il servizio adatto quando
- Differenze non autorizzate rispetto al repository o a composer.lock.
- Moduli, patch o librerie non previste dal progetto.
- Utenti, ruoli, chiavi o configurazioni modificate.
- File eseguibili nelle directory pubbliche o private.
- Route, redirect o contenuti non riconosciuti.
- Infezione che torna dopo un deploy apparentemente pulito.
Controlli Drupal specifici
Le verifiche cambiano in base al sito. Queste sono le aree che più spesso devono essere distinte prima di intervenire.
Repository e Composer
Diff del codice, lock, patch e dipendenze.
Moduli e codice custom
Vulnerabilità, modifiche e servizi esposti.
Configurazione e utenti
Config attiva, ruoli, permessi, chiavi e account.
Files e database
Directory pubbliche/private, contenuti e persistenze.
Drush, cron e log
Processi pianificati, watchdog/syslog e richieste anomale.
Come si svolge il lavoro
Copia e confronto
Preservo l’ambiente e confronto repository, Composer e filesystem.
Analisi di dati e config
Verifico utenti, ruoli, configurazione, files e database.
Deploy attendibile
Ripristino codice da sorgenti controllate e applico aggiornamenti di sicurezza.
Rotazione degli accessi
Cambio credenziali, chiavi e token coinvolti.
Rebuild e test
Eseguo update, cache rebuild e verifica di route, cron e log.
Cosa ricevi
Codice riallineato
Repository, dipendenze e file verificati.
Configurazione controllata
Utenti, ruoli e dati sensibili revisionati.
Deploy riproducibile
Sequenza documentata per ripristino e aggiornamenti.
Monitoraggio
Log, cron e segnali di nuova compromissione.
Approfondimenti utili
Pagine collegate allo stesso ambiente tecnico, selezionate per continuare il percorso senza duplicare l’intento.
Domande frequenti
È sufficiente ripristinare un backup?
Non sempre. Il backup può essere precedente all’attacco, ma può anche contenere file già alterati. Prima del ripristino occorre valutarne data, integrità e distanza temporale dai primi indicatori di compromissione.
Il sito deve essere messo offline?
Dipende dal rischio. Se distribuisce malware, esfiltra dati, invia spam o altera pagamenti, il contenimento ha priorità. In altri casi può essere possibile limitare l’accesso mantenendo una pagina di servizio.
Puoi garantire che il sito non verrà più attaccato?
Nessun intervento può azzerare il rischio. Il lavoro serve a rimuovere le persistenze individuate, correggere la causa nota, ridurre la superficie esposta e predisporre monitoraggio e procedure di aggiornamento.
Gestisci anche incidenti con dati personali o pagamenti?
Posso intervenire sul sito e sull’infrastruttura tecnica. Quando l’incidente coinvolge dati personali, carte o obblighi di notifica, è necessario coordinarsi anche con responsabili privacy, legali, provider di pagamento e specialisti di sicurezza qualificati.
Passo successivo
Il progetto Drupal mostra modifiche o accessi non autorizzati?
Indica versione, repository, workflow di deploy, sintomi e log disponibili. Conserva una copia prima di eseguire un nuovo deploy.