Respuesta a incidentes DFIR: web hackeada, qué hacer

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Descubrir que tu web está hackeada produce el mismo impulso en casi todo el mundo: entrar corriendo al panel, borrar lo que parezca sospechoso y «dejarlo limpio» cuanto antes. Es exactamente lo que no debes hacer. Cada minuto de reacción improvisada destruye evidencia, alerta al atacante y, con demasiada frecuencia, deja la puerta por la que entró abierta de par en par. La respuesta a incidentes —lo que en el sector llamamos DFIR, por Digital Forensics and Incident Response— existe precisamente para sustituir ese pánico por un método.

Esta página es el punto de partida del recorrido completo: qué significa responder a un incidente con criterio, en qué orden se hacen las cosas y por qué ese orden no es negociable. Desde aquí enlazamos a las guías operativas específicas —primeras 24 horas, análisis de logs, restauración y limpieza— para que puedas ir del marco general al procedimiento concreto que necesites en cada momento.

Qué es la respuesta a incidentes (DFIR) y por qué el orden importa

DFIR combina dos disciplinas que en la práctica van juntas. La informática forense preserva y analiza la evidencia para entender qué pasó, cómo entró el atacante y qué tocó. La respuesta a incidentes ejecuta las decisiones que devuelven el control del sistema y reducen el daño. Separarlas es un error: si limpias antes de investigar, pierdes las pruebas que te dirían por dónde volverán a entrar.

El estándar de referencia internacional, la guía NIST SP 800-61 de manejo de incidentes, organiza el proceso en fases encadenadas. La secuencia importa porque cada etapa depende del trabajo bien hecho en la anterior. Contener antes de entender el alcance deja piezas fuera; erradicar sin haber contenido permite al atacante reaccionar; recuperar sin haber erradicado te devuelve a la casilla de salida con una reinfección en cuestión de horas.

El ciclo DFIR de un vistazo

Fase	Objetivo	Pregunta que responde
Preparación	Tener copias, accesos y contactos listos antes del incidente	¿Puedo actuar sin improvisar?
Detección y análisis	Confirmar el compromiso y medir su alcance	¿Qué ha pasado y hasta dónde llega?
Contención	Frenar la propagación y el daño en curso	¿Cómo detengo la hemorragia?
Erradicación	Eliminar la causa raíz y toda persistencia	¿Cómo me aseguro de que se ha ido?
Recuperación	Restaurar el servicio de forma verificada	¿Cómo vuelvo a operar sin reinfectarme?
Lecciones aprendidas	Cerrar el vector y mejorar la postura	¿Cómo evito que se repita?

Las primeras horas: contener no es borrar

La ventana inicial define casi todo lo que viene después. En esas primeras horas el objetivo no es dejar la web bonita, sino preservar la evidencia y frenar el daño activo: aislar el sitio si hace falta, tomar una instantánea del estado actual, revocar sesiones y credenciales, y empezar a acotar qué se ha comprometido. Borrar ficheros en caliente en este punto es tirar a la basura la información que te dirá cómo entraron.

Si estás en mitad de un incidente ahora mismo, empieza por el protocolo concreto de qué hacer en las primeras 24 horas tras una web hackeada: es la guía DFIR para pymes que traduce esta fase en pasos accionables sin destruir pruebas por el camino.

Detección y análisis: de los logs a los IoC

No puedes responder a lo que no entiendes. Antes de tocar nada de forma irreversible hay que reconstruir la historia del ataque, y esa historia casi siempre está escrita en los registros del servidor. Los indicadores de compromiso (IoC) —una IP que aparece justo antes de la primera subida maliciosa, un user-agent anómalo, peticiones POST a un fichero que no debería existir, un pico de tráfico a horas imposibles— son las migas de pan que te llevan al punto de entrada.

Dos lecturas encadenadas cubren esta fase. Primero, qué buscar en el access.log tras un ataque, para saber leer el registro y separar el ruido de la señal. Después, cómo priorizar las señales de un informe, porque encontrar cien indicadores no sirve de nada si no sabes cuáles atacar primero. Analizar bien aquí es lo que evita que la erradicación deje flecos.

Cuando el análisis define la magnitud legal

No todos los incidentes son iguales ante la ley. Si en el compromiso hay datos personales, el deber de notificar una brecha a la autoridad de protección de datos puede activarse en un plazo de 72 horas. Y si hablamos de datos de tarjeta, el marco PCI DSS impone obligaciones adicionales de contención, forense y notificación al adquirente. El análisis no es solo técnico: determina qué tienes que declarar y a quién.

Erradicación: eliminar la causa, no solo el síntoma

Aquí es donde se juega la partida. Erradicar significa quitar toda la presencia del atacante: el webshell, sí, pero también las puertas traseras replicadas en directorios de uploads, las tareas programadas que reinyectan el malware, los usuarios administradores creados de forma silenciosa, las claves SSH añadidas y el fichero legítimo que fue modificado para cargar código malicioso. Si dejas una sola de esas piezas, no has erradicado: has hecho una limpieza cosmética que durará hasta la próxima ejecución del cron.

La causa raíz importa tanto como los artefactos. Un plugin desactualizado, una credencial robada por un infostealer, un permiso de fichero mal configurado: si el vector sigue abierto, la reinfección es cuestión de tiempo. Por eso la erradicación honesta obliga a responder cómo entraron, no solo qué dejaron.

Limpiar sin tumbar el negocio

Una tienda que factura no puede estar días fuera de servicio, pero limpiar en producción tiene riesgos reales. La decisión entre trabajar en caliente o clonar a un entorno de staging depende del tipo de incidente y de tu tolerancia a la parada. Lo desarrollamos en limpiar malware sin tumbar tu web: limpieza en caliente vs. staging, con los criterios para elegir bien en cada caso.

Recuperación: restaurar sin reinfectarte

La recuperación es la fase que más falsos finales provoca. «Restauro la copia de seguridad y listo» es el error más caro del sector, porque casi nadie sabe cuándo entró el atacante. Si el backup es posterior a la intrusión, estás restaurando el propio compromiso; si la puerta de entrada sigue abierta, te reinfectan sobre la copia limpia. Por eso decimos que el backup, por sí solo, no basta.

Hazlo bien con estas tres guías, según tu plataforma y tu punto de partida:

• Restaurar desde copia de seguridad sin reinfectarte: cómo verificar que la copia es anterior al compromiso y por qué el backup no basta.
• Restaurar un WordPress desde cero tras un incidente: reconstrucción limpia paso a paso cuando la copia no es fiable.
• Plan de recuperación tras un hackeo: de la contención a estar 100% operativo, con el orden completo de vuelta al servicio.

La regla de oro: no se restaura hacia un entorno que aún no has erradicado, y no se declara «recuperado» un sistema que no has monitorizado durante días buscando reapariciones. La recuperación termina cuando puedes demostrar que el atacante ya no vuelve, no cuando la web carga.

Cuando hay datos de tarjeta: e-commerce y PrestaShop

Los incidentes en tiendas online tienen un agravante: además del daño operativo, puede haber robo de datos de pago. Los skimmers web —código inyectado que captura los datos de la tarjeta en el propio formulario de pago, al estilo Magecart— son sigilosos por diseño: la tienda funciona con normalidad mientras exfiltra tarjetas en segundo plano. Detectarlos y responder exige forense específico y una cadena de custodia impecable, porque la investigación puede acabar ante un adquirente, una aseguradora o un juzgado.

Para el ecosistema PrestaShop, que concentra buena parte del e-commerce hispano, tenemos dos recorridos complementarios:

• Robaron tarjetas en mi PrestaShop: peritaje forense y respuesta al incidente, cuando la prioridad es entender el alcance del robo y responder a las obligaciones legales.
• Limpiar una tienda PrestaShop hackeada, para eliminar el malware y aplicar el hardening posterior que evita la reincidencia.

Lecciones aprendidas: cerrar el ciclo

Un incidente bien gestionado deja tu web más segura de lo que estaba, no solo tan segura como antes. La última fase —la que casi todo el mundo se salta— es la que convierte un mal día en una mejora real: documentar el vector, aplicar el hardening que cierra esa puerta concreta, revisar la política de copias, endurecer credenciales y accesos, y establecer una monitorización que detecte la próxima anomalía en horas, no en semanas. Organismos como INCIBE publican guías de referencia para pymes que ayudan a formalizar este cierre.

Responder a un incidente no es un acto de limpieza, es un proceso de investigación con método. Contener sin destruir evidencia, entender antes de erradicar, erradicar la causa y no el síntoma, y recuperar sin reinfectarte: ese es el camino que separa una web «que vuelve a cargar» de una web de la que puedes fiarte. Cada enlace de esta página lleva al procedimiento concreto de una de esas etapas.