RemoteMonologue: Armando o DCOM para coerções de autenticação NTLM

Os dias de obter credenciais sem esforço com Mimikatz estão, para o bem ou para o mal, chegando ao fim. À medida que a Microsoft fortalece as defesas contra roubo de credenciais e as soluções de Detecção e Resposta de Endpoint (EDR) continuam avançando, as técnicas tradicionais de red team, como movimento lateral, execução de carga útil e acesso direto ao Local Security Authority Subsystem Service (LSASS), estão sob análise cada vez mais rigorosa. Como resultado, a comunidade red team foi forçada a explorar métodos alternativos para coletar credenciais em sistemas Windows.

Imagine alcançar resultados semelhantes sem a necessidade de um payload “avançado” ou de acessar o LSASS, simplesmente utilizando recursos já existentes e aproveitando objetos pouco utilizados do Component Object Model (COM). Se isso empolga você, fique de olho, porque este blog está repleto de dicas divertidas que podem ser usadas em seu próximo engajamento.

Vamos abordar brevemente os fundamentos do COM e seu equivalente distribuído, o Distributed Component Object Model (DCOM), explorar a configuração RunAs e explicar por que as coerções de autenticação são impactantes, além de apresentar uma nova ferramenta de coleta de credenciais - RemoteMonologue.

O Component Object Model (COM) é uma das tecnologias mais antigas e onipresentes no Windows, que opera silenciosamente nos bastidores de aplicações e serviços do dia a dia. Apesar de sua idade, o COM continua sendo um recurso valioso para os invasores, oferecendo maneiras alternativas de obter movimento lateral, escalada de privilégios e persistência. No entanto, sua complexidade inerente fez com que grande parte de sua superfície de ataque não fosse explorada.

Para este blog, os principais conceitos a serem entendidos são:

• COM: uma tecnologia central do Windows que permite que componentes de software interajam entre si, através de limites de processo. O COM permite que os programas reutilizem funcionalidades de outros programas sem duplicá-las. Por exemplo, um programa pode usar um objeto COM para ler logs do sistema ou adicionar novas entradas a um arquivo do Excel sem implementar essas funcionalidades em si.
• DCOM (Distributed Component Object Model): uma extensão do COM que permite a comunicação baseada em rede. Com o DCOM, um processo em execução em uma máquina pode invocar funções em um objeto COM localizado em outra máquina. Esse recurso baseado em rede tornou o DCOM uma ferramenta valiosa para o movimento lateral. O acesso a objetos DCOM normalmente exige privilégios de administrador local no sistema remoto.

Em um nível mais elevado, pense nos objetos COM como unidades independentes com dois componentes principais:

• Propriedades: representam o estado ou a configuração do objeto.
• Métodos: representam as ações que o objeto pode executar. Por exemplo, um objeto COM pode ter um método para iniciar um processo, criar um arquivo ou iniciar uma solicitação de autenticação.

Os invasores podem explorar esses métodos para facilitar a movimentação lateral e, como ilustraremos em breve, forçar autenticações NTLM remotas para ataques de quebra de senhas e retransmissão.

Antes de entrar na parte divertida, um componente importante do COM precisa ser discutido com mais detalhes. Um identificador de aplicação (AppID) em COM serve como um mecanismo fundamental para gerenciar a segurança, a identidade e o comportamento de tempo de execução de aplicações COM, particularmente em cenários que envolvem DCOM ou aplicativos que exigem contextos de segurança específicos. Quando uma classe COM é registrada com um AppID, ela herda as configurações de segurança definidas para esse AppID.

A configuração de segurança de maior interesse é a chave RunAs, que especifica qual conta de usuário será usada para executar um objeto DCOM na instanciação. A chave RunAs pode ser encontrada no registro em:

• HKEY_CLASSES_ROOT\AppID\{AppID_GUID}

Ao analisar a documentação da Microsoft sobre DCOM e a chave RunAs, um valor específico chamou a atenção: Interactive User. Esse valor configura o objeto DCOM para ser executado no contexto de segurança do usuário atualmente conectado à sessão de console do sistema. Do ponto de vista ofensivo, isso é interessante porque poderia nos permitir aproveitar objetos DCOM para operar como outro usuário sem saber as credenciais do usuário afetado.

Nem todos os objetos DCOM com um AppID têm um valor RunAs definido como Interactive User. Na verdade, aproximadamente metade dos AppIDs não tem um valor RunAs definido. No entanto, e se o valor RunAs pudesse ser adicionado ou modificado para atender aos nossos objetivos?

Por padrão, um AppID no registro é protegido com uma Discretionary Access Control List (DACL), concedendo privilégios de propriedade ao TrustedInstaller e restringindo os administradores locais ao acesso somente leitura, conforme mostrado na Figura 1.

No entanto, os administradores locais recebem o privilégio SeTakeOwnershipPrivilege, em que é permitido assumir a propriedade de objetos do sistema, incluindo chaves de registro. Esse privilégio é relevante para esse ataque porque nos permite alterar a propriedade de um AppID. Uma vez que a propriedade é alterada, podemos conceder permissões de Controle total sobre o AppID e, posteriormente, modificar suas configurações para adicionar ou alterar o valor RunAs.

Uma vez que o valor RunAs é modificado para Interactive User, o ataque se torna simples. Isso nos permite forçar a execução de um objeto DCOM no contexto de outra sessão ativa. No entanto, o sucesso desse ataque depende, em última análise, das propriedades e dos métodos expostos pelo objeto DCOM específico que está sendo visado.

Agora que sabemos que é possível converter um objeto DCOM em uma ferramenta de sequestro de sessão, a próxima etapa é identificar quais métodos e propriedades podem ser aproveitados para concluir o sequestro. Para esta pesquisa, verifiquei se o comprometimento do usuário poderia ser obtido sem executar uma carga útil, adotando uma abordagem diferente da maioria das técnicas públicas de movimento lateral do DCOM.

Meu objetivo era alcançar resultados comparáveis em um formato "sem arquivos", ou seja, sem a necessidade de transferir ou executar uma carga útil no sistema de destino. Essa distinção é importante porque transferir e executar cargas úteis em um sistema de destino geralmente é considerado uma ação “cara” nas operações de red team. Ao evitar essa etapa, o risco de acionar controles de segurança comuns é significativamente reduzido. Portanto, meu objetivo era comprometer contas de usuários remotos forçando uma autenticação NTLM via DCOM.

Existem diversos benefícios em forçar autenticações NTLM em vez de executar técnicas tradicionais de movimento lateral:

• Capture hashes NTLMv1/NTLMv2 e tente quebrá-los offline
• Retransmita hashes NTLMv1 ou WebDAV NTLMv2 para outros serviços de rede, como LDAP ou SMB, para executar ações como o usuário afetado
• Evite transferir e executar uma carga útil no sistema de destino, o que normalmente atrai mais atenção das ferramentas de segurança
• Evite tocar no processo LSASS, reduzindo assim os riscos de detecção

No momento em que este artigo foi escrito, a assinatura LDAP e a vinculação de canais não eram necessárias e aplicadas por padrão na maioria dos controladores de domínio. Essas funcionalidades de segurança são obrigatórias apenas no Windows Server 2025. Isso significa que, se pudermos forçar uma autenticação NTLMv1 ou WebDAV do sistema de destino, podemos retransmiti-la para o LDAP e executar ações como o usuário afetado. Da mesma forma, a assinatura SMB não é exigida por padrão nos servidores Windows, exceto para controladores de domínio.

Outro fator importante a considerar é que os hashes NTLMv1 podem ser facilmente quebrados usando tabelas rainbow, que foram compartilhadas publicamente por Nic Losby, em dezembro de 2024. Essas tabelas reduzem drasticamente o tempo e o esforço necessários para recuperar as credenciais NTLM dos hashes NTLMv1. Para obter um hash NTLMv1 em vez de um hash NTLMv2, modificamos a seguinte chave de registro no sistema de destino:

• HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

A configuração de LmCompatibilityLevel em um valor igual ou inferior a 2 força o sistema a usar NTLMv1 para autenticação. Essa modificação é possível com privilégios de administrador local e é comumente chamada de "ataque de downgrade NetNTLMv1".

Como alternativa, podemos capturar uma autenticação WebDAV e retransmiti-la para o LDAP, já que as autenticações baseadas em HTTP podem ser encaminhadas para esse serviço. Caso o serviço WebClient ainda não esteja em execução com acesso privilegiado, podemos habilitá-lo remotamente no sistema de destino. Uma vez habilitado, podemos forçar uma autenticação WebDAV NTLM para nosso listener especificando o nome NetBIOS da máquina no caminho UNC. Por exemplo:

• \\MYHACKERBOX@80\giveme\creds.txt

Para obter mais informações sobre ataques de retransmissão NTLM e os protocolos que podem ser retransmitidos para diferentes endpoints, consulte o seguinte recurso aqui.

Durante minha pesquisa, analisei o objeto DCOM ServerDataCollectorSet, que possui o CLSID {03837546-098B-11D8-9414-505054503030}, para identificar métodos e propriedades que poderiam ser aproveitados para coerção de autenticação. Uma propriedade que se destacou foi a DataManager, e felizmente, esse objeto COM incluía uma biblioteca de tipos, que define seus métodos e propriedades com mais detalhes.

Usando o OleView.NET, eu revisei a biblioteca de tipos do ServerDataCollectorSet’s e descobri que a propriedade DataManager tinha um método Extract que esperava dois parâmetros:

1. CabFilename – nome de um arquivo CAB a ser extraído.
2. DestinationPath – caminho para extrair o conteúdo do arquivo CAB.

A presença do parâmetro CabFilename era particularmente interessante porque oferecia a possibilidade de fornecer um caminho UNC, o que poderia resultar em uma ação de autenticação de rede.

Para testar essa teoria, forneci um caminho UNC para o parâmetro CabFilename apontando para o meu sistema(172.22.164.58) executando Responder, como mostrado na Figura 4. O resultado? Sucesso! Conseguimos capturar um hash NTLMv2, como mostra a Figura 5.

Em seguida, testei se era possível capturar credenciais de um usuário diferente em um sistema remoto (172.22.166.170) modificando a chave RunAs do ServerDataCollectorSet. Para conseguir isso, usei o serviço Remote Registry para adicionar o valor Interactive User ao AppID {03837503-098B-11D8-9414-505054503030}.

Quando um usuário diferente estava conectado ao sistema de destino (nesse caso, GALAXY\yoda), acessei o objeto DCOM ServerDataCollectorSet como GALAXY\Administrator e executei o mesmo método Extract mostrado na Figura 6. Novamente, capturei com sucesso uma autenticação; no entanto, desta vez a partir do GALAXY\yoda, como mostra a Figura 7. Isso demonstra que a modificação da chave RunAs para Interactive User nos permite aproveitar os objetos DCOM para sequestrar sessões de outros usuários.

O fluxo desse ataque é mostrado no diagrama abaixo.

Outro objeto DCOM interessante suscetível à coerção de autenticação é o FileSystemImage, que tem o CLSID {2C941FC5-975B-59BE-A960-9A2A262853A5}. Esse objeto é particularmente único porque a coerção é acionada simplesmente modificando uma propriedade em vez de invocar um método – uma técnica menos comum em ataques baseados em DCOM.

A propriedade em questão é o WorkingDirectory que, por padrão, aponta para a pasta %TEMP% do usuário interativo. No entanto, ao alterar o valor de WorkingDirectory para um caminho UNC que aponte para o nosso listener, é possível capturar uma autenticação NTLMv2, conforme mostrado nas Figuras 9 e 10.

Para validar seus recursos de sequestro de sessão, testei isso remotamente, definindo a chave RunAs para o AppID {2C941FD1-975B-59BE-A960-9A2A262853A5} para Interactive User. Essa configuração fez com que o objeto DCOM FileSystemImage fosse executado no contexto de segurança do usuário ativo no sistema de destino. E, como esperado, consegui capturar o hash NTLMv2 desse usuário.

Essa técnica demonstra que as coerções de autenticação podem ser alcançadas modificando tanto as propriedades quanto os métodos, expandindo assim a superfície de ataque de objetos DCOM.

Um último objeto DCOM que vale a pena compartilhar é o UpdateSession, que tem o CLSID {4CB43D7F-7EEE-4906-8698-60DA1C38F2FE}. Ao analisar sua biblioteca de tipos, o método AddScanPackageService se destaca por exigir um argumento serviceName e, mais interessante ainda, um argumento scanFileLocation . A presença do ScanFileLocation indica que ele pode aceitar um caminho UNC.

Ao testar essa teoria, capturamos com sucesso uma autenticação NTLMv2, mas em vez de recebermos as credenciais da conta do usuário, recebemos as credenciais da conta da máquina, conforme ilustrado abaixo.

Essa descoberta é particularmente interessante porque, mesmo após adicionar uma chave RunAs e configurá-la como Interactive User, o objeto DCOM UpdateSession ainda executava operações de rede como a conta da máquina. Então, por que isso acontece? A resposta simples é que, enquanto o próprio objeto DCOM é executado sob o contexto de segurança do usuário interativo ou de instanciação, as operações de rede são executadas por um processo separado: svchost.exe. O caminho UNC é passado para o svchost.exe, que por padrão usa a conta SYSTEM para essas operações. Portanto, a configuração da chave RunAs não afeta esse comportamento.

Embora a chave RunAs não influencie a conta usada para operações de rede, a captura de credenciais de conta de máquina ainda é valiosa para vários cenários de ataque:

1. Acesso a permissões interessantes da DACL no Active Directory:
   Contas de máquina (por exemplo, DOMAIN\MACHINE$) podem ter permissões para objetos específicos no Active Directory que podem ser úteis para movimento lateral ou escalonamento de privilégios.
2. Forjar silver tickets para maior evasão:
   Podemos usar o hash NTLM de uma conta de máquina para forjar um silver ticket, o que nos permite passar por qualquer usuário no sistema e executar ações com um risco reduzido de detecção.

Esse ataque foi chamado de RemoteMonologue, pois funciona de forma semelhante ao InternalMonologue, a principal diferença é que ele realiza o ataque remotamente. A ferramenta foi desenvolvida em Python utilizando a biblioteca Impacket e automatiza o processo de ataque.

O RemoteMonologue oferece a capacidade de direcionar qualquer um dos três objetos DCOM mencionados anteriormente(-dcom) para executar a coerção de autenticação em relação a um listener especificado(-auth-to). Além disso, possui uma funcionalidade de pulverização (-spray) para validar credenciais em vários sistemas, com o benefício adicional de capturar credenciais. A ferramenta também oferece suporte a um ataque de downgrade do NetNTLMv1(-downgrade) e tem uma opção para ativar o serviço WebClient para facilitar as autenticações HTTP(-webclient). Por fim, a ferramenta inclui um módulo de consulta(-query) para enumerar os usuários com uma sessão ativa no sistema de destino.

Veja abaixo um exemplo de execução do RemoteMonologue com o ataque de downgrade do NetNTLMv1 enquanto usa o Responder como listener. Por padrão, se nenhuma opção de DCOM for especificada, a ferramenta usará o objeto DCOM ServerDataCollectorSet.

Abaixo está outro exemplo. Desta vez, o ataque é executado usando o objeto DCOM FileSystemImage, permitindo que o serviço WebClient obtenha uma autenticação HTTP, que é então retransmitida para o LDAP usando o ntlmrelayx.

Para proteger e detectar as técnicas descritas neste blog, várias medidas preventivas e de detecção podem ser implementadas.

Medidas preventivas:

1. Habilitar assinatura LDAP e vinculação de canais: configure a aplicação de assinatura LDAP e vinculação de canais em controladores de domínio para proteger o endpoint LDAP contra ataques de retransmissão. Observação: essas configurações serão aplicadas por padrão a partir do Windows Server 2025.
2. Atualize para as versões mais recentes do Windows: atualize servidores para o Windows Server 2025 e estações de trabalho para o Windows 11 versão 24H2 a fim de mitigar ataques de downgrade NetNTLM, já que o NTLMv1 foi removido nessas versões.
3. Imponha a assinatura SMB: habilite e aplique a assinatura SMB nos servidores Windows para evitar ataques de retransmissão SMB.
4. Implemente políticas de senhas fortes: imponha requisitos de senhas robustas para dificultar os ataques de quebra de senhas.

Oportunidades de detecção:

1. Monitore o acesso remoto aos objetos DCOM: rastreie o acesso aos objetos DCOM afetados, suas propriedades e métodos específicos para identificar atividades incomuns.
2. Monitore as modificações no registro: monitore as alterações nas chaves de registro RunAs e LmCompatibilityLevel.
3. Monitore a atividade do serviço WebClient: fique atento às instâncias em que o serviço WebClient está habilitado remotamente, pois isso é usado para facilitar as autenticações NTLM baseadas em HTTP.

O ataque RemoteMonologue mostra como objetos DCOM subutilizados podem ser transformados em armas para realizar ataques de coerção de autenticação ocultos e sem arquivo. Ao modificar propriedades específicas e aproveitar técnicas como o downgrade do NetNTLMv1, os invasores podem comprometer contas de usuários e escalar privilégios sem implementar cargas úteis ou acessar diretamente processos confidenciais como LSASS.

Ao se concentrar no fortalecimento dos principais sistemas, como impor a assinatura LDAP, a assinatura SMB e a desativação de protocolos legados, como o NTLMv1, os defensores podem reduzir significativamente a superfície de ataque. Além disso, o monitoramento robusto de modificações de registro, atividade DCOM e alterações de serviço remoto pode ajudar a detectar essas técnicas em estágios iniciais e mitigar o impacto.