Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
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.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
FalconEye — Driver de kernel do Windows para detecção em tempo real de técnicas de injeção de processos, incluindo shellcode, DLL e injeção reflexiva, com hooking de syscall e detecção de anomalias. | Kitploit
Ferramentas/GitHubGitHub/rajiv2790/falconeye
Ferramentas DefensivasAnálise de MalwareAnálise de BináriosDetecção de Intrusão
GitHubrajiv2790/falconeye

FalconEye

Driver de kernel do Windows para detecção em tempo real de técnicas de injeção de processos, incluindo shellcode, DLL e injeção reflexiva, com hooking de syscall e detecção de anomalias.

Ver Repositório
3106754há 5 anosRevisado 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

FalconEye: Software de detecção em tempo real para injeções de processos no Windows

FalconEye é um software de detecção de endpoint do Windows para injeções de processos em tempo real. É um driver em modo kernel que visa capturar injeções de processos conforme elas acontecem (tempo real). Como o FalconEye é executado em modo kernel, ele fornece uma defesa mais forte e confiável contra técnicas de injeção de processo que tentam evadir vários hooks em modo de usuário.

Você pode conferir nossa apresentação no 2021 Blackhat ASIA Arsenal e slides.

Visão Geral do Projeto

Cobertura de Detecção

A tabela abaixo mostra o status de implementação e a lógica de detecção para as várias técnicas de injeção de processo. WPM significa WriteProcessMemory. Para testar a detecção, consulte a seção de referências.

TechniqueStatusDetectionPOC Used
Atombombing✓Hook do QueueUserAPC e procura pela família de funções GlobalGetAtomPinjectra
Instrumentation callback injection✓Detecta se uma nova thread é criada a partir de código flutuantehttps://github.com/antonioCoco/Mapping-Injection
Reflective DLL Injection✓Detecta se uma nova thread é criada a partir de código flutuante e se o cabeçalho PE está sendo escrito na vítimaMInjector
PROPagate✓Hook do SetProp para obter o endereço da propriedade que está sendo escrita e correlacionar com as chamadas WPM anteriores para obter o endereço do código flutuantePinjectra
Process Hollowing✓Detectado usando cabeçalho PE escrito na memória do processo alvoMInjector
CreateRemoteThread with LoadLibrary✓Nova thread com endereço inicial apontando para LoadLibrary. A versão do MInjector também escreve o caminho da DLL usando WPM, que também é detectadoMInjector, Pinjectra
CreateRemoteThread with MapViewOfFile✓Detecta se uma nova thread é criada a partir de código flutuantePinjectra
Suspend-Inject-Resume✓Detecta se uma nova thread é criada a partir de código flutuante(MInjector). Caminho da DLL sendo escrito via WPM (MInjector). Detecta se o contexto foi definido em uma thread previamente suspensa (Pinjectra)MInjector, Pinjectra
QueueUserAPC✓Caminho da DLL sendo escrito via WPMMInjector
QueueUserAPC com memset (Stackbombing)✓Hook do QueueUserAPC e procura por memsetPinjectra
SetWindowLong (Injeção de memória extra de janela)✓Hook do SetWindowLong para obter o endereço do ponteiro de função sendo escrito e correlacionar com as chamadas WPM anteriores para obter o endereço do código flutuantePinjectra
Unmap + Overwrite✓Alerta se o processo atacante está desmapeando ntdll da vítimaPinjectra
Kernel Ctrl Table✓Detecta se WPM está sobrescrevendo o campo KernelCallbackTable no PEB da vítimahttps://github.com/odzhan/injection/blob/master/kct
USERDATA✓Verifica se o endereço alvo do WPM está no intervalo do conhost.exe. Se sim, verifica se algum ponteiro de função relevante do conhost corresponde ao endereço WPM armazenado anteriormentehttps://github.com/odzhan/injection/blob/master/conhost
Ctrl-inject✓Detecta se o atacante faz WPM no intervalo KernelBase.dll da vítimaPinjectra
ALPC Callback✓Extrai o pid da vítima em chamadas NtConnectPort para a porta ALPC. Para o par atacante-vítima pid, verifica chamadas WPM anteriores e aplica detecção de código flutuantePinjectra
WNF Callback✓WPM seguido por chamada UpdateWNFStateDatahttps://github.com/odzhan/injection/tree/master/wnf
SetWindowsHook✓Salva caminhos de módulo registrados no hook NtUserSetWindowsHookEx. Posteriormente, quando um módulo correspondente a esse caminho carrega em um processo diferente, gera alertaMInjector
GhostWriting✓Detecta se o contexto é definido (NtSetContextThread é chamado) em uma thread previamente suspensaPinjectra
Service Control✓WPM sobrescrevendo o Service ID de um processo (serviço)https://github.com/odzhan/injection/tree/master/svcctrl
Shellcode injection✓Nova thread iniciada a partir de código flutuante. Caminho da DLL sendo escrito por WPMMInjector
Image Mapping✓Thread iniciada a partir de código flutuante. Cabeçalho PE sendo escrito por WPM. Caminho da DLL sendo escrito por WPMMInjector
Thread Reuse✓Thread iniciada a partir de código flutuante. Caminho da DLL sendo escrito por WPMMInjector

Visão Geral da Arquitetura

alt text

  1. O driver é um driver carregado sob demanda
  2. A inicialização inclui configurar callbacks e hooks de syscall via libinfinityhook
  3. Os callbacks mantêm um mapa de PIDs construído a partir de atividade entre processos, como OpenProcess, mas não se limita a OpenProcess
  4. Os callbacks subsequentes e hooks de syscall usam este mapa de PID para reduzir o ruído no processamento. Como parte da redução de ruído, os hooks de syscall filtram a atividade do mesmo processo.
  5. A lógica de detecção é dividida em subcategorias: stateless (exemplo: Atombombing), stateful (Unmap+Overwrite) e código flutuante (shellcode de múltiplas técnicas)
  6. Para detecções stateful, os hooks de syscall registram um ActionHistory que é implementado como um buffer circular. Por exemplo, registra todas as chamadas NtWriteVirtualMemory onde o processo chamador é diferente do processo alvo.
  7. A lógica de detecção possui funcionalidade comum de detecção de anomalias, como detecção de código flutuante e detecção de acionadores de shellcode em processos remotos. Tanto os callbacks quanto os hooks de syscall invocam essa funcionalidade comum para a detecção real.

NOTA: Nosso foco tem sido a detecção e não a criação de um mecanismo de detecção com desempenho. Continuaremos esses esforços após a apresentação no BlackHat.

Arquivos

.
├── src 
│   ├── FalconEye ---------------------------# FalconEye user and kernel space
│   └── libinfinityhook ---------------------# Kernel hook implementation
├── 2021BHASIA_FalconEye.pdf
└── README.md

Primeiros Passos

Pré-requisitos

  1. Windows 10 Build 1903/1909
  2. Microsoft Visual Studio 2019 em diante
  3. Software de virtualização como VmWare, Hyper-V (Opcional)

Instalação

Compilação

  1. Abra a solução com o Visual Studio 2019
  2. Selecione x64 como plataforma de compilação
  3. Compile a solução. Isso deve gerar o binário FalconEye.sys em src\kernel\FalconEye\x64\Debug ou src\kernel\FalconEye\x64\Release
Baixar ferramenta