Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CallStackSpoofer — Uma implementação de PoC para efetuar spoofing de pilhas de chamadas arbitrárias ao fazer sys calls (ex.: obter um handle via NtOpenProcess) | Kitploit
Ferramentas/GitHubGitHub/withsecurelabs/callstackspoofer
Evasão de IDS/IPSPós-ExploraçãoRed TeamingAtaque Adversário
GitHubwithsecurelabs/callstackspoofer

CallStackSpoofer

Uma implementação de PoC para efetuar spoofing de pilhas de chamadas arbitrárias ao fazer sys calls (ex.: obter um handle via NtOpenProcess)

Ver Repositório
589744há 1 anoRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

CallStackSpoofer

Este repositório demonstra uma implementação de PoC para falsificar pilhas de chamadas arbitrárias ao fazer chamadas de sistema. Para uma explicação técnica completa, consulte o post do blog aqui: https://labs.withsecure.com/blog/spoofing-call-stacks-to-confuse-edrs.

Por padrão, ele contém três pilhas de chamadas de exemplo para imitar, que podem ser selecionadas informando --wmi, --rpc ou --svchost, conforme demonstrado abaixo:

readmeexample

Essas pilhas de chamadas foram obtidas executando o SysMon com eventos de acesso a processos habilitados e procurando eventos em que o lsass era o alvo da operação de handle.

Nota: a título de cautela, este PoC foi testado na seguinte compilação do Windows:

  • 10.0.19044.1706 (21h2)

Ele não foi testado em outras versões e os offsets podem obviamente variar (e, portanto, quebrar) em compilações diferentes do Windows.

Se estiver com problemas, uma técnica para depurar erros é encontrar o processo que gera eventos OpenProcess no SysMon e anexar a ele no WinDbg. Depois de anexado, execute bp ntdll!NtOpenProcess e, quando o bp for atingido, execute knf.

Isto exibirá uma saída semelhante à abaixo, que conterá resolução completa de símbolos e o espaço correto de utilização da pilha (indicado pela coluna 'Memory'):

root@kitploit:~
0:003> knf
 #   Memory  Child-SP          RetAddr               Call Site
00           00000037`f01fe300 00007ffd`221d2ea6     ntdll!NtOpenProcess+0x12
01         8 00000037`f01fe308 00007ffd`1ffee959     KERNELBASE!ProcessIdToSessionId+0x96
02        80 00000037`f01fe388 00007ffd`23b99633     lsm!RpcOpenEnum+0x129
03       430 00000037`f01fe7b8 00007ffd`23b33711     RPCRT4!Invoke+0x73
04        40 00000037`f01fe7f8 00007ffd`23bfd77b     RPCRT4!Ndr64UnmarshallHandle+0xe1
05        70 00000037`f01fe868 00007ffd`23b7d2ac     RPCRT4!Ndr64StubWorker+0xb0b
06       6c0 00000037`f01fef28 00007ffd`23b7a408     RPCRT4!NdrServerCallAll+0x3c
07        50 00000037`f01fef78 00007ffd`23b5a266     RPCRT4!DispatchToStubInCNoAvrf+0x18
08        50 00000037`f01fefc8 00007ffd`23b59bb8     RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x1a6
09        e0 00000037`f01ff0a8 00007ffd`23b68a0f     RPCRT4!RPC_INTERFACE::DispatchToStub+0xf8
0a        70 00000037`f01ff118 00007ffd`23b67e18     RPCRT4!LRPC_SCALL::DispatchRequest+0x31f
0b        d0 00000037`f01ff1e8 00007ffd`23b67401     RPCRT4!LRPC_SCALL::HandleRequest+0x7f8
0c       110 00000037`f01ff2f8 00007ffd`23b66e6e     RPCRT4!LRPC_ADDRESS::HandleRequest+0x341
0d        a0 00000037`f01ff398 00007ffd`23b6b542     RPCRT4!LRPC_ADDRESS::ProcessIO+0x89e
0e       140 00000037`f01ff4d8 00007ffd`24ab0330     RPCRT4!LrpcIoComplete+0xc2
0f        a0 00000037`f01ff578 00007ffd`24ae2f26     ntdll!TppAlpcpExecuteCallback+0x260
10        80 00000037`f01ff5f8 00007ffd`23387034     ntdll!TppWorkerThread+0x456
11       300 00000037`f01ff8f8 00007ffd`24ae2651     KERNEL32!BaseThreadInitThunk+0x14
12        30 00000037`f01ff928 00000000`00000000     ntdll!RtlUserThreadStart+0x21

Como observação, o espaço total da pilha usado pelo local de chamada atual é indicado na linha abaixo (por exemplo, ntdll!NtOpenProcess ocupa apenas 8 bytes). Como dito anteriormente, uma explicação técnica completa é abordada no blog vinculado no início deste readme, que explicará isso (e conceitos como Child-SP) em mais detalhes. Os valores gerados pelo windbg podem então ser usados para correlacionar com o que está sendo retornado por CalculateFunctionStackSize() em caso de problemas.

Trabalhos Relacionados

Agradecimentos ao projeto unicorn_pe (https://github.com/hzqst/unicorn_pe) pelo código de exemplo no parsing de UNWIND_CODEs.

Baixar ferramenta