TT-CSIRT – 451.13.09.25 – Malware Alert: Azure Function Abuse
Please be advised there has been a discovery of a highly evasive attack using a malicious ISO image named Servicenow-BNM-Verify.iso, containing four files, with two openly visible and two hidden. The visible files include a Windows shortcut, servicenow-bnm-verify.lnk, which launches PanGpHip.exe; a legitimate Palo Alto Networks binary. Hidden are libeay32.dll, a genuine OpenSSL library, and libwaapi.dll, a malicious DLL side-loaded by the Palo Alto executable. The low detection rate and use of trusted cloud infrastructure make this a significant threat.
Although the shortcut’s target path points to an “excluded” directory that does not exist on victim machines, the LNK file gracefully falls back to its own directory, ensuring PanGpHip.exe executes whenever the ISO is mounted.
Attack Method: DLL Side-Loading and Payload Injection
The core of the attack lies in the hidden libwaapi.dll. This library exports only one code-bearing function, wa_api_setup, which first hides the console window by invoking Windows GUI APIs.
It then checks for a mutex named 47c32025. If the mutex is absent, wa_api_setup calls a function we’ve renamed fn_payload_injection, which carries out in-memory payload injection.
That function computes the SHA-256 hash of the string “rdfY*&689uuaijs,” using the result as an RC4 key.
The string “chakra.dll,” is deobfuscated and loads the legitimate Windows DLL from C:\Windows\System32, locates its first executable section, makes it writable, zeros its contents, and base64-decodes a hidden payload stored in the DLL’s .data section.
After decrypting the data with RC4, it validates the payload’s integrity against a hard-coded SHA-256 value, once the check is passed, memory permissions are restored and execution transfers into the injected payload.
The injected shellcode unpacks an embedded DLL via RtlDecompressBuffer using the LZNT1 algorithm with maximum compression, with the resulting DLL bearing a fabricated timestamp of May 5, 1984, and implements its malicious behavior in its DllUnload export.
The module unhooks to evade detection and the final payload enters a loop that sends victim data to logsapi.azurewebsites[.]net/api/logs, hosting Azure Functions as its command and control backend.
Impact
By abusing Azure Functions, the threat actor leverages a scalable, serverless environment with event-driven triggers and bindings with the malware sending an XML-formatted payload containing system metadata—architecture, uptime, OS build, computer and user names, running process, and other details.
This information is encrypted before transit but can be captured in its pre-encryption form, revealing the actor’s intent to profile compromised hosts precisely.
Defence and Detection
The following are recommended defence and detection strategies:
- SSL/TLS Inspection: Decrypt and inspect HTTPS traffic, allowing for the detection of malicious C2 communication hidden within encrypted traffic.
- Cloud Application Security Broker (CASB): Use tools like Microsoft Defender for Cloud Apps to monitor for suspicious activity within sanctioned cloud services.
- Network Level: Block traffic to the known malicious domain logsapi.azurewebsites[.]net at your network perimeter.
- Endpoint Level: Deploy IOC blocks to prevent execution of files with the specified hashes and alert on the presence of the filenames, particularly libwaapi.dll alongside PanGpHip.exe. Tune EDR rules to detect and alert on DLL side-loading patterns, specifically processes loading DLLs from unusual, writable paths.
- Log Analysis: Audit logs from proxies and firewalls for anomalous patterns to Azure Functions, such as:
- Connections to newly created or rarely seen Azure Function URLs.
- Connections to Azure Functions from non-developer workstations suddenly talking to an Azure Function API.
References
