Resumo técnico e descoberta
O pesquisador identificou o objeto COM COpenControlPanel (CLSID {06622D85-6856-4460-8DE1-A81921B41C4B}), exposto por shell32.dll, que implementa a interface IOpenControlPanel (IID {D11AD862-66DE-4DF4-BF6C-1F5621996AF1}). Essa interface oferece a função Open(), capaz de forçar a carga de DLLs registradas nos locais do registro usados pelo Painel de Controle — mesmo quando o nome do item passado é arbitrário.
Vetor de abuso e fluxo de ataque
O fluxo descrito pela pesquisa segue três etapas rastreáveis nas evidências experimentais:
- Carregar um binário (DLL) malicioso no host alvo;
- Registrar essa DLL nas chaves do registro destinadas a Control Panel applets (por exemplo, HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls ou as equivalentes em HKLM);
- Invocar remotamente o método Open() do COpenControlPanel via DCOM, forçando o COM Surrogate (dllhost.exe) a carregar a DLL registrada e executar seu DllEntryPoint.
O pesquisador comprovou o comportamento criando uma DLL que exibia uma caixa de mensagem, registrando-a em HKCU e chamando Open() por um cliente COM: o dllhost.exe passou a hospedar a DLL e o objeto COpenControlPanel simultaneamente.
Implicações para movimento lateral e persistência
Além de permitir execução remota sobre DCOM, a técnica cria um mecanismo de persistência que será acionado sempre que o Painel de Controle for aberto localmente. Em ambiente remoto, a técnica não depende de interação humana: uma chamada DCOM que invoque Open() já faz com que as DLLs registradas sejam carregadas.
O autor também observou que a DLL não precisa ter extensão .cpl nem exportar CPlApplet — qualquer DLL com ponto de entrada válido registrada nos locais corretos é carregada.
Evasões, limitações e ambiente alvo
Algumas variações de Windows removem nomes de interfaces do registro (por exemplo, versões mais recentes como Windows Server 2025 e Windows 11), o que dificulta a identificação direta via ferramentas como OleViewDotNet. Ainda assim, o comportamento do objeto COpenControlPanel e seu AppID fazem com que ele siga as políticas DCOM padrão do sistema; o autor notou que, quando as permissões de Launch/Access estão vazias, o padrão do sistema (normalmente: Administradores podem ativar/acessar) se aplica.
Detecção e recomendações práticas
A pesquisa lista recomendações práticas de detecção que administradores devem implementar imediatamente:
- Monitorar criações e alterações nas chaves de registro usadas para Control Panel applets: HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls, HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls e HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Control Panel\Cpls.
- Observar processos dllhost.exe que carreguem DLLs incomuns ou com «bitness» inesperado (por exemplo, dllhost.exe *32 em hosts x64), pois isso pode indicar carga de um binário 32 bits em ambiente 64 bits.
- Monitorar uso do Remote Registry, frequentemente abusado para registrar componentes remotamente em ataques desse tipo.
- Auditar objetos DCOM com AppID sem permissões explícitas de Launch/Access e revisar política DCOM para limitar quais contas podem ativar objetos remotamente.
Contexto e observações finais
O trabalho ilustra que a superfície DCOM continua a oferecer vetores úteis para movimento lateral, especialmente quando combinada com caminhos de persistência menos monitorados — como os registros de applets de Painel de Controle. O autor disponibilizou um trigger em Python como prova de conceito (repositório citado na pesquisa original) e descreve abordagens de enumeração (PowerShell, C++ e OleViewDotNet) usadas para identificar objetos e interfaces.
Faltam, porém, indicadores públicos de exploração ampla dessa técnica em campanhas reais no momento da publicação; o relatório foca em demonstração técnica e orientações de detecção. Organizações expostas a ambientes Windows tradicionais devem incluir as verificações acima em seus playbooks de detecção e resposta.