Una breve lección de historia
Para quienes no lo conocen, AUTOEXEC.BAT era un archivo que ejecutaba el procesador de comandos de DOS al iniciar el sistema. En los primeros sistemas operativos Windows NT, esta función cambió un poco para que AUTOEXEC.BAT se procesara al iniciar sesión el usuario. Sin importar el momento de ejecución, su propósito era casi siempre establecer variables de entorno e iniciar aplicaciones y utilidades de bajo nivel.
Como te puedes imaginar, esta función —junto con archivos similares como WIN.INI, SYSTEM.INI y CONFIG.SYS— era comúnmente explotada por actores malintencionados. Uno de los ejemplos clásicos fue el gusano Pikachu que se propagaba por correo electrónico y sobrescribía AUTOEXEC.BAT para eliminar archivos críticos del sistema de Windows:
A medida que Windows NT siguió evolucionando, estos archivos finalmente quedaron obsoletos, se trasladaron al registro y, supuestamente, se eliminaron por completo. Sin embargo, Microsoft tiene un largo historial de compatibilidad con versiones anteriores y no pude resistir explorar si se podía hacer que Windows todavía procesara este archivo.
El valor ParseAutoexec
Normalmente no documentaría una investigación rápida y fallida como esta, pero @Hexacorn (Adam) y yo solemos pensar en la misma onda. Su reciente publicación de blog destacando su intento fallido de evadir Autoruns con la función AutorunsDisabled fue mi motivación para esto.
Al igual que Adam, yo conocía cierta función interna que pensé que podría aprovecharse para un comportamiento inesperado. En este caso, pensaba específicamente en un antiguo valor del registro (introducido en NT 4.0) que se agregó para deshabilitar el procesamiento de AUTOEXEC.BAT. Este valor REG_SZ, hace tiempo olvidado, se llamaba "ParseAutoexec" y se ubicaba en " Software\Microsoft\Windows NT\CurrentVersion\Winlogon".
Mi hipótesis era simple: se accedería a AUTOEXEC.BAT (posiblemente incluso se procesaría) si volvía a agregar el valor "ParseAutoexec" a la clave de registro esperada y configuraba el dato del valor en "1" (habilitado). Después de agregar el valor a HKLM y a la colmena HKU específica del usuario, configuré ProcMon para que comenzara a registrar desde el arranque con la opción "Enable Boot Logging".
Las máquinas virtuales se reiniciaron y ProcMon registró los datos sin problema. Con los datos cargados, configuré algunos filtros para buscar procesos que:
- Accedieran a rutas que contuvieran la cadena "autoexec"
- Hicieran consultas al registro en las claves de registro "Winlogon"
- Accedieran a archivos donde el resultado fuera "NAME NOT FOUND"
Lamentablemente, todos los filtros arrojaron resultados vacíos, lo que confirmó mi sospecha de que AUTOEXEC.BAT probablemente ya no se usa.
¿Qué hay de la función de persistencia?
Aunque archivos como AUTOEXEC.BAT ya no se ejecutan ni se analizan directamente, casi toda la funcionalidad de inicio automático que los hackers solían aprovechar todavía existe en lo profundo del Registro:
Los parámetros “Load=” y “Run=” de WIN.INI se trasladaron a valores dentro de las claves HLKM y HKU “Software\Microsoft\Windows NT\CurrentVersion\Windows”. Los actores de Goblin Panda fueron descubiertos esta misma semana abusando de esto para mantener su acceso persistente (¡buen blog, @Sebdraven!).
El valor “Shell=” de SYSTEM.INI también se trasladó a un valor del registro, pero se encuentra en las claves HLKM y HKU “Software\Microsoft\Windows NT\CurrentVersion\Winlogon”. Lamentablemente, mi equipo en Huntress Labs también encuentra malware usando estas claves constantemente…
Reflexiones finales
Como toda investigación, esto dista mucho de ser una prueba concluyente de que AUTOEXEC.BAT realmente ha muerto. Probablemente haría falta una cantidad interminable de ingeniería inversa para confirmar del todo algo tan oscuro. Sin embargo, parece poco probable que el valor ParseAutoexec por sí solo traiga de vuelta esta función (innecesaria) ;) Si has visto lo contrario, avísame y cuéntame qué has descubierto.
¡Espero que hayas disfrutado este rápido viaje por la memoria!
