SigFlip

Cos'è?

SigFlip è uno strumento per modificare file PE firmati con authenticode (exe, dll, sys ..etc) in modo che non influisca o rompa la firma authenticode esistente. In altre parole, è possibile modificare il checksum/hash del file PE incorporando dati (ad esempio shellcode) senza rompere la firma del file, i controlli di integrità o la funzionalità del file PE.

SigInject crittografa e inietta shellcode nella tabella dei certificati [WIN_CERTIFICATE] di un file PE; la chiave di crittografia viene stampata per l'uso con un loader BOF/C/C# di base (SigLoader). SigInject salva le modifiche in un file PE modificato e mantiene intatta la sua firma e la validità del certificato.

SigLoader è un loader di base che prende come parametri il percorso di un file PE modificato creato da SigInject e la chiave di decrittazione, quindi estrae e decritta lo shellcode incorporato per essere utilizzato con una tecnica di iniezione di shellcode a scelta.

SigFlip verifica se l'hash del PE è stato modificato con successo e, in caso di endpoint protetti contro questa comune configurazione errata, termina correttamente (vedere la sezione "Dettagli").

Nota rapida: SigFlip, SigInject e SigLoader sono disponibili come script BOF e assembly .NET; l'unica differenza è che la funzionalità di SigInject è implementata come parte di SigFlip (-i) nel caso si scelgano artefatti .NET invece di BOF.

Perché?

Può essere utilizzato principalmente per persistenza, movimento laterale o esecuzione di codice/comandi e può essere d'aiuto in:

• Bypass delle whitelist delle applicazioni, modifica dell'hash del file PE (es. msbuild.exe) senza rompere la firma.
• Bypass degli EDR che si basano sugli hash di specifici LOLBIN per il rilevamento dell'esecuzione di codice/comandi dannosi.
• Caricare driver firmati con un hash diverso; potrebbe aiutare a eludere eventuali EDR che monitorano driver vulnerabili firmati comuni utilizzando un elenco predefinito di hash.
• Incorporare shellcode crittografato in un file PE firmato e utilizzare uno stager (sigloader) a scelta per analizzare, decrittare, caricare ed eseguire lo shellcode.
• I vendor di sicurezza degli endpoint tendono a classificare i file PE firmati come benigni nella maggior parte dei casi; incorporare codice non firmato (shellcode ..etc.) in un file PE firmato rende leggermente più difficile il rilevamento/flagging.
• Bypassare i vendor di sicurezza degli endpoint che si basano principalmente sul WinVerifyTrust predefinito per la validazione della firma.
• Migliorare l'OPSEC e mettere alla prova i difensori che si affidano esclusivamente a utilità di verifica della firma tipiche come signtool, sigcheck, Get-AuthenticodeSignature ..etc. per validare la firma authenticode dei file PE.

Utilizzo ed Esempi:

Compilazione/Build:

I BOF precompilati non sono forniti in questo progetto; possono essere compilati usando Mingw-w64. Per .NET usare VS o csc.exe per compilare i progetti .NET (SigFlip, SigLoader). Per BOF seguire i passaggi seguenti;

• ➜ i686-w64-mingw32-gcc -c sigflip.c -o sigflip.x86.o
• ➜ x86_64-w64-mingw32-gcc -c sigflip.c -o sigflip.x64.o
• ➜ x86_64-w64-mingw32-gcc -c SigLoader/sigloader.c -o sigloader.x64.o
• ➜ i686-w64-mingw32-gcc -c SigLoader/sigloader.c -o sigloader.x86.o

Assicurarsi che tutti i file oggetto si trovino nella stessa directory di sigflip.cna, quindi caricare lo script sigflip.cna in Cobalt Strike.

Nota rapida: i BOF precompilati sono stati testati e sono compatibili con mingw-64 v8.0.0_3; l'uso di mingw-64 >= v9 potrebbe funzionare ma potrebbe causare il crash dei beacon attivi. Per maggiori dettagli, consultare https://github.com/med0x2e/SigFlip/issues/2 .

Cobalt Strike:

1. Execute-Assembly

   • execute-assembly SigFlip.exe -h
   • execute-assembly SigLoader -h

2. BOF

   • Per l'uso con Cobalt Strike, una volta caricato lo script SigFlip.cna, verranno registrati due nuovi comandi: SigFlip e SigInject, quindi utilizzare come di seguito;

     • SigFlip: Modifica l'hash di un file PE (DLL, EXE, SYS, OCX ..etc) senza rompere la firma o la validità del certificato:

       • SigFlip "<PE_FILE_PATH>" "<OUTPUT_PE_FILE_PATH (con estensione)>"

     • SigInject: Crittografa e inietta shellcode nella tabella dei certificati [WIN_CERTIFICATE] di un file PE; la chiave di crittografia viene stampata per l'uso con un loader C/C# di base, mantenendo intatta la firma e la validità del certificato:

       • SigInject "<PE_FILE_PATH> <OUTPUT_PE_FILE_PATH (con estensione)>" "<SHELLCODE_FILE>"

     • SigLoader: Carica lo shellcode crittografato dai file PE creati da SigInject, quindi utilizza Early Bird queueuserapc per generare/iniettare lo shellcode in un processo sacrificale; la logica di iniezione dello shellcode può essere personalizzata o sostituita con qualsiasi altra tecnica di iniezione del codice a scelta:

       • SigLoader <PE_FILE_PATH_WITH_SH> <DECRYPTION_KEY> <SPAWNTO_PROCESS_PATH> <PARENT_PROCESS_ID>

3. Esempi

   • BOF:

     • Iniettare dati casuali in msbuild.exe (aka bit flip msbuild.exe):

---

Dettagli:

Questa è una tecnica nota utilizzata da APT#10 in diverse campagne o set di intrusioni.

Firme digitali Authenticode?

Authenticode è una tecnologia di firma del codice di Microsoft che identifica l'editore del software firmato con Authenticode. Authenticode verifica anche che il software non sia stato manomesso dopo essere stato firmato e pubblicato.

Come funziona?

Microsoft si affida principalmente al formato di firma Authenticode per verificare l'integrità e l'origine dei binari PE. Secondo la specifica del formato Portable Executable di Authenticode, le firme Authenticode possono essere "incorporate" in un file PE Windows, in una posizione specificata dalla voce della Tabella dei Certificati nelle Directory Dati dell'Intestazione Opzionale. Quando Authenticode viene utilizzato per firmare un file PE Windows, l'algoritmo che calcola il valore hash Authenticode del file esclude alcuni campi PE. Quando la firma viene incorporata nel file, il processo di firma può modificare questi campi senza influenzare il valore hash del file. Questi campi sono: **il checksum, RVA della tabella dei certificati, dimensione della tabella dei certificati e la tabella dei certificati degli attributi. La tabella dei certificati degli attributi contiene una struttura PKCS #7 SignedData contenente il valore hash del file PE, una firma creata con la chiave privata dell'editore del software e i certificati X.509 v3 che legano la chiave di firma dell'editore del software a un'entità legale.

In parole povere, possiamo modificare o incorporare dati in campi esclusi dal calcolo dell'hash authenticode senza preoccuparci di rompere la firma authenticode e i controlli di integrità del file.

Maggiori dettagli su tali campi esclusi:

• RVA e dimensione della tabella dei certificati: la struttura dell'intestazione opzionale di un PE firmato contiene un array di directory dati, inclusa la voce della directory di sicurezza IMAGE_DIRECTORY_ENTRY_SECURITY che ha due campi: RVA e Dimensione.

  • RVA: un offset di file (non un offset di memoria) alla tabella dei certificati degli attributi.
  • Dimensione: dimensione della tabella dei certificati degli attributi.

• Tabella dei certificati degli attributi: una struttura dati WIN_CERTIFICATE che incapsula la firma e i certificati e ha i seguenti campi:

  • dwLength: dimensione della tabella dei certificati.
  • wRevision: la "revisione" di WIN_CERTIFICATE.
  • wCertificateType: il tipo di dati del certificato incapsulato.
  • bCertificate: i dati effettivi del certificato. Per WIN_CERT_TYPE_PKCS_SIGNED_DATA, si tratta della struttura PKCS#7 SignedData menzionata sopra (che contiene il valore hash del PE, la firma e il certificato x.509). È esattamente qui che SigFlip incorpora dati casuali o shellcode.

Con tutto ciò in mente, ora SifFlip esegue le seguenti operazioni:

1. Controlla la configurazione del sistema
2. Carica il file PE e verifica la firma del file PE, calcola l'hash Sha1
3. Ottiene l'offset "e_lfanew" (che punta all'HEADER DEL FILE PE -> IMAGE_NT_HEADERS)
4. Ottiene IMAGE_OPTIONAL_HEADER da IMAGE_NT_HEADERS
5. Ottiene IMAGE_DATA_DIRECTORY da IMAGE_OPTIONAL_HEADER
6. Ottiene il campo IMAGE_DIRECTORY_ENTRY_SECURITY e recupera RVA e DIMENSIONE della Tabella dei Certificati degli Attributi (WIN_CERTIFICATE).
7. Modifica il blob del file PE aggiungendo byte extra (casuali/shellcode) alla Tabella dei Certificati.
8. Aggiorna la directory dati IMAGE_DIRECTORY_ENTRY_SECURITY nell'intestazione opzionale -> Dimensione
9. Aggiorna dwLength di WIN_CERTIFICATE (Tabella dei Certificati)
10. Genera il nuovo checksum del PE e lo aggiorna. (Checksum dell'intestazione opzionale)
11. Salva il PE finale con la nuova dimensione.
12. Verifica la firma del file PE modificato

Il primo passaggio è essenziale per confermare se il sistema è configurato in modo errato tale da consentire il padding e l'iniezione di shellcode nei file PE firmati con authenticode; pertanto vengono eseguiti i seguenti controlli di integrità:

1. Verifica se la correzione MS13-098 non è installata (KB2893294). Tenere presente che POTREBBE ESSERE INSTALLATA MA LE CHIAVI DI REGISTRO NON SONO IMPOSTATE CORRETTAMENTE, RENDENDO LA PATCH INUTILE
2. Verifica le chiavi di registro

   1. X86:

      • Verifica se la chiave di registro "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" non è presente
        • -> se presente, verifica se il valore di registro "EnableCertPaddingCheck" non è presente

   2. X64:

      • Verifica se la chiave di registro "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" non è presente
        • -> se presente, verifica se il valore di registro "EnableCertPaddingCheck" non è presente.

Perché non è possibile leggere i dati iniettati quando il PE modificato viene caricato come modulo nel proprio spazio degli indirizzi o nello spazio degli indirizzi di altri processi?

Il loader di Windows non carica i dati del certificato nello spazio degli indirizzi del processo; ecco perché è necessario un loader personalizzato per estrarre dati come shellcode e utilizzarli (es: SigLoader). Questo spiega anche perché IMAGE_DIRECTORY_ENTRY_SECURITY ha un RVA che è un offset di file invece di un tipico offset di memoria.

Rilevamento/Prevenzione:

• https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720?redirectedfrom=MSDN
• Una volta installata la patch e impostate le chiavi di registro corrette, non è necessario riavviare il sistema; è sufficiente riavviare i Servizi crittografici. Il servizio Applocker verrà riavviato anch'esso poiché dipende dai servizi crittografici. (@p0w3rsh3ll)
• Regola Yara di Adrien; https://twitter.com/Int2e_/status/1330975808941330432

Riferimenti

• https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2013/ms13-098?redirectedfrom=MSDN
• https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720?redirectedfrom=MSDN
• http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/authenticode_pe.docx
• https://msrc-blog.microsoft.com/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode/
• https://www.specterops.io/assets/resources/SpecterOps_Subverting_Trust_in_Windows.pdf
• https://p0w3rsh3ll.wordpress.com/2014/05/24/testing-ms13-098-certificate-padding-check/
• http://jsac.jpcert.or.jp/archive/2021/pdf/JSAC2021_202_niwa-yanagishita_en.pdf