Limitaciones de BAM y antiforense: lo que BAM no ve

TL;DR. BAM es preciso pero olvidadizo y selectivo. La ingeniería inversa publicada muestra que elimina al arrancar las entradas de más de siete días, borra las de ejecutables que ya no existen y no crea entradas para soportes extraíbles, recursos de red ni (según lo observado) programas de consola lanzados desde la línea de comandos. Guarda una sola marca de tiempo, sin hash ni contador. Los atacantes obtienen gran parte de esa evasión sin esfuerzo; la manipulación deliberada es posible, pero deja incoherencias que se pueden buscar.

Todo artefacto tiene sus fallos; el problema solo aparece cuando el informe no los menciona. Esta es la lista que tenemos junto a cada hallazgo de BAM. Contexto: la guía completa de BAM/DAM. La mayoría de las afirmaciones sobre comportamiento que siguen proceden de BAM internals, de Maxim Suhanov, basado en las compilaciones 18363 y 19592 de Windows 10 — vuelve a probarlas en la compilación de tu evidencia cuando una conclusión dependa de ellas.

Puntos ciegos de serie

Retención de siete días

Suhanov comprobó que las entradas de más de siete días se eliminan durante el arranque, y localizó un parámetro de vida útil, UserSettingsLifetimeMs, cuyo valor predeterminado equivale a siete días. Las entradas cuyo estado de moderación cambió el usuario no están sujetas a esa eliminación por antigüedad (fuente).

Consecuencias:

• Un equipo que se reinició más de una semana después de la actividad probablemente ha perdido la entrada.
• Un equipo que no se ha reiniciado puede conservar entradas de más de una semana, porque la purga ocurre al arrancar.
• Para actividad más antigua, analiza las colmenas SYSTEM de las instantáneas de volumen — cada una es una foto de BAM en el momento de la copia (visión general de VSS). Nuestra herramienta acepta varias colmenas SYSTEM a la vez y conserva el archivo de origen en cada fila.

Ejecutables borrados o movidos

«Las entradas de BAM pueden eliminarse si un ejecutable se retira de su ubicación original», y Suhanov vio desaparecer la entrada tras un reinicio (fuente). Así que la costumbre clásica del atacante — ejecutar una herramienta y borrarla — elimina el rastro en BAM en el siguiente arranque. Hasta entonces, la entrada sigue ahí. Es un buen argumento para recopilar SYSTEM antes de que nadie reinicie el equipo.

Soportes extraíbles y recursos de red

Suhanov comprobó que bam.sys se niega a crear entradas para ejecutables en dispositivos marcados como remotos o extraíbles («no se crean entradas BAM para ejecutables en soportes extraíbles y/o recursos compartidos de red»). Las herramientas ejecutadas desde un USB o desde \\server\share\tool.exe no aparecerán.

Una pregunta abierta que no hemos visto probada públicamente: los discos externos que se presentan a Windows como discos fijos y no como extraíbles. Si tu caso depende de ello, reprodúcelo con el mismo hardware.

Para esas ejecuciones, consulta en su lugar Prefetch, Amcache, los archivos LNK y las Jump Lists para el acceso, y los artefactos de dispositivos USB para la unidad.

Programas de consola lanzados desde la línea de comandos

Suhanov observó que «las aplicaciones de consola no obtienen entrada en BAM si se lanzan desde la sesión de línea de comandos», y señaló que no identificó la causa. En la práctica, whoami.exe, net.exe o una herramienta de ataque de consola lanzada desde cmd.exe pueden faltar aunque cmd.exe sí aparezca. Considera que la ausencia de una herramienta de consola no aporta información.

Una marca de tiempo, sin contexto

• Sin primera ejecución, sin contador, sin duración.
• La hora se actualiza al crear y al terminar el proceso (fuente), así que en programas que estuvieron abiertos mucho tiempo puede reflejar el cierre.
• Ni hash, ni tamaño, ni firmante, ni línea de comandos, ni proceso padre.
• Las rutas usan nombres de dispositivo de volumen, no letras de unidad (ver formato de los valores).

Huecos debidos a la adquisición

• Colmena dirty. Puede haber escrituras recientes en SYSTEM.LOG1/LOG2. Reprodúcelas antes de concluir que falta una entrada (dónde está la clave).
• Control set equivocado. Leer ControlSet002 en lugar del que indica Select\Current te da un estado anterior.
• Solo la clave antigua. Desde la 1809 los datos actuales están en State\UserSettings; una herramienta que solo lee bam\UserSettings ve una instantánea congelada (versiones).

Antiforense deliberada

Los valores de BAM son datos de registro normales. Un atacante con privilegios suficientes puede modificarlos (MITRE ATT&CK T1112, Modify Registry; T1070, Indicator Removal). Opciones realistas, de menor a mayor esfuerzo:

No hemos comprobado qué nivel de privilegio hace falta para escribir en estas claves en las compilaciones actuales; revisa los permisos de la clave en un sistema de referencia en lugar de suponer que solo SYSTEM, o cualquier administrador, puede modificarlas (seguridad de las claves del registro).

Detectar la manipulación

1. Hora de la clave frente a los valores. La hora de última escritura de cada clave SID debería estar cerca de la de su valor más reciente. Una clave escrita mucho después que todos los valores que quedan significa que algo cambió después — quizá un borrado. Nuestro analizador muestra esa hora en el panel de detalle y la exporta (SidKeyLastWriteUtc).
2. Comparar control sets e instantáneas. Una entrada presente en la colmena SYSTEM de una instantánea de volumen pero ausente en la actual, cuando el ejecutable sigue existiendo y ha pasado menos de una semana, merece una nota.
3. Coherencia entre artefactos. Una herramienta en Prefetch o Amcache pero no en BAM, sin que se aplique ninguno de los motivos naturales anteriores, es una pista, no una conclusión.
4. Telemetría del registro. Los eventos 12 a 14 de Sysmon registran la creación/eliminación de objetos del registro, la escritura de valores y los cambios de nombre cuando están configurados (Sysmon); analízalos con EVTX Parser. La mayoría de las organizaciones no vigila específicamente la clave BAM, así que la ausencia de eventos demuestra poco.
5. Registros de transacciones. Un borrado justo antes de la adquisición puede seguir siendo visible si comparas la colmena antes y después de reproducir los registros.

Cómo redactar un hallazgo de BAM

• Presencia: «Un registro de BAM bajo el SID X muestra ruta con una última actividad registrada a las T UTC.»
• Ausencia: «No se encontró ningún registro de BAM para ruta. BAM no registra ejecutables en soportes extraíbles ni en recursos de red, purga al arrancar las entradas de más de siete días y elimina las de ejecutables borrados antes de un reinicio; por tanto, la ausencia no demuestra que el programa no se ejecutara.»

Después, corrobora con la matriz comparativa y analiza la colmena con el BAM/DAM Parser, que avisa de colmenas dirty y formatos antiguos para que los huecos se vean desde el principio.

Preguntas frecuentes

¿Por qué falta en BAM un programa que sé que se ejecutó?

Motivos habituales: se ejecutó desde un soporte extraíble o un recurso de red, era un programa de consola lanzado desde la línea de comandos, su entrada se purgó al arrancar tras siete días, su ejecutable se borró y el equipo se reinició, o las últimas escrituras siguen en SYSTEM.LOG1/LOG2.

¿Puede un atacante modificar o borrar entradas de BAM?

Sí: con privilegios suficientes, los valores son datos de registro normales. Los borrados o modificaciones pueden dejar rastro: hora de última escritura de la clave SID posterior a todos los valores, discrepancias con Prefetch o Amcache, y eventos de auditoría del registro o de Sysmon si estaban activados.