CASO DI STUDIO · EDITORIA

Portale editoriale con redirect mobile nascosti: trigger SQL e payload in wp_options

  • CLIENTETestata giornalistica locale (dati anonimizzati)
  • PIATTAFORMAWordPress

Redirect verso finte lotterie visibili solo da mobile e da Google: trigger SQL che reinfettavano gli articoli e un payload in wp_options. Pulizia entro 12 ore.

Uno smartphone con un articolo da cui parte una freccia rossa tratteggiata verso una pagina sconosciuta, accanto a un piccolo database colpito da un fulmine

Il contesto

Un portale di informazione locale realizzato con WordPress, con una redazione di diverse persone e un archivio di molti anni. La maggior parte dei lettori arriva da smartphone, dai motori di ricerca e dai social. Per riservatezza, il nome della testata e i dettagli che permetterebbero di identificarla sono stati omessi.

I sintomi

Alcuni lettori avevano scritto alla redazione che, aprendo un articolo da Google sul telefono, finivano su pagine di finte lotterie e di presunti premi da riscuotere. Nessuno in redazione riusciva a riprodurre il problema: dal computer il sito era normale, e anche dai telefoni dei giornalisti, collegati come utenti del sito, non succedeva niente. Un primo controllo con uno scanner di sicurezza non aveva trovato nulla di rilevante.

Il cliente ha scelto l’intervento entro 12 ore.

Cosa abbiamo trovato a livello applicativo

Il redirect era selettivo: si attivava solo per chi arrivava da un motore di ricerca, da un dispositivo mobile, senza essere collegato a WordPress, e una sola volta per visitatore, grazie a un cookie. Era una scelta precisa, pensata per non farsi vedere proprio da chi gestisce il sito.

Il codice JavaScript del redirect non era nei file. Era salvato, offuscato, in un’opzione di wp_options con un nome generico e caricamento automatico attivo, e veniva stampato nelle pagine da poche righe aggiunte a un file di un plugin di condivisione sui social. Quelle righe, da sole, sembravano innocue: leggevano un’opzione e la mostravano nel footer.

Molti articoli contenevano inoltre uno script aggiuntivo in fondo al testo. La redazione, avvisata, ne aveva già corretti alcuni a mano, ma lo script ricompariva appena l’articolo veniva salvato di nuovo.

Cosa abbiamo trovato a livello di sistema

La ricomparsa dello script negli articoli non dipendeva da PHP. Nel database c’erano due trigger, BEFORE INSERT e BEFORE UPDATE sulla tabella degli articoli, che a ogni salvataggio aggiungevano lo script al contenuto. Un terzo trigger, sulla tabella dei commenti, creava un nuovo amministratore quando arrivava un commento contenente una certa stringa: una porta di rientro che non richiedeva nessun file sul server.

L’utente del database del sito aveva tutti i privilegi, compreso quello di creare trigger. Analizzando i virtual host del server abbiamo trovato la probabile origine: una vecchia copia di prova del sito, dimenticata in una sottocartella e raggiungibile da internet, con plugin non aggiornati da anni e le stesse credenziali di database del sito in produzione. I log di accesso mostravano richieste mirate a un plugin vulnerabile di quella copia, qualche settimana prima della comparsa dei trigger.

Come l’abbiamo rimosso

  1. Salvate le prove: definizioni dei trigger, contenuto dell’opzione, file modificati, log rilevanti.
  2. Eliminati i tre trigger e verificata l’assenza di procedure ed eventi pianificati.
  3. Rimosso il codice dal plugin di condivisione, sostituendolo con la versione originale, ed eliminata l’opzione con il payload.
  4. Ripuliti tutti gli articoli con una ricerca mirata nel database, estesa ai metadati e ai commenti, e verificato che un nuovo salvataggio non reintroducesse lo script.
  5. Eliminati due amministratori non autorizzati, creati dal trigger dei commenti.
  6. Messa offline la copia di prova e cambiate tutte le credenziali, a partire da quelle del database condiviso.

L’hardening

L’utente del database del sito ora ha solo i privilegi necessari a WordPress, senza la possibilità di creare trigger, procedure o eventi. Ogni ambiente di prova ha un proprio database con credenziali diverse ed è protetto da autenticazione. Abbiamo inoltre configurato un controllo periodico che segnala la comparsa di trigger o di opzioni sospette nel database.

Il risultato

Il sito è stato ripulito entro le 12 ore previste. I test dai dispositivi mobili, simulando l’arrivo da un motore di ricerca e senza cookie, non hanno più mostrato redirect, e gli articoli salvati dopo l’intervento sono rimasti puliti. La redazione ha ricevuto indicazioni su come riconoscere per tempo segnali simili nelle segnalazioni dei lettori.

IL PROSSIMO PASSO

Il tuo sito
è infetto?

Ogni ora conta: il malware continua a colpire visitatori e clienti, e Google, l’hosting e le blacklist non aspettano. Scegli il piano, paga online e condividi gli accessi: la bonifica parte subito, a prezzo fisso e con tempi garantiti.

Richiedi la bonifica

Ti porta ai piani: bonifica entro 6, 12 o 24 ore dalla ricezione degli accessi.

MANAGED SERVER S.R.L.info@rimozionemalware.com +39 02 5656 9681

Lunedì – venerdì · 09:30 – 19:30

Preferisci un modulo online?
Contattaci su managedserver.it ↗