¿Nos hackearon la web de WordPress o se rompió un plugin? ¿Cómo saber si hay alguien adentro?

La razón por la que tus clientes lo ven y vos no es el filtrado por User-Agent y Referer. El código PHP malicioso le muestra la página limpia a las visitas directas, pero activa la redirección maliciosa para quienes vienen de búsquedas de Google o sitios externos. Revisá los archivos .htaccess e index.php en la raíz de tu servidor. Vas a ver fragmentos de código raros escondidos bien arriba que llaman a eval, base64_decode o a archivos externos.

Para solucionar esto sin destruir las pruebas, seguí estos pasos: 1) Descargá de una al disco local el archivo access.log crudo de los últimos 30 días desde el panel del servidor. 2) Hacé un backup completo de la base de datos desde phpMyAdmin. 3) Anotá la fecha de creación del usuario sospechoso en la tabla wp_users. 4) Filtrá los logs de acceso en ese rango de fecha y hora para identificar a qué archivo PHP o vulnerabilidad le mandaron la petición POST.

Tuvimos un caso parecido el año pasado en nuestra tienda de repuestos en Hannover. Nuestro programador nos tuvo cinco días con el cuento de que se había roto la caché. Cuando Google le puso la advertencia de seguridad a la web, el flujo de pedidos de 4.000 EUR semanales se nos cayó a cero de golpe. Al contratar a un especialista para hacer la limpieza nos cobró 850 EUR, pero nos llevó seis semanas sacar la sanción del buscador y recuperar la facturación de antes. No pierdan tiempo.

Eso de que «la actualización del plugin rompió la base de datos» que te dijo el desarrollador no se lo cree nadie. Un plugin roto no te crea un usuario admin falso en la base de datos ni te mete palabras clave raras en los resultados de Google. O bajó un plugin pirata de una fuente no confiable o no quiere admitir que dejó un agujero de seguridad. Tenés que hacer revisar el sitio por un especialista independiente de ese desarrollador.

Lo más urgente que hay que hacer ahora mismo es poner la web en modo mantenimiento. Si a los clientes los redirige a otro lado en la pasarela de pago, les pueden estar robando los datos de la tarjeta de crédito. Intentar limpiar archivos con la web en vivo solo perjudica a tus clientes. Desde el panel de control del hosting, restringí el acceso al sitio solo a la IP de tu oficina y cortá el tráfico externo de inmediato.

abri la carpeta uploads x ftp y busca archivos php ya mismo y normalmente ahi no puede haber nada q no sea imagen o pdf. apenas encuentres algo borralo y mete un archivo htaccess en esa carpeta q bloquee la ejecucion de php. la verdad sino x mas q limpies mañana a la mañana la web vuelve a ser un zombi.

¿En qué clase de entorno está corriendo exactamente tu infraestructura de hosting? ¿Estás en un servidor compartido o tenés un VPS independiente? Si tenés alojados varios dominios o sitios de prueba bajo la misma cuenta, ¿podría ser que los atacantes hayan entrado a los directorios de tu web principal a través de un subdominio viejo y abandonado? ¿Se ven movimientos de ese tipo de acceso cruzado en los logs?

Mencionó que se están produciendo redirecciones externas en la página de pago. En caso de que los datos de tarjetas de crédito o datos personales de sus clientes hayan caído en manos de terceros, podría tener la obligación de notificar a la autoridad de control competente en un plazo de 72 horas, en virtud de la normativa de protección de datos de Alemania. Por ello, le sugiero que no trate el asunto únicamente como un fallo técnico, sino que considere sus implicaciones legales y conserve los registros de log con el debido rigor forense.

Gracias por escribir.

Este hilo es para archivar.

Tiene razón.

Permíteme resumir lo que se ha dicho hasta ahora. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Si no me equivoco, quieres decir esto: Tomar notas durante dos semanas da mejores resultados que estimar seis meses.

Si decidimos sin medir, siempre acabamos en el mismo punto. Si escribís el resultado aquí, también servirá de ayuda a otros.

no sabía eso luego si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde.

Totalmente. Si tuviera que añadir algo más: Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

Corrijanme si me equivoco.

Os explico cómo se hace en la práctica. Si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola.

Las decisiones apresuradas son las que hay que corregir seis meses después. Si tenéis dudas, escribid, os responderé en la medida de lo posible.

Resumen breve para nuevos usuarios: Todo lo que no está por escrito, ambas partes lo recordarán de forma distinta en el futuro.

Por supuesto, cambia si tu situación es diferente.

Aquí hay una trampa, no puedo dejar de mencionarla. Intentar hacerlo solo es la vía más cara.

Antes de decidir, mirad qué datos tenéis en la mano. Eso es todo disculpa si me he extendido demasiado.