Vamos verificar manualmente as permissões do serviço `RpcEptMapper` usando a interface gráfica do `regedit`. Uma coisa que eu realmente gosto na janela _Advanced Security Settings_ é a guia _Effective Permissions_. Você pode escolher qualquer nome de usuário ou grupo e imediatamente ver as permissões efetivas concedidas a esse principal sem a necessidade de inspecionar todas as ACEs separadamente. A seguinte captura de tela mostra o resultado para a conta de baixo privilégio `lab-user`.
A maioria das permissões são padrão (por exemplo: `Query Value`), mas uma em particular se destaca: `Create Subkey`. O nome genérico correspondente a essa permissão é `AppendData/AddSubdirectory`, que é exatamente o que foi relatado pelo script:
Isso significa que não podemos simplesmente modificar o valor `ImagePath`, por exemplo. Para fazer isso, precisaríamos da permissão `WriteData/AddFile`. Em vez disso, só podemos criar uma nova subchave.
Neste ponto, sabemos que podemos criar subchaves arbitrárias em `HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper`, mas não podemos modificar subchaves e valores existentes. Essas subchaves já existentes são `Parameters` e `Security`, que são bastante comuns para serviços do Windows.
Portanto, a primeira pergunta que veio à mente foi: _existe alguma outra subchave predefinida - como `Parameters` e `Security` - que poderíamos aproveitar para modificar efetivamente a configuração do serviço e alterar seu comportamento de alguma forma?_
Para responder a essa pergunta, meu plano inicial era enumerar todas as chaves existentes e tentar identificar um padrão. A ideia era ver quais subchaves são _significativas_ para a configuração de um serviço. Comecei a pensar em como poderia implementar isso em PowerShell e, em seguida, classificar o resultado. No entanto, antes de fazer isso, perguntei-me se essa estrutura de registro já estava documentada. Então, pesquisei algo como `windows service configuration registry site:microsoft.com` e aqui está o primeiro [resultado](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/hklm-system-currentcontrolset-services-registry-tree) que apareceu.
Parece promissor, não é? À primeira vista, a documentação não parecia ser exaustiva e completa. Considerando o título, eu esperava ver algum tipo de estrutura de árvore detalhando todas as subchaves e valores que definem a configuração de um serviço, mas claramente não estava lá.
Ainda assim, dei uma olhada rápida em cada parágrafo. E rapidamente identifiquei as palavras-chave "_**Performance**_" e "_**DLL**_". Sob o subtítulo "**Perfomance**", podemos ler o seguinte:
> **Performance**: _Uma chave que especifica informações para monitoramento de desempenho opcional. Os valores sob esta chave especificam **o nome da DLL de desempenho do driver** e **os nomes de certas funções exportadas nessa DLL**. Você pode adicionar entradas de valor a esta subchave usando entradas AddReg no arquivo INF do driver._
De acordo com este breve parágrafo, teoricamente, pode-se registrar uma DLL em um serviço de driver para monitorar seu desempenho graças à subchave `Performance`. **OK, isso é realmente interessante!** Essa chave não existe por padrão para o serviço `RpcEptMapper`, então parece ser _exatamente_ o que precisamos. Há um pequeno problema, no entanto, este serviço definitivamente não é um serviço de driver. De qualquer forma, ainda vale a pena tentar, mas precisamos de mais informações sobre esse recurso de "Monitoramento de Desempenho" primeiro.
> **Observação:** no Windows, cada serviço tem um determinado `Tipo`. Um tipo de serviço pode ser um dos seguintes 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)` ou `SERVICE_INTERACTIVE_PROCESS (256)`.
Depois de pesquisar um pouco, encontrei este recurso na documentação: [Criando a chave de desempenho do aplicativo](https://docs.microsoft.com/pt-br/windows/win32/perfctrs/creating-the-applications-performance-key).
Primeiro, há uma estrutura de árvore agradável que lista todas as chaves e valores que precisamos criar. Em seguida, a descrição fornece as seguintes informações-chave:
Se você seguir os links incluídos neste recurso, encontrará o protótipo dessas funções junto com alguns exemplos de código: [Implementando OpenPerformanceData](https://docs.microsoft.com/pt-br/windows/win32/perfctrs/implementing-openperformancedata).
Graças a todos os pedaços de informação que consegui coletar ao longo da documentação, escrever uma DLL simples de prova de conceito deve ser bem simples. Mas ainda assim, precisamos de um plano!
Quando preciso explorar algum tipo de vulnerabilidade de sequestro de DLL, geralmente começo com uma função de ajuda de log simples e personalizada. O objetivo desta função é escrever algumas informações-chave em um arquivo sempre que for invocada. Normalmente, registro o PID do processo atual e do processo pai, o nome do usuário que executa o processo e a linha de comando correspondente. Também registro o nome da função que desencadeou este evento de log. Dessa forma, eu sei qual parte do código foi executada.
Em meus outros artigos, sempre pulei a parte de desenvolvimento porque assumi que era mais ou menos óbvio. Mas, também quero que meus posts sejam amigáveis para iniciantes, então há uma contradição. Vou remediar essa situação aqui detalhando o processo. Então, vamos abrir o Visual Studio e criar um novo projeto "Aplicativo de console C++". Observe que eu poderia ter criado um projeto "Biblioteca de vínculo dinâmico (DLL)", mas acho que é mais fácil começar com um aplicativo de console.
Claro, isso não é o que queremos. Queremos criar uma DLL, não um EXE, então temos que substituir a função `main` por `DllMain`. Você pode encontrar um código esqueleto para esta função na documentação: [Inicializar uma DLL](https://docs.microsoft.com/pt-br/cpp/build/run-time-library-behavior#initialize-a-dll).
Em paralelo, também precisamos alterar as configurações do projeto para especificar que o arquivo compilado de saída deve ser um DLL em vez de um EXE. Para fazer isso, você pode abrir as propriedades do projeto e, na seção "**Geral**", selecionar "**Biblioteca dinâmica (.dll)**" como o "**Tipo de configuração**". Logo abaixo da barra de título, você também pode selecionar "**Todas as configurações**" e "**Todas as plataformas**" para que essa configuração possa ser aplicada globalmente.
Então, podemos preencher a DLL com as três funções que vimos na documentação. A documentação também afirma que elas devem retornar `ERROR_SUCCESS` se forem bem-sucedidas.
Ok, então o projeto está agora configurado corretamente, `DllMain` está implementado, temos uma função auxiliar de log e as três funções necessárias. No entanto, falta uma última coisa. Se compilarmos este código, `OpenPerfData`, `CollectPerfData` e `ClosePerfData` estarão disponíveis apenas como funções internas, então precisamos **exportá-las**. Isso pode ser alcançado de várias maneiras. Por exemplo, você poderia criar um arquivo [DEF](https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-def-files) e, em seguida, configurar o projeto adequadamente. No entanto, prefiro usar a palavra-chave `__declspec(dllexport)` ([doc](https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport)), especialmente para um projeto pequeno como este. Dessa forma, só precisamos declarar as três funções no início do código-fonte.
Finalmente, podemos selecionar _**Release/x64**_ e “_**Build the solution**_”. Isso produzirá nosso arquivo DLL: `.\DllRpcEndpointMapperPoc\x64\Release\DllRpcEndpointMapperPoc.dll`.
Antes de prosseguir, sempre me certifico de que minha carga útil está funcionando corretamente testando-a separadamente. O pouco tempo gasto aqui pode economizar muito tempo depois, evitando que você entre em um beco sem saída durante uma fase hipotética de depuração. Para fazer isso, podemos simplesmente usar `rundll32.exe` e passar o nome do DLL e o nome de uma função exportada como parâmetros.
Ótimo, o arquivo de log foi criado e, se o abrirmos, podemos ver duas entradas. A primeira foi escrita quando a DLL foi carregada pelo `rundll32.exe`. A segunda foi escrita quando `OpenPerfData` foi chamado. Parece bom! 😊
Ok, agora podemos nos concentrar na vulnerabilidade real e começar criando a chave e os valores do registro necessários. Podemos fazer isso manualmente usando `reg.exe` / `regedit.exe` ou programaticamente com um script. Como eu já passei pelas etapas manuais durante minha pesquisa inicial, mostrarei uma maneira mais limpa de fazer a mesma coisa com um script do PowerShell. Além disso, criar chaves e valores de registro no PowerShell é tão fácil quanto chamar `New-Item` e `New-ItemProperty`, não é mesmo? 
`Acesso ao registro solicitado não é permitido`... Hmmm, ok... Parece que não será tão fácil assim. 
Eu não investiguei muito esse problema, mas minha suposição é que, quando chamamos `New-Item`, o `powershell.exe` tenta abrir a chave do registro pai com algumas flags que correspondem a permissões que não temos.
De qualquer forma, se os cmdlets integrados não fizerem o trabalho, sempre podemos descer um nível e invocar as funções DotNet diretamente. De fato, as chaves do registro também podem ser criadas com o seguinte código no PowerShell.
Aqui vamos nós! No final, eu montei o seguinte script para criar a chave e valores apropriados, esperar por alguma entrada do usuário e finalmente encerrar limpando tudo.
O último passo agora, **como enganamos o serviço RPC Endpoint Mapper para carregar nossa DLL de desempenho?** Infelizmente, não acompanhei todas as diferentes coisas que tentei. Teria sido realmente interessante no contexto deste post destacar como a pesquisa pode ser tediosa e demorada às vezes. De qualquer forma, uma coisa que encontrei ao longo do caminho é que você pode consultar _Contadores de Desempenho_ usando o WMI (_Windows Management Instrumentation_), o que não é muito surpreendente afinal. Mais informações aqui: [_Tipos de Contadores de Desempenho do WMI_](https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-performance-counter-types).
> _Os tipos de contadores aparecem como o qualificador CounterType para propriedades nas classes_ [_Win32\_PerfRawData_](https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-perfrawdata) _, e como o qualificador CookingType para propriedades nas classes_ [_Win32\_PerfFormattedData_](https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-perfformatteddata) _._
Eu esperava obter a execução de código arbitrário como `NETWORK SERVICE` no contexto do serviço `RpcEptMapper`, no máximo, mas parece que obtive um resultado muito melhor do que o esperado. Na verdade, obtive a execução de código arbitrário no contexto do próprio serviço `WMI`, que é executado como `LOCAL SYSTEM`. Como isso é incrível?! 
> **Observação:** se eu tivesse obtido a execução de código arbitrário como `NETWORK SERVICE`, estaria a apenas um token da conta `LOCAL SYSTEM`, graças ao truque que foi demonstrado por James Forshaw alguns meses atrás neste post do blog: [Sharing a Logon Session a Little Too Much](https://www.tiraniddo.dev/2020/04/sharing-logon-session-little-too-much.html).
Não sei como essa vulnerabilidade passou despercebida por tanto tempo. Uma explicação é que outras ferramentas provavelmente procuravam acesso total de gravação no registro, enquanto `AppendData/AddSubdirectory` era suficiente nesse caso. Em relação à "configuração incorreta" em si, eu presumiria que a chave do registro foi definida dessa maneira para um propósito específico, embora eu não possa pensar em um cenário concreto em que os usuários teriam algum tipo de permissão para modificar a configuração de um serviço.
Decidi escrever sobre essa vulnerabilidade publicamente por duas razões. A primeira é que eu a tornei pública - sem perceber inicialmente - no dia em que atualizei meu script PrivescCheck com a função `GetModfiableRegistryPath`, que foi há vários meses. A segunda é que o impacto é baixo. Requer acesso local e afeta apenas versões antigas do Windows que não são mais suportadas (a menos que você tenha adquirido o Suporte Estendido...). Neste ponto, se você ainda estiver usando o Windows 7 / Server 2008 R2 sem isolar adequadamente essas máquinas na rede primeiro, impedir que um invasor obtenha privilégios do SYSTEM provavelmente é a menor de suas preocupações.
Além do lado anedótico dessa vulnerabilidade de escalonamento de privilégios, acredito que essa configuração de registro de "Desempenho" abre oportunidades realmente interessantes para pós-exploração, movimento lateral e evasão de AV/EDR. Já tenho alguns cenários específicos em mente, mas ainda não testei nenhum deles. Continua?...
- Você trabalha em uma **empresa de segurança cibernética**? Quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
- Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
- **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Compartilhe suas técnicas de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
