Un ciberincidente rara vez comienza con un mensaje del tipo «te han hackeado». Normalmente, la primera señal es un inicio de sesión sospechoso en una cuenta corporativa, una regla inesperada de reenvío de correo, un agente EDR desactivado, un servidor inaccesible o la queja de un empleado por una solicitud inusual de autenticación multifactorial.
En ese momento, la organización aún desconoce el alcance del ataque. Pero son precisamente las primeras decisiones las que determinan si el incidente se quedará en un problema local o se convertirá en una crisis de varias semanas con paralización de la actividad empresarial, pérdida de datos y daño a la reputación.
El tiempo para tomar estas decisiones es cada vez más escaso. En los casos más rápidos investigados por Unit 42, los atacantes tardaron 72 minutos en pasar del acceso inicial a la descarga confirmada de datos. Esto es aproximadamente cuatro veces más rápido que un año antes. No se trata del tiempo medio de todos los ataques, sino de los casos más rápidos, pero este indicador ilustra bien hasta qué punto se ha reducido el margen de maniobra de los defensores. En nuestras propias investigaciones, hemos observado ataques contra la infraestructura de AWS que se completaron en menos de 10 minutos. El atacante, al obtener la clave, comenzaba inmediatamente a extraer los datos. Solo tardó 6 minutos en iniciar la extracción de datos del bucket de la empresa.
La respuesta adecuada en 2026 no consistirá en una carrera heroica del turno de guardia. Se trata de un proceso preparado de antemano y controlado que permite limitar rápidamente las acciones del atacante, conservar las pruebas, mantener las operaciones críticas y volver a poner los sistemas en funcionamiento sin que se vuelvan a ver comprometidos.
Qué habrá cambiado en 2026
El ataque ya no se limita a un solo sistema
Un atacante moderno puede utilizar simultáneamente la infraestructura local, una cuenta en la nube, el correo corporativo, aplicaciones SaaS y el acceso de un subcontratista.
Incluso tras aislar un portátil infectado, este puede seguir teniendo:
- una sesión en la nube activa;
- un token de actualización;
- un permiso OAuth;
- una clave de API;
- una cuenta de servicio comprometida;
- acceso administrativo delegado;
- canal de gestión alternativo a través de un servicio en la nube legítimo.
Según los datos de Unit 42, en el 87 % de los incidentes analizados fue necesario contrastar pruebas procedentes de al menos dos fuentes diferentes para determinar lo ocurrido y, en los casos más complejos, de hasta diez. Esto significa que la investigación ya no puede limitarse a un solo ordenador o a un único registro de eventos: es necesario analizar simultáneamente los datos de identificación, los puntos finales, la red, la nube y el SaaS. (Unit 42)
El modelo de «encontrar el archivo malicioso, eliminarlo y reinstalar el ordenador» ya no garantiza una contención completa.
Las identidades y las vulnerabilidades son igualmente importantes
Un incidente actual no tiene un único vector de intrusión universal.
Según los datos de Unit 42, el 65 % de las intrusiones iniciales en sus investigaciones estuvieron relacionadas con técnicas basadas en la identidad: datos de acceso robados, manipulación de la autenticación multifactorial (MFA), secuestro de sesiones, suplantación de identidad como empleado del servicio de asistencia técnica o abuso del acceso remoto legítimo. (Unit 42)
Al mismo tiempo, el DBIR 2026 de Verizon señala la explotación de vulnerabilidades de software como el principal vector inicial en su muestra: apareció en el 31 % de las filtraciones y, por primera vez, superó a las credenciales robadas.
Conclusión práctica: no se puede elegir entre la protección de identidades y la gestión de vulnerabilidades. Un programa de respuesta maduro debe abarcar ambos aspectos. El equipo debe ser capaz de revocar simultáneamente tokens y sesiones, analizar el acceso privilegiado, cerrar los servicios externos vulnerables y determinar qué vía concreta utilizó el atacante.
Los proveedores se han convertido en parte de la superficie de ataque
Según el informe DBIR 2026 de Verizon, los terceros estuvieron implicados en el 48 % de las filtraciones, un 60 % más que el año anterior. Como punto de entrada puede actuar un proveedor de software, un MSP, un integrador, un servicio en la nube o un subcontratista con acceso legítimo.
La organización debe saber de antemano:
- quién puede facilitar los registros del proveedor;
- con qué rapidez se le puede retirar el acceso;
- cuánto tiempo se conservan los datos de telemetría;
- qué acciones están permitidas por el contrato;
- quién es responsable de la comunicación;
- cómo conservar las pruebas en una infraestructura ajena.
Si estas cuestiones surgen por primera vez durante el ataque, el equipo ya está perdiendo un tiempo crucial.
El chantaje ya no requiere cifrado
El cifrado de la infraestructura sigue siendo una amenaza grave, pero ya no es un elemento obligatorio de las extorsiones. Los atacantes pueden sustraer datos y pasar directamente a amenazar con su publicación o venta, sin provocar los incidentes masivos de cifrado para los que están tradicionalmente preparados los sistemas de protección.
El ransomware estuvo presente en casi la mitad de las fugas analizadas en el DBIR 2026 de Verizon. Sin embargo, la ausencia de servidores cifrados no significa que el incidente sea insignificante: el acceso no autorizado al correo electrónico, al CRM, al almacenamiento de archivos o al entorno en la nube puede acarrear consecuencias financieras y reputacionales comparables.
La IA acelera a ambas partes
La IA ayuda a los atacantes a analizar más rápidamente la superficie de ataque, adaptar la ingeniería social, buscar vulnerabilidades y crear código malicioso. El informe DBIR 2026 de Verizon destaca 15 técnicas de ataque que ya se están potenciando mediante la IA generativa.
Los defensores, por su parte, utilizan modelos para correlacionar eventos, construir líneas temporales, agrupar alertas y preparar consultas para la búsqueda de amenazas.
Pero la automatización no sustituye a un proceso verificable. Una conclusión errónea tomada a toda prisa durante una crisis puede resultar tan peligrosa como una reacción lenta.
Nuevo marco: la respuesta comienza antes del incidente
En abril de 2025, el NIST publicó la SP 800-61, revisión 3, que sustituyó a la guía de 2012.
El principal cambio radica en que la respuesta a incidentes ya no se considera un proceso lineal independiente que se activa tras una alerta. Está integrada en el modelo general de gestión de riesgos cibernéticos NIST CSF 2.0 y está relacionada con sus seis funciones:
Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar.
La gestión de roles, el inventario de activos, la segmentación, las copias de seguridad, los contratos con proveedores y el registro de eventos no son medidas auxiliares, sino parte de la preparación ante incidentes. (Centro de Recursos de Seguridad Informática del NIST)
El 11 de junio de 2026, el NIST también publicó el IR 8374, Revisión 1: un perfil actualizado de gestión de riesgos de ransomware basado en el CSF 2.0. El documento integra la preparación, la protección, la respuesta y la recuperación en un único ciclo de gestión de riesgos. (Centro de Recursos de Seguridad Informática del NIST)
La conclusión principal es sencilla:
Una respuesta adecuada comienza mucho antes de la primera alerta.
Antes de que se produzca un incidente, la organización debe definir las funciones y competencias, preparar un canal de comunicación fuera de la red, garantizar un almacenamiento adecuado de los registros, proteger las copias de seguridad y comprobar los procedimientos de recuperación. También son necesarios manuales específicos para el ransomware, la compromisión del correo corporativo, la apropiación de cuentas en la nube, el robo de datos y los ataques a través de un subcontratista.
Los simulacros revisten especial importancia. Un plan que solo existe sobre el papel y que nunca se ha puesto a prueba bajo presión de tiempo no deja de ser una hipótesis, y no una herramienta de protección.
Los primeros 60 minutos: no se debe actuar a ciegas
Al inicio de un incidente, el equipo casi siempre dispone de información incompleta.
En ese momento, no solo son peligrosas las acciones del atacante, sino también las decisiones impulsivas de los defensores: el apagado masivo de servidores, el borrado prematuro de los sistemas, el cambio caótico de contraseñas o la restauración inmediata a partir de una copia de seguridad no verificada.
1. Nombra a un responsable del incidente
No se puede llevar a cabo una investigación seria a través de llamadas desordenadas, mensajes privados y decenas de chats paralelos.
Es necesario contar con un «response bridge» único y con un responsable del incidente designado: el Incident Commander.
No está obligado a realizar personalmente las operaciones forenses. Su tarea consiste en gestionar el proceso:
- mantener un plan único;
- asignar responsables a las tareas;
- resolver los conflictos de prioridades;
- consolidar las decisiones;
- sincronizar los flujos técnicos y de gestión;
- actualizar periódicamente el estado confirmado;
- supervisar la coordinación de las acciones críticas.
El especialista con mayores conocimientos técnicos no tiene por qué dirigir todo el incidente. Los analistas investigan el ataque, y el comandante del incidente evita que la investigación se convierta en un conjunto de acciones descoordinadas.
2. Recurre a un canal de comunicación de confianza
Si el correo corporativo, el sistema de identificación o la aplicación de mensajería pueden estar comprometidos, no se debe discutir la investigación a través de ellos.
Utilice un canal «out-of-band» preparado de antemano. No se debe transmitir a través de sistemas potencialmente comprometidos:
- planes de aislamiento;
- hipótesis de la investigación;
- nuevas contraseñas;
- claves y tokens;
- pruebas recopiladas;
- información sobre la comunicación con el atacante;
- decisiones internas de la dirección.
El atacante, al observar las acciones del equipo, tiene la oportunidad de cambiar de táctica, borrar rastros y preparar de antemano canales de acceso alternativos.
3. Confirma el incidente y determina su alcance inicial
No es necesario esperar a tener una visión completa de la situación para comenzar a reaccionar.
La evaluación inicial debe responder, como mínimo, a cinco preguntas:
- ¿Qué se ha detectado exactamente?
- ¿Qué usuarios, dispositivos y servicios pueden verse afectados?
- ¿Continúa la actividad del atacante?
- ¿Existe riesgo de que se interrumpa algún proceso crítico?
- ¿Hay indicios de robo de datos, destrucción de copias de seguridad o compromiso del acceso privilegiado?
La clasificación puede variar a medida que avanza la investigación. Lo importante es formular una hipótesis de trabajo y establecer prioridades lo antes posible.
Resulta útil diferenciar desde el principio entre hechos confirmados, conclusiones probables, hipótesis sin verificar y circunstancias desconocidas. Esto reduce el riesgo de que la suposición de un solo analista se convierta en la base de una decisión de gestión desastrosa.
4. Aísla las pruebas, pero no las destruyas
Aislar y desconectar no es lo mismo.
Por lo general, el host afectado debe desconectarse de la red mediante EDR, NAC, VLAN, un conmutador o una política en la nube. Pero, a menos que sea necesario, no conviene:
- apagar o reiniciar el equipo;
- eliminar archivos;
- ejecutar un análisis antivirus;
- reinstalar el sistema operativo;
- volver a poner el dispositivo en funcionamiento tras una comprobación superficial.
En la memoria RAM pueden encontrarse claves de cifrado, conexiones de red activas, procesos incrustados, tokens de acceso, comandos no registrados y rastros de las herramientas del atacante.
Pueden darse excepciones cuando el funcionamiento continuado del sistema suponga una amenaza inaceptable para las personas, la infraestructura crítica o la empresa. No obstante, dicha decisión debe tomarse de forma consciente y quedar registrada en el registro de incidentes.
5. Establece una línea temporal única
Anota cada evento relevante:
- la hora de la primera alerta;
- la fuente de la detección;
- el cambio de estado de los sistemas;
- las órdenes de los administradores;
- el aislamiento de los dispositivos;
- bloqueo de cuentas;
- exportación de registros;
- creación de instantáneas;
- decisiones adoptadas;
- responsables y personas que han dado su visto bueno a las acciones.
Utilice un único huso horario, preferiblemente UTC. Guarde los registros originales separados de las copias de trabajo, calcule las sumas de comprobación de los archivos recopilados y registre quién ha trabajado con las pruebas y cuándo.
Sin una línea temporal, la investigación se convierte rápidamente en un conjunto de recuerdos contradictorios.
6. Proteja las copias de seguridad
En un incidente de ransomware, los sistemas de copias de seguridad suelen ser uno de los primeros objetivos del atacante.
No inicie una restauración masiva hasta que se haya aclarado:
- si el atacante tiene acceso a la consola de copias de seguridad;
- si se han visto comprometidas las cuentas de los operadores;
- si se han eliminado las instantáneas;
- si se han modificado las políticas de almacenamiento;
- cuándo se produjo, presuntamente, la intrusión inicial;
- ¿contiene la copia seleccionada algún mecanismo de fijación?;
- si se han conservado copias aisladas o inmutables.
El estado «correcto» de la última tarea de copia de seguridad solo confirma que se ha creado la copia. No confirma que esté limpia y sea apta para una restauración segura.
En caso de incidente activo, el equipo DFIR de PWN-ALL puede hacerse cargo de la coordinación técnica: contención inicial, conservación de pruebas, determinación del alcance de la compromisión y preparación de un plan de recuperación seguro. La empresa cuenta con experiencia en casos de ransomware, robo de datos, BEC, suplantación de cuentas y compromiso de entornos en la nube.
La respuesta debe desarrollarse en flujos paralelos
Un error habitual es completar primero la investigación técnica y solo después involucrar a la dirección, a los abogados, a la aseguradora y a los propietarios de la empresa.
En un incidente real, estas vías deben desarrollarse simultáneamente.
Vía técnica
El equipo debe localizar al atacante, establecer el posible vector de entrada inicial, identificar los activos y las identidades afectadas, detectar los mecanismos de persistencia, evaluar la posible exfiltración de datos y preparar una recuperación segura.
Flujo de gestión
La dirección y los responsables de los procesos deben evaluar el impacto en el negocio, establecer las prioridades de recuperación, determinar la duración admisible del tiempo de inactividad y coordinar las medidas necesarias para detener los procesos críticos.
Flujo jurídico y de comunicación
Paralelamente, es necesario identificar a los propietarios de los datos afectados, comprobar las obligaciones contractuales, establecer los requisitos de notificación aplicables, ponerse en contacto con la aseguradora y preparar los comunicados internos y externos.
Los requisitos concretos varían en función del sector, los contratos y las jurisdicciones. Por ello, la evaluación jurídica no debe esperar al informe forense definitivo.
La tarea del equipo DFIR es proporcionar a este flujo de trabajo hechos técnicos verificables: la cronología, la lista de activos afectados, los indicadores confirmados, la evaluación del acceso inicial y la información sobre una posible exfiltración. La calificación jurídica definitiva corresponde a los asesores especializados de la organización.
Recuperación de identidades: recuperar el control sobre las identidades
En una infraestructura híbrida, no basta con restaurar el servidor. En primer lugar, la organización debe asegurarse de que vuelve a controlar su propio sistema de identificación.
Se deben comprobar:
- las cuentas privilegiadas y de emergencia;
- las sesiones activas y los tokens de actualización;
- los métodos de autenticación multifactorial (MFA) nuevos o modificados;
- las aplicaciones OAuth y los permisos concedidos;
- entidades de servicio e identidades de carga de trabajo;
- reglas de federación;
- políticas de acceso condicional;
- acceso administrativo delegado;
- claves de API, certificados y secretos de CI/CD;
- reglas de reenvío de correo;
- dispositivos registrados;
- acceso de los contratistas.
El cambio de contraseña no siempre cierra la sesión en la nube activa. Por ello, la rotación de credenciales debe ir acompañada de la revocación de tokens, el cierre de sesiones y la verificación de las aplicaciones de confianza.
Resulta especialmente peligroso llevar a cabo una rotación masiva desde un entorno administrativo comprometido.
En primer lugar, se crea un entorno de trabajo limpio con dispositivos verificados, un canal de comunicación independiente, cuentas controladas y un sistema de registro autónomo. Solo después de esto comienza la recuperación coordinada de identidades.
La nube y el SaaS requieren un plan de acción específico
Un incidente en la nube no puede investigarse como una infección habitual de una estación de trabajo.
Parte de las pruebas solo existe en los registros del proveedor y puede conservarse durante un tiempo limitado. En las primeras horas hay que conservar:
- los registros de inicio de sesión y de auditoría;
- el historial de cambios de IAM;
- los registros del plano de control;
- los eventos de correo electrónico y colaboración;
- los cambios en las políticas y las reglas de red;
- información sobre la creación de claves y tokens;
- instantáneas de discos y configuraciones;
- datos de aplicaciones SaaS conectadas mediante SSO u OAuth.
Por separado, es necesario comprobar la creación de nuevos administradores, los cambios en la federación, la emisión de tokens de larga duración, las autorizaciones de consentimiento de OAuth, la desactivación de políticas de seguridad, la puesta en marcha de nuevos recursos en la nube y la exportación de datos.
El procedimiento de escalación de emergencia al proveedor, las competencias de las partes y el procedimiento de conservación de la telemetría deben definirse de antemano.
PWN-ALL utiliza procesos independientes para investigar la compromisión de Microsoft 365, Google Workspace, la infraestructura en la nube y las cuentas corporativas. Esto permite analizar acciones que podrían no haber dejado rastros en los puntos finales tradicionales.
Cómo utilizar la IA durante una investigación
La IA puede acelerar:
- la normalización de eventos;
- la agrupación de alertas;
- la creación de una línea temporal;
- la preparación de consultas para la búsqueda de amenazas;
- la comparación de indicadores;
- búsqueda de anomalías;
- análisis de grandes conjuntos de registros;
- elaboración de informes provisionales.
Sin embargo, el modelo no debe tomar por sí mismo decisiones que puedan acarrear un daño potencial elevado.
Un proceso seguro implica el uso de un entorno controlado, la minimización de los datos sensibles, el registro de las consultas y respuestas, la verificación de las conclusiones por parte del analista y la vinculación de cada hipótesis a los datos de telemetría originales.
Sin una autorización adicional, no se puede encargar al modelo la desconexión de un segmento crítico, la eliminación de cuentas, la rotación masiva de claves, la destrucción de artefactos, la publicación de mensajes a los clientes o la conclusión definitiva sobre la ausencia de exfiltración.
La IA puede sugerir la dirección de la investigación. La responsabilidad de la conclusión recae en el ser humano.
La recuperación no es volver al estado anterior
La frase más peligrosa durante un incidente:
«Simplemente lo recuperaremos todo de la copia de seguridad».
Si se restaura la arquitectura anterior junto con las vulnerabilidades, los secretos comprometidos y los errores de configuración anteriores, el atacante podría volver.
Una recuperación segura se lleva a cabo por etapas:
- Se crea un entorno administrativo limpio.
- Se recupera el control sobre las identidades.
- Se cierra el vector de intrusión inicial.
- Se eliminan los mecanismos de persistencia.
- Se renuevan las claves secretas, las claves, los tokens y los certificados.
- Se comprueban las copias de seguridad.
- Se restablecen las dependencias críticas.
- Los sistemas se conectan por grupos controlados.
- En cada fase se comprueban la seguridad y el funcionamiento.
- Tras la puesta en marcha, se mantiene una supervisión reforzada.
El responsable del negocio confirma el funcionamiento del servicio, y el equipo de seguridad, la ausencia de indicios conocidos de que la compromisión continúe.
La disponibilidad del sistema no significa aún que el incidente haya concluido.
Como parte del proceso de recuperación, PWN-ALL evalúa las copias de seguridad limpias, la posibilidad de reconfigurar los sistemas, las opciones disponibles para el descifrado y la recuperación de claves, y a continuación establece las prioridades para volver a poner en funcionamiento la infraestructura. El resultado depende de la familia de ransomware, del estado de los sistemas, de las pruebas conservadas y de la calidad de las copias de seguridad, por lo que no se puede garantizar el descifrado completo ni la recuperación de todos los datos.
Si la organización se plantea pagar el rescate
Un enfoque profesional ante el ransomware no debe partir de la base de que el pago del rescate queda descartado bajo ninguna circunstancia.
En ocasiones, la dirección se plantea esta opción debido a una amenaza para la vida o la seguridad de las personas, la interrupción de procesos críticos, la falta de copias de seguridad válidas, el riesgo de una pérdida irreversible del negocio o el coste extremadamente elevado de un tiempo de inactividad prolongado.
Las recomendaciones oficiales no respaldan el pago: no garantiza la recuperación del acceso a los datos, la eliminación de la presencia maliciosa ni la supresión de la información robada. Además, la organización que haya pagado puede volver a ser objeto de un ataque.
No obstante, el pago no es una medida técnica, sino una decisión de gestión excepcional en situaciones de crisis.
En primer lugar, es necesario valorar las alternativas
Antes de tomar una decisión, hay que evaluar:
- la idoneidad de las copias de seguridad;
- la posibilidad de una recuperación parcial;
- la reconstrucción de los servicios críticos;
- los procesos manuales temporales;
- la disponibilidad de descifradores;
- la posibilidad de recuperar datos de otras fuentes;
- la duración admisible del modo de emergencia.
La afirmación del atacante de que el pago es la única salida no debe aceptarse sin una verificación técnica independiente.
PWN-ALL puede evaluar el estado real de la infraestructura y las copias de seguridad, estudiar la posibilidad de descifrar o recuperar las claves y proporcionar a la dirección una comparación de los escenarios posibles. La decisión final recae en los representantes autorizados de la organización afectada.
Es necesario determinar las consecuencias reales
No basta con comparar únicamente el importe del rescate y el coste de la recuperación.
Hay que tener en cuenta el impacto en las personas, la duración del tiempo de inactividad, la sostenibilidad de los procesos temporales, las consecuencias para los clientes y socios, la probabilidad de que se publiquen los datos, el coste de una recuperación segura y el daño a la reputación.
La decisión debe basarse en hechos contrastados, y no solo en las promesas y los plazos del atacante.
Las restricciones legales y sancionadoras se evalúan por separado
El destinatario, el grupo asociado, el intermediario o la infraestructura de pago utilizada pueden estar sujetos a restricciones sancionadoras o de otro tipo.
Las autoridades sancionadoras oficiales advierten expresamente de los riesgos a los que se exponen las empresas que facilitan los pagos de ransomware. Por lo tanto, las restricciones aplicables deben ser verificadas por asesores jurídicos y en materia de sanciones cualificados antes de emprender cualquier acción.
PWN-ALL se encarga de la parte técnica del proceso: recopila datos sobre la infraestructura del atacante, verifica sus afirmaciones, documenta las comunicaciones y facilita la documentación a la aseguradora y a los asesores especializados. La evaluación jurídica y la decisión sobre la transacción corresponden a la organización y a sus asesores autorizados.
La comunicación con el atacante debe estar controlada
La correspondencia directa con el extorsionador puede revelar la vulnerabilidad de determinados sistemas, la situación interna de la organización o los límites de sus capacidades.
Previo acuerdo, PWN-ALL puede supervisar la comunicación controlada, ayudando a:
- verificar si el atacante dispone realmente de los datos que afirma tener;
- solicitar un descifrado de prueba;
- evaluar el funcionamiento del descifrador;
- determinar la viabilidad técnica de las exigencias;
- ganar tiempo adicional;
- conservar un historial completo de los mensajes y las decisiones.
Este servicio de asistencia no sustituye a un análisis jurídico, no implica una recomendación de pago ni otorga al equipo de DFIR la facultad de tomar decisiones en nombre del cliente.
Es necesario verificar las afirmaciones del atacante
Antes de tomar una decisión definitiva, se podrá solicitar un descifrado de prueba de un conjunto limitado de archivos, una prueba de acceso a los datos alegados y una confirmación del funcionamiento de la herramienta propuesta.
Sin embargo, ni siquiera una verificación satisfactoria garantiza una recuperación completa.
El atacante podría proporcionar un descifrador inestable, descifrar solo una parte de los datos, conservar la información robada, transmitirla a otros participantes o volver a acceder a través del acceso que haya conservado.
Las herramientas recibidas deben analizarse y probarse en un entorno aislado.
Las negociaciones no detienen la investigación
La comunicación con el atacante no sustituye a la respuesta.
Paralelamente, es necesario continuar con:
- la localización de la amenaza;
- la búsqueda del vector inicial;
- la cancelación de las sesiones comprometidas;
- la rotación de claves;
- la protección de las copias de seguridad;
- recopilación de pruebas;
- comprobación del entorno en la nube;
- búsqueda de mecanismos de fijación;
- preparación de una recuperación segura.
Tras el pago, el incidente no se considera resuelto. De todos modos, es necesario limpiar o reconfigurar los sistemas, sustituir los datos de acceso comprometidos y eliminar los mecanismos de fijación.
El pago puede modificar un aspecto de la crisis, pero no elimina la compromisión ni sustituye a una recuperación segura.
Lo que no se debe hacer durante un incidente activo
Apagar toda la infraestructura sin un plan
Esto puede destruir pruebas volátiles, complicar el análisis y detener procesos no afectados. El aislamiento debe ser puntual o por segmentos y basarse en una evaluación de riesgos.
Reinstalar los sistemas antes de recopilar datos
El formateo rápido elimina los rastros del acceso inicial, el establecimiento de puntos de anclaje y los movimientos del atacante.
Declarar la victoria tras eliminar el malware
Un archivo malicioso puede ser solo una de las herramientas. Es necesario comprobar las identidades, las sesiones en la nube, los tokens, el acceso remoto, las reglas de correo electrónico, las aplicaciones SaaS y la infraestructura de gestión.
Considerar que el cambio de contraseña supone una contención total
El atacante puede conservar sesiones activas, tokens de actualización, autorizaciones OAuth o métodos alternativos de autenticación multifactorial (MFA).
Utilizar canales de comunicación comprometidos
El atacante puede leer los mensajes del equipo, adaptar sus tácticas y borrar sus rastros.
Ponerse en contacto por su cuenta con el extorsionador
Una comunicación sin preparación puede debilitar la posición negociadora, revelar la vulnerabilidad de los sistemas o generar riesgos legales y operativos adicionales.
Restaurar los sistemas antes de cerrar el punto de entrada
De lo contrario, la recuperación se convierte en un nuevo incidente.
Considerar que la ausencia de cifrado implica que no ha habido fuga
El robo de datos puede producirse a través de servicios en la nube legítimos y sesiones de usuario activas, sin generar los eventos característicos del ransomware.
Confiar en una copia de seguridad sin verificarla
La copia debe verificarse no solo en cuanto a su legibilidad, sino también en cuanto a su integridad, pureza y ausencia de mecanismos de fijación almacenados.
Publicar conclusiones no confirmadas
No se puede prometer que no haya habido ninguna fuga hasta que la investigación lo haya confirmado.
Declarar que el entorno está limpio por la ausencia de nuevas alertas
La ausencia de incidentes puede significar no que no haya ningún atacante, sino que la visibilidad es insuficiente.
Cómo medir la preparación
El número de alertas cerradas no dice prácticamente nada sobre la capacidad de la organización para sobrevivir a un ataque grave.
Indicadores más útiles:
- el tiempo transcurrido hasta la confirmación del incidente;
- el tiempo transcurrido hasta el nombramiento del comandante de incidentes;
- el tiempo hasta el primer aislamiento;
- el tiempo transcurrido hasta la cancelación de las sesiones comprometidas;
- tiempo de obtención de los registros en la nube;
- tiempo de verificación de una copia de seguridad limpia;
- porcentaje de sistemas críticos con telemetría suficiente;
- integridad de la línea temporal;
- tiempo de eliminación del vector inicial;
- porcentaje de medidas aplicadas tras la revisión posterior al incidente.
Es importante medir no solo la rapidez, sino también la calidad de las soluciones:
- cuántas acciones se llevaron a cabo sin un responsable asignado;
- cuántos cambios no se registraron en el registro;
- qué pruebas se han perdido;
- cuántos sistemas hubo que restaurar de nuevo;
- qué supuestos del plan de respuesta a incidentes (IR) resultaron ser erróneos.
Tras un incidente, no se necesita un documento formal que indique «se ha mantenido una reunión», sino un plan concreto de cambios con los responsables, los plazos y los criterios de verificación.
Nivel mínimo de preparación de la organización en 2026
Antes de que se produzca el incidente, la empresa debe contar con:
- un plan de respuesta a incidentes (IR) aprobado;
- una matriz de funciones y competencias;
- un canal de comunicación fuera de la red;
- guiones de actuación específicos para los principales escenarios;
- un mapa de los sistemas críticos y sus dependencias;
- un plazo de conservación de los registros suficiente;
- copias de seguridad inalterables y verificables;
- un procedimiento de conservación de pruebas;
- un entorno administrativo limpio;
- datos de contacto del equipo externo de DFIR;
- plantillas de comunicaciones internas y externas;
- procedimiento para tramitar las exigencias del extorsionador;
- simulacros periódicos de mesa y técnicos.
No solo debe evaluarse al equipo técnico. En los simulacros deben participar la dirección, el departamento de TI, el departamento de seguridad, los responsables de los procesos de negocio, los departamentos jurídico y de comunicación, la aseguradora, los proveedores clave y el socio externo de DFIR.
Un plan que nunca se haya probado en condiciones de tiempo limitado es una suposición, no un medio de protección.
La respuesta consiste en gestionar la incertidumbre
Durante un ataque, rara vez se consiguen todas las respuestas de inmediato.
Un equipo sólido no espera tener una certeza absoluta, pero tampoco actúa a ciegas. Separa los hechos de las hipótesis, toma decisiones reversibles siempre que sea posible, coordina las medidas de mitigación, conserva las pruebas, mantiene una línea temporal unificada y gestiona en paralelo los riesgos técnicos y empresariales.
No es posible hacer que un incidente sea totalmente predecible.
Pero sí se puede hacer que el trabajo del equipo sea predecible.
Cuándo se necesita un equipo de respuesta externo
PWN-ALL interviene en incidentes en los que son fundamentales la rapidez, la conservación de las pruebas y la recuperación controlada:
- ransomware y extorsión sin cifrado;
- robo y publicación de datos;
- BEC y compromiso del correo corporativo;
- suplantación de cuentas;
- comprometimiento de Microsoft 365 y Google Workspace;
- ataques a la infraestructura en la nube;
- piratería de aplicaciones web y servidores;
- incidentes a través de proveedores y subcontratistas.
El trabajo puede incluir medidas de contención de emergencia, la investigación forense digital, la determinación del alcance de la violación, la recopilación y conservación de pruebas, el estudio de opciones de descifrado, la verificación de copias de seguridad, el apoyo técnico a las comunicaciones controladas, la recuperación segura, la elaboración de informes y el refuerzo posterior de la seguridad. Para los incidentes activos, PWN-ALL cuenta con un proceso de respuesta específico que funciona las 24 horas del día.
En caso de incidente activo:
No apague los sistemas afectados, no elimine rastros, no responda al atacante por su cuenta y no inicie una recuperación masiva antes de la evaluación inicial.
La primera tarea consiste en limitar las acciones del atacante sin destruir la información necesaria para la investigación, la toma de decisiones y la reanudación segura de la actividad empresarial.