Què importa primer: El directori de càrregues normalment ha de contenir suports, no codi d’aplicació executabla. Els atacants l’afavoreixen perquè es pot escriure i sovint sobreviu plugin o substitueixment de nucli.
Què indica realment aquest símptoma
Elimina un shell no revela com va arribar o si un altre carregador pot recrear- lo. Les marques de temps, la propietat i l’accés als registres i fitxers relacionats connecten la càrrega útil a un punt d’entrada.
Recull proves abans de canviar res
- Enumeix cada connector executa i extensió doble sospitosa sota les càrregues.
- Registre de fashes, data i hores, propietari i rutes abans de la quarantena.
- Coincideix els temps de creació amb l’accés, càrrega i autenticació registres.
- Cerca referències als fitxers cron, opcions, temes, plugins i regles del servidor.
Causes més habituals
- Endpoint de càrrega vulnerable: Un plugin va acceptar contingut executabla o controls de tipus omesos.
- Credencials robades: Un atacant va escriure fitxers a través de SFTP, servidoring o WordPress admin.
- Porta del darrere existent: Un altre shell o carregador va generar la càrrega útil.
- Servidor mal configurat: l’execució PHP està permesa en un directori destinat únicament a suports.
Seqüència segura de diagnòstic i reparació
- Evidència de quarantena fora de l’arrel del web i bloquegi l’execució PHP en càrregues.
- Elimina tota persistència relacionada i substitueix els components compromesos de fonts de confiança.
- Pedaç o elimini la ruta de càrrega vulnerable i roti les credencials pertinents.
- Escaneja els llocs veïns i comparteix comptes servidoring usant el mateix usuari del sistema.
Com distingir entre les causes probables
No tractis Endpoint de càrrega vulnerable i Credencials robades com a causes equivalents. Un plugin va acceptar contingut executant o controls de tipus omesos. En canvi, un atacant va escriure fitxers a través de SFTP, servidoring o WordPress admin. Per distingir- les, usa aquestes dues comprovacions: Enumeri cada connector executa i extensió doble sospitosa sota les càrregues; i registre de hashes, data i hores, propietari i rutes abans de la quarantena. Amb aquestes dades podràs decidir si convé aplicar la primera acció controlada — Evidència de quarantena fora de l’arrel de la web i bloquegi l’execució PHP en càrregues — 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 obre un shell web en un navegador per a “ver el que fa” Analitzar una còpia preservada fora de línia i assumir que cada petició podria desencadenar lògica atacant.
Com verificar la reparació
- No queden fitxers d’execució en els directoris de suports d’escriptura.
- El servidor rebutja els intents d’execució sota càrrega.
- El monitoratge no mostra recreació i la ruta d’escriptura original està tancada.
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.
CRITERI D’INCIDENT WP REPAIR
Seqüència d’intervenció segura
Elimina un shell no revela com va arribar o si un altre carregador pot recrear- lo. Les marques de temps, la propietat i l’accés als registres i fitxers relacionats connecten la càrrega útil a un punt d’entrada.
- Enumeix cada connector executa i extensió doble sospitosa sota les càrregues.
- Registre de fashes, data i hores, propietari i rutes abans de la quarantena.
- Coincideix els temps de creació amb l’accés, càrrega i autenticació registres.
- Cerca referències als fitxers cron, opcions, temes, plugins i regles del servidor.
Què ha de quedar verificat
- No queden fitxers d’execució en els directoris de suports d’escriptura.
- El servidor rebutja els intents d’execució sota càrrega.
- El monitoratge no mostra recreació i la ruta d'escriptura original està tancada.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
N'hi ha prou amb eliminar el fitxer PHP maliciós una vegada que el trobi en càrregues?+
No. Eliminar el fitxer elimina la càrrega immediata però no revela com va arribar allà o si un carregador separat pot simplement recrear-lo. Les marques de temps, propietat, registres d’accés i fitxers relacionats han de ser rastrejats fins al punt d’entrada real abans que l’incident pugui ser considerat tancat.
Heu d’obrir el fitxer PHP sospitós en un navegador per veure què fa?+
No, això és explícitament insegur. Un shell web pot executar la lògica de l’atacant en el moment en què se sol·licita, de manera que s'ha d’analitzar com una còpia offline preservada en lloc d’activada en viu, sota la suposició que qualsevol petició a la mateixa podria executar codi maliciós.
Per què malware segueix apareixent en wp-contentent/uploads específicament, en comptes de en carpetes plugin o theme?+
El directori de càrregues normalment es refereix només a mitjans, però és escrit per WordPress i sovint sobrevisqui a plugin complet o reemplaçament de nucli, el que el converteix en un objectiu atractiu per als atacants que desitgen una càrrega útil que persisteix a través de la neteja.
Si només un lloc està afectat, s'haurien de comprovar també altres llocs en el mateix servidor?+
Sí. Quan diversos llocs comparteixen el mateix compte hosting o usuari del sistema, un punt final de càrrega vulnerable o credencials robades en un lloc es poden usar per escriure fitxers en d’altres, de manera que els llocs veïns i comptes que comparteixen aquest usuari del sistema també han de ser escanejats.