<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Otras formas de apoyar a HackTricks:
* Si quieres ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Vamos a verificar manualmente los permisos del servicio `RpcEptMapper` utilizando la GUI de `regedit`. Algo que realmente me gusta de la ventana _Configuración de seguridad avanzada_ es la pestaña _Permisos efectivos_. Puedes elegir cualquier nombre de usuario o grupo e inmediatamente ver los permisos efectivos que se le otorgan a este principal sin la necesidad de inspeccionar todos los ACEs por separado. La siguiente captura de pantalla muestra el resultado para la cuenta de bajo privilegio `lab-user`.
La mayoría de los permisos son estándar (por ejemplo: `Query Value`) pero uno en particular destaca: `Create Subkey`. El nombre genérico correspondiente a este permiso es `AppendData/AddSubdirectory`, que es exactamente lo que reportó el script:
¿Qué significa esto exactamente? Significa que no podemos simplemente modificar el valor de `ImagePath`, por ejemplo. Para hacerlo, necesitaríamos el permiso `WriteData/AddFile`. En cambio, solo podemos crear una nueva subclave.
En este punto, sabemos que podemos crear subclaves arbitrarias bajo `HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper` pero no podemos modificar subclaves y valores existentes. Estas subclaves ya existentes son `Parameters` y `Security`, que son bastante comunes para los servicios de Windows.
Por lo tanto, la primera pregunta que me vino a la mente fue: _¿hay alguna otra subclave predefinida - como `Parameters` y `Security` - que podríamos aprovechar para modificar efectivamente la configuración del servicio y alterar su comportamiento de alguna manera?_
Para responder a esta pregunta, mi plan inicial fue enumerar todas las claves existentes e intentar identificar un patrón. La idea era ver qué subclaves son _significativas_ para la configuración de un servicio. Empecé a pensar en cómo podría implementar eso en PowerShell y luego ordenar el resultado. Sin embargo, antes de hacerlo, me pregunté si esta estructura del registro ya estaba documentada. Así que busqué algo como `windows service configuration registry site:microsoft.com` y aquí está el primer [resultado](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/hklm-system-currentcontrolset-services-registry-tree) que apareció.
Parece prometedor, ¿no es así? A primera vista, la documentación no parecía ser exhaustiva y completa. Considerando el título, esperaba ver algún tipo de estructura de árbol detallando todas las subclaves y valores que definen la configuración de un servicio, pero claramente no estaba allí.
Aun así, eché un vistazo rápido a cada párrafo. Y rápidamente identifiqué las palabras clave "_**Performance**_" y "_**DLL**_". Bajo el subtítulo "**Performance**", podemos leer lo siguiente:
> **Performance**: _Una clave que especifica información para el monitoreo opcional del rendimiento. Los valores bajo esta clave especifican **el nombre de la DLL de rendimiento del controlador** y **los nombres de ciertas funciones exportadas en esa DLL**. Puedes agregar entradas de valor a esta subclave usando entradas AddReg en el archivo INF del controlador._
Según este breve párrafo, uno teóricamente puede registrar una DLL en un servicio de controlador para monitorear su rendimiento gracias a la subclave `Performance`. **¡Esto es realmente interesante!** Esta clave no existe por defecto para el servicio `RpcEptMapper`, por lo que parece ser _exactamente_ lo que necesitamos. Hay un pequeño problema, sin embargo, este servicio definitivamente no es un servicio de controlador. De todos modos, todavía vale la pena intentarlo, pero necesitamos más información sobre esta característica de "_Monitoreo de Rendimiento_" primero.
> **Nota:** en Windows, cada servicio tiene un `Type` dado. Un tipo de servicio puede ser uno de los siguientes valores: `SERVICE_KERNEL_DRIVER (1)`, `SERVICE_FILE_SYSTEM_DRIVER (2)`, `SERVICE_ADAPTER (4)`, `SERVICE_RECOGNIZER_DRIVER (8)`, `SERVICE_WIN32_OWN_PROCESS (16)`, `SERVICE_WIN32_SHARE_PROCESS (32)` o `SERVICE_INTERACTIVE_PROCESS (256)`.
Después de buscar en Google, encontré este recurso en la documentación: [Creating the Application’s Performance Key](https://docs.microsoft.com/en-us/windows/win32/perfctrs/creating-the-applications-performance-key).
Primero, hay una bonita estructura de árbol que enumera todas las claves y valores que tenemos que crear. Luego, la descripción proporciona la siguiente información clave:
Si sigues los enlaces que se incluyen en este recurso, incluso encontrarás el prototipo de estas funciones junto con algunos ejemplos de código: [Implementing OpenPerformanceData](https://docs.microsoft.com/en-us/windows/win32/perfctrs/implementing-openperformancedata).
Gracias a todos los fragmentos de información que pude recopilar a lo largo de la documentación, escribir una simple DLL de Prueba de Concepto debería ser bastante directo. ¡Pero aún así, necesitamos un plan!
Cuando necesito explotar algún tipo de vulnerabilidad de secuestro de DLL, normalmente comienzo con una función de ayuda de registro personalizada y simple. El propósito de esta función es escribir información clave en un archivo cada vez que se invoca. Típicamente, registro el PID del proceso actual y del proceso padre, el nombre del usuario que ejecuta el proceso y la línea de comandos correspondiente. También registro el nombre de la función que desencadenó este evento de registro. De esta manera, sé qué parte del código se ejecutó.
En mis otros artículos, siempre omití la parte de desarrollo porque asumí que era más o menos obvio. Pero, también quiero que mis publicaciones en el blog sean amigables para principiantes, así que hay una contradicción. Remediaré esta situación aquí detallando el proceso. Así que, ¡enciendamos Visual Studio y creemos un nuevo proyecto de "_C++ Console App_". Cabe destacar que podría haber creado un proyecto de "_Dynamic-Link Library (DLL)_" pero encuentro que en realidad es más fácil comenzar con una aplicación de consola.
Por supuesto, eso no es lo que queremos. Queremos crear una DLL, no un EXE, por lo que tenemos que reemplazar la función `main` por `DllMain`. Puedes encontrar un código base para esta función en la documentación: [Inicializar una DLL](https://docs.microsoft.com/en-us/cpp/build/run-time-library-behavior#initialize-a-dll).
En paralelo, también necesitamos cambiar la configuración del proyecto para especificar que el archivo compilado de salida debe ser una DLL en lugar de un EXE. Para hacerlo, puedes abrir las propiedades del proyecto y, en la sección "**General**", seleccionar "**Biblioteca Dinámica (.dll)**" como el "**Tipo de Configuración**". Justo debajo de la barra de título, también puedes seleccionar "**Todas las Configuraciones**" y "**Todas las Plataformas**" para que esta configuración se aplique de manera global.
Entonces, podemos poblar la DLL con las tres funciones que vimos en la documentación. La documentación también indica que deben retornar `ERROR_SUCCESS` si tienen éxito.
Ok, el proyecto ahora está correctamente configurado, `DllMain` está implementado, tenemos una función de ayuda para el registro y las tres funciones requeridas. Sin embargo, falta una última cosa. Si compilamos este código, `OpenPerfData`, `CollectPerfData` y `ClosePerfData` estarán disponibles solo como funciones internas, por lo que necesitamos **exportarlas**. Esto se puede lograr de varias maneras. Por ejemplo, podrías crear un archivo [DEF](https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-def-files) y luego configurar el proyecto adecuadamente. Sin embargo, prefiero usar la palabra clave `__declspec(dllexport)` ([doc](https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport)), especialmente para un proyecto pequeño como este. De esta manera, solo tenemos que declarar las tres funciones al principio del código fuente.
Finalmente, podemos seleccionar _**Release/x64**_ y "_**Compilar la solución**_". Esto producirá nuestro archivo DLL: `.\DllRpcEndpointMapperPoc\x64\Release\DllRpcEndpointMapperPoc.dll`.
Antes de continuar, siempre me aseguro de que mi payload funcione correctamente probándolo por separado. El poco tiempo invertido aquí puede ahorrar mucho tiempo después al evitar que te adentres en un agujero de conejo durante una hipotética fase de depuración. Para hacerlo, simplemente podemos usar `rundll32.exe` y pasar el nombre de la DLL y el nombre de una función exportada como parámetros.
Genial, el archivo de registro fue creado y, si lo abrimos, podemos ver dos entradas. La primera fue escrita cuando la DLL fue cargada por `rundll32.exe`. La segunda fue escrita cuando se llamó a `OpenPerfData`. ¡Se ve bien! 
Ahora podemos centrarnos en la vulnerabilidad actual y comenzar creando la clave de registro y los valores necesarios. Podemos hacer esto manualmente usando `reg.exe` / `regedit.exe` o programáticamente con un script. Dado que ya pasé por los pasos manuales durante mi investigación inicial, mostraré una forma más limpia de hacer lo mismo con un script de PowerShell. Además, crear claves y valores de registro en PowerShell es tan fácil como llamar a `New-Item` y `New-ItemProperty`, ¿no es así? 
`Requested registry access is not allowed`… Hmm, ok… Parece que después de todo no será tan fácil. 
Realmente no investigué este problema, pero mi suposición es que cuando llamamos a `New-Item`, `powershell.exe` en realidad intenta abrir la clave de registro padre con algunas banderas que corresponden a permisos que no tenemos.
De todos modos, si los cmdlets integrados no hacen el trabajo, siempre podemos bajar un nivel e invocar funciones de DotNet directamente. De hecho, las claves de registro también pueden crearse con el siguiente código en PowerShell.
Aquí vamos. Al final, armé el siguiente script para crear la clave y los valores apropiados, esperar la entrada del usuario y finalmente terminar limpiando todo.
El último paso ahora, **¿cómo engañamos al servicio RPC Endpoint Mapper para que cargue nuestra DLL de Rendimiento?** Desafortunadamente, no he seguido la pista de todas las diferentes cosas que intenté. Habría sido realmente interesante en el contexto de esta entrada de blog destacar lo tedioso y consumidor de tiempo que a veces puede ser la investigación. De todos modos, una cosa que encontré en el camino es que puedes consultar _Contadores de Rendimiento_ usando WMI (_Instrumentación de Gestión de Windows_), lo cual no es demasiado sorprendente después de todo. Más información aquí: [_Tipos de Contadores de Rendimiento de WMI_](https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-performance-counter-types).
> _Los tipos de contadores aparecen como el calificador CounterType para propiedades en clases_ [_Win32\_PerfRawData_](https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-perfrawdata) _, y como el calificador CookingType para propiedades en clases_ [_Win32\_PerfFormattedData_](https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-perfformatteddata) _._
Esperaba obtener la ejecución de código arbitrario como `NETWORK SERVICE` en el contexto del servicio `RpcEptMapper` como mucho, pero parece que obtuve un resultado mucho mejor de lo anticipado. ¡De hecho, conseguí la ejecución de código arbitrario en el contexto del servicio `WMI` en sí, que se ejecuta como `LOCAL SYSTEM`! ¿No es increíble? 
> **Nota:** si hubiera conseguido la ejecución de código arbitrario como `NETWORK SERVICE`, habría estado a solo un token de distancia de la cuenta `LOCAL SYSTEM` gracias al truco que fue demostrado por James Forshaw hace unos meses en esta entrada de blog: [Compartiendo una Sesión de Inicio de Sesión un Poco Demasiado](https://www.tiraniddo.dev/2020/04/sharing-logon-session-little-too-much.html).
No sé cómo esta vulnerabilidad ha pasado desapercibida durante tanto tiempo. Una explicación es que otras herramientas probablemente buscaban acceso completo de escritura en el registro, mientras que `AppendData/AddSubdirectory` era en realidad suficiente en este caso. En cuanto a la "configuración incorrecta" en sí, asumiría que la clave del registro se estableció de esa manera por un propósito específico, aunque no puedo pensar en un escenario concreto en el que los usuarios tendrían algún tipo de permisos para modificar la configuración de un servicio.
Decidí escribir sobre esta vulnerabilidad públicamente por dos razones. La primera es que la hice pública - sin darme cuenta inicialmente - el día que actualicé mi script PrivescCheck con la función `GetModfiableRegistryPath`, que fue hace varios meses. La segunda es que el impacto es bajo. Requiere acceso local y solo afecta a versiones antiguas de Windows que ya no tienen soporte (a menos que hayas comprado el Soporte Extendido...). A estas alturas, si todavía estás usando Windows 7 / Server 2008 R2 sin aislar estas máquinas adecuadamente en la red primero, entonces prevenir que un atacante obtenga privilegios de SYSTEM es probablemente lo menos de tus preocupaciones.
Aparte del lado anecdótico de esta vulnerabilidad de escalada de privilegios, creo que esta configuración del registro "Perfomance" abre oportunidades realmente interesantes para la post-explotación, el movimiento lateral y la evasión de AV/EDR. Ya tengo en mente algunos escenarios particulares pero aún no he probado ninguno de ellos. ¿Continuará?...
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
