OWN-Defender — Pesquisa sobre o COM do Windows Security Center

OWN-Defender é um projeto de pesquisa de segurança do Windows focado em entender como o Windows Security Center (WSC) representa e gerencia produtos de segurança antivírus por meio de suas interfaces COM.

O projeto começou como uma investigação sobre o comportamento demonstrado pelo DefendNot, mas em vez de tratar a implementação existente como uma caixa-preta, usei-a como ponto de partida para engenharia reversa independente e verificação.

O objetivo deste projeto é entender o caminho completo de execução:

COM
 ↓
CLSID / IID
 ↓
CoCreateInstance
 ↓
QueryInterface
 ↓
ATL Interface Map
 ↓
vtable
 ↓
IWscAVStatus4
 ↓
CWscIsv
 ↓
WSCAPI.dll
 ↓
RPC
 ↓
Windows Security Center

O projeto foi desenvolvido e testado em um ambiente de pesquisa controlado do Windows.

Somente para Pesquisa / Uso Educacional

Este projeto destina-se à pesquisa de internals do Windows, engenharia reversa, educação em segurança e testes de segurança autorizados. Não o utilize para interferir em softwares de segurança em sistemas que você não possui ou para os quais não tem permissão explícita de teste.

---

Motivação da Pesquisa

A pergunta inicial era simples:

Como o Windows Security Center sabe que um produto antivírus existe?

Em vez de parar na documentação pública da API, quis entender o que acontece por baixo da API.

Isso levou a várias perguntas:

• Qual classe COM implementa a funcionalidade do WSC?
• Qual IID corresponde à interface de antivírus?
• Como o QueryInterface() resolve a interface?
• Onde a interface está armazenada no mapa de interfaces ATL?
• Por que o IDA às vezes mostra apenas __int64 a1 para um método?
• Por que a interface C++ reconstruída contém parâmetros adicionais?
• Qual função Register() é realmente a função de registro de AV?
• Como o registro chega ao Windows Security Center?
• Onde aparece o limite do RPC?
• Como o resultado pode ser verificado de forma independente?

---

Jornada de Engenharia Reversa

1. Identificando a Classe COM

O primeiro passo foi identificar a classe COM do Windows Security Center.

O projeto usa a classe COM do WSC:

CLSID_WscIsv
F2102C37-90C3-450C-B3F6-92BE1693BDF2

A implementação também contém lógica para localizar o CLSID dinamicamente no registro do Windows, em vez de depender exclusivamente de um valor fixo.

Conceitualmente:

HKLM
 └── SOFTWARE
     └── Classes
         └── CLSID
             └── {CLSID}
                 └── Windows Security Center ISV API

Isso forneceu a primeira relação importante:

Registro
   ↓
CLSID
   ↓
Windows Security Center ISV API

---

2. Identificando a Interface Correta

O próximo desafio foi determinar qual interface COM deveria ser solicitada.

O projeto usa:

IWscAVStatus4

com:

4DCBAFAC-29BA-46B1-80FC-B8BDE3C0AE4D

Uma das lições importantes da pesquisa foi:

Somente o nome de um GUID não é evidência suficiente.

Verifiquei a relação por meio de engenharia reversa, em vez de assumir que o nome da interface e o GUID estavam corretos.

A investigação incluiu:

• Referências de GUID
• QueryInterface
• Mapas de interfaces ATL
• _ATL_INTMAP_ENTRY
• Localizações de vtable
• Referências cruzadas
• Implementações de funções
• Comportamento em tempo de execução

---

3. Entendendo o QueryInterface

Uma das etapas de reversão mais úteis foi seguir a implementação de:

CComAggObject<CWscIsv>::QueryInterface()

que eventualmente chega a:

ATL::CComObjectRootBase::InternalQueryInterface()

O mapa de interfaces ATL é usado para comparar o IID solicitado com as entradas de interface registradas.

Conceitualmente:

IID solicitado
     ↓
QueryInterface()
     ↓
InternalQueryInterface()
     ↓
ATL Interface Map
     ↓
Comparação de GUID
     ↓
Interface correspondente
     ↓
Ponteiro de interface

Isso forneceu evidência independente de que o GUID investigado realmente correspondia à interface COM esperada.

---

4. A Confusão do Register()

Um dos maiores desafios da reversão foi entender por que o IDA/Ghidra nem sempre exibia a assinatura de método que eu esperava.

A interface reconstruída contém:

virtual HRESULT __stdcall Register(
    BSTR path,
    BSTR name,
    unsigned int,
    unsigned int
) = 0;

No entanto, o descompilador poderia mostrar uma implementação como:

_IWscAVStatus4<CWscIsv>::Register(__int64 a1)

À primeira vista, isso parecia inconsistente.

Uma investigação mais aprofundada mostrou que a representação do descompilador descrevia um wrapper/thunk e a chamada indireta subjacente à vtable, em vez de apresentar a assinatura lógica completa da interface.

Isso se tornou uma lição importante:

A saída do descompilador é uma interpretação do código de máquina, não a verdade original no nível do código-fonte.

Para resolver essas discrepâncias, comparei:

Definição da interface COM
        ↓
Layout da vtable
        ↓
Assembly
        ↓
Wrapper/thunk
        ↓
Convenção de chamada
        ↓
Função alvo real

---

5. Múltiplas Funções Register()

Outra fonte de confusão foi a presença de múltiplas funções com nomes como:

IWscAVStatus2::Register
IWscAVStatus4::Register
IWscFWStatus2::Register
RegisterAV

A percepção importante foi que nomes semelhantes não significam interfaces idênticas.

Por exemplo:

AV
 ↓
IWscAVStatus4
 ↓
Registro de AV

enquanto:

Firewall
 ↓
IWscFWStatus2
 ↓
Registro de firewall

O número da interface e a implementação ao redor tiveram que ser verificados, em vez de selecionar uma função simplesmente porque seu nome continha Register.

Esta foi uma das partes mais úteis da pesquisa, pois me forçou a correlacionar:

Interface
+
IID
+
vtable
+
implementação
+
layout de parâmetros
+
alvo da chamada

---

6. Rastreando o Caminho de Registro

Após identificar a interface correta, rastreei a operação de registro mais profundamente no binário.

O caminho observado foi aproximadamente:

IWscAVStatus4::Register()
        ↓
CWscIsv
        ↓
RegisterSecurityProductFunction
        ↓
wscRegisterSecurityProduct()
        ↓
WSCAPI.dll
        ↓
s_wscRegisterSecurityProduct()
        ↓
NdrClientCall3()
        ↓
RPC
        ↓
Windows Security Center

Isso foi particularmente importante porque o método COM em si não era a operação final.

A chamada eventualmente cruzava um limite de RPC.

Isso mudou a forma como eu via a arquitetura:

COM
  ≠
implementação final

Em vez disso:

COM
 ↓
implementação local
 ↓
API do WSC
 ↓
cliente RPC
 ↓
componente do Windows

---

7. Entendendo o WSCAPI.dll

A próxima camada era o WSCAPI.dll.

O caminho reconstruído por engenharia reversa chegava a:

wscRegisterSecurityProduct()

que eventualmente invocava:

s_wscRegisterSecurityProduct()

e depois:

NdrClientCall3()

Este foi o ponto em que a investigação passou de uma chamada COM normal para a infraestrutura RPC do Windows.

Entender essa camada ajudou a explicar por que o comportamento não podia ser totalmente compreendido olhando apenas para a DLL COM original.

---

8. Verificação em Tempo de Execução

A análise estática foi apenas uma parte da pesquisa.

Após reconstruir a interface e o caminho de chamada relevantes, criei minha própria implementação controlada e comparei o comportamento resultante com o Windows Security Center.

Usei informações do Windows Security Center / WMI, como:

ROOT\SecurityCenter2
    AntiVirusProduct