nirvanaon/own-defenderProjeto de pesquisa que faz engenharia reversa das interfaces COM do Windows Security Center para rastrear o registro de antivírus por meio de ATL, vtable, WSCAPI e RPC, com verificação em tempo de execução via WMI.
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.
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:
QueryInterface() resolve a interface?__int64 a1 para um método?Register() é realmente a função de registro de AV?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
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:
QueryInterface_ATL_INTMAP_ENTRYQueryInterfaceUma 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.
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
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
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
WSCAPI.dllA 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.
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
para observar de forma independente as informações do produto registrado.
O processo de verificação foi:
Engenharia reversa
↓
Reconstrução da interface
↓
Implementação própria
↓
Execução em tempo de execução
↓
Windows Security Center
↓
Observação via WMI
↓
Comparação de resultados
Isso me permitiu verificar que as conclusões da análise estática correspondiam ao comportamento observável do Windows.
Este projeto me ensinou consideravelmente mais do que como interagir com uma interface COM.
CoCreateInstanceQueryInterfaceWSCAPI.dllNdrClientCall3Acima de tudo, aprendi a evitar depender de uma única evidência.
Em vez disso:
Símbolo
↓
Descompilador
↓
Assembly
↓
GUID
↓
Mapa de Interfaces
↓
vtable
↓
Grafo de Chamadas
↓
RPC
↓
Verificação em Tempo de Execução
Cada camada aumenta a confiança na conclusão.
A implementação da pesquisa consiste em dois componentes principais.
OWN-Defender
│
├── OWN-Defender.cpp
│ ├── Interação COM com o WSC
│ ├── Descoberta de CLSID
│ ├── Inicialização COM
│ ├── Interação com IWscAVStatus4
│ ├── Registro
│ ├── Atualização de status
│ └── Limpeza
│
└── dllmain.cpp
├── Ponto de entrada da DLL
├── Carregador de pesquisa
├── Execução controlada
└── Tratamento de limpeza/parada
O repositório é intencionalmente pequeno para que a relação entre o comportamento reconstruído por engenharia reversa e a implementação permaneça fácil de seguir.
Este projeto foi construído em torno de perguntas, em vez de simplesmente reproduzir funcionalidade:
Como o WSC identifica a classe COM?
Como o IID é mapeado para a interface?
Como o QueryInterface localiza a interface?
Por que o IDA mostra assinaturas de função diferentes?
Onde está a vtable real?
Qual Register() é a implementação de AV?
O que acontece após o método COM?
Onde o WSCAPI.dll entra na cadeia de chamadas?
Onde o RPC começa?
Como o resultado pode ser verificado de forma independente?
Essas perguntas foram, em última análise, mais valiosas do que a própria implementação final.
O projeto também fornece um ponto de partida útil para estudar o limite de segurança entre:
Aplicação
↓
COM
↓
Windows Security Center
↓
Informações do Provedor de Segurança
Uma distinção importante é que registrar informações de produto de segurança não é automaticamente equivalente a desabilitar o mecanismo do Defender ou contornar seus mecanismos de proteção.
Portanto, este projeto deve ser visto principalmente como:
Pesquisa de engenharia reversa do Windows Security Center / COM
em vez de uma afirmação de que o registro no WSC por si só constitui uma vulnerabilidade do Defender.
Qualquer impacto de segurança exige investigação e validação separadas.
Esta pesquisa foi inspirada em parte pelo trabalho demonstrado no DefendNot por es3n1n.
Um agradecimento especial ao autor por fornecer um ponto de partida útil para entender o mecanismo do WSC.
Projeto original: https://github.com/es3n1n/defendnot
O propósito deste repositório não é reivindicar a pesquisa original como minha, mas documentar meu próprio processo de engenharia reversa, implementação independente e verificação do comportamento subjacente do Windows.
Este repositório é fornecido para:
Use este projeto apenas em sistemas que você possui ou para os quais está explicitamente autorizado a testar.
O autor não é responsável por uso indevido, danos, perda de dados, interferência em controles de segurança ou implantação não autorizada.
Este projeto está licenciado sob a GNU General Public License v3.0.
Consulte LICENSE para obter detalhes.
O objetivo principal do OWN-Defender não é simplesmente reproduzir uma técnica de registro de AV.
É demonstrar uma metodologia de engenharia reversa repetível:
Encontrar
↓
Mapear
↓
Reverter
↓
Reconstruir
↓
Rastrear
↓
Implementar
↓
Verificar
O que começou com uma pergunta sobre o Windows Security Center tornou-se uma exploração mais profunda de COM, ATL, mapeamento GUID/IID, vtables, código gerado pelo compilador, WSCAPI, RPC e arquitetura de segurança do Windows.
A implementação é o resultado. O processo de engenharia reversa é o verdadeiro projeto.