Un backdoor è un metodo nascosto per accedere a un sistema che bypassa l'autenticazione normale e i controlli di sicurezza.

Analisi Tecnica:

Analisi Statica di Base:

Caricalo prima su VirusTotal per un'analisi iniziale. I risultati indicano che il file è una DLL a 64 bit, identificata nella famiglia di malware Kalim. Inoltre, diverse rilevazioni suggeriscono una potenziale associazione con il gruppo di minacce MuddyWater.

Il malware stabilisce anche una comunicazione di rete con il dominio moodleuni[.]com.

Rilascia alcuni file:

Ora aprilo in Die (Detect it Easy):

Il campione importa un gran numero di API di Windows, indicando che non è packed. In totale, importa funzioni da sei DLL: KERNEL32.dll, USER32.dll, ADVAPI32.dll, SHELL32.dll, ole32.dll e WININET.dll.

Sebbene siano importate più API da ogni DLL, diverse funzioni sono particolarmente degne di nota per il loro ruolo nel comportamento del malware.

Nello specifico, il campione importa API relative alla rete da WININET.dll per stabilire la comunicazione con il server di comando e controllo (C2). Sfrutta anche funzioni relative a COM da ole32.dll per creare e interagire con oggetti del Component Object Model (COM). Inoltre, il malware usa SHGetFolderPathW da SHELL32.dll per recuperare i percorsi delle directory di sistema identificati dai valori CSIDL.

Analisi Statica Avanzata:

In DllMain, l'unica azione eseguita è la creazione di un nuovo thread. All'interno di questo thread, vengono eseguite due funzioni: sub_1800063A0 e StartAddress.

Analizzando la funzione sub_1800063A0, ho scoperto che consiste in due fasi distinte. La prima fase: il malware rilascia una copia di sé stesso nella directory AppData\Roaming. Lo fa creando una nuova sottodirectory chiamata Updates, seguita dalla creazione di un file eseguibile chiamato update.exe. Il payload binario scritto in questo file proviene direttamente dai dati incorporati situati in unk_18002AA10. Di conseguenza, il file finale viene scritto nel seguente percorso: “C:\Users\AppData\Roaming\Update\update.exe”.

Nella seconda fase, il malware inizializza un oggetto Component Object Model (COM) utilizzando RCLSID: {00021401-0000-0000-C000-000000000046}, che corrisponde all'oggetto Shell Link (CLSID_ShellLink)e RIID: {000214F9-0000-0000-C000-000000000046}, che mappa all'interfaccia IShellLinkW. Osservando l'intera tabella delle interfacce COM di Shell implementata da shell32.dll, è possibile identificare accuratamente i metodi invocati. Il malware chiama quattro metodi COM chiave: SetPath, SetDescription, Save e Release. Utilizzando queste funzioni, crea un collegamento dannoso all'avvio chiamato MicrosoftUpdateSerice.lnk nella directory di avvio di Windows, stabilendo così la persistenza sul sistema infetto.

Analisi della Funzione StartAddress

Il malware implementa la sua logica di comunicazione di rete attraverso tre funzioni distinte e genera due thread separati. Un thread è responsabile della creazione e gestione di una shell dei comandi, mentre il secondo thread gestisce il caricamento dei dati raccolti dopo che il malware ha completato la sua esecuzione.

Le tre funzioni gestiscono collettivamente la comunicazione tra l'host infetto e il server di comando e controllo (C2) e sono organizzate in tre livelli logici.

Il primo livello è responsabile della raccolta di informazioni di fingerprinting basate sull'host dal sistema compromesso. Il secondo livello elabora questi dati eseguendo crittografia e ulteriori manipolazioni per prepararli alla trasmissione. Il terzo livello stabilisce la comunicazione di rete con il dominio C2 moodleuni[.]com e trasmette i dati elaborati.

Le prime due funzioni relative alla rete sono specificamente responsabili dell'autenticazione e della costruzione di richieste HTTP POST, consentendo la trasmissione autenticata dei dati al server remoto.

La terza funzione è responsabile della ricezione dei comandi dal server C2. In base alla risposta del server, il malware determina la sua azione successiva: generare una shell dei comandi nascosta o caricare i dati raccolti in base al comando ricevuto dal C2.

Analisi dei due thread per capire completamente cosa fanno.

Nel primo thread, il malware crea un oggetto job insieme ad altri due pipe e poi imposta una certa proprietà su di essi. Poi crea un CMD con alcune proprietà: Il valore 1 nel quarto argomento significa che il CMD può ereditare dagli handle dei pipe Il valore 0x1000200u nel quinto argomento significa che il CMD ha quanto segue: CREATE_NO_WINDOW = 0x0000000u CREATE_NEW_PROCESS_GROUP = 0x0000200u CREATE_UNICODE_ENVIRONMENT = 0x0000400u E alcune informazioni di avvio: {dimensione della struttura = 104 byte, hStdError = hWritePipe, hStdOutput = hWritePipe, hStdInput = hReadPipe2, dwFlags |= 0x100u = STARTF_USESTDHANDLES}. Il primo pipe è responsabile di leggere l'output dalla shell e il secondo di scrivere nella shell. E un puntatore a PROCESS_INFORMATION E dopo aver creato la shell, la assegna all'oggetto job e la mette in stato di attesa in attesa di comandi dal C2.

La shell controlla i comandi di controllo inviati tramite memoria condivisa: Pending: Esecuzione normale. Terminate: Uccidi la shell e pulisci. Shell completamente distrutta e resettata Ctrlc: Forza l'uccisione di eventuali processi figli rimanenti.

In funzionamento normale, se esiste un comando, lo scrive nel CMD e poi controlla un output usando PeekNamedPipe e lo memorizza nel buffer.

Il secondo thread. Il thread inizia creando un nuovo file nel percorso specificato. Questo file viene utilizzato per archiviare temporaneamente i dati prima di caricarli sul server C2. Se il file non può essere creato o si verifica un errore durante l'inizializzazione, la funzione imposta una stringa di stato "error" nella memoria condivisa ed esce. Il file viene trasmesso tramite HTTPS al server di comando e controllo del malware (moodleuni[.]com) utilizzando intestazioni personalizzate e identificatori di sessione per imitare il traffico legittimo. Dopo il completamento del caricamento, la funzione aggiorna la memoria condivisa per indicare successo o fallimento:

• "error" if the upload fails.
• "done" if the upload succeeds.

Riepilogo:

Il malware backdoor Kalim si concentra prima sull'instaurazione della persistenza per garantire una presenza a lungo termine sul sistema vittima. Raggiunge questo obiettivo creando un collegamento dannoso nella directory di avvio (CSIDL_STARTUP):

C:\Users<User>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Questo meccanismo garantisce che il malware venga eseguito automaticamente ogni volta che il sistema si avvia.

Una volta stabilita la persistenza, il malware avvia la comunicazione con il suo server di comando e controllo (C2), moodleuni[.]com. Esegue una fase iniziale di autenticazione e fingerprinting del sistema, durante la quale vengono raccolte, elaborate e crittografate informazioni basate sull'host. Il malware entra quindi in uno stato di attesa dei comandi, interrogando continuamente il C2 per istruzioni.

In base ai comandi ricevuti, il malware può decidere dinamicamente le sue azioni successive, inclusa la generazione di una shell dei comandi nascosta per il controllo interattivo o il caricamento dei dati raccolti al server C2. Questo design modulare consente sia l'esecuzione remota di comandi che l'esfiltrazione di dati, rendendo Kalim un backdoor flessibile e persistente.

Tattiche e Tecniche (MITRE ATT&CK):

IOCs:

Regola YARA: