Què importa primer: l’arrel index.php és petita i comunament monitorada, per la qual cosa els atacants la fan servir com a punt d’execució fiable. La modificació repetida demostra que la neteja no va tenir un carregador, credencial o compromís veí.
Què indica realment aquest símptoma
Fresh data i hores i hashes separen la reinfecció real de la sortida cau. Propietat i auditoria registres ajuden a identificar web, SFTP o escriu a nivell de sistema.
Recull proves abans de canviar res
- Preserva cada versió infectada, hash, data i hora i propietari.
- Fes un seguiment del fitxer per a la següent escriptura i correlacional amb el procés i accedeix a registres.
- Cerca cron, mu-plugins, càrregues, configuració d’autoprepensió i llocs de germans.
- Auditoria servidoring, SFTP i credencials de gestor emprades prop del temps d’escriptura.
Causes més habituals
- Carregador ocult: Un altre fitxer PHP reescriu index.php en sol·licituds o cron.
- Credencials compromeses: Un atacant continua carregant el fitxer externament.
- Lloc veí: Una aplicació diferent sota el mateix usuari escriu a través de directoris.
- Persistència a nivell del servidor: _prepend_ file o tasques programades del sistema s’ executen abans de WordPress.
Seqüència segura de diagnòstic i reparació
- Substitueix index.php del paquet de nucli net exacte després de preservar l’evidència.
- Suprimiu el mecanisme de persistència i tancar la ruta d’escriptura.
- Gira totes les credencials privilegiades i invalida les sessions.
- Separar o netejar cada lloc compartint el compte i monitoritzar la integritat.
Com distingir entre les causes probables
No tractis Carregador ocult i Credencials compromeses com a causes equivalents. Un altre fitxer PHP reescriu index.php en sol· licituds o cron. En canvi, un atacant continua carregant el fitxer externament. Per a distingir- les, useu aquestes dues comprovacions: Preserva cada versió infectada, hash, data i hora i propietari; i monitoritza el fitxer per a la següent escriptura i correlacional amb el procés i accedeix a registres. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada —Reemplaça index.php del paquet de nucli net exacte després de preservar l’evidència — 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 segueix substituint index.php mentre el lloc roman en línia i canviant activament. Preservar estat i contenir accés a escriptura primer.
Com verificar la reparació
- Index.php segueix sent idèntic a través del trànsit, cron i reiniciar.
- Cap procés o compte desconegut pot escriure a l’arrel de la web.
- Els llocs germans i la configuració a nivell de servidor estan nets.
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
Reconstrueix la incidència abans de corregir-la
Fresh data i hores i hashes separen la reinfecció real de la sortida cau. Propietat i auditoria registres ajuden a identificar web, SFTP o escriu a nivell de sistema.
- 1
Preserva cada versió infectada, hash, data i hora i propietari.
- 2
Fes un seguiment del fitxer per a la següent escriptura i correlacional amb el procés i accedeix a registres.
- 3
Cerca cron, mu-plugins, càrregues, configuració d'autoprepensió i llocs de germans.
- 4
Auditoria servidoring, SFTP i credencials de gestor emprades prop del temps d’escriptura.
Què ha de quedar verificat
- index.php segueix sent idèntic a través del trànsit, cron i reiniciar.
- Cap procés o compte desconegut pot escriure a l’arrel de la web.
- Els llocs germans i la configuració a nivell de servidor estan nets.
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.
És útil continuar substituint index.php amb una còpia neta mentre s'investiga?+
No, això s'ha desmarcat explícitament. Repetidament es substitueix el fitxer mentre el lloc roman en línia i activament s'escriu per restablir el símptoma sense tancar la ruta d’escriptura, de manera que és probable que el fitxer es torni a infectar abans que es trobi la causa real.
Per què index.php seria específicament el fitxer que es continua tornant a infectar?+
És petit i comunament monitorat, el que el converteix en un punt d’execució fiable per als atacants en comptes d’una coincidència. La modificació repetida d’aquest fitxer en particular és en si mateixa evidència que la neteja va ometre un carregador, una credencial compromesa, o una infecció relacionada en una altra part del compte.
Podria un lloc web completament diferent en el mateix servidor ser la font real de reinfecció?+
Sí. Quan diversos llocs comparteixen el mateix compte hosting o usuari del sistema, una aplicació veïna compromesa pot escriure a través de directoris i tornar a infectar index.php en un lloc que d’altra manera està net, de manera que els llocs germans han de ser revisats com a part de la investigació.
Quina és la diferència entre un carregador ocult i la persistència a nivell del servidor que causa això?+
Un carregador ocult és un altre fitxer PHP dins de la instal·lació WordPress que reescriu index.php en sol·licituds o a través de cron, mentre que la persistència a nivell de servidor usa mecanismes com auto_ prepend_ file o tasques programades del sistema que s'executen abans de que WordPress fins i tot s'executi.