Pharma hack a WordPress: eliminar pàgines ocultes de spam farmacèutic i cloaking

Què importa primer: Un hack farmacèutic injecta o genera pàgines sobre medicaments, sovint mostrant diferents continguts per a cercar els rastrejadors i visitants normals. L’incident inclou la càrrega útil, persistència, punt d’entrada i URLs indexat.

Què indica realment aquest símptoma

Els resultats de la cerca poden romandre contaminats després que el lloc visible es vegi normal. Cal mapejar on es genera el spam, què ho recrea i quin URLs Google ha descobert.

Recull proves abans de canviar res

• L’exportació va afectar URLs i els patrons de consulta de la consola de cerca.
• Compara les respostes del rastrejador i del navegador normal per a URLs representatiu.
• Cerca fitxers, opcions de base de dades, publicacions, regles de reescriptura, mu- plugins i cron.
• Enregistrar usuaris inesperats, fitxers modificats i components vulnerables.

Causes més habituals

• Injecció de la base de dades: Els títols, enllaços o plantilles Spam es desen en publicacions o opcions.
• Encapsulat dinàmic: PHP genera contingut farmacològic només per a referres de cerca o agents d’usuari de rastrejadors.
• Generador de reescriptura: Les regles converteixen les rutes de paraules clau arbitràries en respostes indexables.
• Porta posterior persistent: Una tasca programada o un carregador ocult restaura spam eliminat.

Seqüència segura de diagnòstic i reparació

1. Preserva una base de dades i una instantània de fitxer abans de netejar.
2. Retiri el generador i la persistència, després reemplaciu el codi compromès amb paquets nets.
3. Tanqueu el punt d’entrada i gir WordPress, servidoring, SFTP i credencials de la base de dades.
4. Retorna les respostes correctes 404 o 410 per a spam URLs i neteja el webmap.

Com distingir entre les causes probables

No tractis Injecció de la base de dades i Encapsulat dinàmic com a causes equivalents. Els títols, enllaços o plantilles Spam es desen en publicacions o opcions. En canvi, pHP genera contingut farmacològic només per a referres de recerca o agents d’usuari de rastrejadors. Per a distingir- les, useu aquestes dues comprovacions: l’exportació va afectar URLs i els patrons de consulta de la consola de cerca; i compara les respostes del rastrejador i del navegador normal per a URLs representatiu. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada — Preservar una base de dades i una instantània de fitxer abans de netejar — o si has de conservar l’estat actual i ampliar la recerca.

En una web compromesa, contenir i netejar són decisions diferents. Conserva el fitxer sospitós i els registres d’accés abans d’eliminar la persistència, i gira les credencials només després de tancar la via activa. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.

Què no has de fer

No demana una revisió de cerca fins que la inspecció en viu estigui neta sota les mateixes condicions de rastreig que van revelar el spam.

Com verificar la reparació

• No es generen nous fàrmacs URLs.
• El representant spam URLs retorna l’estat previst i està absent dels mapes de lloc.
• La integritat del fitxer, els usuaris i cron romanen estables a través de diversos cicles.

Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.