El reflejo natural cuando descubres que te han atacado la web es limpiarla. Borrar el fichero raro, eliminar el usuario que no reconoces, restaurar la copia de ayer y seguir trabajando. Es comprensible y es, casi siempre, el motivo por el que dos semanas después vuelve a pasar.
Con las evidencias destruidas no hay forma de saber por dónde entraron. Y si no lo sabes, no has cerrado nada: has limpiado el síntoma.
Para qué sirven las evidencias
- Encontrar la vía de entrada y cerrarla, que es lo único que evita la reinfección.
- Saber qué datos se vieron afectados, que es de lo que depende si tienes que notificar a la Agencia y avisar a tus clientes.
- Denunciar, si decides hacerlo. Sin material, la denuncia es una declaración de intenciones.
- Reclamar al seguro o al proveedor, que te pedirán pruebas de lo ocurrido.
- Demostrar diligencia ante una inspección: haber investigado en serio es parte de lo que se valora.
Qué hay que conservar
| Evidencia | Por qué importa | Cuidado con… |
|---|---|---|
| Registros de acceso del servidor | La huella de la petición que explotó el fallo | Suelen rotarse cada 7-30 días: cópialos ya |
| Registros de errores de PHP | Marcan el momento y el fichero implicado | Se sobrescriben rápido |
| Copia completa de ficheros | Los ficheros modificados y sus fechas | Conserva las marcas de tiempo: usa una copia que las respete |
| Copia de la base de datos | Usuarios creados, contenido inyectado, opciones alteradas | Hazla antes de limpiar nada |
| Lista de usuarios y roles | Cuentas creadas durante el incidente | Exporta antes de borrar cuentas |
| Capturas de lo que se ve | La página modificada, el aviso del navegador, el resultado en el buscador | Con fecha y URL visibles |
| Correos implicados | Con cabeceras completas, no como captura | Reenviar pierde las cabeceras: guarda el original |
| Tareas programadas | Persistencia habitual | Anótalas antes de tocarlas |
Cómo conservarlas sin estropearlas
1. Primero copiar, después tocar
La regla de oro. Antes de borrar, restaurar o reinstalar: copia completa del estado actual, guardada fuera del servidor afectado, en un sitio de solo lectura para el resto del equipo.
2. No trabajes sobre el original
Investiga sobre una copia. El original se queda intacto, aunque el análisis se complique.
3. Anota una cronología
Un documento simple: hora, quién, qué hizo, qué observó. Incluye también lo que hiciste tú —cambiaste contraseñas, desactivaste plugins—, porque si no, dentro de tres días nadie sabrá qué cambios son del atacante y cuáles son tuyos.
4. Calcula huellas de los ficheros sospechosos
Un hash (SHA-256) de cada fichero raro te permite demostrar después que no ha cambiado, y buscarlo en bases de datos públicas de malware.
5. Guarda quién tuvo acceso a las evidencias
Si todo esto acaba en una denuncia o en una reclamación, importa poder decir dónde estuvo el material y quién lo manejó.
El error más caro que vemos: restaurar una copia de seguridad encima del sitio comprometido. En un movimiento se pierden los registros del ataque, los ficheros modificados y las fechas. Y como la copia suele ser posterior a la intrusión, además se restaura ya infectada.
Lo que puedes hacer sin destruir nada
Contener no es limpiar. Estas medidas son seguras y no borran pruebas:
- Poner la web en mantenimiento o restringir el acceso por IP.
- Cambiar contraseñas de administrador, del panel y de la base de datos, y cerrar sesiones abiertas.
- Regenerar las claves de seguridad del
wp-config.php. - Activar el segundo factor donde no lo hubiera: cómo hacerlo.
- Bloquear tráfico malicioso en el cortafuegos o en el CDN: qué puede hacer un WAF.
- Copiar los registros antes de que roten. Esto es lo más urgente de todo.
Cuánto tiempo guardarlas
Como mínimo, hasta que el incidente esté cerrado y hayan pasado los plazos de reclamación que puedan aplicarte. Si hay denuncia o expediente abierto, hasta que concluya. Y ten en cuenta que las evidencias pueden contener datos personales: guárdalas cifradas, con acceso restringido, y refléjalo en tu registro de tratamientos.
Cuándo pedir ayuda
Si hay datos personales de terceros afectados, si hay dinero de por medio, o si es la segunda vez que ocurre lo mismo, la investigación deja de ser un ejercicio de sentido común. En ese punto, lo barato es que alguien con experiencia mire los registros antes de que desaparezcan.
Ten el guion preparado por adelantado: quién hace qué y en qué orden está en el plan de respuesta a incidentes. Decidirlo en caliente es como se pierden las pruebas.
INCIBE-CERT atiende a empresas y puede orientarte sobre los primeros pasos si te coge sin nadie técnico al lado.
Seguir leyendo en esta sección
- Me han atacado la web: qué obligaciones legales tengo y en qué orden
- Notificar una brecha de datos a la AEPD en 72 horas: paso a paso
- Sanciones de la AEPD a pymes: por qué se ponen de verdad y cómo evitarlas
- Cómo comunicar una brecha a tus clientes sin perderlos
- Plan de respuesta a incidentes para una pyme: una página, cinco pasos
Ver todo en Brechas y obligaciones tras un incidente → · Mapa completo del sitio