
Si acabas de descubrir que los archivos de tu empresa no abren, que tienen extensiones desconocidas o que apareció una nota de rescate, esto es lo primero:

No pagues. No reinstales. No ejecutes herramientas de recuperación. Detén el daño y preserva la evidencia.
Un ataque de ransomware no es solamente un problema informático. Es una crisis de continuidad del negocio, de evidencia digital y de decisiones tomadas bajo presión.
El orden importa. Y suele ser diferente de lo que la intuición manda.
Primeros 15 minutos: contén el incidente, no la discusión
1. Aísla los equipos afectados
Impide que el equipo comprometido siga comunicándose con otros sistemas.
Si tu empresa tiene personal técnico, lo recomendable es bloquear su salida a Internet y segmentarlo desde el firewall o el router, sin alterar más de lo necesario la infraestructura.
Si no sabes cómo hacerlo, desconecta el cable de red o el WiFi. Perder temporalmente la conectividad es mejor que permitir que el incidente alcance otros equipos, servidores o respaldos.
No apagues el router de toda la empresa. No todos los equipos deben perder conectividad si solamente uno está comprometido.
2. Si el cifrado está avanzando, detén el equipo
Cuando los archivos continúan cifrándose, dejar el servidor encendido es dejar que el incendio avance.
En ese escenario, el apagado inmediato puede ser la medida menos mala. Si el ataque está ejecutándose localmente, desconectar Internet no detiene el cifrado.
No utilices Inicio → Apagar. Un malware puede ejecutar acciones durante el cierre normal del sistema. El apagado forzado es una medida de contención, no una ceremonia de administración ordinaria.
Esta decisión tiene un costo: también puede perderse información volátil de la memoria RAM. Si hay especialistas disponibles y tiempo para preservarla antes, conviene hacerlo. Pero cuando el cifrado sigue activo, detener el daño suele ser prioritario.
3. No investigues desde el equipo comprometido
No abras el navegador. No instales antivirus nuevos. No descargues recuperadores. No ejecutes scripts. No compruebes “a ver qué archivos se perdieron” abriendo carpetas una por una.
Cada acción puede modificar registros, fechas, procesos y evidencia que después necesitarás para reconstruir lo ocurrido.
Tampoco formatees ni borres el malware todavía. Antes de limpiar, hay que preservar.
4. Documenta lo que está sucediendo
Desde un dispositivo limpio, registra:
La fecha y la hora de detección no son un trámite administrativo: marcan el punto a partir del cual las decisiones pueden cambiar la evidencia. Identifica cada equipo afectado, las extensiones anómalas y el texto exacto de la nota de rescate sin abrir archivos para comprobarlos uno por uno. Registra también qué usuarios tenían acceso, qué herramientas remotas estaban instaladas y qué servidores, NAS o respaldos podían verse alcanzados. Esa relación permite separar el incidente visible del alcance real.
La cronología debe incluir quién desconectó cada componente, cuándo lo hizo y con qué propósito. Si una persona apagó un servidor y otra restauró una copia, esas acciones forman parte de la historia técnica. No las presentes como prueba de responsabilidad: son medidas que explican qué cambió después del ataque y por qué algunos rastros pueden faltar.
En un caso real, una empresa amaneció con su información cifrada y la primera reacción fue desconectar el servidor de la red. El gesto parecía suficiente, pero el proceso ya se ejecutaba dentro del equipo y siguió trabajando sin Internet. La revisión también encontró decenas de miles de intentos de acceso externo que no habían sido bloqueados, credenciales que llevaban años sin rotarse y accesos remotos que seguían disponibles.
El arreglo de discos había replicado fielmente el daño: redundancia, sí; respaldo histórico, no. La recuperación se trabajó sobre una copia y permitió rescatar casi toda la información, pero ese resultado no convierte cada incidente en una promesa de recuperación. Lo que sí demuestra el caso es que apagar, aislar, preservar y reconstruir son decisiones distintas que deben tomarse en el orden correcto.
Si diriges una empresa, anota quién hizo cada movimiento y no uses el servidor afectado para investigar. Si eres abogado, pide que esa cronología distinga el ataque de las acciones posteriores de contención. El servicio pericial sirve aquí para entender la puerta de entrada y recuperar sin borrar la escena, no para señalar al administrador más cercano.
Conviene conservar esa documentación en un dispositivo limpio y con acceso restringido. No necesitas preparar un informe perfecto mientras el incidente avanza; necesitas hechos suficientemente claros para que otra persona pueda reconstruirlos sin depender de recuerdos contradictorios.
Toma fotografías de lo visible sin alterar el sistema. Una cronología escrita a mano vale más que veinte recuerdos contradictorios dentro de una semana.
Lo que nadie debería aprender a la mala: desconectar no siempre es contener
Es como cerrar la puerta de la oficina mientras el ladrón sigue encerrado dentro: ya no puede llamar a nadie, pero continúa rompiendo todo lo que encuentra.
Si el ransomware ya se ejecuta en memoria, no necesita Internet para seguir cifrando.
En ese mismo incidente, el arreglo RAID replicó el cifrado en los discos. Eso no era un respaldo: era una copia exacta del desastre.
También existían acceso remoto desatendido, una cuenta administrativa activa durante años y credenciales almacenadas en el navegador. El atacante no tuvo que derribar la puerta. Encontró las llaves debajo del tapete.
Después de contener: protege cuentas y respaldos
5. Cambia credenciales desde un equipo limpio
Utiliza un dispositivo que no esté comprometido y, según el alcance del incidente:
- Cambia contraseñas de administradores y usuarios.
- Revoca sesiones activas.
- Renueva tokens y accesos remotos.
- Desactiva cuentas que no deberían estar habilitadas.
- Activa un segundo factor de autenticación.
- Revisa reglas de buzón y delegaciones de correo.
- Considera comprometidas las credenciales que estuvieron en el equipo atacado.
No cambies solamente la contraseña de Windows y declares la crisis terminada. Si el atacante obtuvo credenciales, puede conservar otros accesos.
6. Revisa herramientas de acceso remoto
AnyDesk, TeamViewer, SimpleHelp y otras herramientas legítimas pueden convertirse en la puerta de entrada si están mal configuradas.
Revisa:
- Acceso desatendido.
- Contraseñas compartidas.
- Inicio automático.
- Permisos administrativos.
- Reglas de firewall.
- Cuentas creadas por el atacante.
- Segundos mecanismos de acceso remoto instalados para mantener persistencia.
No las elimines antes de documentar su configuración y sus registros. Primero evidencia; después remediación.
7. Desconecta los respaldos para protegerlos
Un respaldo conectado al equipo comprometido también puede cifrarse.
Desconecta discos externos, unidades compartidas y sistemas de copia que puedan resultar alcanzados. No los conectes “solo para comprobar si sobrevivieron” mientras el entorno no esté controlado.
Y recuerda:
RAID no es respaldo. Es redundancia.
Si borras un archivo, RAID borra dos. Si cifras un archivo, RAID cifra dos. Es como hacer dos fotocopias del incendio: tienes dos copias del incendio.
Un respaldo útil debe estar separado, protegido y, preferentemente, en una versión que el atacante no pueda modificar.
¿Debes pagar el rescate?
No tomes esa decisión en pánico ni negocies solo.
Pagar no compra archivos recuperados. Compra una promesa del atacante. No existe garantía de que entregue la clave, de que funcione o de que no vuelva a pedir dinero.
Antes de decidir:
- Preserva la nota y las comunicaciones.
- Identifica la variante del ransomware cuando sea posible.
- Evalúa el estado real de los respaldos.
- Consulta al equipo jurídico y al asegurador, si existe cobertura.
- Documenta el incidente ante la autoridad correspondiente.
- Evalúa recuperación, reconstrucción y continuidad del negocio.
La urgencia es real, pero una mala decisión puede convertirla en dos urgencias: la pérdida de información y la pérdida del dinero.
¿Se puede recuperar la información?
Depende de la variante, del cifrado, de los respaldos y del estado de la infraestructura.
Algunas familias tienen descifradores públicos para versiones concretas. Otras no permiten recuperación sin la clave del atacante.
No instales cualquier “descifrador milagroso”. Una empresa en crisis también es un blanco atractivo para quienes distribuyen malware disfrazado de solución.
La recuperación puede incluir:
- Restauración desde respaldos independientes.
- Reconstrucción de sistemas limpios.
- Recuperación parcial de archivos.
- Revisión de instantáneas o versiones anteriores.
- Análisis forense de discos y registros.
- Reconstrucción manual de información crítica.
Reinstalar no siempre es recuperar. A veces solamente es borrar la escena y seguir sin respuesta.
¿Hubo robo de datos?
No lo asumas.
Que un ransomware haya cifrado información no significa necesariamente que también la haya extraído. Son dos preguntas distintas:
- ¿Qué información quedó inaccesible?
- ¿Qué información salió de la infraestructura?
La respuesta debe buscarse en registros, conexiones, historiales, servicios y otras fuentes. No en la nota del atacante, que puede afirmar lo que le convenga.
Con esa investigación podrás evaluar, junto con asesoría jurídica, qué obligaciones de documentación, notificación y protección de datos aplican a tu caso.
Lo que debes corregir para que no vuelva a suceder
Cuando el incidente esté controlado, revisa al menos estos puntos:
- Cuentas administrativas integradas habilitadas innecesariamente.
- Contraseñas sin rotación.
- Acceso remoto desatendido.
- Ausencia de segundo factor.
- Servidores utilizados para navegación general.
- Credenciales guardadas en navegadores.
- Red plana, sin segmentación.
- Registros que nadie revisa.
- Respaldos que nunca se han restaurado.
- Ausencia de un procedimiento escrito de respuesta.
Un plan de respuesta no es un documento que se guarda para cumplir. Es algo que se ensaya antes de necesitarlo, como un simulacro de incendio, no como una lectura posterior al funeral.
Una precisión útil antes de restaurar
En un secuestro de datos o cifrado malicioso, restaurar no debe ser la primera acción automática. La empresa necesita saber si persisten accesos del atacante, qué respaldos están aislados y qué información volátil puede perderse al apagar. Dirección necesita continuidad; el abogado necesita que cada cambio quede documentado. El servicio pericial delimita esas decisiones, sin convertir la recuperación en una demostración pública de herramientas.
