7 señales de que tu WordPress ya fue hackeado — y qué hacer ANTES de limpiarlo
Tu sitio fue hackeado. Lo sabes porque redirige a spam, Google lo marca como "dañino", o aparecieron usuarios administradores que tú no creaste. Tu instinto es limpiarlo ya. Pero si lo haces sin preservar evidencia, puedes destruir pruebas clave para una demanda civil o penal. Te explicamos las 7 señales de hackeo y el protocolo forense que debes seguir antes de tocar un solo archivo.
En una línea: Si tu WordPress fue hackeado, limpiarlo es lo último que debes hacer. Primero necesitas preservar la evidencia: copiar archivos, descargar logs, documentar la línea de tiempo del incidente. Si limpias antes de preservar, puedes destruir pruebas que sirvan para una demanda civil o penal. Este artículo te explica cómo hacerlo bien.
1. Las 7 señales de que tu WordPress fue hackeado
Estas son las señales que hemos visto consistentemente en más de 9,700 casos resueltos desde 2015. Si ves una o más de estas señales, tu sitio probablemente fue comprometido:
Redirecciones a sitios de spam, casinos o phishing
Tu sitio redirige automáticamente a páginas de apuestas, pornografía, venta de réplicas o phishing bancario. Esta es la señal más obvia y la más común. Los atacantes inyectan código JavaScript o PHP que detecta si el visitante viene desde Google (para no afectar al administrador) y redirige a sitios maliciosos.
Cómo verificarlo: Navega tu sitio en modo incógnito (sin cookies de administrador). Si redirige, está comprometido. Revisa también el código fuente: busca eval(base64_decode, gzinflate, o redirecciones a dominios sospechosos.
Google marca tu sitio como "dañino" o "engañoso"
Recibes una notificación en Google Search Console diciendo que tu sitio fue marcado como "dañino" (malware) o "engañoso" (phishing). Google detectó código malicioso y está mostrando una advertencia a los visitantes.
Cómo verificarlo: Entra a Google Search Console → Seguridad y acciones manuales. Si ves alertas de seguridad, tu sitio está en la lista negra de Google.
Usuarios administradores que tú no creaste
Entras a Usuarios en WordPress y ves cuentas de administrador con nombres que no reconoces: admin123, support_user, webmaster_backup. Los atacantes crean estas cuentas para mantener acceso persistente incluso si cierras la brecha inicial.
Cómo verificarlo: Revisa la lista de usuarios y filtra por rol "Administrador". Si ves usuarios que no reconoces, especialmente creados en fechas recientes, tu sitio fue comprometido.
Archivos modificados en el core de WordPress
Los archivos del core de WordPress (wp-includes, wp-admin) fueron modificados. Esto es inusual porque el core no debería cambiar salvo por actualizaciones oficiales. Los atacantes inyectan código malicioso en estos archivos para que sobreviva a actualizaciones de plugins y temas.
Cómo verificarlo: Compara los archivos de tu instalación con los archivos oficiales de WordPress.org. Si hay diferencias en archivos del core (no en plugins ni temas), está comprometido.
Entradas o páginas con contenido que no publicaste
Aparecen entradas, páginas o productos con contenido de spam: enlaces a sitios de apuestas, venta de medicamentos, o contenido adulto. Los atacantes usan tu sitio para generar backlinks hacia sus redes de spam.
Cómo verificarlo: Revisa las entradas recientes y busca contenido que no reconozcas. También revisa las páginas ocultas o con estado "Privado" que pueden estar pasando desapercibidas.
Lentitud extrema o consumo inusual de recursos
Tu sitio se volvió extremadamente lento o tu hosting te notifica que estás consumiendo recursos inusualmente (CPU, memoria, ancho de banda). Los atacantes pueden estar usando tu sitio para enviar spam, minar criptomonedas, o lanzar ataques DDoS.
Cómo verificarlo: Revisa el panel de tu hosting. Si ves picos de CPU o tráfico inusual (especialmente de noche), o si tu sitio tarda más de 10 segundos en cargar cuando antes cargaba en 2 segundos, investiga.
Correos de tu dominio llegando a spam o rebotando
Los correos que envías desde tu sitio (formularios de contacto, confirmaciones de pedido, notificaciones) están llegando a spam o rebotando. Tu dominio fue puesto en listas negras por enviar spam.
Cómo verificarlo: Revisa si tu dominio o IP está en listas negras con herramientas como MXToolbox. Si aparece en múltiples listas negras, tu sitio está enviando spam.
No borres archivos. No reinstales WordPress. No elimines usuarios sospechosos. No actualices plugins. Cada una de estas acciones puede destruir evidencia del hackeo. Primero preserva, después limpia. Si necesitas ayuda urgente, contáctanos antes de tocar nada.
2. Por qué NO debes limpiar inmediatamente
Cuando descubres que tu sitio fue hackeado, el instinto es limpiarlo ya: borrar archivos maliciosos, eliminar usuarios sospechosos, restaurar desde backup. Pero si lo haces sin preservar evidencia, puedes destruir pruebas clave.
¿Por qué necesitas preservar evidencia?
Hay tres escenarios donde la evidencia del hackeo es crítica:
- Demanda civil o penal: Si sabes quién hackeó tu sitio (un ex-empleado, un proveedor, un competidor), necesitas evidencia para una demanda. Sin evidencia, no hay caso.
- Reclamación de seguro: Algunas pólizas de seguro cibernético requieren evidencia del incidente para procesar la reclamación.
- Investigación forense: Necesitas saber cómo entraron, qué hicieron, qué datos accedieron, y cuánto tiempo estuvieron dentro. Sin evidencia, no puedes responder estas preguntas.
En México, el acceso ilícito a sistemas es un delito federal (Artículo 211 bis del Código Penal Federal). Si puedes demostrar quién accedió, cuándo, y qué hizo, puedes ejercer acción penal. Pero necesitas evidencia documentada con cadena de custodia: copias forenses, logs con sello temporal, línea de tiempo del incidente.
Si limpias el sitio antes de preservar evidencia, esa evidencia se pierde para siempre. No hay forma de recuperarla después.
Limpiar un sitio hackeado sin preservar evidencia es como limpiar la escena de un crimen antes de que llegue la policía. Puede que resuelvas el síntoma, pero pierdes la capacidad de entender qué pasó, quién lo hizo, y cómo prevenirlo en el futuro.
— Manuel Macedo, Mexico WordPress3. Protocolo forense: qué hacer en las primeras horas
Este es el protocolo que seguimos cuando un cliente reporta un hackeo. El orden es crítico: primero preservar, después contener, después limpiar.
Copia forense del sitio completo
Antes de tocar cualquier archivo, haz una copia completa del sitio: archivos, base de datos, logs del servidor, logs de acceso. Esta copia debe almacenarse fuera del servidor comprometido (S3, Backblaze, disco externo) y documentarse con fecha, hora y hash de verificación (MD5 o SHA-256). Esta es tu evidencia primaria.
Descarga de logs del servidor
Descarga los logs de acceso (access.log) y errores (error.log) del servidor. Estos logs contienen las IPs de origen, los archivos accedidos, y los timestamps de las actividades. Son críticos para reconstruir la línea de tiempo del incidente. Si tu hosting no te da acceso a los logs, solicítalos inmediatamente.
Documentación de la línea de tiempo
Documenta cuándo descubriste el hackeo, qué síntomas viste, y qué cambios notaste en las últimas 72 horas. Revisa los logs para identificar cuándo comenzaron las actividades sospechosas. Esta línea de tiempo es esencial para entender el alcance del incidente.
Contención: aislar el sitio
Una vez preservada la evidencia, aísla el sitio para evitar que el atacante siga accediendo o que el malware se propague. Esto puede incluir poner el sitio en modo mantenimiento, bloquear IPs sospechosas, o desconectar el sitio del dominio temporalmente.
Análisis de la brecha
Identifica cómo entraron: plugin vulnerable, contraseña débil, tema pirata con backdoor, credenciales comprometidas. Revisa los archivos modificados, los usuarios creados, y los procesos en segundo plano. Este análisis te dice qué cerrar para evitar reinfestación.
Limpieza y recuperación
Solo después de preservar evidencia y contener el incidente, procede con la limpieza: eliminar archivos maliciosos, remover usuarios sospechosos, restaurar archivos del core desde fuentes oficiales, actualizar plugins y temas vulnerables, y cambiar todas las contraseñas.
Informe forense (si aplica)
Si necesitas evidencia para una demanda o reclamación de seguro, solicita un informe forense documentado: copia forense con cadena de custodia, línea de tiempo del incidente, análisis de la brecha, y recomendaciones de seguridad. Este informe debe ser entendible por abogados y jueces, no solo por técnicos.
4. Casos reales: cuando limpiar primero fue un error
Sitio redirigido a casino online: el plugin nulled con backdoor
Síntoma: Un sitio corporativo de servicios profesionales redirigía a un casino online cuando los visitantes venían desde Google. El administrador no veía la redirección porque estaba condicionada al referrer.
Lo que hizo el cliente: Antes de contactarnos, el cliente intentó limpiar el sitio por su cuenta. Borró archivos sospechosos, eliminó usuarios desconocidos, y restauró desde un backup de hace 3 meses. El sitio volvió a funcionar, pero el cliente no sabía cómo habían entrado ni cuánto tiempo estuvieron dentro.
Lo que encontramos: Al revisar la copia forense que hicimos antes de limpiar, identificamos un plugin nulled (pirata) con un backdoor inyectado 6 meses antes. El atacante había estado accediendo al sitio durante 6 meses, extrayendo datos de formularios de contacto (nombres, correos, teléfonos de clientes potenciales). El cliente no tenía forma de saber qué datos fueron robados porque destruyó la evidencia al limpiar.
Lección: Si el cliente hubiera preservado evidencia antes de limpiar, podríamos haber identificado exactamente qué datos fueron robados, cuándo, y posiblemente quién. Sin evidencia, no hay forma de notificar a los clientes afectados ni de ejercer acción legal.
Google marca el sitio como "dañino": JavaScript malicioso en footer.php
Síntoma: Google marcó un sitio de ecommerce como "dañino" y mostraba una advertencia roja a los visitantes. El tráfico orgánico cayó un 90% en 48 horas.
Diagnóstico: Encontramos JavaScript malicioso inyectado en el archivo footer.php del tema. El JavaScript cargaba código desde un dominio externo que intentaba instalar malware en los visitantes.
Preservación de evidencia: Antes de limpiar, hicimos copia forense del sitio completo, descargamos los logs de acceso, y documentamos la línea de tiempo. Los logs mostraron que la inyección ocurrió hace 3 semanas, durante una actualización manual del tema hecha por un freelancer externo.
Resultado: Con la evidencia documentada, el cliente pudo ejercer acción legal contra el freelancer negligente. Además, el informe forense sirvió para solicitar la revisión de Google y eliminar la advertencia en 2 semanas. Sin evidencia, el cliente habría perdido tráfico permanentemente y no habría tenido forma de recuperar los daños.
5. Cuándo necesitas un informe forense-legal
No todos los hackeos requieren un informe forense-legal. Pero hay escenarios donde es crítico:
| Situación | ¿Necesitas informe forense? | Por qué |
|---|---|---|
| Sospechas que un ex-empleado hackeó tu sitio | Sí | Necesitas evidencia para demanda laboral o penal |
| Datos de clientes fueron robados (correos, teléfonos, direcciones) | Sí | Necesitas saber qué datos fueron robados para notificar a afectados (LFPDPPP) |
| Un competidor podría estar detrás del hackeo | Sí | Necesitas evidencia para demanda civil por competencia desleal |
| Reclamación de seguro cibernético | Sí | La aseguradora requiere evidencia documentada del incidente |
| Hackeo por plugin vulnerable sin sospechoso específico | Opcional | Útil para entender la brecha y prevenir reinfestación, pero no crítico legalmente |
| Sitio hackeado por ataque automatizado (bot) | No necesario | No hay sospechoso identificable. Enfócate en limpiar y fortalecer seguridad |
Un informe forense-legal profesional incluye: (1) copia forense del sitio con cadena de custodia documentada, (2) logs de acceso con sello temporal, (3) línea de tiempo del incidente, (4) análisis de la brecha (cómo entraron, qué hicieron, cuánto tiempo estuvieron dentro), (5) datos comprometidos (si es posible identificarlos), y (6) recomendaciones de seguridad. El informe debe ser entendible por abogados y jueces, no solo por técnicos.
6. Checklist de preservación de evidencia
Si tu sitio fue hackeado, pasa este checklist antes de limpiar nada:
| Acción | Prioridad | Cómo |
|---|---|---|
| Copia forense de archivos | Crítica | Comprimir todo el directorio de WordPress y almacenar fuera del servidor |
| Copia forense de base de datos | Crítica | Exportar SQL completo y almacenar fuera del servidor |
| Descarga de logs de acceso | Crítica | Solicitar access.log y error.log al hosting (últimos 30 días mínimo) |
| Documentación de síntomas | Crítica | Capturas de pantalla, descripciones escritas, fechas y horas |
| Línea de tiempo del incidente | Alta | Reconstruir con base en logs y cambios recientes |
| Identificación de usuarios sospechosos | Alta | Listar usuarios administradores creados recientemente |
| Identificación de archivos modificados | Alta | Comparar con archivos oficiales de WordPress.org |
| Hash de verificación de la copia forense | Recomendado | Generar MD5 o SHA-256 de la copia para verificar integridad |
Preserva primero, limpia después. Si no sabes cómo hacer una copia forense o no tienes acceso a los logs del servidor, solicita un análisis forense profesional antes de tocar cualquier archivo. La evidencia se pierde para siempre si la destruyes.
¿Tu sitio fue hackeado y necesitas preservar evidencia?
Hacemos copia forense del sitio completo, descargamos logs, documentamos la línea de tiempo del incidente, y te entregamos un informe entendible por abogados y jueces. Si necesitas evidencia para una demanda o reclamación de seguro, podemos ayudarte.
7. Preguntas frecuentes
Depende del alcance del incidente. Un análisis forense básico (copia forense, descarga de logs, línea de tiempo del incidente) toma entre 4 y 6 horas. Un análisis forense completo con informe legal (cadena de custody documentada, análisis de brecha, identificación de datos comprometidos) puede tomar 10-15 horas. El diagnóstico es pagado y se descuenta al 100% si contratas la limpieza y recuperación con nosotros. Solicita un análisis forense aquí.
Técnicamente sí, pero hay riesgos. Si no sabes cómo hacer una copia forense con cadena de custodia documentada, la evidencia puede no ser admisible en un proceso legal. Además, si tocas archivos o ejecutas comandos incorrectos, puedes alterar timestamps o destruir evidencia sin darte cuenta. Si necesitas evidencia para una demanda, lo más seguro es contratar a un profesional con experiencia en forense digital.
Los logs del servidor suelen rotarse cada 30 días (algunos hostings los guardan solo 7 días). Después de ese tiempo, los logs se borran permanentemente. Los archivos del sitio pueden ser sobrescritos por actualizaciones automáticas o por el atacante. La evidencia digital es frágil: cuanto antes la preserves, más completa será. Si descubriste el hackeo hoy, preserva evidencia hoy. Mañana puede ser demasiado tarde.
Sí, si está documentado correctamente. Un informe forense profesional incluye cadena de custodia, logs con sello temporal, y análisis técnico que puede ser presentado como evidencia en un proceso legal. En México, el acceso ilícito a sistemas es un delito federal (Artículo 211 bis del Código Penal Federal). Si puedes demostrar quién accedió, cuándo, y qué hizo, puedes ejercer acción penal. El informe debe ser entendible por abogados y jueces, no solo por técnicos.
Si ya limpiaste el sitio sin preservar evidencia, la evidencia original se perdió. No hay forma de recuperarla. Sin embargo, aún puedes hacer un análisis forense del sitio actual para identificar vulnerabilidades residuales, verificar que la limpieza fue completa, y documentar el estado actual. Este análisis no te da evidencia del hackeo original, pero te ayuda a prevenir reinfestaciones y a entender qué medidas de seguridad implementar. Solicita un análisis aquí.