C:\myapplication\myapplication.exe
      C:\myapp\subfolder\myapp.exe
      C:\SoftwareCompany\software.exe
      C:\myapplication\myapplication.dll
      C:\myapp\subfolder\myapp.dll
      C:\SoftwareCompany\software.dll
           

**Un modelo mental práctico es:**

el proceso carga libeay32.dll

→ el proceso llama a OPENSSL_config(NULL)

→ OpenSSL lee openssl.cnf

→ la sección engine provoca un intento de carga de un dll especificado

→ el cargador de Windows acepta el dll y sus dependencias

***Si falta algún paso, tu DLL no se cargará.***

Una regla mínima que puedes usar al depurar:

Si el proceso solo carga libeay32.dll, eso no es suficiente.
También debe llamar a la carga de configuración de OpenSSL y no deshabilitarla.

- Debería llamar a OPENSSL_config para funcionar o
- CONF_modules_load_file o
- OPENSSL_no_config no está establecido.


Sin comprobación de firma. Sin verificación. Cualquier DLL especificado se carga, si el proceso llama a OPENSSL_config.
Podemos consultar nombres típicos de DLL relacionados con OpenSSL para enumerar posibles aplicaciones con las que probar más. Queremos comprobar el OPENSSLDIR de la DLL y si el proceso está llamando a OpenSSL_conf.
Podemos comprobar OpenSSLDIR verificando el hash del archivo contra la lista en este repositorio, o conseguir una copia de la dll relacionada con criptografía y simplemente ejecutar openssldir_check sobre la cryptodll (libeay32.dll etc).
También podemos usar ProcMon para comprobar si el proceso llama a algún openssl.cnf. Si vemos openssl.cnf en procmon entonces sabemos con certeza que la aplicación lo llama. En otros métodos lo que queremos obtener es la información de versión (en campos de event.code 7) y desde qué ruta carga el archivo openssl.cnf verificando el hash del archivo contra la lista en este repositorio, conseguir una copia de la misma DLL y hacer la comprobación manual.


**Ejemplo al ejecutar openssldir_check.exe**

`openssldir_check32.exe libeay32.dll`

`openssldir_check v1.0 by 0xm1rch`

**Salida:**

`SSLeay_version() returned OpenSSL 1.0.1g 7 Apr 2014`

`SSLeay_version() returned OPENSSLDIR: "/usr/local/ssl"`

- ref https://github.com/mirchr/openssldir_check
> Salida similar con un openssldir_check modificado a medida que está precompilado en este repositorio.

> La salida da la versión de OpenSSL 1.0.1g y que el OpenSSLDIR está establecido en **/usr/local/ssl** lo cual es **¡muy interesante!**

> **Sysmon event.code 7** te da las DLLs de OpenSSL cargadas y también la información de versión de la dll en el campo file.pe.file_version.


#### Escenario de escalada
1. Un servicio se ejecuta como **SYSTEM** y usa OpenSSL
2. La DLL de OpenSSL llama a openssl_conf y lee `C:\usr\local\ssl\openssl.cnf` al arrancar, pero ese archivo es editable o no existe
3. Si un usuario con pocos privilegios puede escribir en esa carpeta puede:
   - Colocar un `openssl.cnf` malicioso
   - Colocar su DLL
   - Esperar al reinicio del servicio
   - El código se ejecuta como **SYSTEM**

> Resultado: escalada de privilegios local colocando un openssl.cnf que la dll de openssl de la aplicación carga y termina cargando una dll "maliciosa" personalizada.



### Vulnerabilidad del instalador/desinstalador NSIS

NSIS es un framework de instaladores de Windows ampliamente usado. El problema descrito aquí es que, cuando un instalador o desinstalador NSIS se ejecuta con privilegios elevados, puede usar directorios temporales bajo C:\Windows\Temp de una forma en la que un usuario local normal puede interferir.

En la práctica, eso significa que un atacante con pocos privilegios puede tomar el control de archivos en los que confía el instalador, como archivos de plugins temporales o archivos del desinstalador, y convertirlo en ejecución de código como SYSTEM. En otras palabras, la debilidad no es "el instalador se ejecuta como admin", sino que el manejo de archivos temporales del instalador puede permitir a un usuario sin privilegios secuestrar un flujo de instalación o desinstalación elevado.

#### DLLs comunes vistas en instaladores NSIS

> Nota: Algunas de estas son **plugins oficiales de NSIS**, mientras que otras son **plugins de terceros comunes** usados a menudo por instaladores NSIS.  
> Ver una de estas DLLs es una pista, pero no una prueba absoluta, de que un instalador usa NSIS. Una ruta de archivo como `C:\Windows\Temp\*.tmp\*.dll` es un indicio fuerte.

| DLL | Propósito típico | Tipo | Notas |
|---|---|---|---|
| `System.dll` | Llama a APIs de Win32 y funciones de DLLs externas desde scripts NSIS | Plugin oficial de NSIS | Uno de los indicadores más fuertes de NSIS |
| `nsDialogs.dll` | Construye diálogos y controles personalizados del instalador | Plugin oficial de NSIS | Común en instaladores NSIS modernos |
| `nsExec.dll` | Ejecuta comandos de consola y captura la salida | Plugin oficial de NSIS | A menudo usado para comandos auxiliares silenciosos |
| `StartMenu.dll` | Permite al usuario elegir una carpeta del Menú Inicio | Plugin oficial de NSIS | Común en instaladores clásicos |
| `LangDLL.dll` | Muestra un diálogo de selección de idioma | Plugin oficial de NSIS | Aparece a menudo en instaladores multilingües |
| `Banner.dll` | Muestra una UI de banner/progreso durante los pasos de instalación | Plugin oficial de NSIS | Mayormente cosmético |
| `InstallOptions.dll` | Crea páginas personalizadas de estilo antiguo a partir de definiciones INI | Plugin oficial de NSIS | En gran medida reemplazado por `nsDialogs.dll` |
| `UserInfo.dll` | Recupera información sobre el usuario/cuenta actual | Plugin oficial de NSIS | Usado para comprobaciones de privilegios o cuentas |
| `Dialer.dll` | Gestiona el comportamiento de conexión por marcación/red | Plugin oficial de NSIS | Mayormente heredado |
| `Math.dll` | Proporciona ayudas aritméticas para scripts NSIS | Plugin oficial de NSIS | Menos necesario en scripts más nuevos |
| `NSISdl.dll` | Descarga archivos de internet | Plugin oficial de NSIS | Plugin de descarga antiguo; a menudo reemplazado por `inetc.dll` |
| `Splash.dll` | Muestra una pantalla de bienvenida | Plugin oficial de NSIS | Mayormente heredado/cosmético |
| `AdvSplash.dll` | Muestra una pantalla de bienvenida más avanzada | Plugin común de NSIS | Rol similar a `Splash.dll` |
| `BgImage.dll` | Muestra una imagen de fondo en la UI del instalador | Plugin oficial/común de NSIS | Mayormente cosmético |
| `inetc.dll` | Descarga archivos por HTTP/FTP | Plugin de terceros común de NSIS | Muy común en instaladores web |
| `InetLoad.dll` | Descarga archivos de internet | Plugin de terceros común de NSIS | Alternativa a `NSISdl.dll` / `inetc.dll` |
| `UAC.dll` | Gestiona la elevación y el comportamiento relacionado con UAC | Plugin de terceros común de NSIS | Pista fuerte relacionada con NSIS |
| `AccessControl.dll` | Cambia ACLs y permisos de archivos/carpetas | Plugin de terceros común de NSIS | Usado en instalaciones sensibles a admin |
| `Registry.dll` | Operaciones avanzadas sobre el Registro de Windows | Plugin de terceros común de NSIS | Más capaz que los comandos de registro integrados en algunos casos |
| `ShellLink.dll` | Crea o edita accesos directos de Windows (`.lnk`) | Plugin de terceros común de NSIS | Ayudante de gestión de accesos directos |
| `SimpleFC.dll` | Compara archivos o comprueba diferencias entre archivos | Plugin de terceros común de NSIS | Plugin de utilidad/ayuda |
| `FindProcDLL.dll` | Detecta si un proceso se está ejecutando | Plugin de terceros común de NSIS | A menudo usado antes de actualizaciones |
| `KillProcDLL.dll` | Termina procesos en ejecución | Plugin de terceros común de NSIS | Común en desinstaladores/actualizadores |
| `NScurl.dll` | Descarga/transfiere datos usando funcionalidad estilo curl | Plugin de terceros común de NSIS | Ayudante de red más nuevo/más capaz |
| `ZipDLL.dll` | Gestiona la extracción o creación de archivos ZIP | Plugin de terceros común de NSIS | Utilidad de archivos |
| `unzipdll.dll` | Extrae archivos ZIP | Plugin de terceros común de NSIS | Plugin de archivos más antiguo |
| `untgz.dll` | Extrae archivos `.tar.gz` | Plugin de terceros común de NSIS | Menos común, pero visto en algunos paquetes |
| `VPatch.dll` | Aplica parches/actualizaciones binarias | Plugin común relacionado con NSIS | A menudo usado en instaladores de parches |
| `CabDLL.dll` | Trabaja con archivos CAB | Plugin común relacionado con NSIS | Visto mayormente en flujos de empaquetado más antiguos |
| `nsJSON.dll` | Analiza o genera datos JSON | Plugin de terceros común de NSIS | Más común en instaladores con scripts modernos |
| `StdUtils.dll` | Utilidades auxiliares de propósito general para NSIS | Plugin de terceros común de NSIS | A menudo usado para ayudantes de SO/versión/rutas |
| `ExecDos.dll` | Ejecuta comandos con mejor control sobre E/S y espera | Plugin de terceros común de NSIS | Alternativa/extensión a `nsExec.dll` |

#### Indicadores más fuertes de NSIS

Las siguientes DLLs son especialmente sugestivas de NSIS:

- `System.dll`
- `nsDialogs.dll`
- `nsExec.dll`
- `LangDLL.dll`
- `StartMenu.dll`
- `NSISdl.dll`
- `inetc.dll`
- `UAC.dll`

#### Precaución

Algunos instaladores extraen estas DLLs temporalmente en una carpeta como:

- `$PLUGINSDIR`

Por lo que pueden aparecer solo en tiempo de ejecución, no junto al ejecutable del instalador en disco.


### Vulnerabilidades de redirección DotLocal
**El abuso de la redirección DotLocal es un problema de secuestro de DLL de Windows en el que una carpeta de aplicación escribible permite a un atacante engañar a un programa legítimo para que cargue primero una DLL maliciosa**

La vulnerabilidad de redirección DotLocal abusa de la característica integrada de Windows .local / DotLocal DLL redirection. Windows soporta la redirección de DLL respetando un archivo o carpeta con un nombre como App.exe.local; cuando está presente, el cargador comprueba primero la carpeta del ejecutable o esa carpeta .local en busca de DLLs, y esto puede aplicarse incluso cuando se especifica una ruta completa de DLL. Microsoft documenta esto como una característica legítima para redirigir cargas de DLL.

Por qué se convierte en una vulnerabilidad: si un atacante puede escribir en el directorio del ejecutable (rutas escribibles por el usuario), o en un directorio temporal de extracción usado por un proceso privilegiado, puede crear la carpeta Target.exe.local y colocar una DLL maliciosa donde Windows la preferirá. Eso convierte la característica en un secuestro de DLL, de modo que el proceso de confianza carga la librería del atacante en lugar de la librería prevista.

#### Control manual
Los procesos identificados con altos privilegios en rutas escribibles por todo el mundo deberían investigarse para ver si son vulnerables a la redirección DotLocal. Si los consultas y encuentras aplicaciones. Haz el último control usando ProcMon para ver si el proceso intenta cargar librerías desde la carpeta .exe.local creada. Puedes usar la herramienta GetSxsPath para determinar la ruta completa del archivo. Procmon debería mostrarte eventos NAME NOT FOUND / PATH NOT FOUND apuntando a un directorio .exe.local si es vulnerable. Según informes públicos, las aplicaciones durante la instalación son particularmente vulnerables durante el proceso de instalación.

**Una buena regla general es:**
ProcMon puede proporcionar evidencia de sondeo .local, pero la ausencia de un fallo visible de .exe.local no prueba que la aplicación no sea susceptible. Para comctl32.dll especialmente, el rastro a menudo refleja el enlace de manifiesto/SxS en lugar de una simple búsqueda de DLL en la carpeta de la aplicación.


#### Si un programa carga:

`C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

#### Comprueba esto:

`C:\Path\To\Application.exe.local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

**Determinar la ruta de redirección para SxS DotLocal DLL Hijacking** - https://gist.github.com/rxwx/1717e95e5ec11bea12d33e93a3832508

#### DotLocal Wiz Installer
**WiX Burn EXE bootstrapper** Versiones afectadas >= 4, < 4.0.4 < 3.14.0. Esto afecta a cualquier instalador construido con el framework de instalación WiX.
WiX también permite a los autores reemplazar el icono por defecto y usar la UI estándar de WixStdBA o una aplicación bootstrapper personalizada, por lo que el EXE puede personalizarse para parecer del proveedor en lugar de "WiX".

##### Detalles
Si el bundle no se ejecuta como admin, se usa la carpeta TEMP del usuario y no la carpeta TEMP del sistema. Una utilidad es capaz de monitorizar la carpeta TEMP del usuario en busca de cambios y colocar su propia DLL en la carpeta .be/.Local inmediatamente cuando se crea la carpeta .be. Cuando el motor burn se eleva, la DLL maliciosa recibe privilegios elevados.

> **Ref** https://github.com/wixtoolset/issues/security/advisories/GHSA-7wh2-wxc7-9ph5

"Un proceso wixstdba.exe separado es una buena huella de WiX Burn, pero el indicador más fuerte para las versiones afectadas es la propia versión del motor Burn: vulnerable si se identifica como <3.14.0 o 4.0.0–4.0.3."


## Requisitos previos
Una configuración de SYSMON bien configurada para capturar eventos de interés, como event.code 1, 7, 11 y 13 para las rutas escribibles por el usuario y las colmenas de registro mencionadas.
 - https://github.com/SwiftOnSecurity/sysmon-config
 - https://github.com/olafhartong/sysmon-modular

Auditoría avanzada habilitada para algunos de los eventos de Windows.

El Event ID 4688 (creación de procesos) debe habilitarse explícitamente para registrar procesos recién creados. 
Por defecto, no captura la línea de comandos usada para iniciar el proceso; esta característica debe habilitarse específicamente en la política de seguridad.

Tarea programada - 4698 no está habilitada por defecto.


## ACL ⭐
### 🔹 Algunos principales de ACL comunes que cubren a usuarios conectados

| Principal               | Descripción                                                                 |
|--------------------------|-----------------------------------------------------------------------------|
| **Everyone**             | Todos los usuarios, incluidos los Invitados (y en versiones antiguas de Windows, incluso Anonymous Logon). Muy amplio, normalmente restringido a acceso de lectura. |
| **Authenticated Users**  | Cualquier cuenta que haya iniciado sesión correctamente (local o de dominio). Excluye a usuarios anónimos. |
| **BUILTIN\Users**        | El grupo local **Users** en la máquina. Incluye todas las cuentas locales estándar (no admin). |
| **INTERACTIVE**          | Cualquier usuario conectado **localmente en la consola** (teclado/sesión). Útil para diferenciar acceso local vs. remoto. |
| **COMPUTERNAME\\Username** | Una **cuenta local** específica en ese equipo (p. ej., `LAPTOP01\Bob`). Los permisos se aplican solo cuando ese usuario inicia sesión localmente. |
| **DOMAIN\\Username**     | Una **cuenta de dominio** específica (p. ej., `CORP\Alice`). Los permisos siguen al usuario en todas las máquinas unidas al dominio. |


### 📑 Atributos de ACL (algunos de los interesantes a examinar)

Los atributos de la Lista de Control de Acceso (ACL) definen qué acciones puede realizar un usuario o grupo sobre archivos o carpetas.  
Aquí hay algunos clave que vale la pena destacar:

| Atributo | Nombre / Significado           | Por qué es interesante                                                                 |
|-----------|--------------------------|--------------------------------------------------------------------------------------|
| **F**     | Acceso total              | Concede **todos los derechos posibles** (leer, escribir, ejecutar, eliminar, cambiar permisos, tomar posesión). Equivalente a control "a nivel de propietario". |
| **M**     | Acceso de modificación            | Permite leer, escribir y eliminar archivos/carpetas, pero **no cambiar ACLs** ni la propiedad. Lo más común para usuarios normales. |
| **W**     | Acceso solo de escritura        | El usuario puede **crear o modificar contenido** pero no puede volver a leerlo. Poco común, pero útil en escenarios de "buzón de depósito" (p. ej., envíos seguros de archivos). |
| **WD**    | Write Data / Add File    | Permite específicamente **crear o escribir archivos en un directorio**. Esencial para poder añadir o sobrescribir archivos dentro de una carpeta. |
| **AD**    | Append Data / Add Subdirectory | En archivos: añadir datos al final de un archivo (no puede sobrescribir). En carpetas: crear nuevos subdirectorios dentro. |


## Falsos positivos
#### Haz tus consultas, ajústalas y al final crea alertas a partir de ellas. 
Puede que necesites hacer alguna lista blanca (ver más abajo rutas típicas en ProgramData). La idea es consultar rutas típicas escribibles por el usuario, pero ocurre que los (archivos o carpetas) tienen la ACL correcta establecida. Si la mentalidad ofensiva no ayuda a escalar privilegios - ponlos en lista blanca.
Filtra los menos interesantes: los que tienen la ACL correcta, nombres de archivo aleatorizados (filtra la carpeta). Queremos reducir el ruido y tener una línea base. Es importante hacer esto después de verificar que no es una vulnerabilidad. Así no te pierdes una tarea programada que sea vulnerable en todos los clientes.


## Lista blanca
Probablemente necesitarás poner en lista blanca las consultas. Haz tu búsqueda, ajusta las consultas y crea alertas a partir de ellas para capturar nuevos eventos que no hayas examinado.
##### Probablemente necesitarán lista blanca:
      C:\ProgramData\Microsoft
      C:\ProgramData\Package Cache
      C:\ProgramData\Packages
      etc.

Otras que pueden necesitar lista blanca, que pueden ser comunes, son drivers relacionados con hardware y cosas similares que tienen nombres aleatorizados.
      

## Metodología
No olvides consultar en el intervalo de tiempo de tu "periodo de retención de logs".
Una buena metodología es consultar al principio un intervalo de tiempo corto que vaya aumentando progresivamente.
1) 1 día
2) 1 semana
3) 2 semanas
4) 1 mes
5) 2 meses
6) etc..

Haz tu búsqueda y comprueba los interesantes y ajusta y pon en lista blanca.. al final crea alertas a partir de ellos para capturar nuevos eventos..

## Consejos y trucos
Si un reemplazo de binario no es posible debido a una ACL correcta. Comprueba los permisos de la carpeta y si tienes permisos para escribir archivos
comprueba si el ejecutable intenta cargar alguna dll que no existe. Si es así, créalas y tienes tu ejecución de código. Si el reemplazo de binario no es posible porque es un proceso en ejecución. Comprueba un posible DLL sideloading o comprueba si tú, como usuario normal, tienes permisos para reiniciar el propio servicio. Otra forma es comprobar si tú, como usuario normal, puedes realizar un "shutdown" del que escapas en el último segundo. Un inicio de apagado detiene procesos y si te sales de él, puede que seas capaz de reemplazar el binario del proceso terminado. Si el servicio está en modo Autostart y no tienes permisos para iniciar/detener el servicio, lo que puedes comprobar es si tienes SeShutdownPrivilege y, si es así, iniciar un reinicio con shutdown /r /t 0.

Si un servicio está generando el proceso y si no es posible reemplazar el binario, el binario no intenta cargar ninguna DLL faltante. No te rindas - ¿quizás la ruta no está entrecomillada y tienes permisos de escritura y puedes usar eso?

Construye tus consultas capa sobre capa.. así que comprueba creaciones de servicios/tareas programadas, comprueba la creación de procesos con padre como servicios o proceso relacionado con tareas programadas (svchost.exe con argumento Schedule). Es posible que algún sistema cree el servicio o la tarea programada pero la ruta del binario etc. no exista y la creación del proceso nunca ocurra. Pero la vulnerabilidad sigue ahí y se pueden crear diferentes eventos relacionados con ella.

Para reducir la carga de consultas (rendimiento) y probablemente la lista blanca.. puede ser una buena idea tener consultas separadas para clientes/servidores. Así, un conjunto de consultas usado solo para los endpoints cliente y el mismo conjunto usado para los endpoints servidor.

La creación genérica de procesos por SYSTEM es una consulta de alto valor. Captura muchos escenarios.. además de servicios y schtask generando procesos hijos, también captura msiexec.exe generando un proceso hijo. También captura si un ejecutable desde c:\windows\ccmcache está generando un proceso hijo desde una ruta escribible por el usuario. Si tuviéramos que ordenar los ejecutables en vulnerabilidad, yo seguiría diciendo que services.exe está relacionado con malas configuraciones de software y schtasks es más una mala configuración del administrador..

Si has probado todas las consultas y no has tenido éxito. si quieres buscar más a fondo, y hacer un poco más de trabajo - ve a por cada proceso hijo de services.exe y schtasks (svchost.exe con argumento Schedule), independientemente de dónde. Enumera la empresa y busca también los que están en rutas típicamente protegidas por admin (Program Files & Program Files (x86)). Es más común de lo que crees que los proveedores de software estropeen la ACL incluso en rutas típicamente protegidas. Usa los eventos de creación de procesos y los eventos de servicios y tareas programadas. Para tareas programadas - consulta cada campo Command y campo Argument. El campo argument puede estar apuntando a un archivo de script en una ruta escribible por el usuario o en la raíz de C. Los campos command pueden estar apuntando a un binario que tiene una ACL insegura. También podrías examinar C:\PROGRA~3 que es la representación de nombre corto (DOS) 8.3 de C:\ProgramData.

## Procesos de desinstalación
Es probable que si un usuario puede desencadenar una instalación, también pueda desencadenar una desinstalación. Los procesos de desinstalación son de interés independientemente de dónde esté la ruta del archivo.
Si la ACL no es correcta - un reemplazo de binario probablemente causará problemas.
Consulta también la creación de archivos típicos de desinstalación usando Sysmon event.code:11.
Queremos hacer esto para capturar cada desinstalador sin confiar en los eventos de creación de procesos. Esto es porque no es común que los usuarios realmente desinstalen aplicaciones instaladas.. Simplemente no les importa y por lo tanto será más fácil perder algunos eventos de desinstalación que existen pero nunca se desencadenan.

### Ejemplo de nombres de procesos de desinstalación
#### Nombres genéricos comunesuninstall.exe – El más genérico y ampliamente utilizado.
          unins000.exe, unins001.exe – Común con instaladores de Inno Setup.
          unwise.exe – A menudo utilizado por paquetes más antiguos de Wise Installer.
          uninst.exe – Versión abreviada, frecuente en software heredado.
          uninstaller.exe – Variante ligeramente más larga y descriptiva.
          remove.exe – A veces utilizado para instaladores mínimos.
          setup.exe (con parámetro /uninstall o /remove) – Algunas aplicaciones reutilizan el ejecutable del instalador para la desinstalación.
          appname_uninstall.exe (p. ej., chrome_uninstall.exe)
          update.exe (con --uninstall) – Visto en aplicaciones como Slack o Discord que usan instaladores Squirrel.

#### Patrones a considerar

          *_uninstall.exe – Muchas aplicaciones anteponen el nombre de la app, p. ej., teams_uninstall.exe, zoom_uninstall.exe.
          *_cleanup.exe – Las herramientas de eliminación suelen tener variantes de limpieza, p. ej., driver_cleanup.exe.
          *_remover.exe – Otro estilo común de nomenclatura de AV/proveedores.


## Archivos PE / binarios con ejecución de código al cargar
### Considere consultar los de la lista tanto en los registros de windows/sysmon como en los registros de procmon
| Extensión | Tipo PE | ¿Ejecución de código al cargar? | Punto de entrada / mecanismo | Notas |
|-----------|---------|--------------------------|-------------------------|-------|
| `.exe` | Ejecutable PE | Sí | PE `AddressOfEntryPoint` | El código comienza cuando se lanza el ejecutable |
| `.dll` | DLL PE | Sí | `DllMain` / callbacks TLS | El código puede ejecutarse cuando la DLL se carga en un proceso |
| `.sys` | Controlador de kernel PE | Sí | `DriverEntry` | El código de inicialización del controlador se ejecuta cuando se carga el controlador |
| `.scr` | Ejecutable PE | Sí | PE `AddressOfEntryPoint` | Esencialmente un ejecutable; `.scr` es principalmente una convención |
| `.cpl` | DLL PE | Sí | `DllMain` + `CPlApplet` | Cargado por la infraestructura del Panel de Control |
| `.ocx` | DLL PE / ActiveX | Sí | `DllMain` + puntos de entrada COM/ActiveX | La inicialización de la DLL ocurre cuando se carga |
| `.drv` | DLL PE / controlador heredado | Normalmente | `DllMain` o punto de entrada específico del controlador | Depende del tipo específico de `.drv` |
| `.efi` | Binario EFI PE/COFF | Sí | Punto de entrada EFI | El código se ejecuta cuando lo carga UEFI |
| `.ax` | DLL PE | Sí | `DllMain` + interfaces DirectShow | La inicialización de la DLL ocurre al cargar |
| `.acm` | DLL PE | Sí | `DllMain` + puntos de entrada ACM | Cargado como códec de Audio Compression Manager |
| `.ime` | DLL PE | Sí | `DllMain` + puntos de entrada IME | La inicialización de la DLL ocurre cuando se carga |
| `.tsp` | DLL PE | Sí | `DllMain` + puntos de entrada TAPI | La inicialización de la DLL ocurre cuando se carga |
| `.pyd` | DLL PE | Sí | `DllMain` + inicialización de módulo Python | Extensión nativa de Python |
| `.node` | DLL PE | Sí | `DllMain` + inicialización de addon de Node.js | Addon nativo de Node.js |
| `.xll` | DLL PE | Sí | `DllMain` + puntos de entrada XLL de Excel | Cargado por `EXCEL.EXE` |
| `.wll` | DLL PE | Sí | `DllMain` + carga de complemento de Word | Cargado por `WINWORD.EXE` |



## Archivos de script
### Considere consultar los de la lista
| Extensión | Lenguaje / Tipo           | Propósito / Uso                                         | Contexto de ejecución                                          |
|-----------|---------------------------|---------------------------------------------------------|------------------------------------------------------------|
| .bat      | Script por lotes               | Tareas heredadas de automatización de línea de comandos, scripts simples     | `cmd.exe` (Símbolo del sistema)                                  |
| .cmd      | Script por lotes (estilo NT)    | Similar a `.bat`, preferido en sistemas basados en NT         | `cmd.exe` (Símbolo del sistema)                                  |
| .vbs      | VBScript                   | Tareas de automatización, scripts de inicio de sesión, scripts de administración           | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .vbe      | VBScript (codificado)         | Versión codificada de `.vbs` para ofuscación              | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .ps1      | Script de PowerShell          | Tareas modernas de automatización y configuración de Windows       | PowerShell (`powershell.exe`, `pwsh.exe`)                   |
| .js       | JScript                    | Versión de Microsoft de JavaScript para tareas de WSH          | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .jse      | JScript (codificado)          | Versión cifrada de `.js` para ofuscación               | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .wsf      | Archivo de script de Windows (XML)  | Mezcla VBScript, JScript y otros scripts en formato XML       | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .wsh      | Configuración de Windows Script Host | Ajustes de configuración para scripts de WSH                  | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .jar      | Archivo Java               | Aplicaciones Java empaquetadas como un único archivo             | `java.exe` (consola) / `javaw.exe` (sin ventana de consola)       |
| .hta      | Aplicación HTML (HTA)     | Scripts de Windows con GUI usando HTML, CSS y JScript/VBScript | `mshta.exe` (Microsoft HTML Application Host)          |
| .com      | Aplicación MS-DOS / Ejecutable DOS | Programas ejecutables heredados, pequeñas utilidades de línea de comandos | Se ejecuta directamente como programa; en Windows moderno, los programas clásicos .com de 16 bits se ejecutan a través de NTVDM en Windows de 32 bits, y no son compatibles de forma nativa en Windows x64/ARM |
| .chm     | Ayuda HTML compilada          | Archivos de ayuda/documentación sin conexión para programas de Windows   | `hh.exe` (Visor de ayuda HTML de Microsoft)                           |

## Scripts de inicio/inicio de sesión

Los scripts de inicio e inicio de sesión (y de apagado o cierre de sesión) son scripts de automatización que se ejecutan (gpscript.exe) automáticamente en equipos unidos a un dominio o cuando los usuarios inician sesión, y comúnmente se despliegan mediante Objetos de directiva de grupo (GPO) desde un controlador de dominio en un entorno de Windows Active Directory.

Inicio/Apagado
- Se ejecutan como: Cuenta Local System (privilegios altos).

Inicio de sesión/Cierre de sesión
- Se ejecutan como: Usuario actual (privilegios altos si es administrador).
### Usos comunes:
- Asignar unidades de red para todos los usuarios
- Instalar software
- Aplicar configuraciones a nivel de sistema
- Iniciar o configurar servicios
- Ejecutar scripts o ejecutables

### Colmenas del Registro afectadas

Cuando se ejecuta un script de inicio/inicio de sesión mediante GPO:

| Colmena / Ruta | Propósito |
|-------------|---------|
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logon | Rastrea los scripts de inicio de sesión del usuario, su orden de ejecución, estado, última hora de ejecución y parámetros. |
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logoff | Seguimiento similar para scripts de cierre de sesión. |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Startup | Información de seguimiento de scripts de inicio (se aplica a todos los usuarios). |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown | Información de scripts de apagado. |

#### Busque rutas escribibles por el usuario para scripts y ejecutables en el proceso hijo de gpscript.exe, o recursos compartidos de red escribibles o genéricos (SYSVOL). 
Lea los scripts que se ejecutan y busque si hay configuraciones incorrectas como otras rutas escribibles por el usuario o rutas que no existen o información sensible. Busque posibles contraseñas usadas (net use z: \\server\share /user:domain\username password) u otra información sensible. 

**Categorías de configuración incorrecta de scripts de inicio de sesión**
- SS1 – Credenciales en texto plano
- SS2 – Permisos inseguros (script de inicio de sesión modificable por un usuario normal)
- SS3 – Recursos compartidos inexistentes (que pueden ser creables por un usuario normal)
- SS4 - Administradores con scripts de inicio de sesión

**Configuraciones incorrectas de scripts de inicio de sesión**

1. SS1 - Credenciales en texto plano dentro de un script de inicio de sesión
2. SS2 - Permisos de recurso compartido inseguros
3. SS2 - Permisos de archivo inseguros
4. SS2 - Permisos inseguros de NETLOGON/SYSVOL
5. SS2 - Permisos inseguros de script de inicio de sesión
6. SS2 - Permisos inseguros de script de inicio de sesión de GPO
7. SS3 - Recursos compartidos inexistentes
8. SS4 - Administradores con script de inicio de sesión
9. SS4 - Administradores con scripts de inicio de sesión asignados desde un recurso compartido inexistente



## MSIExec / Reparaciones MSI
##### Nuestras pruebas no dieron ningún resultado en la escalada de privilegios en escenarios donde podíamos lanzar edge y salir a un símbolo del sistema de cmd. Esto probablemente se debe a que los navegadores basados en chromium suplantan al usuario/restringen el proceso de renderizado para ejecutarse como SYSTEM y no permiten que internet explorer/edge lancen cmd u otros procesos como el usuario SYSTEM. Creemos que si no hay instalado ningún navegador basado en chromium (como firefox) o versiones más antiguas. Una escalada de privilegios podría ser posible si se pudiera lanzar dicho proceso y salir de él a un símbolo del sistema.

Si desea enumerar posibles eventos relacionados con esto, consulte msiexec.exe como proceso padre con cmd.exe O conhost.exe O powershell.exe O pwsh.exe como proceso hijo.
Contacte a los usuarios de los que su consulta obtenga resultados y pregúnteles qué instalaron/repararon. También puede comprobar event.provider: "MsiInstaller" y event.code: (1033 OR 11707) o similar para obtener más contexto sobre qué instalador msi se instaló alrededor de la misma marca de tiempo.
También podría intentar esto usted mismo en Software Center e instalar las aplicaciones y buscar símbolos del sistema que pueda pausar antes de que desaparezcan marcando una sección en la ventana. Luego salga usando las mismas técnicas mencionadas en el enlace a continuación.



##### Consulta de ejemplo```
(event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1 AND winlog.event_data.IntegrityLevel: System AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))
OR
(event.provider: Microsoft-Windows-Security-Auditing AND event.code: 4688 AND winlog.event_data.TokenElevationType: "%%1936" AND winlog.event_data.MandatoryLabel: "S-1-16-16384" AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))