
Uma implementação de PoC para efetuar spoofing de pilhas de chamadas arbitrárias ao fazer sys calls (ex.: obter um handle via NtOpenProcess)
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:

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:
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'):
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.
Agradecimentos ao projeto unicorn_pe (https://github.com/hzqst/unicorn_pe) pelo código de exemplo no parsing de UNWIND_CODEs.