Ciberseguridad
Ransomware en Softland ERP: qué pasa con la base y cómo se sale
Un cifrado por ransomware no distingue entre la base de producción y el respaldo que quedó en la misma máquina. Qué se pierde, en qué orden y qué hace falta para volver a operar.
· 7 min de lectura · Equipo ERPBackup
Un ataque de ransomware sobre un servidor con Softland ERP no es un evento informático abstracto. Es la facturación detenida, las remuneraciones sin procesar y el inventario sin cuadrar, con el reloj corriendo.
Lo que sigue es la secuencia habitual y lo que realmente permite salir de ella.
Qué pasa en el servidor
El acceso inicial casi nunca es sofisticado. Suele ser un escritorio remoto publicado a internet con una contraseña débil, o un correo con un adjunto que alguien abrió desde un equipo de la red.
Una vez adentro, el atacante busca privilegios de administrador y recién ahí lanza el cifrado. Antes de hacerlo, en la mayoría de las familias de ransomware ocurren dos cosas que importan mucho para el respaldo:
- Se eliminan las instantáneas de volumen. Las Volume Shadow Copies de Windows son lo primero que se borra, justamente porque permitirían volver atrás sin pagar.
- Se cifra todo lo que el usuario comprometido puede escribir. Eso incluye
los archivos de datos de SQL Server, los
.bakque estaban en una carpeta del mismo servidor y las unidades de red mapeadas.
Ese último punto es el que sorprende a mucha gente. El respaldo existía. Estaba programado. Y quedó cifrado junto con la base, porque vivía en el mismo lugar y bajo las mismas credenciales.
Qué hace falta para volver a operar
Recuperarse de un cifrado sin pagar rescate requiere tres cosas, en este orden.
Una copia que el atacante no pudo tocar
Una copia en otro servidor, en una cuenta de nube distinta o en un medio que no
estaba montado al momento del ataque. Si la única copia estaba en el disco D:
del mismo servidor, no hay desde dónde volver.
Esto es exactamente lo que resuelve la regla 3-2-1: la copia que salva es la que está fuera.
Un servidor limpio
No se restaura sobre el equipo comprometido. Se levanta un servidor nuevo o se reinstala desde cero, se aplican parches y recién ahí se instala SQL Server y Softland. Restaurar sobre un sistema todavía infectado suele terminar en un segundo cifrado, esta vez con la copia buena ya montada.
Saber cuánto se perdió
Entre el último respaldo bueno y el momento del cifrado hay un intervalo de trabajo que no está en ninguna copia. Si el respaldo corre a las 02:00 y el ataque fue a las 16:00, se perdió un día de digitación.
Ese intervalo tiene nombre: es el RPO, el punto de recuperación. Definirlo antes del incidente es una decisión de negocio, no técnica. Determina cada cuánto conviene respaldar.
El orden práctico de la recuperación
- Aislar el servidor comprometido de la red. No apagarlo de inmediato si hay una investigación en curso, pero sí desconectarlo.
- Confirmar qué copias existen fuera del servidor y de qué fecha son.
- Levantar el equipo limpio, con SQL Server y Softland instalados.
- Restaurar las bases con las herramientas nativas de Softland, en el mismo procedimiento que usa el equipo de sistemas cualquier día.
- Recuperar también las carpetas de Terminal Server: formatos de impresión, informes personalizados y documentos de los usuarios (qué incluir).
- Reprocesar a mano lo que quedó en el intervalo perdido.
- Cerrar la puerta de entrada antes de volver a publicar el servicio.
Lo que un respaldo no hace
Conviene decirlo derecho: ninguna herramienta de respaldo evita una infección. El antivirus, los parches, el segundo factor y el control del escritorio remoto son otra capa, y siguen siendo responsabilidad del equipo de sistemas.
Lo que hace un respaldo automático fuera del servidor es garantizar que exista un punto al cual volver, y que ese punto sea de anoche y no del trimestre pasado. Eso convierte un incidente terminal en un mal día de trabajo.
En ciberseguridad de Softland detallamos qué parte cubre ERPBackup y cuál queda de tu lado.