DCOM como vetor de movimentação lateral no Windows: o walkthrough técnico que todo SOC precisa ler antes do próximo alerta

Distributed COM (DCOM) é um recurso administrativo legítimo do Windows que permite a um processo em uma máquina instanciar e invocar métodos de objetos COM em outro host da rede — exatamente a propriedade que faz com que atacantes que já capturaram credenciais usem o protocolo para movimentação lateral sem precisar plantar malware no destino. Um novo guia técnico publicado em 23 de junho de 2026 por oxfemale na core-jmp.org, baseado em material original de Zshan Hyder (Detect FYI), reconstrói o fluxo de ataque passo a passo, mapeia os Event IDs do Sysmon e do Windows Security que correlacionam cada estágio, e oferece uma régua de prevenção que combina ACLs de ativação DCOM, segmentação de porta 135, LAPS e Credential Guard. Para times de SOC e blue team brasileiros, é um dos walkthroughs mais úteis disponíveis sobre T1021.003 do MITRE ATT&CK.

O que é DCOM e por que ele existe

Component Object Model (COM) é a camada que permite que dois aplicativos rodando no mesmo host Windows troquem dados e funcionalidade — o mecanismo clássico por trás de embutir um gráfico do Excel dentro de um documento do Word, por exemplo. Distributed COM (DCOM) estende esse modelo para a rede: um programa rodando no Computador A pode instanciar e chamar métodos em um objeto COM hospedado no Computador B. É uma capacidade administrativa legítima, e por isso mesmo é exatamente o vetor preferido para quem já tem credenciais válidas e quer se mover sem disparar alarmes triviais.

O artigo da core-jmp.org parte dessa premissa para construir um modelo mental completo: descreve o handshake DCOM com o serviço RPCSS na porta 135, a checagem de Machine Launch Restriction (MLR) feita antes de a Service Control Manager spawnar o processo solicitado, a negociação de uma porta TCP dinâmica de alto número para o resto da conversa, e a invocação de métodos via IRemUnknown. A maior parte das equipes de detecção trata DCOM como uma caixa-preta — esse guia abre a caixa para que o analista possa investigar de fato um alerta em vez de fechá-lo às cegas.

O fluxo de ataque: das credenciais ao processo filho remoto

O cenário canônico de abuso começa com o atacante dumpando credenciais do Local Security Authority Subsystem Service (lsass.exe) na Máquina A — via Mimikatz, comsvcs.dll, ProcDump ou qualquer técnica equivalente. O que ele precisa é de um token utilizável: hash NTLM válido ou ticket Kerberos suficiente para autenticar como um usuário com direitos de remote launch ou remote activation nas ACLs DCOM da Máquina B.

Munido da credencial, o cliente DCOM abre conexão TCP para a porta 135 da Máquina B. O serviço RPCSS responde, autentica a requisição e consulta a Machine Launch Restriction para decidir se o usuário pode ativar a classe COM pedida. Se a checagem passa, RPCSS instrui o Service Control Manager a spawnar o processo correspondente — por exemplo wmiprvse.exe para WMI, mmc.exe para MMC, ou excel.exe para o objeto Excel.Application. Uma porta dinâmica de alto número é negociada, a conexão inicial em 135 é fechada, e a partir daí o atacante invoca métodos da classe via IRemUnknown.

O detalhe importante para o defensor é que nada malicioso é gravado em disco. O atacante simplesmente pede a um binário Windows assinado e confiável que execute um processo secundário através de um método já exposto pelo objeto — algo como ExecuteShellCommand. Quando o comando dispara, o aplicativo solicitado nasce como filho do svchost.exe (o launcher DCOM), e o comando do atacante executa a partir daí, herdando contexto e privilégios.

“Nenhum evento isolado prova movimentação lateral via DCOM — a detecção é comportamental. Você correlaciona vários eventos que, juntos, representam os passos do fluxo de ataque.” — Trecho do guia da core-jmp.org

Estratégia de detecção: correlacione, não alerte isoladamente

O guia organiza a detecção em camadas que reproduzem o fluxo de ataque. O primeiro filtro é o Event ID 4624 do Security log com Logon Type 3 (rede), que sozinho é barulhento, mas vira ouro quando cruzado com os indicadores subsequentes. O segundo é o Sysmon Event ID 3 (network connection) buscando svchost.exe abrindo conexão para a porta 135 (epmap) de outro host — em uma LAN típica de endpoints, esse padrão de workstation para workstation é raro e suspeito por si só.

O terceiro nível é a linhagem de processo. Sysmon Event ID 1 (process creation, com parent command line habilitado) revela o padrão tell-tale: um host DCOM — mmc.exe, excel.exe, mmc20, visio.exe — nascendo como filho de svchost.exe, frequentemente com a flag -Embedding no parent command line. O nível final é o spawn de cmd.exe ou powershell.exe a partir desses hosts DCOM, o que é o sinal mais alto da cadeia em quase todos os cenários reais.

Event IDs e fontes que toda regra precisa correlacionar

• Windows Security 4624 (Logon Type 3) no destino — autenticação de rede entrante, ponto de pivô inicial.
• Sysmon Event ID 3 — conexão TCP para porta 135 (epmap) entre hosts não-administrativos.
• Sysmon Event ID 1 com Parent Image = svchost.exe e Image = mmc.exe / excel.exe / wmiprvse.exe — processo DCOM hospedado.
• Sysmon Event ID 1 com Parent CommandLine contendo -Embedding — assinatura clássica do contexto DCOM.
• Sysmon Event ID 1 com Parent Image = mmc.exe/excel.exe e Image = cmd.exe / powershell.exe — pivot final para shell.
• Windows Security 4688 com auditoria de linha de comando habilitada — alternativa para ambientes sem Sysmon.

O autor original disponibilizou uma regra de correlação que amarra as etapas 1, 3 e 4 do fluxo no repositório zshanhyder01/Detection-Engineering, na pasta lateral movement/dynamic component object model dcom. Vale o esforço de adaptar para sua plataforma de SIEM (Splunk, Sentinel, Elastic, Wazuh) e testar contra logs sintéticos antes de soltar em produção.

Prevenção: feche a superfície e quebre o pré-requisito

A defesa contra abuso de DCOM combina três frentes: reduzir a superfície de ativação remota, quebrar a reutilização de credenciais e proteger o LSASS que serve como ponto de partida da cadeia. Em conjunto, essas medidas tornam o ataque caro o suficiente para empurrar o adversário a técnicas mais ruidosas e mais fáceis de pegar.

• Bloqueie tráfego workstation-to-workstation na porta TCP 135. Em uma LAN corporativa típica, endpoints não precisam abrir DCOM uns para os outros — apenas para servidores administrativos específicos. Use Windows Defender Firewall com perfil de domínio e regras explícitas de allowlist.
• Aperte as ACLs de ativação DCOM. Via dcomcnfg ou pelo registry da MachineLaunchRestriction, remova direitos de Remote Launch e Remote Activation de usuários não-administradores em todos os servidores e estações.
• Quebre a reutilização de senha local. Implante Windows LAPS para que cada máquina tenha senha de administrador local única, eliminando o pivot de uma única credencial roubada virar passe-livre na rede inteira.
• Proteja o LSASS. Habilite Credential Guard, LSA Protection (RunAsPPL) e as regras ASR do Microsoft Defender que bloqueiam credential dumping. Isso nega o pré-requisito da cadeia inteira.
• Cace a linhagem continuamente. Alerta para qualquer filho de host DCOM (mmc.exe, excel.exe, mmc20, visio etc.) que execute cmd.exe ou powershell.exe, especialmente com -Embedding no parent.
• Instrumente com Sysmon. Garanta coleta de Event ID 1 (com parent command line) e Event ID 3 (network connection), e mapeie as detecções para o MITRE ATT&CK T1021.003 (Distributed Component Object Model).
• Force least privilege e PowerShell logging. Constrained Language Mode, script block logging e transcription logging fecham as escapatórias residuais de quem chega ao shell.

Análise: por que esse walkthrough importa para SOCs brasileiros

Movimentação lateral via DCOM aparece com frequência crescente nos relatórios pós-incidente brasileiros, particularmente em ataques de ransomware operados por afiliados de famílias como LockBit, Black Basta, BlackCat e Akira. O motivo é ergonômico para o adversário: nenhuma ferramenta exótica precisa ser depositada na vítima, todo o tráfego pode ser confundido com administração legítima, e a técnica funciona em qualquer Windows de fábrica sem ajustes adicionais. Para o defensor, o problema espelhado é que poucas organizações no Brasil têm Sysmon plenamente instrumentado em endpoints, e ainda menos têm regras de correlação que amarram os Event IDs descritos acima em uma assinatura única.

O guia da core-jmp.org é especialmente valioso porque trata DCOM como conceito operacional — não como obscurantismo de Windows internals. Cada passo da cadeia de ataque tem um Event ID associado, cada Event ID tem um padrão de query, e o pacote inteiro mapeia diretamente para o T1021.003 do MITRE ATT&CK. Para uma equipe de blue team que ainda está construindo cobertura de detecção, é o tipo de material que vale ser usado como roteiro de pelo menos uma sprint de detection engineering: implantar coleta, escrever a regra, testar contra emulação (Atomic Red Team tem testes específicos para T1021.003), refinar limiar de falso positivo e operacionalizar com playbook de resposta.

O autor original, Zshan Hyder, mantém regras prontas no repositório citado, e a recomendação prática é não reinventar a roda: pegue a regra, adapte para o seu SIEM, e direcione esforço para o que realmente diferencia uma cobertura madura — a triagem dos alertas correlacionados e a integração com playbooks de contenção (isolamento via EDR, revogação de credenciais, force re-auth Kerberos).

Recomendações práticas para esta semana

• Audite as ACLs de DCOM nos seus servidores e estações: dcomcnfg → Component Services → My Computer → Properties → COM Security. Documente quem hoje tem Remote Launch e Remote Activation, e justifique cada exceção.
• Faça um inventário rápido de hosts em que a porta 135 está exposta em LAN corporativa, e desabilite onde não houver justificativa administrativa explícita.
• Se ainda não usa Sysmon, deploy hoje com a configuração SwiftOnSecurity (ou Olaf Hartong sysmon-modular) — comece pelos servidores e endpoints administrativos.
• Habilite LSA Protection (RunAsPPL) e Credential Guard nos seus controladores de domínio e servidores críticos, em janela de manutenção. Teste compatibilidade com produtos de EDR antes do rollout massivo.
• Implemente LAPS (ou Windows LAPS no Active Directory atualizado) para erradicar senhas de admin local compartilhadas.
• Crie uma regra de correlação simples no SIEM combinando 4624 LT3 + Sysmon EID 3 (porta 135 saindo de svchost.exe) + Sysmon EID 1 (mmc.exe ou wmiprvse.exe filho de svchost.exe). Calibre limiar e teste com Atomic Red Team T1021.003.
• Treine o time de SOC para reconhecer a assinatura -Embedding na linha de comando do parent — é o discriminador mais útil para separar DCOM legítimo de abuso.

Fonte: core-jmp.org — DCOM Explained: How Attackers Turn a Windows Feature into a Lateral Movement Tool (texto original de Zshan Hyder em Detect FYI, junho de 2026).