Trauma Zer0
ES

EDR apagado y logs borrados: la evidencia que queda

El ransomware ya apaga el EDR y borra los logs antes de cifrar. Si la evidencia estaba solo en el equipo atacado, se perdió. Vea qué debe quedar fuera.

Diagrama con tres tarjetas blancas dentro de un grupo punteado, rotulado 'en el equipo atacado' — EDR detenido, log borrado y AnyDesk nuevo, cada una con un punto de alerta —, unidas por una flecha a una tarjeta azul del servidor de la empresa, dentro de la red, con alertas de protección apagada y equipo en silencio, Event Log ya leído y caso sellado con SHA-256.

A las dos de la madrugada, la consola mostraba todo el parque protegido. A las tres, seguía igual. Solo que, a esa altura, la mitad de los equipos ya no le enviaba nada.

Así empiezan muchos ataques de ransomware en 2026. El intruso no intenta pasar inadvertido ante la herramienta de seguridad: la apaga, limpia el registro de eventos y recién después pasa al cifrado.

Para quien responde por un parque grande, la pregunta cambia de lugar. No alcanza con saber si la defensa frena el ataque. Hay que saber qué se puede probar todavía cuando no lo frena, y dónde estaba guardada esa prueba.

Tumbar la defensa se volvió el primer paso

Cisco Talos publicó el 29 de octubre el balance de sus casos de respuesta a incidentes del tercer trimestre de 2026. Ransomware y pre-ransomware representaron el 27% de los casos, por encima del máximo de 20% de los cuatro trimestres anteriores.

El mismo informe dice que, en la mayoría de los casos, los atacantes eligieron desactivar el EDR, muchas veces explotando drivers vulnerables o aplicando en su contra una política de WDAC (el control de aplicaciones del propio Windows).

Y la principal debilidad encontrada fue el registro insuficiente, que dejó huecos de visibilidad en más del 40% de los casos, en parte por la práctica habitual de borrar los logs.

Una semana después, el 5 de noviembre, el equipo de búsqueda de amenazas de Symantec describió un ataque de octubre contra una organización de Estados Unidos. En cerca de una hora, los atacantes lanzaron al menos 13 ejecutables para detener servicios de seguridad, 11 de ellos nunca vistos, junto con cinco drivers vulnerables conocidos.

También configuraron AnyDesk para seguir funcionando cuando Windows arrancara en Modo seguro, donde las protecciones suelen quedar afuera.

En ese caso, el cifrado fue bloqueado. Aun así, la organización tuvo que responder qué pasó antes del bloqueo: en qué equipos, con qué cuenta, durante cuánto tiempo.

Por qué la evidencia local desaparece con él

Si el registro vive solo en el equipo atacado, quien controla el equipo controla el registro. Limpiar el registro de eventos de Windows lleva un comando, y a quien ya tiene permisos de administrador no le hace falta nada más.

Un EDR tumbado se reinstala en un día. El historial que se llevó consigo, no.

El problema no es tener EDR. Es convertirlo en el único testigo y guardar su declaración en el mismo lugar que el atacante acaba de tomar.

Con Trauma Zer0, el agente del equipo envía lo que recoge al servidor de la propia empresa, dentro de la red. Tz0 Security lee el Event Log de los equipos y muestra la lectura en la consola: lo que ya llegó al servidor no depende de que el registro local siga existiendo.

Ningún agente es inmune a quien tiene permisos de administrador en el equipo, tampoco el de Trauma Zer0. Por eso lo que cuenta es la evidencia que ya salió de él, y el silencio que queda cuando deja de reportar.

Cinco señales que suelen llegar antes del cifrado

La protección que se detuvo

Una herramienta derribada rara vez avisa. El análisis de comportamiento de Tz0 Security señala los equipos en los que la protección se fue apagando, y los cambios de servicios muestran cuándo el servicio del antivirus desapareció de una estación o de un servidor.

La nota de seguridad verifica, equipo por equipo, si antivirus, firewall y EDR están activos y actualizados. Una alerta así es un indicio para investigar, no un veredicto: a veces es un mantenimiento mal comunicado.

El equipo que se quedó en silencio

Una estación activa que deja de enviar eventos es sospechosa por sí misma. Tz0 Security trata el equipo silencioso como alerta, en lugar de dejarlo como una línea verde más en el panel.

El acceso remoto que apareció

AnyDesk preparado para el Modo seguro es persistencia con cara de software de soporte. En los cambios de software, Tz0 Security aparta el ruido del propio Windows y destaca lo que pide atención, como una herramienta de acceso remoto recién instalada, con fecha y equipo.

El privilegio que abrió el camino

Para cargar un driver vulnerable, el atacante normalmente necesita antes permisos de administrador. Tz0 Security muestra quién trabaja como administrador local y qué programas corren con privilegios totales, y cruza el software del parque con el catálogo de fallas explotadas de CISA, marcando las usadas por ransomware.

El borrado masivo

Las copias de seguridad y las carpetas enteras suelen ser el siguiente blanco. Tz0 Forensics separa el borrado de rutina (build, caché, temporales) del que importa, reconstruye archivos eliminados e identifica quién eliminó la carpeta. En las carpetas compartidas, cada operación queda con equipo, persona, hora y ruta.

Preparar la prueba antes del incidente

Nada de esto funciona si se enciende el día del ataque. La evidencia existe si se registró en su momento, o no existe. Algunos pasos sirven para cualquier parque:

  • Liste qué registros existen solo en la estación y cuáles ya llegan a un servidor de la empresa.
  • Trate la protección apagada y el equipo silencioso como alerta con responsable y plazo, no como estado.
  • Mantenga la lista de herramientas de acceso remoto aprobadas, para que una nueva llame la atención.
  • Reduzca el administrador local al mínimo que el trabajo exige.
  • Escriba la regla de recolección y el plazo de conservación antes de encender cualquier rastreo, con la finalidad definida, como exige la ley de protección de datos.

El plazo también pesa. Bajo la LGPD de Brasil, si hay datos personales involucrados, la empresa tiene 3 días hábiles para explicar qué pasó en el equipo. Y la permanencia del atacante suele ser mayor de lo que parece: conviene revisar si su conservación de evidencia cubre el dwell time.

Pagar el rescate o restaurar el backup tampoco responde estas preguntas. Pagar el rescate no explica qué pasó en el equipo; la evidencia guardada fuera de él, sí.

Cómo ayuda Trauma Zer0

  • EDR tumbado sin aviso → alerta de protección apagándose, servicio de antivirus eliminado y equipo silencioso en Tz0 Security → el equipo de TI sabe qué máquinas quedaron sin defensa y desde cuándo, y decide qué investigar primero.
  • Registro borrado en el equipo → lectura del Event Log y recolección de Tz0 Forensics guardadas en el servidor de la empresa → la cronología del incidente no depende del equipo comprometido.
  • Nueva herramienta de acceso remoto → cambios de software con el ruido filtrado → la persistencia aparece como un cambio fechado, por equipo, en lugar de esconderse entre programas comunes.
  • Carpetas y copias borradas → reconstrucción de archivos eliminados, autoría del borrado y caso sellado con SHA-256 en Tz0 Forensics → evidencia exportable para la investigación interna o para el proceso.

Todo esto corre instalado en la infraestructura del cliente. Los datos recogidos de las estaciones no salen a la nube: quedan en el servidor de la empresa, bajo la política que la propia empresa escribió. Tz0 Forensics, por ser el módulo más sensible, solo debe encenderse con regla de uso, alcance y autorización definidos.

Si la consola sigue en verde, ¿qué puede probar todavía?

La protección de la estación seguirá siendo un blanco. Lo que TI elige es si, el día en que caiga, el único testigo cae con ella.

Conozca Tz0 Security y Tz0 Forensics y agende una demostración con su escenario. Si prefiere probarlo en su entorno real, solicite una evaluación de Trauma Zer0.

Quer ver isso funcionando no seu parque?