Smascheramento di VEILDrive: gli attori della minaccia sfruttano i servizi Microsoft per il comando e il controllo

Di Hunters Team Axon

In breve

• Il team di cacciatori AXON ha identificato e sta attualmente monitorando una campagna di minaccia in corso, denominata " VEILDrive "
• La campagna è stata originariamente identificata come parte di un impegno AXON per affrontare un'attività dannosa identificata nell'infrastruttura di uno dei nostri clienti
• Nell'ambito dell'indagine, abbiamo identificato diversi componenti dell'infrastruttura Microsoft di ulteriori organizzazioni vittime che sono stati compromessi e utilizzati dall'aggressore
• L'aggressore ha sfruttato diversi servizi e applicazioni Microsoft SaaS come parte della campagna, tra cui Microsoft Teams, SharePoint, Quick Assist e OneDrive
• L'aggressore ha utilizzato un metodo di comando e controllo (C&C) basato su OneDrive come parte del malware trovato nell'infrastruttura della vittima
• Sulla base delle conclusioni della nostra indagine, vi è una probabilità significativa che questa campagna provenga dalla Russia
• Il team AXON ha segnalato le sue scoperte a Microsoft per aiutarla a chiudere l'infrastruttura dell'attore
• Il team ha anche contattato numerose vittime colpite identificate durante la nostra ricerca

Sintesi

Il Team AXON di Hunters ha scoperto e sta monitorando attivamente una campagna di minacce in corso denominata "VEILDrive". Inizialmente scoperta durante un'indagine su attività dannose nell'infrastruttura di un cliente, VEILDrive sfrutta la suite SaaS di Microsoft, in particolare Teams, SharePoint, Quick Assist e OneDrive, per eseguire le sue tattiche. In modo unico, l'attore della minaccia utilizza un metodo Command & Control (C&C) basato su OneDrive incorporato in malware personalizzato che viene distribuito in ambienti compromessi. La nostra analisi indica una probabile origine russa per questa campagna e il Team AXON ha da allora avvisato sia Microsoft che le organizzazioni interessate per mitigare ulteriori sfruttamenti.

La nostra ricerca è iniziata a settembre 2024 in seguito a una risposta a un attacco a un'entità infrastrutturale critica negli Stati Uniti. Le tecniche di attacco di VEILDrive divergono nettamente dal tipico comportamento delle minacce. Si basano fortemente sull'infrastruttura SaaS di Microsoft per distribuire campagne di spear-phishing e archiviare software dannoso. Questa strategia dipendente da SaaS complica il rilevamento in tempo reale e aggira le difese convenzionali.

Il malware associato a VEILDrive è un file .jar basato su Java che in particolare non presenta offuscamento, il che lo rende insolitamente leggibile e ben strutturato. Nonostante la sua semplicità, il malware è sfuggito al rilevamento da parte di uno strumento di Endpoint Detection and Response (EDR) di alto livello e di tutti i motori di sicurezza in VirusTotal. Ciò evidenzia un rischio critico: anche il codice semplice e non offuscato può eludere i moderni meccanismi di rilevamento, il che suggerisce una più ampia necessità di rivisitare le strategie di rilevamento in ambienti ad alto rischio.

Questo rapporto fornisce approfondimenti sulle metodologie di VEILDrive e sui limiti degli attuali approcci di rilevamento per equipaggiare al meglio la comunità della sicurezza informatica contro le minacce in continua evoluzione.

Sfondo

Nel settembre 2024, il Team AXON è intervenuto in seguito a un incidente che aveva come obiettivo un'azienda di infrastrutture critiche negli Stati Uniti. Questa indagine ha rivelato una campagna di minacce unica, "VEILDrive", che ha mostrato tattiche, tecniche e procedure (TTP) insolite che si discostavano in modo significativo da quelle solitamente osservate in incidenti simili.

Sulla base delle nostre scoperte, stimiamo che la campagna VEILDrive sia iniziata all'inizio di agosto 2024 e sia ancora attiva al momento di questo report. Sfruttando i servizi Microsoft SaaS, tra cui Teams, SharePoint, Quick Assist e OneDrive, l'aggressore ha sfruttato le infrastrutture affidabili di organizzazioni precedentemente compromesse per distribuire attacchi di spear-phishing e archiviare malware. Questa strategia incentrata sul cloud ha consentito all'autore della minaccia di evitare il rilevamento da parte dei sistemi di monitoraggio convenzionali.

In particolare, VEILDrive ha introdotto un nuovo metodo Command & Control (C&C) basato su OneDrive incorporato in malware basato su Java distribuito su dispositivi compromessi. Il malware stesso, un file .jar, presenta due caratteristiche sorprendenti:

• Trasparenza del codice: senza alcun offuscamento e con un codice ben strutturato, questo malware sfida la tipica tendenza alla progettazione incentrata sull'elusione, risultando insolitamente leggibile e diretto.
• Efficacia stealth: nonostante la sua semplicità, questo malware non è stato rilevato né dalla soluzione Endpoint Detection and Response (EDR) di livello superiore implementata nell'ambiente della vittima né da tutti i motori di sicurezza di VirusTotal (vedere Figura 1 di seguito):

Queste caratteristiche evidenziano che anche senza sofisticate tecniche di evasione, malware attentamente realizzati e non offuscati possono eludere le difese moderne. Questa indagine sottolinea una lacuna nelle attuali strategie di rilevamento e sottolinea la necessità di vigilanza contro approcci di attacco meno convenzionali.

Il team AXON ha condiviso le sue scoperte con Microsoft e le organizzazioni interessate, offrendo informazioni fruibili per mitigare questa minaccia in corso.

Il percorso di attacco VEILDrive

All'inizio di settembre 2024, uno dei clienti di Hunters, di seguito denominato "Org C", ha contattato il Team AXON per ricevere supporto nella gestione di un incidente attivo. Il caso era incentrato su uno specifico dispositivo all'interno di Org C che era stato compromesso tramite social engineering.

Un'attività pianificata creata in modo sospetto sul dispositivo di un dipendente dell'Org C ha attivato un avviso, richiedendo ulteriori indagini. Correlando i log e comunicando con l'utente interessato, il team ha chiarito il metodo di accesso iniziale.

Di seguito è riportato un diagramma di attacco che fornisce una panoramica di alto livello del flusso di attacco:

La sequenza degli eventi si è svolta come segue:

Passo 1

L'attore malintenzionato ha sfruttato Microsoft Teams per inviare messaggi a quattro dipendenti selezionati di Org C, che, oltre a non essere tecnici in base ai loro ruoli, non avevano altre connessioni apparenti. L'attaccante si è spacciato per un membro del team IT e ha richiesto l'accesso al dispositivo di ciascun dipendente tramite lo strumento di utilità remota Quick Assist .

Invece di utilizzare un account appena creato per impersonificarsi, l'aggressore ha utilizzato un account utente compromesso di una potenziale vittima precedente, qui denominata "Org A".

I registri di controllo di M365 sono stati utilizzati per identificare gli attacchi di spear-phishing di Microsoft Teams.

• Sono stati identificati più eventi " MessageSent " e " ChatCreated ", tutti originati dall'utente precedentemente compromesso di Org A , di proprietà dell'autore della minaccia.

• Sebbene siano stati presi di mira 4 dipendenti, è stato identificato un solo evento " MemberAdded " rivolto all'utente compromesso di Org A.

  
  

• Questo evento " MemberAdded " è stato condotto dall'unico account utente dei 4 utenti presi di mira che ha accettato la richiesta di accesso dell'attore della minaccia, creando una chat one-to-one. Ciò significa che questo utente è stato l'unico che ha interagito attivamente con il messaggio in arrivo.
• Queste informazioni erano in linea con i dati della telemetria EDR dell'organizzazione, confermando che l'utente non solo aveva accettato la richiesta e ricevuto il messaggio, ma aveva anche consentito all'aggressore di ottenere l'accesso iniziale grazie al successo dell'ingegneria sociale.

L'intuizione di cui sopra è stata sia intrigante che preziosa, evidenziando la crescente prevalenza del phishing tramite Microsoft Teams e strumenti di comunicazione simili. Distinguere tra tentativi di phishing riusciti e falliti utilizzando i log di controllo M365, insieme alla correlazione con i log EDR, può essere altamente significativo per le indagini.

I messaggi di Microsoft Teams ricevuti dagli utenti target dell'organizzazione C sono stati resi possibili dalla funzionalità " Accesso esterno " di Microsoft Teams, che consente per impostazione predefinita la comunicazione individuale con qualsiasi organizzazione esterna.

Passo 2

L'attaccante ha attirato con successo la vittima di Org C per eseguire lo strumento Quick Assist di Microsoft e le ha fornito il codice di accesso tramite Microsoft Teams. Ciò ha portato l'attore della minaccia all'accesso interattivo al computer della vittima.

Passo 3

L'autore della minaccia ha quindi condiviso un link di download per SharePoint di un'organizzazione separata (la vittima apparteneva a un tenant diverso da quello utilizzato per il phishing tramite la chat di Microsoft Teams, che chiameremo "Org B"). Questo link conteneva un file .zip protetto da password denominato Client_v8.16L.zip, che includeva vari file, tra cui uno strumento RMM aggiuntivo.

Il file è stato scaricato, probabilmente tramite mezzi interattivi, dall'aggressore, già dotato di accesso remoto, operando nel contesto di explorer.exe, che gli ha consentito di cliccare sul collegamento e scaricare gli strumenti necessari.

Vale la pena ricordare che durante l'indagine abbiamo correlato i registri di controllo di M365, che fornivano informazioni precise sugli URL in arrivo nei messaggi di Microsoft Teams, con la telemetria EDR dell'host della vittima per comprendere appieno le TTP dell'aggressore.

Passo 4

Sono stati fatti diversi tentativi di eseguire operazioni dannose manuali tramite accesso remoto. Queste attività hanno coinvolto principalmente sforzi di persistenza, come la creazione di attività pianificate per eseguire ripetutamente uno dei file scaricati dall'attaccante, uno strumento RMM chiamato LiteManager ("ROMServer.exe").

schtasks /Create /TN "Perfomance monitoring" /SC MINUTE /TR C:\ProgramData\500000003\ROMServer.exe

Passo 5

Dopo aver eseguito le attività sopra descritte, l'attore scarica manualmente un altro file .zip denominato Cliento.zip.

Come in precedenza, il link è stato condiviso nella chat tra l'utente vittima e l'autore della minaccia. Questo file .zip includeva il malware .JAR principale e l'intero Java Development Kit per eseguire il malware .JAR.

Passo 6

L'autore della minaccia ha eseguito il malware .JAR utilizzando quanto segue: C:\\ProgramData\\Cliento\\jdk-22_windows-x64_bin\\jdk-22.0.2\\bin\\javaw.exe -jar C:\\ProgramData\\Cliento\\Cliento.jar

Passo 7

Sono state identificate molteplici attività di rete ed esecuzioni di comandi nel contesto del file .JAR dannoso, tra cui:

• Diverse richieste DNS/attività di rete in uscita verso → safeshift390-my.sharepoint.com

• Diverse richieste DNS/attività di rete in uscita verso → graph.microsoft.com

• Diverse richieste DNS/attività di rete in uscita verso → login.microsoftonline.com

• Esecuzione dei comandi di enumerazione locale:

  • Ottieni le specifiche del sistema - Systeminfo
  • Ottieni informazioni sul tempo macchina - net time
  • Ottieni l'UUID della macchina ( ricordatelo; ne parleremo più avanti ) - Get-WmiObject -Class Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID
  • Enumerazione dei dispositivi USB - {$_.interfacetype -eq \"USB\"}"

  
  

La seguente schermata mostra le parti principali dell'albero dei processi relativi alle attività dannose:

Passo 8

L'aggressore ha anche aggiunto un binario JAR dannoso come chiave di esecuzione nel registro per l'esecuzione persistente del malware Java.

Riga di comando:

Set-ItemProperty -Path \"HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\" -Name \"current\" -Value \"C:\\ProgramData\\Cliento\\jdk-22_windows-x64_bin\\jdk-22.0.2\\bin\\javaw.exe -jar C:\\ProgramData\\Cliento\\Cliento.jar\" -ErrorAction Stop"

Il contenimento e l'eradicazione di questo incidente sono stati molto rapidi ed efficaci e, secondo le prove forensi in nostro possesso, non vi erano indicazioni che l'aggressore fosse riuscito a causare danni significativi all'host e all'organizzazione della vittima.

Un aspetto fondamentale che si evince dal flusso di attacco descritto sopra è che l'aggressore ha utilizzato diversi servizi Microsoft noti e comunemente utilizzati come parte del suo attacco, sia per nascondersi in bella vista sia potenzialmente per comodità.

Riassumiamo rapidamente i servizi Microsoft utilizzati dall'autore della minaccia utilizzando la seguente tabella:

A questo punto, avevamo identificato i quattro servizi/app Microsoft menzionati sopra. Mentre avevamo compreso lo scopo dei primi tre, l'attività rivolta alla Graph API rimaneva poco chiara. Avevamo diverse ipotesi sul suo potenziale scopo, ma nella risposta agli incidenti, le ipotesi da sole non sono sufficienti, non è vero?

Per raccogliere maggiori informazioni e comprendere meglio il malware .JAR 'Cliento.jar' in OneDrive/SharePoint, sia per valutare le potenziali azioni intraprese dall'aggressore sia per comprendere meglio le sue intenzioni, abbiamo proceduto con un'analisi dettagliata del malware.

Malware Java "ODC2": OneDrive come comando e controllo

Abbiamo utilizzato un decompilatore Java denominato “JDGUI” per decompilare il malware Client.jar (chiamato “ODC2”).

Già da un primo sguardo di alto livello al malware, abbiamo potuto immediatamente correlarlo con l'esecuzione di PowerShell che abbiamo visto nell'indagine sull'incidente. Ciò è dovuto all'inclusione del pacchetto Java " jPowerShell ", un wrapper di PowerShell per Java.

Inoltre, abbiamo potuto vedere pacchetti aggiuntivi come "comandi", "connessione", "launcher", "o connessione", ecc. Ciò ci ha fornito una comprensione di alto livello della struttura del malware.

1. Abbiamo iniziato con Main.class sotto il pacchetto "launcher" e abbiamo trovato un set di credenziali hard-coded utilizzate dal malware. Questo è stato un po' sorprendente per noi, ma molto interessante.

   
   

Analizzando ulteriormente il malware (come descritto nell'analisi dettagliata di seguito), abbiamo scoperto che il malware ha utilizzato queste credenziali per condurre un'autenticazione "per conto" all'ID Entra. Per condurre questa autenticazione, il token di aggiornamento hard-coded è stato utilizzato con l'ID client e il segreto client per richiedere un token di accesso.

L'autenticazione ha consentito al malware di accedere a OneDrive di specifici utenti con ID Entra, in tenant presumibilmente di proprietà dell'autore, abusando di tale accesso per scopi C2.

2. Nella funzione principale di Main.class possiamo vedere il punto di ingresso stesso, che include più thread. Include l'esecuzione delle funzioni "odThread1" e "mainThread1".

   
   

"odThread1" include l'esecuzione della funzione "odRun" del controller che ottiene il primo set di credenziali hardcoded (token di aggiornamento, ecc.) per l'autenticazione.

• Utilizza l'indirizzo IP "40.90.196.221" per la configurazione della connessione "odRun"

• L'indirizzo IP "40.90.196.228" per "Run" inizializza il socket HTTPS sul C2 dell'attaccante. Questo IP è anche l'IP di Azure ed è molto probabile che sia una macchina virtuale. Questo canale C2, come dettagliato di seguito, è più "classico" e porta all'esecuzione di comandi PowerShell

• Per ottenere maggiori informazioni su questi indirizzi IP, abbiamo controllato risorse note come ipinfo.io e i Service Tag degli indirizzi IP di Azure pubblicati da Microsoft, come mostrato nello screenshot qui sotto:

  
  

  
  

• Vale anche la pena menzionare che l'indirizzo IP hard-coded aggiuntivo trovato in questo malware (38.180.136.85) sembra essere di proprietà di un altro fornitore di servizi ed è associato a servizi di hosting. In base alle nostre intuizioni, questo indirizzo IP non è stato utilizzato attivamente dal malware. Supponiamo che fosse lì per motivi legacy (precedente infrastruttura C2).

  
  

Presa HTTPS C2

3. Scavando un po' più a fondo nel “mainThread1()“ che esegue la funzione “ctrl.run()”, possiamo vedere che la funzione run() tenta di creare una connessione e controlla regolarmente se la connessione è attiva. Quindi tenta di “parseCommand”, eliminandone le parti irrilevanti.

   
   

4. Questa funzione "run" usa "connect()" per impostare/reimpostare una connessione. Crea un socket all'indirizzo IP remoto che abbiamo visto sopra - 40.90.196.228.

5. Questa funzione "run" utilizza "CommandManager", che include diverse gestioni per i diversi tipi di comandi/capacità forniti da questo malware, tra cui il trasferimento di file dal client al server e dal server al client, la compressione dei file, gli screenshot, la chiusura delle connessioni di rete e, naturalmente, l'esecuzione dei comandi.

   
   

Controlla se il comando ricevuto è vuoto o se è stato ricevuto un comando effettivo dal server C2.

6. Se viene trovato un comando, lo analizza e lo esegue. L'esecuzione avviene fondamentalmente nel contesto di PowerShell.

   
   

   L'esecuzione del comando in arrivo come comando PowerShell viene effettuata utilizzando il wrapper jPowerShell menzionato in precedenza.

Comando e controllo OneDrive

Prima di addentrarci nel cuore della funzionalità OneDrive C2, è importante notare che parti critiche del codice del malware si basano in larga misura su tre specifici "tipi" di file OneDrive: UUID, cf_UUID e rf_UUID. Come osservato nella nostra indagine, è stato eseguito il comando Get-WmiObject -Class Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID , rivelando l'UUID dell'hardware del dispositivo. Questo identificatore univoco serve a distinguere ogni vittima nella campagna VEILDrive.

Ogni tipo di file svolge un ruolo distinto nelle operazioni del malware. La seguente schermata fornisce esempi di questi file e dei loro ruoli principali nell'esecuzione del malware.

Analizziamo nel dettaglio il flusso delle funzionalità di OneDrive C2 e come vengono utilizzati nella pratica i file UUID:

7. Oltre alle classiche capacità di esecuzione remota su PowerShell, la funzione "odRun" è responsabile di un altro thread basato su "OneDrive" come canale di comunicazione. Questa è la parte unica di questo malware.

   
   

   L'“odRun” come lo vediamo, probabilmente prende il nome da “OneDrive” (OneDriveRun) e include la creazione di una connessione OneDrive utilizzando la funzione “Odconnect” come primo passaggio:

   
   

8. Come puoi vedere, prima la stringa "machineUUID" è impostata come una stringa vuota. Seguita dall'esecuzione della funzione "getMachineUUID()", che, come suggerisce il nome, ottiene il Machine UUID del dispositivo vittima:

   
   

9. Possiamo quindi vedere che la connessione OneDrive viene condotta utilizzando la funzione "OdConnect": la connessione viene effettuata a "login[.]microsoftonline[.]com" per la creazione/aggiornamento di un set di nuovi token di accesso e token di aggiornamento.

   
   

10. La funzione successiva che verrà chiamata è "WriteFileToOneDrive", a patto che non vi sia alcun file denominato UUID della macchina vittima corrente nel computer di destinazione, in base a un controllo condotto dalla funzione "checkFile".

• "checkFile": questa funzione controlla se è presente un file denominato == machineUUID nella cartella home dell'utente corrente OneDrive

  
  

11. Se non esiste un file del genere, "writeFileToOneDrive()" entra nel gioco e crea un file denominato UUID del computer della vittima corrente senza alcun prefisso.

12. La parte successiva di “odRun” è la funzione “getFiles()” che ottiene il contenuto dell’UUID.

File OneDrive denominato in base al machineUUID del dispositivo (senza prefissi).

• Se il contenuto del file non è vuoto, controlla se inizia con la parola "invia":
  • Esegue una certa normalizzazione del contenuto, preparandolo per i controlli successivi - rimuovendo la stringa "invia" e sostituendo "\" "con" " (niente) salvandolo in una variabile denominata " filenameForDownload "
  • filenameForDownload viene passato alla funzione getFileDownloadUrl . Questa ottiene il file scelto dall'attaccante. L'attaccante specificherebbe il nome del file dopo la parola "send" nel file UUID e lo salverebbe nel percorso di destinazione specificato sulla macchina della vittima che è "user.home"\downloads (la cartella dei download).
  • Successivamente, viene chiamata la funzione " downloadFile ", che scarica il file remoto sul dispositivo locale della vittima, in base all'output della funzione getFileDownloadUrl .
  • L'attaccante ottiene un'indicazione sull'esecuzione del file utilizzando " writeFileToOneDrive " che viene eseguito subito dopo come parte di "odRun" per scrivere quanto segue "rf_" + "send file" + filenameForDownload + "done" → per far sapere all'attaccante che l'esecuzione è stata eseguita. Successivamente, c'è un'altra esecuzione di "writeFileToOneDrive", in cui un altro file, denominato "cf_" + machineUUID, viene scritto su OneDrive, senza alcun contenuto al suo interno.
• Se il contenuto del file non è vuoto ma non inizia con "send":

  • Verrà eseguito il contenuto del file cf_MachineUUID.

  • Seguito ancora dalla scrittura di un file su OneDrive, utilizzando “ writeFileToOneDrive ”, prima “rf_“ + machineUUID, con il contenuto della risposta di esecuzione.

  • E un altro utilizzo di " writeFileToOneDrive ", per scrivere e svuotare il file "cf_", impedendo sostanzialmente un'altra esecuzione dello stesso comando (poiché il malware viene eseguito in un loop).

    
    

Riassumendo brevemente, questo malware sembra avere due diversi canali C2 con cui può interagire:

• HTTPS Socket C2 : un approccio più classico, che riceve comandi da una macchina virtuale di Azure remota ed eseguendoli nel contesto di PowerShell.

• C2 basato su OneDrive : è più unico e il suo funzionamento è un po' più complesso e creativo. Include tre file diversi, tutti con l'UUID del dispositivo della vittima, alcuni con prefissi (rf_ e cf_). Per semplificare l'invio e la ricezione di comandi da parte dell'autore della minaccia tramite Microsoft Graph.

  
  

  Nota : è importante menzionare che questo malware ha capacità aggiuntive oltre all'esecuzione standard dei comandi, incluso il trasferimento di file. Tuttavia, le informazioni dettagliate di cui sopra si concentrano solo sull'aspetto dell'esecuzione dei comandi.

  
  

Servizi/app Microsoft come infrastruttura dell'attaccante

A questo punto, è chiaro che questo attacco ha sapientemente combinato tecniche semplici con tattiche sofisticate e uniche. Una caratteristica di spicco della nostra indagine iniziale è stato l'ampio utilizzo di infrastrutture e servizi Microsoft integrati in tutta la campagna.

Dopo aver analizzato il malware e aver correlato le nuove informazioni con le nostre intuizioni di indagine, abbiamo acquisito una comprensione più chiara dell'uso di vari servizi da parte dell'attaccante e dei loro scopi. Abbiamo scoperto che l'utilizzo dei servizi e dell'infrastruttura Microsoft era persino più esteso di quanto inizialmente pensato.

Per un breve riepilogo, vedere la tabella seguente:

Indicatori di Compromesso (IOCS)

• Tenant Entra ID noti di proprietà dell'attaccante:
  • C5f077f6-5f7e-41a3-8354-8e31d50ee4d
  • 893e5862-3e08-434b-9067-3289bec85f7d
• Applicazioni note registrate dagli ID client dell'attaccante:
  • B686e964-b479-4ff5-bef6-e360321a9b65
  • 2c73cab1-a8ee-4073-96fd-38245d976882
• ID di accesso dei tenant utilizzati dall'attaccante (cercare le richieste DNS in uscita verso tali domini):
  • SafeShift390[.]onmicrosoft[.]com
  • GreenGuard036[.]onmicrosoft[.]com
• File IOC (SHA256) rinvenuti nell'ambito dell'indagine:
  • ROMServer.exe a515634efa79685970e0930332233aee74ec95aed94271e674445712549dd254
  • HookDrv.dll 1040aede16d944be8831518c68edb14ccbf255feae3ea200c9401186f62d2cc4
  • ROMFUSClient.exe 7f61ff9dc6bea9dee11edfbc641550015270b2e8230b6196e3e9e354ff39da0e
  • AledensoftIpcServer.dll d6af24a340fe1a0c6265399bfb2823ac01782e17fc0f966554e01b6a1110473f
  • ROMwln.dll7f33398b98e225f56cd287060beff6773abb92404afc21436b0a20124919fe05 7f33398b98e225f56cd287060beff6773abb92404afc21436b0a20124919fe05
• Indirizzi IP:
  • 40.90.196[.]221
  • 40.90.196[.]228
  • 38.180.136[.]85
  • 213.87.86[.]192

Query di ricerca delle minacce

Oltre agli IOC specifici menzionati sopra, abbiamo creato più query di ricerca delle minacce che possono essere utilizzate per rilevare attacchi originati dallo stesso attore, condotti nell'ambito della stessa campagna o che condividono caratteristiche simili (TTP)

Nota: il periodo di caccia consigliato per VEILDrive è da luglio 2024.

QUERY DI CACCIA 1 : Javaw che genera Powershell con flag specifici - Comportamento insolito

• Logica di query: durante la nostra analisi, abbiamo identificato che lo strumento di accesso remoto (RAT) dell'attaccante ha utilizzato Powershell per recuperare l'UUID della macchina come parte del suo processo di esecuzione. Questa query rileva istanze insolite di Powershell generate da javaw.exe con i flag della riga di comando specifici utilizzati dall'attore della minaccia.

• Domanda:

   SELECT EVENT_TIME, AGENT_ID, PARENT_PROCESS_NAME, PARENT_PROCESS_COMMANDLINE, INITIATING_PROCESS_NAME, INITIATING_PROCESS_COMMANDLINE, TARGET_PROCESS_NAME, TARGET_PROCESS_COMMANDLINE, TARGET_PROCESS_OS_PID FROM INVESTIGATION.EDR_PROCESS_CREATION_EVENTS WHERE 1=1 AND PARENT_PROCESS_NAME ILIKE '%javaw%' AND INITIATING_PROCESS_NAME ILIKE '%cmd%' AND TARGET_PROCESS_NAME ILIKE '%powershell%' AND TARGET_PROCESS_COMMANDLINE ILIKE 'powershell.exe -ExecutionPolicy Bypass -NoExit -NoProfile %' AND EVENT_TIME > current_timestamp - interval '60d'

  
  

QUERY DI CACCIA 2: Persistenza dello strumento ROM tramite attività pianificate

• Logica di query: questa query rileva le istanze di un'attività pianificata che si registra con l'esecuzione di uno strumento ROM utilizzato dall'autore della minaccia per la persistenza.

• Domanda:

   SELECT EVENT_TIME AS EVENT_TIME, AID AS AGENT_ID, CID AS COMPUTER_ID, EVENT_SIMPLE_NAME AS EVENT_NAME, RAW:TaskName AS TASK_NAME, RAW:TaskExecCommand AS TASK_EXEC_COMMAND, RAW:TaskAuthor AS TASK_AUTHOR, RAW:UserName AS USER_NAME --- Adjust according to your EDR of choice FROM RAW.CROWDSTRIKE_RAW_EVENTS WHERE EVENT_SIMPLE_NAME = 'ScheduledTaskRegistered' AND TASK_EXEC_COMMAND ILIKE '%romserver%' AND EVENT_TIME > CURRENT_TIMESTAMP - interval '60d'

QUERY DI CACCIA 3 : Utenti non organizzativi che condividono collegamenti a domini di SharePoint di terze parti tramite Microsoft Teams

• Logica di query: questa query rileva i casi in cui un collegamento di SharePoint è condiviso in una chat di Teams, ma il dominio del collegamento di SharePoint non appartiene a nessuno dei partecipanti alla chat. Ciò potrebbe indicare un potenziale tentativo di phishing o esfiltrazione di dati, in cui un dominio esterno viene utilizzato per condividere file o informazioni con utenti ignari all'interno dell'organizzazione.
• Domanda:

 SET YOUR_ORGANIZATION_NAME = 'hunters'; SELECT EVENT_TIME, ORGANIZATION_ID AS ORG_ID, OPERATION AS EVENT_TYPE, SPLIT_PART(LOWER(SPLIT_PART(USER_ID, '@', 2)), '.', 1) AS SENDER_ORG_DOMAIN, RECORD_SPECIFIC_DETAILS:message_ur_ls AS MESSAGE_URLS, WORKLOAD AS WORKLOAD, USER_ID AS USER_ID, RECORD_SPECIFIC_DETAILS:chat_thread_id AS CHAT_THREAD_ID, RECORD_SPECIFIC_DETAILS:communication_type AS COMMUNICATION_TYPE, RECORD_SPECIFIC_DETAILS:members[0].DisplayName AS MEMBER_DISPLAY_NAME, RECORD_SPECIFIC_DETAILS:members[0].UPN AS MEMBER_UPN, RECORD_SPECIFIC_DETAILS:members[0] AS MEMBERS, RECORD_SPECIFIC_DETAILS:resource_tenant_id AS RESOURCE_TENANT_ID, RECORD_SPECIFIC_DETAILS FROM RAW.O365_AUDIT_LOGS WHERE NOT USER_ID ILIKE '%' || $YOUR_ORGANIZATION_NAME || '%' AND (NOT (MESSAGE_URLS ILIKE '%' || SENDER_ORG_DOMAIN || '%') AND MESSAGE_URLS ILIKE '%sharepoint%') AND NOT MESSAGE_URLS ILIKE '%' || $YOUR_ORGANIZATION_NAME || '%' AND EVENT_TIME > CURRENT_TIMESTAMP - interval '60d'

QUERY DI CACCIA 4 : Microsoft Teams - Rilevamento phishing - DM multipli da domini non comuni

• Logica di query: la query seguente rileva i messaggi inviati in una chat one-to-one da utenti esterni da domini non comuni. La query filtra i domini ampiamente utilizzati in base all'attività storica e identifica i membri esterni aggiunti alle chat che potrebbero condurre attacchi di phishing.

• Domanda:

   SET YOUR_DOMAIN_NAME = 'hunters'; --- GET EXTERNAL TEAMS AND ONEDRIVE USERS OF THE LAST 3 MONTHS - TO CLEAN EXTENSIVELY USED DOMAINS WITH COMMONLY_USED_DOMAINS AS ( SELECT LOWER(SPLIT_PART(USER_ID , '@', 2)) AS DOMAIN_COMMONLY_USED, MIN(EVENT_TIME) AS MIN_EVENT_TIME, MAX(EVENT_TIME) AS MAX_EVENT_TIME, ARRAY_AGG(DISTINCT OPERATION) AS OPERATIONS, COUNT(*) AS COUNTER FROM RAW.O365_AUDIT_LOGS WHERE WORKLOAD IN ('MicrosoftTeams', 'OneDrive') AND EVENT_TIME > CURRENT_TIMESTAMP - interval '90d' AND USER_ID ILIKE '%@%' GROUP BY DOMAIN_COMMONLY_USED HAVING COUNTER > 20 ), ---- Get List of External Domains that recently communicated with our organization using Microsoft Teams LATEST_EXTERNAL_DOMAINS AS ( SELECT USER_ID AS LATEST_EXT_USERS, LOWER(SPLIT_PART(USER_ID , '@', 2)) AS USER_DOMAIN, MIN(EVENT_TIME) AS MIN_EVENT_TIME, MAX(EVENT_TIME) AS MAX_EVENT_TIME, ARRAY_AGG(DISTINCT OPERATION) AS OPERATIONS, ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:communication_type) AS COMMUNICATION_TYPE, COUNT(*) AS COUNTER FROM RAW.O365_AUDIT_LOGS WHERE EVENT_TIME > CURRENT_TIMESTAMP - interval '50d' AND NOT USER_ID ILIKE '%' || $YOUR_DOMAIN_NAME || '%' AND NOT USER_ID IN ('app@sharepoint') AND USER_ID ILIKE '%@%' -- CLEAN-UP OF EXTENSIVELY USED DOMAINS AND USER_DOMAIN NOT IN (SELECT DISTINCT DOMAIN_COMMONLY_USED FROM COMMONLY_USED_DOMAINS) AND OPERATION IN ('MemberAdded', 'ChatCreated') AND RECORD_SPECIFIC_DETAILS:communication_type = 'OneOnOne' GROUP BY USER_ID HAVING COUNT(*) > 5 ) SELECT EVENT_TIME, ORGANIZATION_ID AS ORG_ID, WORKLOAD AS WORKLOAD, OPERATION AS OPERATION, USER_ID AS USER_ID, LOWER(SPLIT_PART(USER_ID , '@', 2)) AS USER_DOMAIN, RECORD_SPECIFIC_DETAILS:chat_thread_id AS CHAT_THREAD_ID, RECORD_SPECIFIC_DETAILS:communication_type AS COMMUNICATION_TYPE, RECORD_SPECIFIC_DETAILS:members[0].DisplayName AS MEMBER_DISPLAY_NAME_0, RECORD_SPECIFIC_DETAILS:members[0].UPN AS MEMBER_UPN_0, RECORD_SPECIFIC_DETAILS:members[0] AS MEMBERS_0, RECORD_SPECIFIC_DETAILS:members[1].DisplayName AS MEMBER_DISPLAY_NAME_2, RECORD_SPECIFIC_DETAILS:members[1].UPN AS MEMBER_UPN_2, RECORD_SPECIFIC_DETAILS:members[1] AS MEMBERS_2, RECORD_SPECIFIC_DETAILS:resource_tenant_id AS RESOURCE_TENANT_ID, RECORD_SPECIFIC_DETAILS, RAW:ClientIP AS CLIENT_IP FROM RAW.O365_AUDIT_LOGS WHERE 1=1 AND RECORD_SPECIFIC_DETAILS:communication_type = 'OneOnOne' AND ( RECORD_SPECIFIC_DETAILS:members[0].UPN IN (SELECT LATEST_EXT_USERS FROM LATEST_EXTERNAL_DOMAINS) OR RECORD_SPECIFIC_DETAILS:members[1].UPN IN (SELECT LATEST_EXT_USERS FROM LATEST_EXTERNAL_DOMAINS) ) AND USER_ID ILIKE '%' || $YOUR_DOMAIN_NAME || '%' AND OPERATION = 'MemberAdded' AND EVENT_TIME > CURRENT_TIMESTAMP - interval '50d';

• Logica di query approfondita: poiché questa query è un po' complessa, ecco una spiegazione della logica. Innanzitutto, utilizziamo la funzionalità "CTE" di Snowflake per costruire due viste:

  1. DOMINI COMUNEMENTE_UTILIZZATI:
     • Estraiamo i nomi di dominio dall'ID utente dividendo la stringa dopo '@'.
     • Conta tutti gli eventi generati da ciascun dominio negli ultimi 90 giorni
     • Mantieni i domini che hanno più di 20 eventi e considerali comuni. Puoi adattarli in base alle tue esigenze.
  2. ULTIMI_DOMINI_ESTERNI:
     • Filtra i domini interni e i domini comunemente utilizzati identificati nella vista precedente da tutti gli eventi degli ultimi 50 giorni
     • Esegui una query in tutti i domini che hanno più di 5 eventi che comportano l'invio di messaggi diretti e l'aggiunta di membri a Teams.

  Infine, recuperiamo informazioni dettagliate sull'utente e sul dominio associato interrogando i risultati filtrati da LATEST_EXTERNAL_DOMAINS.

  
  

Pepite di igiene

Abbiamo trattato gli aspetti di caccia e investigazione correlati alle molteplici tecniche di attacco utilizzate dall'attore. Alcuni di questi metodi e tecniche dannosi sono noti anche per essere utilizzati in diverse campagne.

Proteggere la tua organizzazione da queste minacce può ridurre significativamente il rischio di attacchi riusciti mirati a diverse parti dell'infrastruttura organizzativa.

Ecco alcuni accorgimenti igienici che puoi utilizzare per migliorare la tua sicurezza:

1. Per ridurre le probabilità di successo degli attacchi di phishing tramite Microsoft Teams, ecco alcuni passaggi che puoi seguire:
   • Di default, Microsoft Teams consente "Accesso esterno", che consente chat individuali con contatti esterni. Se non è essenziale per la tua organizzazione, valuta di disabilitare questa opzione.
   • Se è necessaria una comunicazione esterna, limitarla ai soli domini attendibili.
   • Un altro modo per comunicare con parti esterne in Microsoft Teams è aggiungerle come ospiti o membri. Consigliamo vivamente di limitare questa funzionalità, consentendo solo a utenti selezionati e con privilegi elevati di gestirla.
2. L'aumento degli attacchi informatici che utilizzano strumenti di amministrazione remota richiede chiare distinzioni tra strumenti utilizzati legittimamente e quelli sfruttati dagli attori delle minacce. Ecco alcune raccomandazioni:
   • Limita gli strumenti di amministrazione remota ad applicazioni specifiche e approvate, necessarie per scopi aziendali. Quick Assist è facilmente scaricabile da Microsoft Store; considera di bloccarne l'uso se non è nella whitelist della tua organizzazione. Puoi limitare l'accesso applicando misure come AppLocker, regole di Windows Firewall o gestione MDM.
   • Tieni traccia degli strumenti di gestione remota comunemente utilizzati e monitora eventuali strumenti di terze parti insoliti o non autorizzati. Ad esempio, se viene utilizzato Quick Assist e il tuo team IT non vi fa affidamento per il supporto remoto, dovrebbe attivare un allarme.
3. Formazione sulla consapevolezza della sicurezza: potrebbe sembrare un luogo comune, ma gli errori umani sono costantemente una delle principali cause del successo degli attacchi informatici. La formazione sulla consapevolezza della sicurezza può fare la differenza in questo senso, proteggendoti dalla prossima violazione.
   • Consigliamo di renderlo focalizzato e pertinente alle minacce viste in natura. Ad esempio, i casi di impersonificazione IT tramite piattaforme di comunicazione come Microsoft Teams, Slack o persino le classiche telefonate sono in aumento. Assicurati che i tuoi dipendenti sappiano come gestirli.

Conclusione

• VEILDrive unisce semplicità e sofisticatezza. È stato interessante assistere all'uso delle caratteristiche classiche di C2 in parallelo con C2 su OneDrive, nonché all'uso della classica persistenza basata su attività pianificate combinata con l'esecuzione di malware che un EDR di prim'ordine non rileva.

• Le caratteristiche identificate nell'ambito delle indagini e della ricerca sulle minacce sono state interessanti e ci hanno permesso di comprendere meglio come opera questo attore della minaccia, quali servizi noti sta abusando, come ne sta abusando e per quale scopo.

• Il modo in cui OneDrive è stato abusato per la comunicazione C2 in VEILDrive aveva caratteristiche uniche. Tuttavia, il concetto generale di abuso di OneDrive per scopi C2 è aumentato negli ultimi mesi, ed è qualcosa da tenere a mente.

• L'accesso iniziale tramite spear-phishing su piattaforme di comunicazione come Microsoft Teams, Slack e servizi simili è sempre più comune.

• Prevediamo che diventerà ancora più comune con il passare del tempo. Quindi, le misure di igiene e postura relative a questo aspetto (come menzionato nei Nuggets di igiene sopra) sono cruciali.

• Gli strumenti di amministrazione remota sono già molto popolari tra gli attori delle minacce. Si possono adottare diversi approcci per ridurre al minimo il potenziale di accesso non autorizzato tramite tali strumenti. Dal nostro punto di vista, l'approccio consigliato in quest'area è la whitelisting (allowlisting) combinata con un monitoraggio robusto.

• Prevediamo che emergeranno altre campagne di questa natura, che impiegano metodi e caratteristiche simili. Pertanto, si raccomanda vivamente un monitoraggio continuo e una ricerca proattiva delle minacce per questo tipo di minaccia.

  
  

Per rimanere aggiornati sulle ricerche, le attività e le domande sulla caccia alle minacce, seguite l'account X/Twitter del Team Axon ( @team__axon ).