Obres la web amb la sessió iniciada i tot sembla normal. Un client que arriba des de Google acaba en un anunci, una actualització falsa o una botiga aliena. Les redireccions selectives permeten que la infecció romangui oculta per a qui administra el lloc.
Considera creïble l’avís fins que l’evidència indiqui el contrari. No visitis repetidament la destinació des de l’ordinador habitual ni esborris fitxers abans de conservar les condicions que l’activen.
Si la redirecció és activa, consulta el servei de neteja de redireccions WordPress per definir avaluació, intervenció i proves de tancament. Aquesta guia descriu un símptoma; el títol sol no identifica la causa.
Registra el recorregut exacte
Demana URL original, hora aproximada, dispositiu, navegador i si la visita va arribar des d’un cercador, xarxa social o enllaç directe. Una captura és útil; la URL maliciosa s’ha de tractar com a evidència insegura.
No demanis al client que repeteixi el problema. Un informe clar és suficient per començar proves controlades. Anota si va passar en la primera visita i va desaparèixer en refrescar: el programari maliciós pot deixar una galeta o marca d’emmagatzematge per no mostrar-se dues vegades.
Reprodueix en un entorn aïllat
Utilitza un perfil d’un sol ús sense sessió de WordPress. No obris correu, banca ni el panell des d’aquest perfil.
Prova una matriu petita:
- accés directe i amb referrer de cerca;
- agent mòbil i d’escriptori;
- primera visita sense galetes;
- pàgina afectada i portada;
- CDN i origen, només quan tinguis autorització.
Atura’t si intenta descarregar res. Conserva la petició sense obrir el fitxer.
Inspecciona la cadena de redirecció
Conserva una resposta GET acotada, amb capçaleres i cos, abans de seguir una redirecció. Una consulta HEAD no recull aquest cos:
curl -q --silent --show-error --max-time 15 --max-filesize 1048576 --dump-header headers.txt --output response.txt https://example.com/Utilitza-ho des d’un entorn d’anàlisi net i només amb una URL autoritzada. La primera opció ignora la configuració local de curl; no s’activa el seguiment de redireccions. Revisa capçaleres i text desat sense obrir-lo com a pàgina web. Recull una resposta HTTP, no navegació posterior per JavaScript. El manual de curl documenta HEAD i les opcions de sortida.
A la xarxa del navegador identifica la resposta o script que canvia la ubicació. Un 301 o 302 apunta a servidor, PHP o CDN; si la pàgina carrega primer, hi pot intervenir JavaScript, un iframe o una notificació.
Comparació local original: mètode i condició de visita
En un assaig HTTP innocu del 25 d’octubre del 2026 vam registrar sis peticions a un servidor accessible només des de l’ordinador local. Quatre il·lustren per què una resposta aparentment normal no basta com a control:
Mateixa URL de prova: HEAD → 200; GET → 302
Exemple de visitant: GET de control directe → 200
Exemple de visitant: GET amb condició fictícia → 302
Destinacions de redirecció visitades: 0La condició era una capçalera de formació inventada, no una sessió real d’administrador, mòbil, entrada des de Google ni petició del seu rastrejador. L’exemple va produir respostes diferents expressament. Demostra com comparar; no reprodueix una infecció ni identifica per què redirigeix una web real. No vam executar JavaScript ni fitxers descarregats.
En una incidència, conserva una observació de control i una d’afectada per a la mateixa URL pública. Anota mètode, hora, estat de sessió, origen d’entrada, classe de dispositiu, primer estat de resposta, capa que la va servir i si hi va haver navegació posterior. Canvia una condició cada vegada i mantén aparellades les observacions. Un hash diferent pot venir de contingut dinàmic legítim; compara l’evidència rellevant de redirecció o script.
Captura la primera resposta abans de seguir la cadena. Desa una destinació sospitosa com a evidència en lloc d’obrir-la. Una resposta HTTP neta deixa sense provar el comportament activat per JavaScript. Demana que l’analista assenyali la capa observada i què continua pendent.
Canviar l’etiqueta d’agent d’usuari no autentica un rastrejador de Google. La seva documentació de verificació de peticions explica com comprovar la IP sol·licitant. Distingeix una prova sintètica d’un registre d’accés verificat. Per a URL inesperades a la cerca, la guia de pàgines de spam sense entrada a WordPress separa resposta actual i historial indexat.
Observació HTTP pública: quatre peticions controlades
El 24 d’octubre del 2026 a les 22:40 UTC vam recollir quatre respostes GET de la versió anglesa d’aquesta guia: capçaleres d’escriptori amb entrada directa, les mateixes amb referrer de cerca sintètic, capçaleres de mòbil i repetició de mòbil sense galetes. Totes quatre van retornar HTTP 200, sense capçalera Location i amb cossos idèntics en recollir-los.
És una observació datada de la nostra URL editorial, no d’un client infectat. Les etiquetes descriuen capçaleres, no dispositius físics ni una visita real des de Google. No vam provar sessió d’administrador, executar JavaScript ni verificar un rastrejador de Google. El resultat cobreix només la resposta HTTP inicial; no demostra absència de redirecció al navegador o infecció en altres parts.
Compara l’HTML públic i administratiu
Desa la resposta HTML inicial d’un visitant net i compara-la amb la vista connectada. Cerca dominis de scripts desconeguts, blocs codificats, iframes i codi abans del tancament de body.
No enganxis el codi en un descodificador en línia: pot contenir rutes, secrets o un payload actiu. Treballa amb una còpia desconnectada.
Si l’HTML és net però hi ha redirecció, revisa respostes JavaScript externes, service workers i contingut emmagatzemat per la CDN.
Revisa WordPress i el hosting
Inspecciona fitxers modificats recentment, connectors actius i mu-plugins, tema, wp-config.php, index.php arrel i .htaccess. Cerca scripts injectats en entrades, ginys i opcions de la base.
Comprova també:
- administradors i contrasenyes d’aplicació inesperats;
- cron de WordPress i servidor;
- redireccions del panell de hosting;
- DNS i regles de Cloudflare;
- webs veïnes al mateix compte.
El primer fitxer sospitós rarament demostra tot l’abast.
Contén sense destruir evidències
Si els visitants afronten una estafa o descàrrega, publica manteniment controlat o restringeix l’accés conservant fitxers i registres. Crea una còpia de sistema i base amb les dates.
Una substitució massiva canvia timestamps i dificulta la investigació. Restaurar abans de conèixer l’entrada pot recuperar codi vulnerable o esborrar proves. Coordina amb el hosting si hi ha diverses webs o risc de suspensió.
Verifica amb el desencadenant original
Després d’eliminar codi confirmat i tancar l’entrada, repeteix les mateixes proves de referrer, dispositiu i galetes netes. Revisa HTML públic, peticions externes, usuaris, tasques i canvis de fitxers.
Purga la CDN només després de netejar l’origen. Monitoritza redireccions i integritat per detectar recurrències.
Quan demanar una neteja urgent
Demana ajuda quan la redirecció sigui selectiva, descarregui fitxers, afecti diverses webs o torni després d’esborrar-la. Envia URL públiques, hores i captures, mai contrasenyes ni adjunts maliciosos.
Una neteja responsable conserva evidència, localitza persistència, retira el payload, tanca la via i demostra que la condició original ja no s’activa.
Prepara l’avaluació i la prova de tancament
Envia URL pública, dispositiu/navegador, hora aproximada, origen d’entrada i primera visita o repetició. Inclou destinació com a text i captura sense dades privades si en tens. Sol·licita una avaluació de redireccions sense contrasenyes ni fitxers sospitosos.
Demana que la proposta identifiqui capes afectades, còpia de recuperació, intervenció prevista, proves repetibles i responsable de seguiment. Compara visites afectades amb controls directes i de l’administrador. El procés d’avaluació separa diagnòstic de canvis aprovats.