PoC, IOCs e lógica de detecção para a cadeia de desserialização BinaryFormatter do WS-Federation do SharePoint /_trust. Reconstrução em laboratório cobrindo RCE não autenticado, roubo de chave de máquina em processo e os artefatos que cada variante deixa para trás. SharePoint 2016, 2019 e Subscription Edition. CVE-2026-50522, CVE-2026-45659, CVE-2026-56164, CVE-2026-58644.
/_trust do SharePoint: PoC e notas de detecçãoArtigo ao vivo (GitHub Pages): https://sp-poc.wismansec.com/ (renderização HTML deste documento).
Afetados: SharePoint Server 2016, 2019 e Subscription Edition.
Reconstrução de uma intrusão em um SharePoint Server (Subscription Edition) em laboratório isolado, criada para (a) entender a capacidade total do invasor, (b) determinar o que um defensor deve procurar, incluindo persistência furtiva, e (c) compartilhar um PoC para auxiliar outros investigadores.
Somente pesquisa autorizada. Tudo aqui foi executado em hardware e contas de laboratório isolados e de propriedade pessoal, contra um build deliberadamente deixado sem patch para o teste. O problema subjacente é corrigido pelo fornecedor; aplique as atualizações atuais. Não execute isso contra sistemas que você não possui nem tem autorização explícita para testar. Valores de machine keys, hostnames/IPs internos e domínios de callback estão redigidos no texto e nos artefatos de exemplo. As capturas de tela do SIEM não foram modificadas e contêm os nomes reais do laboratório; veja a nota na §4.
/_trust SecurityContextTokenPOST /_trust/default.aspx não autenticado (sign-in WS-Federation) carregando um SecurityContextToken malicioso dispara a desserialização BinaryFormatter no worker do SharePoint (w3wp.exe), resultando em execução remota de código como a identidade do pool do aplicativo web./_trust a detecta e bloqueia; veja §5). Essas chaves permitem que um invasor forje tokens __VIEWSTATE/de autenticação que sobrevivem ao patch./_trust, que é o único artefato presente em todas as variantes.O SharePoint expõe um endpoint de sign-in passivo WS-Federation em /_trust/default.aspx. Uma resposta de sign-in manipulada (wa=wsignin1.0 + wresult=<RequestSecurityTokenResponse>) incorpora um SecurityContextToken cujo elemento <Cookie> é um fluxo BinaryFormatter compactado em DEFLATE e codificado em base64. No servidor, esse cookie é descompactado e desserializado sem restrição de tipo, de modo que uma cadeia de gadgets (via ysoserial.net) executa código controlado pelo invasor dentro do w3wp.exe.
Esqueleto da requisição (não autenticada):
POST /_trust/default.aspx HTTP/1.1
Content-Type: application/x-www-form-urlencoded
wa=wsignin1.0&wctx=<url>&wresult=<RequestSecurityTokenResponse>...
<SecurityContextToken><Cookie>BASE64(DEFLATE(BinaryFormatter payload))</Cookie>...
| Cadeia | Gadget | Efeito | Canal de saída |
|---|---|---|---|
| RCE OOB | TypeConfuseDelegate → PowerShell -EncodedCommand | execução de código como identidade do pool | out-of-band (beacon HTTP/DNS) |
| Divulgação de machine keys | ActivitySurrogateDisableTypeCheck → ActivitySurrogateSelectorFromFile (compila KeyDump.cs in-process) | extrai ValidationKey/DecryptionKey | inline na resposta HTTP |
Scripts (saneados) em scripts/: um RCE OOB parametrizado e o key-dump em dois estágios. A entrega do payload usa PowerShell -EncodedCommand para que payloads com múltiplas instruções atravessem intactos as camadas cmd.exe/transporte (sem quebra de aspas por ;/&&).
Farm único de SharePoint SE (build fixado antes da correção), identidade do app pool LAB\sp_pool, PowerShell 5.1, Microsoft Defender ativado com proteção de nuvem. A telemetria (Windows Event Log, logs do SharePoint, Defender for Endpoint) era enviada para nano, um SIEM open-source leve; o host do invasor executava ysoserial.net; um cliente interactsh fornecia o listener OOB. Endereços e domínios estão redigidos no texto; veja a nota das capturas de tela na §4.
Cada linha é uma detonação real; artefatos coletados do SIEM + listener OOB por execução.
As capturas de tela não foram modificadas. Elas contêm os nomes reais de host e NetBIOS do laboratório, que são crus e diferem do
SHAREPOINT01/LABsaneados usados ao longo do texto. Mesmas execuções, mesmos eventos, nada encenado. Equivalentes seguros para o trabalho emartifacts/.
| Invocação | Árvore de processos (como LAB\sp_pool, Alta) | Defender | Beacon OOB | Artefatos principais |
|---|---|---|---|---|
| RCE OOB, padrão | w3wp.exe → cmd.exe → powershell.exe → conhost.exe | Behavior:Win32/WebshellLauncher.A (EID 1116 detect / 1117 Remove) | chegou (corrida) | árvore 4688; Defender 1116/1117; POST /_trust |
RCE OOB, -RawCmd | w3wp.exe → powershell.exe → conhost.exe (sem cmd) | nenhum | chegou (DNS+HTTP) | árvore 4688; POST /_trust; beacon |
RCE OOB, -DropFile | w3wp.exe → powershell.exe | nenhum | chegou | gravação de arquivo em …\TEMPLATE\LAYOUTS\ (não está no log auditado de acesso a objetos) |
RCE OOB, -Diag | w3wp.exe → powershell.exe → whoami.exe | nenhum | chegou | exfiltração de divulgação do ambiente: {host, whoami, PSver, LanguageMode} |
| Key-dump | (nenhum, in-process) | nenhum | (nenhum) | apenas o POST /_trust + resposta anômala carregando as chaves |
Esses resultados são para a configuração AMSI padrão (modo Balanced, /_trust não varrido). Com a varredura AMSI do corpo da requisição de /_trust habilitada (modo Full ou direcionado), cada linha é, em vez disso, bloqueada na camada de requisição: HTTP 400, Exploit:Script/SpCookieExec.A, antes da execução (veja §5).

Todas as quatro detonações documentadas, das 15:01 às 15:18 UTC, com todos os filhos de w3wp.exe executando como identidade do pool. Três das quatro são powershell.exe gerados diretamente. Somente a execução das 15:03:34 passa por cmd.exe, e somente essa execução foi detectada. Ao ampliar a janela para além desta, iterações de desenvolvimento anteriores da mesma manhã entram no conjunto de resultados; portanto, a afirmação se limita a essas quatro execuções.

Invocação padrão: w3wp.exe → cmd.exe → powershell.exe, com conhost.exe ao lado. É nessa forma que o Behavior:Win32/WebshellLauncher.A se baseia.

Invocação -RawCmd, mesma primitiva e mesmo payload, com o salto cmd.exe removido. O Defender não produziu nada para esta execução. Uma detecção construída sobre w3wp → cmd não a detecta de forma alguma.