Borrando las huellas: limpiando el log de eventos de Windows

Una vez llevado a cabo una intrusión y tomado el control de uno o varios hosts siempre es una buena idea borrar nuestras huellas, o eso dicen los cánones del buen malvado, véase técnica T1070. 

En Windows el log de seguridad es solo escribible por el servicio LSASS (Local Security Authority Subsystem Service) y no hay funciones del API de Windows para interactuar con los eventos, es decir, necesitaremos ser administradores locales o de dominio o directamente SYSTEM. Además, en Windows los eventos no pueden borrarse individualmente, tiene que ser todo o nada. Cuando los borremos se generará posteriormente un evento de tipo "log clear", con id 1102 en security o 104 en sistema (en windows XP/203 517)

Hace muchos años la herramienta WinZapper supuestamente era capaz de borrar eventos individualmente a nuestra elección, si bien nunca llegó a funcionar bien... los logs se acababan corrompiendo y/o el servicio event log crasheaba. ¿Qué opciones tenemos entonces para limpiar nuestro particular "lugar del crimen"?

Mimikatz

Mimikatz por ejemplo permite el comando event::clear: y sobretodo event::drop que realmente lo que hace es parchear el servicio del log de eventos y dejar de meter registros en Security. Lo bueno es que no añade el evento 1102 después de hacerlo, lo malo es que no permite volver a reanudar el logging por lo que un azulón forense nos acabará pillando y descubriendo que algo ha pasado en la máquina objetivo.


Invoke-Phant0m

Se trata de un script en PowerShell que se utiliza para eliminar el hilo del proceso svchost responsable del registro de eventos. Esta técnica es buena para detener muchos controles de seguridad, no solo el visor de eventos. Lo que "mola" es que el servicio parece seguir funcionando cuando realmente ya no está registrando ningún evento.


Terminar el proceso de Event Log

El proceso responsable para loggear eventos es:

svchost -k LocalServiceNetworkRestricted -p -s eventlog

Si suspendemos este proceso, el visor de eventos se pausará. Aunque tampoco podremos abrir un nuevo CMD o PowerShell podremos seguir usando una shell ya abierta. Eso sí, el visor de eventos se pausará pero los registros aparecerán justo después de reanudar el proceso, lo mismo si mata el proceso y luego inicia los servicios nuevamente.

Downgrade de componentes de Windows

La presencia de la clave de registro MiniNT (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MiniNT) hace que varios componentes de Windows crean que se están ejecutando en el entorno de preinstalación de Windows. Significativamente, la presencia de esta clave rompe el Visor de eventos; intenta abrir cualquier registro y recibirás el siguiente mensaje de error:


Además si esto no fuera suficiente, la comunicación remota de Windows PowerShell también dejará de funcionar con esta clave.

DanderSpritz

Shadow Brokers exfiltró este implante funcional que incluía una herramienta llamada "EventLogEdit". EventLogEdit era más sofisticada en comparación con otras, ya que permite eliminar entradas individuales de los registros de seguridad, aplicación y sistema sin dejar pistas obvias de que los archivos se han editado.

Desde China 3gstudent evolucionó además EventLogEdit para reescribir logs mediante la WinAPI EvtExportLog:
https://github.com/3gstudent/Eventlogedit-evtx--Evolution

También hay una interesante herramienta forense para descubrir si se ha usado DanderSpritz: https://github.com/fox-it/danderspritz-evtx


Manualmente

Por último, también es posible editar los eventos manualmente. Bastante laborioso pero tremendamente "quirúrgico" si es necesario. Básicamente hay que conocer la estructura y el formato de un .evtx y tener en cuenta tres checksums principales que harán que el registro de eventos se corrompa si no se actualizan correctamente, el checksum del encabezado del archivo, el checksum del encabezado del fragmento y el checksum del registro de eventos. Tenéis una buena guía aquí.


Fuentes:

Comentarios

Publicar un comentario