Un ataque de ransomware no se limita a cifrar el equipo donde empezó. Si las credenciales comprometidas pueden acceder a un servidor, a volúmenes montados o a recursos compartidos, el incidente puede afectar datos de producción y copias que parecían estar separadas.
La recuperación depende de dos trabajos distintos: contener el acceso y demostrar que existe una copia íntegra que se puede restaurar. Una copia conectada y escribible desde el mismo entorno no ofrece la misma protección que un soporte aislado.
Cómo puede alcanzar un servidor
El acceso inicial puede proceder de una cuenta robada, una aplicación vulnerable, un servicio expuesto o un equipo desde el que se administra el servidor. No hace falta describir una técnica ofensiva para entender el riesgo: cualquier identidad con permisos amplios puede hacer que el impacto supere el sistema original.
Los volúmenes montados y las carpetas compartidas amplían el conjunto de datos accesibles. Si un proceso comprometido puede escribir en ellos, el cifrado o borrado puede propagarse hasta ubicaciones utilizadas para copias.
Por qué las copias conectadas están expuestas
Una copia montada permanentemente desde producción puede ser modificada con las mismas credenciales o permisos que el atacante obtuvo. También puede contener un software de gestión accesible desde la red afectada. La existencia de varias copias no basta si todas dependen del mismo usuario, dominio o ruta de acceso.
La estrategia 3-2-1 propone mantener varias copias en soportes y ubicaciones diferentes, con al menos una separada del entorno principal. El diseño concreto debe considerar cifrado, retención, control de acceso y la capacidad de restaurar sin reintroducir el compromiso.
Aislamiento, cuentas y mínimo privilegio
Separa las credenciales de producción y backup, limita quién puede borrar o modificar copias y evita que el servidor tenga acceso permanente a todo el repositorio. Un proceso que solo necesita escribir una copia no debería poder eliminar todas las versiones anteriores.
La segmentación reduce rutas de propagación, aunque no reemplaza la monitorización. Revisa accesos inusuales, cambios masivos de archivos, fallos de autenticación y modificaciones de políticas. Conserva registros fuera del sistema que podría verse comprometido.
Copias offline e inmutables
Una copia offline no está disponible para escritura durante la operación normal. Una copia inmutable impone un periodo en el que no puede modificarse o borrarse, según la tecnología y la configuración. Ninguna etiqueta sustituye a comprobar quién puede cambiar la política, cómo se conserva la clave y qué ocurre al restaurar.
Protege también el catálogo y la administración del backup. Si el mismo administrador controla producción y todas las copias, un robo de esa identidad puede neutralizar la separación aparente.
Restaurar por prioridades
Define qué servicios deben volver primero, qué dependencias necesitan y qué datos tienen prioridad. RPO expresa cuánto dato se está dispuesto a perder desde la última copia válida; RTO expresa cuánto tiempo se acepta hasta recuperar el servicio. Son objetivos de planificación, no promesas automáticas.
Una restauración debe realizarse en un entorno controlado, validar integridad y revisar que el acceso comprometido ha sido revocado. Recuperar archivos sin corregir la identidad o la vulnerabilidad puede reabrir el incidente.
Qué debe estar probado antes de necesitar una restauración
Programa pruebas periódicas con copias representativas y mide el tiempo real, los errores y la funcionalidad de la aplicación recuperada. Comprueba que se pueden localizar versiones anteriores, que las credenciales de recuperación están disponibles y que la copia no depende de un único administrador.
Las copias ayudan a recuperar, no impiden por sí solas el compromiso. La reducción del impacto exige actualizaciones, mínimo privilegio, segmentación, registros y un plan de respuesta que el equipo haya ensayado.
Contener antes de restaurar
Cuando se sospecha un cifrado masivo, desconectar sistemas afectados puede limitar propagación, pero debe coordinarse para no destruir evidencias ni interrumpir servicios críticos sin registro. Revoca credenciales sospechosas, separa la administración del backup y confirma qué copias están fuera del alcance del entorno comprometido.
No restaures sobre el mismo sistema sin revisar la causa inicial. Un servicio vulnerable, una cuenta activa o una tarea programada pueden volver a introducir el problema después de recuperar los archivos.
Integridad de la copia y alcance de la recuperación
Comprueba fechas, tamaños, hashes o mecanismos de verificación disponibles y valida que la versión elegida es anterior al incidente. La integridad del archivo no garantiza que la aplicación esté operativa: hay que recuperar configuración, base de datos, claves y dependencias de manera coordinada.
Prioriza servicios que soportan operaciones esenciales y documenta qué quedará temporalmente fuera. Comunicar una recuperación parcial es preferible a presentar como normal un sistema que todavía carece de controles o datos.
Separar recuperación y operación normal
Una restauración de emergencia no debería convertirse en la nueva configuración permanente sin revisión. Tras recuperar un servicio, vuelve a aplicar mínimos privilegios, rota credenciales y retira accesos temporales. Documenta qué datos fueron restaurados y qué quedó pendiente de validar.
La dirección necesita conocer los objetivos de recuperación y sus límites técnicos. Explicar que una copia existe no equivale a explicar cuánto tiempo tardará la recuperación ni qué pérdida de datos puede quedar entre dos puntos de respaldo.
Dependencias que también deben recuperarse
Una aplicación puede necesitar DNS, certificados, claves, colas y servicios externos además de sus archivos y base de datos. Incluye esas dependencias en la prueba y documenta cómo se obtienen tras aislar las credenciales antiguas. Restaurar solo el volumen principal puede producir un sistema aparentemente disponible que no puede operar.