IMPORTANTE

IoC 08/10/2021

CERT-AgID semplifica l’accesso ai propri Indicatori di Compromissione (IoC)

Fino ad oggi per accedere agli indicatori delle campagne malevole gestiti e censiti quotidianamente dal CERT-AGID era necessario disporre di tre requisiti: Essere una Pubblica Amministrazione; Accreditarsi presso il CERT-AGID; Dotarsi di una opportuna instanza MISP o del client di interfacciamento CNTI sviluppato dallo stesso CERT-AgID. Mentre i primi due requisiti resteranno invariati in quanto […]

YAU – Parte 13 – Il client, comandi e trasmissione al C2

23/02/2021

yau

Nell’articolo precedente abbiamo visto la struttura del client Ursnif.

La quantità di codice di Ursnif è piuttosto ingente ed un’analisi dettagliata richiederebbe non solo molto tempo ma anche molta forza di volontà di eventuali lettori.

Ci limitiamo quindi a mostrare le parti più interessanti: i comandi che il client può eseguire (dalla configurazione o dal C2) e la comunicazione con il C2.

Ricordiamo che i comandi sono eseguiti dai processi infetti e che il nome del comando viene prima messo in maiuscolo e poi passato alla funzione CRC32, per cui nel codice troviamo solo riferimenti a CRC32.
Inoltre i comandi così eseguiti sono detti comandi client perchè eseguiti in processi non privilegiati, qualora sia richiesto un comando privilegiato (tipo quello di reboot), essi sono inviati al server dei comandi (tramite un pipe) che gira nel processo explorer.exe.

Si hanno quindi due insiemi di comandi: quelli client (che sono identificati da valori CRC32) e quelli server (identificati da costanti numeriche da 0x102 in poi).

YET ANOTHER URSNIF

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

Vecchi e nuovi comandi client

L’incubo di ogni analista.

I comandi sono processati nella funzione ClientProcessCommand (Il DB IDA si trova qui).
Come evidenze è fornito il DB IDA, che dovrebbe consentire a qualsiasi analista di verificare la veridicità delle seguenti affermazioni.

I comandi che Ursnif può eseguire, alcuni dei quali non presenti nei sorgenti, sono i seguenti:

  • Scaricare ed eseguire DLL ed EXE da URL terzi.
  • Scaricare e registrare per l’avvio DLL ed EXE da URL terzi.
  • Fare screenshot e filmati di quanto visualizzato a schermo.
  • Avviare e fermare il server socks.
  • Avvia e fermare il keylogger.
  • Ricaricare la configurazione da registro.
  • Rubare i dati inviati e ricevuti dai browser.
  • Modificare i dati ricevuti dai browser con dei template eventualmente presenti nella configurazione (dove è possibile usare placeholder come @VNC@ o @VIDEO@ e simili per eseguire comandi durante la visualizzazione dell’URL).
  • Rubare le credenziali di Thunderbird, Windows Live Mail ed Outlook.
  • Bloccare o sbloccare la navigazione verso un URL.
  • Abilitare un knocker verso il C2, ovvero impostare un particolare intervallo di attesa prima di effettuare una richiesta al C2 (in modo da essere riconosciuta come richiesta lecita).
  • Rubare i cookie da IE, FF, EDGE, Chrome e… i file SOL da FlashPlayer (ahahahha).
  • Ottenere informazioni di sistema tramite i comandi: systeminfo.exe, new view, nslookup 127.0.0.1, tasklist.exe /SVC, driverquery.exe, interrogando il valore della chiave Uninstall nel registro di sistema (per determinare i programmi installati).
  • Enumerare directory e trasferire file al C2.
  • Cancellare ed aggiungere cookie.
  • Eseguire comandi arbitrari con cmd.exe.
  • Rimuovere un URL dalla cache.
  • Scaricare un client TOR.
  • Scaricare un server FTP.
  • Scaricare un server VNC.
Ursnif può alterare il contenuto delle pagine web con dei template presenti nella configurazione (contenuta nella DLL o scaricata dal C2). Questi template possono contenere placeholder per eseguire comandi od ottenere i parametri di infezione della vittima (come il suo id).

Comunicazione con il C2

I C2 sono contenuti nella configurazione vista precedentemente.

Questi sono contattati con richieste POST verso URL che hanno la stessa forma di quelli usati dal secondo stadio.

Nel corpo della richiesta è inserito un file che verrà salvato nel C2.

Il codice che genera il corpo della richiesta.

Nell’URL sono contenute le informazioni sul tipo di richiesta.

L’URL prima della codifica (vista negli articoli precedenti).

Spesso i dati da inviare sono divisi in più file, di questi Ursnif crea un file CAB che verrà inviato nel corpo della richiesta.

Il codice che genera un CAB.

Taggato  yau