Nell’articolo precedente abbiamo visto la parte di Ursnif comune a tutti i processi infettati.

Adesso l’esecuzione prende strade diverse a seconda del processo infettato.
Il diramamento avviene in ParserSetHooks ma nell’esposizione linearizzeremo la logica mostrando come Ursnif si sposti da powershell ad explorer.exe e da questi prosegue l’infezione.

YET ANOTHER URSNIF

Questo è il docicesimo di una serie di articoli, tutti raggruppati qui.

ParserSetHooks

Questa è la funzione che effettua azioni diverse a seconda del processo infettato.
Nella maggior parte dei casi installa degli hook (è il caso dei browser) ma per alcuni processi (cmd.exe, explorer.exe e powershell.exe) le azioni eseguite sono più specifiche.

Questa parte differisce maggiormente dai sorgenti, questi sono sempre indispensabili come riferimento ma d’ora in poi ci focalizziamo sul codice trovato in Ursnif.

Powershell.exe

Come abbiamo visto negli aritcoli precedenti, la DLL del client è avviata con PowerShell, più precisamente da MSHTA e poi powershell.
Quando Ursnif rileva di essere in questo processo, non fa altro che caricare il client giusto (32 o 64 bit) salvato nel registro (come abbiamo visto precedentemente) ed iniettarlo in explorer.exe.

Explorer.exe

Explorer.exe riveste un ruolo privilegiato nell’architettura di Ursnif.
E’ considerato un processo privilegiato e a lui sono demandate le seguenti operazioni:

• Disabilitare SPDY per Firefox e IE.
• E’ responsabile dell’esecuzione di comandi privilegiati inviati dagli altri processi infetti tramite un pipe.
• Implementa il keylogger.
• Implementa il proxy SOCKS.
• Infetta i browser.

Disabilitare SPDY

Ursnif, quando in explorer.exe, disabilita SPDY per IE e simili da registro di sistema. Installa inoltre degli hook per impedire di cambiare il valore da lui modificato.

Per FF, viene modificato il file di configurazione nel profilo dell’utente.

Infezione dei browser

Il prossimo passo consiste nell’infettare i browser: IE, EDGE, CHROME, OPERA, SAFARI e FIREFOX.

Vedremo adesso come si comporta Ursnif nei browser infettati.

Il server dei comandi

Ursnif è essenzialmente un piccolo RAT, esegue dei comandi ottenuti dalla configurazione (vedi articolo precedente) e dal C2.
I comandi sono eseguiti dai vari processi infetti ma alcuni di questi comandi possono richiedere permessi più elevati.

Ursnif quindi delega l’esecuzione di alcuni comandi al processo explorer.exe.
Per fare ciò è necessario che sia creato un thread apposito, il quale tramite un pipe (il cui nome è deterministico ma unico per infezione) riceve i comandi da eseguire e li mette in atto.

Questo thread è avviato dalla procedura PipeStartServer.

I comandi disponibili sono analizzati in seguito data la loro numerosità (sono circa 57).

Il server SOCKS

Come si evince dalla figura sopra, quando in explorer.exe, Ursnif esegue un server SOCKS (se configurato).

E’ facile capire che si tratta di un server SOCKS dai sorgenti ma anche da come sono gestiti i dati letti dal socket apposito.
SOCKS è infatti un protocollo molto semplice.

SOCKS richiede un eventuale identificativo utente, questo è generato aggiungendo “-01” al GUID che determina l’id della vittima (vedi i primi articoli di questa serie).

La possibilità di scegliere l’interfaccia, sottoforma di IP, sulla quale mettere in ascolto il proxy può dare la possibilità di usare la macchina come nodo intermedio in altri attacchi.

Il keylogger

Il keylogger utilizza, alla sua base, SetWIndowsHookEx ma questa funzione è chiamata solo se abilitata dalla configurazione (con il comando KEYLOG_ON) e tramite un meccanismo di notifica che gira intorno ad una finestra di 1×1 pixel.

Il keylogger è infatti usato nell’ambito di un’astrazione software più ampia: Ursnif crea una finestra 1×1 ed un thread che ne processa i messaggi.
Questo thread, dalla WindowProc, chiama i vari callback registrati.

Il keylogger è installato con nella chiamata a NSWindowStart.

Questa funzione crea la suddetta finestra 1×1 pixel e installa tre callback.

Il keylogger è in grado di catturare non solo il testo digitato ma anche la clipboard e quale dispositivo (come chiavi USB) viene collegato alla macchina.

I browser

Prima di vedere come continua l’esecuzione in explorer, vediamo cosa succede nei browser.
Infatti l’esecuzione di explorer si riuniformerà a quella dei browser (con varie eccezioni che non saranno dettagliate, sono comunque presenti nel DB IDA).

In tutti i browser sono installati degli hook per leggere i dati ricevuti e trasmessi (ad un livello adeguato per cui TLS non rappresenti un problema).

Viene mostrato, a titolo di esempio, cosa succede per FF.

Per i browser Opera e Safari, Ursnif non installa hook.
Evidentemente questi browser si sono evoluti e gli autori di Ursnif non sono riusciti a seguire i tempi.
Per questi due browser Ursnif termina il processo (iniettando una chiamata a TerminateProcess in ogni thread), rendendoli non usabili.

Dopo l’installazione degli hook, i browser controllano le chiavi Kill e Scr (sempre nella solita posizione nel registro di sistema) e le processano.

La prima, Kill, è creata in seguito all’apposito comando e contiene una lista di processi da terminare.

La seconda è creata in seguito al comando per la creazione di screenshot o di registrazioni dello schermo.
La chiave contiene un elenco di dati che non abbiamo approfondito ma potrebbe trattasti di nomi di file o parametri per l’esecuzione dello screenshot o della registrazione.

In entrambi i casi i comandi sono passati al server dai comandi in explorer. exe.

Notare che non sono presenti funzioni specifiche di un banking trojan, nel codice eseguito dai browser.
Il traffico dati è intercettato per essere inviato al C2 ma non sono presenti funzioni per il riconoscimento di particolari siti.

Ursnif permette comunque il caricamento di plugin, che potrebbero contenere tali funzionalità.

Esecuzione dei comandi

L’esecuzione si riuniforma in tutti i processi infettati, più o meno, dentro MainRequestThread.

Explorer.exe ha il compito di eseguire i comandi configurati nella DLL (o nel registro).

I comandi sono stringhe con il seguente formato:

GET_SYSINFO | LOAD_PLUGIN = 89.44.9.160/gr32.rar, 89.44.9.160/gr64.rar | GET_COOKIES

Ogni comando è separato dal carattere | e contiene un eventuale parametro separato dal carattere =.

Si nota inoltre che il nome del comando è prima trasformato in maiuscolo e poi ne viene effettuato il CRC32.
La funzione ClientProcessCommand userà infatti il CRC32 per determinare quale comando usare (come sempre, il valore è xorato con il cookie, come descritto negli articoli precedenti).

L’esecuzione dei comandi è quindi in ClientProcessCommand. È qui infatti che sono processati i comandi del C2 e della configurazione.
Tuttavia molte istruzioni sono trasmessi al server dei comandi in explorer.exe, questi sono processati in ServerProcessCommand ed utilizzano identificativi numerici.

cmd.exe

Nella procedura ParserSetHook si può notare che anche il processo cmd.exe è annoverato tra quelli infetti.
cmd.exe è lanciato da Ursnif facendogli eseguire il comando “pause” in modo da eseguire due tipi di azioni (a seconda dell’esatta command line usata):

• Eseguire una DLL. Questa viene caricata nel processo cmd.exe ed eseguita.
• Rubare le credenziali degli account di Thunderbird.

Nel prossimo articolo vedremo quali comandi supporta Ursnif e come viene contattato il C2.