INFOTEP Técnico en Ciberseguridad study materials
INFOTEP Técnico en Ciberseguridad study resources

Ransomware en el centro de contacto: respaldo cifrado y presión operativa

INFOTEP Técnico en Ciberseguridad · Put your knowledge to work in context.

All case studies

Ransomware en el centro de contacto: respaldo cifrado y presión operativa

A las 02:40 del domingo, el monitoreo alerta sobre el servidor de archivos de un centro de contacto en Santo Domingo con 500 agentes. Los archivos tienen extensión .loked y hay una nota con una dirección de correo. El NAS de respaldo, que replicaba cada hora, también está cifrado: usaba la misma cuenta de dominio con privilegios de administrador y estaba accesible por SMB desde toda la red. El respaldo en la nube contratado hace un mes sigue sincronizando en este momento. El jefe de operaciones pide restaurar de inmediato para abrir a las 07:00 y «dejar el servidor encendido por si el atacante se arrepiente». La empresa guarda grabaciones de llamadas y datos de clientes de dos bancos, tiene dos analistas y no cuenta con perito forense ni seguro cibernético. Nadie ha revisado todavía los registros del controlador de dominio.

1. ¿Cuáles son las primeras cuatro acciones y en qué orden? Justifique el orden.

Read the worked answer

1. Contener sin apagar. Aislar de la red el servidor de archivos y el NAS (desconectar el cable o deshabilitar el puerto del switch). No apagar: el cifrado puede seguir en curso y el proceso malicioso puede estar replicándose, pero apagar destruye la memoria volátil (claves, procesos, conexiones), que es la evidencia más perecedera. El orden se justifica porque el incidente sigue activo: primero se detiene la propagación, después se recoge.

2. Salvar el respaldo en la nube. Detener la sincronización antes de que la réplica sobrescriba las versiones limpias y verificar si hay versiones inmutables o con bloqueo de objetos y de qué fecha. Es una cuenta atrás: cada hora que sincroniza puede destruir la única copia buena.

3. Determinar el alcance antes de tocar nada más. Revisar el controlador de dominio (cuentas creadas, cambios de grupo, golden ticket), buscar la misma cuenta en otros equipos, revisar correos y el punto de entrada probable. Sin alcance no se puede afirmar que un equipo restaurado esté limpio.

4. Activar el plan y escalar. Designar un coordinador, abrir bitácora con hora y responsable de cada acción, contactar a asesoría legal y a los dos bancos por obligaciones contractuales, y evaluar la denuncia. Con dos analistas y sin perito, hay que decidir rápido si se contrata apoyo forense externo.

El error clásico es invertir el orden: restaurar antes de contener y de conocer el alcance garantiza la reinfección.

2. Evalúe las dos instrucciones del jefe de operaciones: restaurar de inmediato y dejar el servidor encendido.

Read the worked answer

«Restaurar de inmediato»: técnicamente riesgoso. El NAS estaba replicando con la misma cuenta de administrador de dominio, así que sus copias pueden estar dentro de la ventana de persistencia del atacante o ya cifradas. Restaurar sin verificar la integridad del respaldo y sin erradicar la causa (credenciales de dominio comprometidas, persistencia instalada) devuelve los datos a una infraestructura todavía controlada por el atacante: la reinfección suele ocurrir en horas y consume la única copia buena. La secuencia correcta es verificar el respaldo, limpiar credenciales y persistencia, y restaurar en un entorno aislado y validado.

«Dejar el servidor encendido»: parcialmente correcto, con un matiz crítico. Encendido preserva memoria y evidencia, eso es cierto. Pero encendido y conectado permite que el atacante siga cifrando, exfiltre datos o use el equipo como pivote. La respuesta es aislado de red, energizado. La instrucción verbal del jefe es una intuición útil mal formulada.

El conflicto real es de negocio, no técnico. El RTO de 07:00 es una decisión de la dirección y debe quedar documentada como tal, con su costo: abrir con procesos manuales, priorizar los servicios de los dos bancos o aceptar la interrupción. Lo que no corresponde es que la presión horaria redefina el orden de contención. Conviene pactar por escrito con operaciones un objetivo de restablecimiento realista y una comunicación a los clientes, en lugar de improvisar a las 03:00.

3. ¿Debe pagarse el rescate? ¿Qué consideraciones legales y de evidencia aplican?

Read the worked answer

Sobre el pago La recomendación técnica es no pagar, con argumentos concretos:

  • No hay garantía de descifrado ni de que la clave funcione con todos los archivos.
  • Financia la actividad criminal y marca a la organización como pagadora, lo que invita a un segundo ataque.
  • Puede infringir regímenes de sanciones si el grupo está listado, lo que expondría a la empresa y a sus bancos.
  • No resuelve la doble extorsión: los datos probablemente ya fueron exfiltrados y el silencio se compra aparte.

La decisión final es del negocio con asesoría legal, no del analista; lo que corresponde a TI es entregar la evaluación de recuperación real desde respaldo verificado.

Obligaciones y consideraciones legales

  • Hay datos personales y grabaciones de clientes de dos bancos: existen deberes contractuales de notificación y deber general de custodia y confidencialidad sobre datos personales.
  • Corresponde evaluar la denuncia ante la autoridad competente y notificar a los afectados según lo que determine la asesoría jurídica.
  • No se deben borrar registros ni comunicaciones: son prueba y su destrucción agrava la responsabilidad.

Evidencia y cadena de custodia Documentar quién tocó cada equipo, cuándo y para qué; calcular hash de las imágenes forenses; conservar la nota de rescate, los correos y los registros originales; no negociar con el atacante por canales improvisados. Sin perito propio ni seguro, conviene contratar apoyo externo y dejar constancia de esa decisión y de su fecha.