Una versione dannosa dell’immagine ISO denominata Servicenow-BNM-Verify.iso è stata identificata su VirusTotal, segnalata come proveniente dalla Malesia con un livello di rilevamento praticamente nullo. All’interno dell’immagine sono presenti quattro file, di cui due visibili e due nascosti, un elemento che suggerisce un confezionamento studiato per ingannare le analisi superficiali.

Tra i file visibili spicca un collegamento di Windows chiamato servicenow-bnm-verify.lnk che avvia PanGpHip.exe, un eseguibile legittimo prodotto da Palo Alto Networks. Nonostante il percorso di destinazione del collegamento punti a una directory inesistente sulle macchine vittima, il file LNK rimanda correttamente alla propria directory, garantendo l’esecuzione di PanGpHip.exe ogni volta che l’ISO viene montata.

Il DLL sideloading è una tecnica usata dagli attaccanti in cui un programma legittimo carica, senza accorgersene, una libreria (DLL) malevola invece di quella autentica. Questo accade perché Windows, nel cercare la DLL richiesta, dà priorità a determinate cartelle (es. quella locale al programma), permettendo al malware di “camuffarsi” come file legittimo.

All’interno dell’ISO sono state trovate due librerie: la genuina OpenSSL identificata come libeay32.dll e una libreria dannosa chiamata libwaapi.dll, quest’ultima caricata lateralmente dall’eseguibile di Palo Alto e indicata come il fulcro dell’attacco.

Libwaapi.dll esporta una sola funzione contenente codice, wa_api_setup, che avvia il suo flusso operativo nascondendo la finestra della console tramite le API dell’interfaccia utente grafica di Windows.

La routine verifica la presenza di un mutex denominato 47c32025: se il mutex non è presente, viene richiamata una funzione interna, rinominata fn_payload_injection, che procede con l’iniezione del payload in memoria.

La funzione di iniezione calcola l’hash SHA-256 della stringa “rdfY*&689uuaijs” e usa il risultato come chiave RC4 per deoffuscare la stringa “chakra.dll”. Successivamente carica la DLL Windows legittima da C:WindowsSystem32, individua la prima sezione eseguibile, la rende scrivibile, azzera il suo contenuto e decodifica in base64 un payload nascosto memorizzato nella sezione .data della DLL.

Dopo la decrittografia con RC4 viene controllata l’integrità del payload tramite un valore SHA-256 codificato; se il controllo è superato, i permessi di memoria vengono ripristinati e l’esecuzione passa al payload iniettato.

Lo shellcode iniettato decomprime una DLL incorporata usando RtlDecompressBuffer con l’algoritmo LZNT1 a massima compressione. La DLL risultante reca un timestamp fabbricato del 5 maggio 1984 e implementa il comportamento dannoso nell’esportazione DllUnload. L’analisi iniziale indica che il modulo si sgancia in modo da eludere il rilevamento.

Il payload finale entra in un ciclo che trasmette i dati della vittima a logsapi.azurewebsites[.]net api logs, sfruttando Azure Functions come backend di comando e controllo. Viene inviato un payload in formato XML contenente metadati di sistema come architettura, tempo di attività, build del sistema operativo, nomi di computer e utenti, processi in esecuzione e altri dettagli. Sebbene le informazioni siano crittografate in transito, esse possono essere ottenute nella forma pre crittografata, rivelando l’intento dell’autore di profilare accuratamente gli host compromessi e l’abuso di un ambiente serverless scalabile basato su eventi.

Un elemento indicativo di una campagna, secondo un rapporto di Researcher, è l’apparizione su VirusTotal di una DLL simile proveniente da Singapore il 5 settembre 2025. Il deoffuscamento è in corso e mira a rivelare ulteriori capacità del payload; analisi di follow up esploreranno i meccanismi di persistenza e le routine di movimento laterale contenute in questa infrastruttura sofisticata supportata da Azure Functions.

L'articolo Azure Functions nel mirino: librerie legittime usate per il DLL Sideloading proviene da il blog della sicurezza informatica.