P³-Shellcode Loader - Process Parameter Poisoning

Autori: Max Hirschberger & Ogulcan Ugur

Contenuti

Introduzione
Iniezione tipica di processi e API di sistema coinvolte
Fondamenti tecnici degli internals di Windows richiesti
- 3.1 API di creazione dei processi e parametri di avvio
- 3.2 Il Process Environment Block (PEB)
Process Parameter Poisoning (P³)
Passare shellcode arbitrario in una stringa
- 5.1 Metodi helper di basso livello usati dal generatore di shellcode
- 5.2 Implementazione delle operazioni di alto livello
Vantaggi dell'elusione del rilevamento con questa tecnica
Approccio al rilevamento
Conclusione

*Elenco 5: Implementazione di CreateProcessWithPoison* Questa funzione implementa tre diverse scelte di parametri: 1. **Iniezione ShellInfo:** posiziona il veleno nel campo `lpReserved` del parametro `lpStartupInfo` che verrà copiato nella variabile `ShellInfo` nel PEB 2. **Iniezione nell'ambiente:** posiziona il veleno nel parametro `lpEnvironment` con il flag `CREATE_UNICODE_ENVIRONMENT` 3. **Iniezione nella riga di comando:** posiziona il veleno nel parametro `lpCommandLine` di `CreateProcessW` <img width="753" height="445" alt="image" src="https://assets.kitploit.com/production/public/readmes/42034/878e41931d49b82212556e099ba928cab890d427cd87498fb667f3e0965dbbe1.png" /> *Figura 3: Selezione del parametro da avvelenare* <img width="752" height="167" alt="image" src="https://assets.kitploit.com/production/public/readmes/42034/a128d8601b3edcfbf31ba3aa3c10fe995910fc932973a6d86e263f6edafb1bb8.png" /> *Figura 4: Selezione dell'eseguibile dell'applicazione di destinazione* ### 4.2 Individuazione dei dati iniettati nel nuovo processo Dopo la creazione riuscita del processo, i dati iniettati possono essere trovati tramite la struttura PEB. Per individuare il veleno nel nuovo processo sono necessari i seguenti tre passaggi. Per prima cosa, l'indirizzo iniziale della struttura PEB viene determinato chiamando `NtQueryInformationProcess`. `NtQueryInformationProcess` recupera la struttura dati `PROCESS_BASIC_INFORMATION` quando viene chiamato con la classe di informazioni `ProcessBasicInformation`. E `PROCESS_BASIC_INFORMATION` contiene l'indirizzo del PEB nel campo `PebBaseAddress`. Questo passaggio è mostrato nell'Elenco 6.```cpp WinApiResolver winapi = WinApiResolver::GetInstance(); PROCESS_BASIC_INFORMATION pbi = { 0 }; ULONG retLen; winapi.NtQueryInformationProcess( pi.hProcess, // Handle of the new process ProcessBasicInformation, // Query PROCESS_BASIC_INFORMATION &pbi, // Destination sizeof(pbi), // Size of the destination &retLen // Resulting size of what was read );

*Listato 9: Manipolazione del contesto del thread in ThreadSetExec* ### 4.4 Iniezioni di Payload Implementate La nostra implementazione di questa tecnica di iniezione include le seguenti quattro opzioni di payload mostrate nella Figura 5. 1. La prima opzione è una semplice demo che mostra una finestra popup ed è mostrata nella Figura 5. Questa opzione non richiede ulteriore shellcode o file eseguibili da iniettare. 2. La seconda opzione prende una rappresentazione esadecimale dello shellcode e lo inietta. Se lo shellcode contiene byte nulli, viene iniettato con il metodo descritto nella Sezione 5. 3. La terza opzione accetta un percorso di un file DLL che viene poi fornito a `LoadLibraryA` all'interno del target. 4. Infine, la quarta opzione carica shellcode grezzo da un URL HTTP(S) e gestisce anche la limitazione dei byte nulli. <img width="598" height="200" alt="image" src="https://assets.kitploit.com/production/public/readmes/42034/f98211120a8cba1628a3514f30befdc7e8ba315cec4148f071216ee5647b7c9b.png" /> *Figura 5: Scelta dello Shellcode Iniettato* <img width="841" height="556" alt="image" src="https://assets.kitploit.com/production/public/readmes/42034/3d662981ef5fe16b62eb12c934ba483f9cb75e87343e5ea330de69b2ed5f2985.png" /> *Figura 6: Finestra di messaggio creata dallo Shellcode* --- ## 5. Passare Shellcode Arbitrario in una Stringa Non è possibile passare dati arbitrari nei parametri. Questo perché verranno copiati solo i dati fino a un terminatore nullo. Per superare questa limitazione, abbiamo creato un generatore di shellcode che non emette terminatori nulli. Questo generatore di shellcode può creare shellcode per chiamare `MessageBoxA`, `LoadLibraryA`, `NtTerminateProcess` o `NtSuspendThread` con parametri arbitrari. Inoltre, può generare shellcode che decodifica uno shellcode di secondo stadio arbitrario e vi salta. È implementato nella classe C++ `ShellCodeWriter`, con metodi helper privati e metodi pubblici per la funzionalità esposta. I dettagli implementativi saranno spiegati di seguito. ### 5.1 Metodi Helper di Livello Inferiore Usati dal Generatore di Shellcode `Xor` viene usato come primitiva che consente allo shellcode di generare qualsiasi dato, inclusi i byte nulli. Questa primitiva è implementata nel metodo helper `SetRAXXOR` che accetta due valori a 64 bit. Emette shellcode che esegue un'operazione xor con i valori a 64 bit forniti e salva il risultato nel registro `RAX`. L'helper aggiuntivo `SetRAX` crea questi due valori a 64 bit che, quando vengono sottoposti a xor, producono un valore dato. Garantisce inoltre che questi due valori a 64 bit non contengano byte nulli. In sostanza, `SetRAX` emette shellcode che imposta il registro `RAX` a un valore arbitrario a 64 bit. Sia `SetRAXXOR` che `SetRAX` sono mostrati nel Listato 10. Inoltre, il codice macchina risultante da tre chiamate di esempio a `SetRAX` è mostrato nel Listato 11.```cpp void ShellCodeWriter::SetRAXXOR(uint64_t xor_a_value, uint64_t xor_b_value) { const char gadget[] = "\x48\xB8\xB0\xC5\x2F\x6D\xFB\x7F\x01\x01" // mov rax, XOR_A "\x49\xBF\x01\x01\x01\x01\x01\x01\x01\x01" // mov r15, XOR_B "\x4C\x31\xF8"; // xor rax, r15 uint64_t* xor_a = (uint64_t*)(gadget + 2); uint64_t* xor_b = (uint64_t*)(gadget + 12); *xor_a = xor_a_value; *xor_b = xor_b_value; AppendShellCode(gadget, 23); } void ShellCodeWriter::SetRAX(uint64_t value) { if (value == 0) { AppendShellCode("\x48\x31\xC0", 3); // xor rax, rax return; } uint64_t xor_a = 0, xor_b = 0x0101010101010101; // Adjust the xor key (xor_b) to ensure xor_a will have no zero bytes for (int i = 0; i < 8; i++) { if (((uint8_t*)(&value))[i] == 0x01) { ((uint8_t*)(&xor_b))[i] = 0x02; } } xor_a = value ^ xor_b; SetRAXXOR(xor_a, xor_b); }

*Listato 11: Esempi di codice emesso da SetRAX* `SetRAX` è la base per i metodi helper `PushValue`, `PushBuffer`, `SetArgRegister` e `SetArgRegisterStackRelative`. `PushValue` chiama `SetRAX` e lo segue con un'istruzione `push RAX` che quindi consente di inserire valori arbitrari nello stack. `PushBuffer` usa `PushValue` per scrivere un array arbitrario di byte sullo stack; a tale scopo suddivide i dati in valori a 64 bit e li inserisce in ordine inverso. L'ordine deve essere invertito, poiché il puntatore allo stack viene decrementato dopo ogni push. Il generatore di shellcode tiene traccia di quanti byte sono stati inseriti con la variabile `m_total_consumed_stack_bytes`. Questa variabile viene usata nel metodo helper `FreeStack` per pulire lo stack, riportando il puntatore allo stack al suo valore iniziale. Nell'interfaccia binaria delle applicazioni (ABI) Windows x86 a 64 bit, i registri `RCX`, `RDX`, `R8` e `R9` sono usati per i primi quattro argomenti quando si chiama una funzione. Gli argomenti aggiuntivi vengono inseriti nello stack, dopo uno shadow space di 32 byte. Lo shadow space è riservato alla funzione chiamata e viene usato per salvare i primi quattro registri degli argomenti. `SetArgRegister` e `SetArgRegisterStackRelative` sono usati per impostare uno di questi quattro registri degli argomenti. `SetArgRegister` imposta un dato registro su un valore costante arbitrario. E il codice generato da `SetArgRegisterStackRelative` scrive il puntatore allo stack più un offset costante nel corrispondente registro degli argomenti. Qualsiasi argomento aggiuntivo della funzione può essere inserito con il metodo helper `PushValue`. Il metodo helper `Call` genera codice che allinea il puntatore allo stack a 16 byte, quindi esegue una chiamata all'indirizzo indicato e infine annulla qualsiasi modifica di allineamento inizialmente effettuata. È richiesto un puntatore allo stack allineato a 16 byte per evitare crash nelle funzioni che utilizzano operazioni sui registri a virgola mobile XMM. Quando si chiamano funzioni con argomenti passati sullo stack, l'allineamento deve essere corretto prima di chiamare questo helper. Altrimenti, gli argomenti finiscono all'offset sbagliato nello stack. ### 5.2 Implementazione delle operazioni di livello superiore L'operazione più semplice è chiamare `NtTerminateProcess` o `NtSuspendThread`. Data la loro somiglianza, verrà trattato solo `NtTerminateProcess`, mostrato nel Listato 12. `NtTerminateProcess` accetta due parametri e segue la convenzione di chiamata x64. Per prima cosa, il metodo helper `SetArgRegister` viene chiamato per entrambi i parametri, per inizializzarli con i valori forniti. Quindi viene chiamata la funzione API. Poiché lo shellcode viene generato sulla stessa macchina, l'indirizzo della funzione viene risolto al momento della generazione e non all'interno dello shellcode. La risoluzione delle funzioni API è gestita dalla classe `WinApiResolver`. Infine, il metodo helper `Call` genera l'istruzione di chiamata e il codice di allineamento dello stack.```cpp void ShellCodeWriter::CallTerminateProcess (HANDLE ProcessHandle, NTSTATUS ExitStatus) { SetArgRegister(0, (uint64_t)ProcessHandle); SetArgRegister(1, ExitStatus); WinApiResolver winapi = WinApiResolver::GetInstance(); Call((uint64_t)winapi.NtTerminateProcess); }

Elenco 13: Implementazione di ShellCodeWriter::CallLoadLibraryA Infine, `LoadAndCallShellCode` accetta uno shellcode arbitrario che può includere byte zero e lo esegue. La sua implementazione è mostrata negli Elenchi 14 e 15 ed è suddivisa nelle seguenti cinque operazioni: 1. Lo shellcode arbitrario viene scritto nello stack tramite `PushBuffer`. Successivamente, lo shadow space viene allocato per proteggere lo shellcode dalla sovrascrittura. 2. Subito dopo, viene effettuata una semplice chiamata a `VirtualAlloc` che utilizza parametri già noti al momento della generazione. Questa chiamata API alloca memoria protetta in lettura/scrittura e in grado di contenere lo shellcode. 3. Successivamente, l'indirizzo di memoria restituito da `VirtualAlloc` viene salvato nei due registri `R12` e `R10`. Poi `R11` viene inizializzato con la dimensione dello shellcode e `RCX` viene impostato per puntare all'inizio dello shellcode. Con i registri `R10`, `R11` e `RCX` impostati, seguono sei istruzioni che eseguono una copia in memoria, copiando lo shellcode nella regione di memoria appena allocata. 4. Saltare allo shellcode non è ancora possibile, poiché la regione di memoria è protetta in lettura/scrittura. Sarebbe possibile allocare una regione in lettura/scrittura ed eseguibile, ma questo sarebbe probabilmente considerato più sospetto. Pertanto, viene effettuata una chiamata a `VirtualProtect` per cambiare la protezione in leggibile ed eseguibile, ma non scrivibile. 5. E infine, viene effettuato un salto allo shellcode, dopo aver verificato che lo stack sia correttamente allineato.```cpp void ShellCodeWriter::LoadAndCallShellCode(const std::vector<uint8_t>& shellcode) { // 1. Pushes the shellcode to the stack PushBuffer(shellcode.data(), shellcode.size()); int pos_sc = m_total_consumed_stack_bytes; // Shadow Space AppendShellCode("\x48\x83\xEC\x20", 4); // sub rsp, 32 m_total_consumed_stack_bytes += 32; // 2. Allocates READWRITE memory CallVirtualAlloc(NULL, shellcode.size(), MEM_COMMIT, PAGE_READWRITE); { // 3. Copies shellcode from the stack to the newly allocated area AppendShellCode("\x49\x89\xC4", 3); // mov r12, rax ; shellcode_dest AppendShellCode("\x49\x89\xC2", 3); // mov r10, rax ; shellcode_dest SetRAX(shellcode.size()); AppendShellCode("\x49\x89\xC3", 3); // mov r11, rax ; size SetArgRegisterStackRelative(0, (m_total_consumed_stack_bytes - pos_sc)); // r10: Shellcode dest ptr // r11: size // rcx: Shellcode src ptr const char* copy_sc = "\x8A\x01" // mov al, byte ptr ds:[rcx] "\x41\x88\x02" // mov byte ptr ds:[r10], al "\x48\xff\xc1" // inc rcx "\x49\xff\xc2" // inc r10 "\x49\xff\xcb" // dec r11 "\x75\xf0"; // jnz -16 AppendShellCode(copy_sc, 16); } // (...)

*Listato 15: Implementazione di ShellCodeWriter::LoadAndCallShellCode (Passaggi 4–5)* --- ## 6. Vantaggi dell'elusione del rilevamento con questa tecnica Un vantaggio importante di questa tecnica è che nessun processo viene creato in stato sospeso e nessun thread o processo viene sospeso durante la sua esecuzione. La creazione di processi sospesi o le chiamate ripetute a `SuspendThread` sono indicatori noti utilizzati dagli EDR per il process hollowing, l'iniezione di processi e attacchi simili. Inoltre, creando il processo di destinazione, un handle per il thread principale è già disponibile e dispone dell'accesso necessario per modificarne il contesto. | Aspetto | Iniezione Classica | Avvelenamento dei Parametri di Processo | |---|---|---| | Allocazione della memoria | `VirtualAllocEx` richiesto | Nessuna allocazione esplicita | | Scrittura della memoria | `WriteProcessMemory` richiesto | Indiretta tramite `CreateProcessW` | | Reindirizzamento dell'esecuzione | `CreateRemoteThread` o APC | `SetThreadContext` | | Probabilità di rilevamento | Alta (molte API sospette) | Ridotta (creazione di processi legittima) | | Telemetria EDR | Monitorata attentamente | Osservabilità ridotta | Complessivamente, questa tecnica desta molta meno sospetto, poiché lascia un'impronta più piccola utilizzando API legittime di creazione di processi e gestione dei thread. --- ## 7. Approccio al rilevamento Ci sono diversi indicatori sospetti generati da questa tecnica che possono essere usati per rilevarla. - `VirtualProtectEx` che rende eseguibile una regione di memoria seguito da `SetThreadContext` con almeno `CONTEXT_CONTROL`. Vale la pena notare che il puntatore alle istruzioni non deve necessariamente puntare a questa regione eseguibile, poiché può invece puntare a un gadget che poi la reindirizza. Tuttavia, è molto probabile che un puntatore all'interno della regione di memoria venga scritto in uno dei registri della CPU. - `VirtualProtectEx` che rende eseguibili le pagine dei parametri di processo, sia nel processo stesso sia in processi esterni. - Creazione di un processo in cui uno dei tre parametri abusati desta sospetti. Ad esempio, se l'entropia della riga di comando è vicina a quella del shellcode o lontana da quella di un normale valore di riga di comando. Inoltre, la lunghezza del parametro fornito è eccessiva o contiene molti caratteri insoliti. Tuttavia, affidarsi esclusivamente a questo è probabilmente soggetto a falsi positivi. - Lettura della struttura dei parametri di processo di un processo remoto a cui punta il PEB. --- ## 8. Conclusione In sintesi, gli attaccanti possono bypassare le moderne soluzioni di sicurezza grazie a nuove idee e piccole modifiche, sia sviluppando nuove tecniche sia riapplicando vecchie tecniche in modi nuovi. È quindi importante sviluppare continuamente nuove regole di rilevamento e non fare affidamento esclusivamente su una soluzione esistente. --- ## 9. Riferimenti [1] https://web.archive.org/web/20241211190548/https://modexp.wordpress.com/2020/07/31/wpi-cmdline-envar/

Più Popolari

p3-loader

1. Introduzione

2. Iniezione tipica di processi e API di sistema coinvolte

3. Fondamenti tecnici degli internals di Windows richiesti

3.1 API di creazione dei processi e parametri di avvio

3.2 Il Process Environment Block (PEB)

4. Avvelenamento dei parametri di processo (P³)

4.1 Avvio di un processo con un parametro avvelenato

4.3 Esecuzione del codice iniettato