Documentazione tecnica di un intervento reale WpSupporto: richiesta ricevuta, analisi, diagnosi, intervento e verifiche finali.
Questo documento descrive un intervento realmente eseguito dal team WpSupporto. Per tutelare la privacy del cliente, alcuni dettagli identificativi possono essere stati anonimizzati senza alterare la natura tecnica del caso.
WpSupporto è stato contattato per intervenire su un eCommerce realizzato con WordPress e WooCommerce che presentava evidenti anomalie a livello dell’installazione. Durante le prime verifiche era già emersa la presenza di un file index.php compromesso e il sito mostrava inoltre problemi che impedivano di eseguire normalmente alcune operazioni amministrative, tra cui l’installazione e la gestione dei plugin.
La situazione richiedeva un’analisi più ampia rispetto alla semplice sostituzione del file inizialmente individuato. Su un eCommerce in produzione, infatti, la presenza di codice malevolo può coinvolgere più aree dell’installazione e lasciare meccanismi utilizzabili per mantenere l’accesso al sito anche dopo una prima pulizia.
L’obiettivo dell’intervento è stato quindi verificare l’estensione della compromissione, individuare i componenti coinvolti, rimuovere il codice malevolo e controllare che le principali evidenze rilevate durante l’analisi non fossero più presenti.
L’installazione WordPress presentava segni concreti di compromissione. Oltre al file index.php risultato alterato, durante le operazioni amministrative venivano riscontrate limitazioni che impedivano di lavorare normalmente sul sito.
In particolare, alcune operazioni restituivano un errore 403 Forbidden. Questo comportamento rendeva inizialmente difficoltosa anche l’installazione degli strumenti necessari per approfondire l’analisi di sicurezza.
La verifica della configurazione del server ha portato all’individuazione di un file .htaccess anomalo nella root di WordPress. Al suo interno era presente un blocco generale dell’esecuzione PHP accompagnato da una whitelist di file con nomi non riconducibili alla normale installazione, tra cui riferimenti come system_log.php, adminfuns.php e connects.php.
La sostituzione della configurazione compromessa con le regole WordPress corrette ha eliminato il blocco 403 e ha consentito di proseguire con l’analisi dell’installazione.
index.php compromesso..htaccess per individuare la causa degli errori 403 che impedivano alcune operazioni amministrative..htaccess e verifica della scomparsa del blocco 403.wordpress-cache-optimizer, background-image-cropper, CustomWp e mu-installer.footer.php..dat utilizzati dal codice malevolo per memorizzare localmente il contenuto recuperato dall’esterno..htaccess compromesso, collegando il comportamento alla configurazione presente nell’installazione.osohbet.org e wh-footer, non hanno restituito corrispondenze.wp-content e nel tema, quindi la sostituzione dei soli file WordPress non sarebbe stata sufficiente a eliminare l’intera compromissione.L’analisi ha evidenziato una compromissione distribuita su più elementi dell’installazione WordPress. Il problema non era quindi rappresentato da un unico file infetto.
La prima evidenza importante è stata individuata nel file .htaccess della root. La configurazione presente bloccava generalmente l’esecuzione di file PHP ma conteneva contemporaneamente una whitelist anomala che consentiva l’accesso a specifici script. Questa configurazione non corrispondeva al normale funzionamento richiesto da WordPress e provocava gli errori 403 riscontrati durante le operazioni amministrative.
Una volta ripristinato il file .htaccess, è stato possibile eseguire una scansione più approfondita. Wordfence ha analizzato 27.208 file e ha inizialmente rilevato 20 problemi. Tra le segnalazioni erano presenti file classificati come backdoor all’interno delle directory wordpress-cache-optimizer, background-image-cropper, CustomWp e mu-installer.
L’analisi non si è fermata alle directory segnalate dallo scanner. Nel file wp-content/themes/pneupress/footer.php è stato infatti individuato un ulteriore meccanismo malevolo che contattava il dominio esterno linkal.xyz.
Il codice effettuava una richiesta verso un endpoint remoto /pull, recuperava un payload esterno e ne memorizzava localmente il risultato utilizzando file con schema .lp-*.dat. Il contenuto salvato veniva successivamente inserito nell’output della pagina tramite lettura del file locale.
Uno dei file .dat individuati conteneva effettivamente HTML SEO spam con collegamenti verso diversi domini esterni estranei all’attività dell’eCommerce. Questo ha permesso di collegare il codice presente nel footer.php al contenuto spam rilevato sul sito.
Per stabilire se lo stesso contenuto fosse stato inserito anche nel database, sono state effettuate ricerche mirate. Gli indicatori controllati non hanno prodotto risultati, consentendo di concentrare la bonifica sul filesystem e sui componenti compromessi effettivamente individuati, senza effettuare modifiche indiscriminate alle tabelle WordPress.
La root cause tecnica documentabile è quindi una compromissione dell’installazione WordPress con presenza di più backdoor e di un injector nel tema capace di recuperare da un server esterno un payload SEO spam, memorizzarlo in file locali .dat e inserirlo nelle pagine del sito.
La modalità iniziale con cui l’attaccante ha ottenuto l’accesso all’installazione non è stata determinata con certezza. In assenza di una prova tecnica sufficiente, non è quindi corretto attribuire l’origine dell’attacco a uno specifico plugin, password o vulnerabilità.
Installazione WordPress compromessa con più backdoor e file alterati. Nel footer.php del tema era presente un injector che recuperava un payload da un dominio esterno, lo memorizzava in file .dat e lo inseriva nell’output del sito, generando contenuto SEO spam.
Ricezione della segnalazione relativa alle anomalie presenti sull’eCommerce WordPress e apertura del caso per l’analisi tecnica.
Presa in carico dell’intervento e prima verifica dell’installazione. La presenza di un file index.php compromesso porta a classificare il problema come possibile compromissione di sicurezza e non come semplice errore WordPress.
Durante le operazioni amministrative viene rilevato un errore 403 Forbidden. L’analisi viene quindi estesa alle regole di accesso del server e al file .htaccess presente nella root di WordPress.
Nel file .htaccess viene individuata una configurazione anomala: blocco generale dell’esecuzione PHP accompagnato da eccezioni per script non riconducibili alla normale installazione. Il file viene ripristinato con regole WordPress coerenti e il blocco 403 viene rimosso.
Ripristinate le normali operazioni amministrative, viene avviata una scansione approfondita con Wordfence. La scansione analizza 27.208 file e segnala inizialmente 20 problemi da verificare.
Le segnalazioni vengono analizzate manualmente. Vengono individuati file classificati come backdoor in directory quali wordpress-cache-optimizer, background-image-cropper, CustomWp e mu-installer. Le directory compromesse vengono rimosse.
L’analisi viene estesa al tema attivo. Nel file footer.php viene individuato codice non appartenente alla normale logica del tema, collegato a un dominio remoto e alla gestione locale di file con estensione .dat.
Il codice viene analizzato e ricondotto a un injector: recuperava un payload da un endpoint esterno, lo salvava localmente e ne inseriva il contenuto nell’output del sito. Un file .dat individuato conteneva HTML SEO spam e collegamenti verso domini estranei all’eCommerce.
Vengono effettuate ricerche mirate nel database utilizzando gli indicatori emersi dall’analisi. Le stringhe controllate non vengono rilevate nelle tabelle analizzate, evitando così modifiche non necessarie al database.
Dopo la rimozione dei componenti compromessi viene eseguita una nuova scansione e vengono ricontrollate le aree precedentemente coinvolte. Le backdoor individuate nella fase iniziale non risultano più presenti.
Conclusa la fase di bonifica, viene comunicato al cliente l’esito dell’intervento e viene indicata la necessità di mantenere il sito sotto osservazione nei giorni successivi per verificare l’eventuale ricomparsa di file o comportamenti anomali.
index.php..htaccess per determinare l’origine degli errori 403 che impedivano alcune operazioni amministrative e ostacolavano l’utilizzo degli strumenti necessari alla diagnosi..htaccess e ripristinate regole compatibili con il normale funzionamento di WordPress.wordpress-cache-optimizer, background-image-cropper, CustomWp e mu-installer.footer.php, non limitando la bonifica agli elementi rilevati automaticamente dallo scanner..dat, successivamente utilizzati per inserire HTML SEO spam nelle pagine.Injector individuato nel footer del tema
Nel file wp-content/themes/pneupress/footer.php era presente codice estraneo alla normale struttura del tema che effettuava richieste verso il dominio esterno linkal.xyz. Il contenuto recuperato veniva salvato localmente attraverso file con schema .lp-*.dat e successivamente inserito nell’output della pagina.
L’analisi di uno dei file .dat ha mostrato la presenza di HTML SEO spam e collegamenti verso domini esterni non pertinenti all’attività dell’eCommerce. La corrispondenza tra il codice presente nel footer.php, il sistema di cache locale e il contenuto del file generato ha fornito un’evidenza concreta del funzionamento dell’injector.
Backdoor rilevate dalla scansione
La scansione iniziale di 27.208 file ha rilevato 20 problemi. Tra gli elementi analizzati erano presenti file classificati come backdoor in più directory dell’installazione, comprese wordpress-cache-optimizer, background-image-cropper, CustomWp e mu-installer.
La presenza di più elementi compromessi ha confermato che l’infezione non poteva essere trattata come l’alterazione isolata di un singolo file. Dopo la rimozione delle directory coinvolte, una nuova scansione non ha più rilevato quelle stesse backdoor.
Configurazione .htaccess anomala
Il file .htaccess presente nella root conteneva regole che bloccavano generalmente l’esecuzione PHP prevedendo contemporaneamente eccezioni per specifici file dai nomi anomali, tra cui system_log.php, adminfuns.php e connects.php.
Il ripristino di una configurazione WordPress coerente ha rimosso il comportamento 403 riscontrato durante le operazioni amministrative e ha permesso di proseguire con la bonifica.
.htaccess dopo il ripristino delle normali regole di WordPress.footer.php del tema dopo l’individuazione del codice responsabile del caricamento del payload esterno..dat associati al meccanismo di cache utilizzato dall’injector.Componenti malevoli individuati e rimossi
L’intervento ha permesso di rimuovere le backdoor individuate, correggere il file .htaccess compromesso e individuare nel tema il meccanismo utilizzato per recuperare e pubblicare contenuto SEO spam proveniente da un server esterno.
Il sito è rimasto operativo al termine della bonifica e le backdoor rilevate nella scansione iniziale non risultavano più presenti nella scansione successiva.
Non è stata documentata perdita di prodotti, ordini o contenuti dell’eCommerce durante l’intervento. Il database non è stato sottoposto a cancellazioni indiscriminate perché le ricerche mirate degli indicatori individuati non hanno restituito corrispondenze.
Il tempo complessivo dell’intervento non è stato registrato in modo sufficientemente preciso per pubblicare un dato attendibile; per questo non viene indicato un tempo di risoluzione artificiale.
.htaccess anomala che interferiva con le normali operazioni amministrative.index.php compromesso, che avrebbe lasciato attivi altri elementi dell’infezione..htaccess, wp-config.php, file del tema e directory che normalmente non dovrebbero contenere nuovi script PHP.footer.php è stata determinante per ricostruire il meccanismo di iniezione. Questo intervento mostra perché la rimozione del primo file infetto non può essere considerata automaticamente una bonifica completa. Il primo index.php compromesso era soltanto una delle evidenze: approfondendo l’analisi sono emerse una configurazione .htaccess anomala, più backdoor e un injector inserito nel tema.
Un secondo elemento importante riguarda il rapporto tra scansione automatica e analisi manuale. Lo scanner ha fornito indicazioni fondamentali sulle backdoor presenti nell’installazione, ma la ricostruzione del meccanismo di SEO spam ha richiesto l’analisi del codice del tema, dei file .dat generati e del collegamento con il server remoto. Gli strumenti automatici sono quindi parte della diagnosi, non un sostituto dell’analisi tecnica.
Infine, una bonifica dovrebbe distinguere sempre ciò che è dimostrato da ciò che è soltanto possibile. In questo caso è stato possibile documentare come veniva iniettato il contenuto spam, ma non stabilire con sufficiente certezza quale fosse stato il punto d’ingresso iniziale. Attribuire l’attacco a uno specifico plugin o a una password senza evidenze avrebbe reso il report meno attendibile, non più completo.
Intervento documentato dal team WpSupporto
Caso studio ricostruito sulla base del processo operativo seguito durante l’intervento.
I dati identificativi del cliente, del dominio e dei componenti coinvolti sono stati anonimizzati per tutelarne la riservatezza.
Panoramica rapida Data intervento Luglio 2026 Problema Personalizzazione WooCommerce per assicurazione spedizione Bartolini Categoria Personalizzazione WordPress Complessità Alta Livello rischio Calcoli errati…
Leggi il caso studio
Panoramica dell’intervento Il team di WpSupporto è stato contattato dai responsabili di Tenuta Roca Nuova, eCommerce WordPress specializzato nella vendita online di…
Leggi il caso studioI casi studio WpSupporto sono ricostruiti sulla base del processo operativo seguito durante gli interventi tecnici. La documentazione viene curata dal team tecnico per garantire chiarezza, trasparenza e tutela della privacy del cliente.
Se il tuo sito mostra errori, malfunzionamenti o problemi dopo un aggiornamento, puoi richiedere una prima analisi tecnica a WpSupporto.
Richiedi assistenza WordPress