[This is a Guest Diary by Jean-Luc Hurier, an ISC intern as part of the SANS.edu BACS program]

Background

In April 2020, at the height of the global pandemic, virtualization was in high demand.  During that time, vSphere 7.0 was released. With that release, had two unknown vulnerabilities – a match made in heaven for threat actors. It wasn’t until June 2024 that China’s TZL security researchers revealed CVE-2024-38812 and CVE-2024-38813 at China’s 2024 Matrix Cup – a hacking contest.  Since then, both vulnerabilities were published and patched in September, however one of those patches required a hotfix just a month later (CVE-2024-38812).

Findings

The reason that this is a topic of conversation is because I noticed an intermittent pattern of reconnaissance of possible vSphere related web traffic over the course of the last 3.5 months.

On the surface, this is part of any other automated scan. They cover a lot of ground, probing for openings, vulnerabilities, etc. The URI /sdk stands out because it is a known endpoint for vSphere SOAP APIs. This could be a coincidence, but what I did notice is a slight uptick in scanning for that endpoint starting 9/18/2024. This is notably interesting due to the fact of CVE-2024-33812 and CVE-2024-33813 being public on 9/17/2024.

This activity spanned across 22 not-so-reputable IPs from providers based in USA, Germany, and Spain – most of which are associated to DigitalOcean. For /sdk: since the POST request content-length was short and included text/plain content, then the assumption is that the activity is merely looking for the existence of vSphere. The same can be said for /webui, which can be tied to vSphere’s legacy web client, which indicates an interest in older endpoints (and older vulnerabilities). The rare case of /ui/authentication GET requests also indicates probing instead of actual attempts of an exploit.  The IPs didn’t solely scan for vSphere endpoints – they also targeted other exposed management interfaces, web portals, configuration files, and source-code repositories. Analysis of other vSphere endpoints did not yield any other indicators.  

An interesting artifact of note is the use of User-Agent string related to Odin – an “AI” powered scanner to catalog internet assets.

While there is no public proof of concept, this activity piqued my interest – especially as it relates to a very recent post (11/18/2024) by Broadcom stating, “Updated advisory to note that VMware by Broadcom confirmed that exploitation has occurred in the wild for CVE-2024-38812 and CVE-2024-38813” [2].

Theory

My theory is that the vulnerabilities hedge on the existence of Platform Services Controller (PSC) introduced in v7.0 of the vCenter server appliance [8].  With the introduction of the PSC as an integrated service, backend processes such as authentication, token management, and inter-component communication began relying heavily on the DCERPC protocol. In a hypothetical break-in using CVE-2024-38812/13, an attacker could target either /ui/authentication (authentication workflows) or /sdk (SOAP API requests) to exploit these vulnerabilities. By sending a specially crafted request to either endpoint, CVE-2024-38812 (Heap Overflow) could be triggered in DCERPC, granting unauthorized RCE within the PSC environment. Once initial access is achieved, the attacker could exploit CVE-2024-38813 (Memory Corruption) through escalated API calls to /sdk, allowing privilege escalation and persistence. This chain would enable complete compromise of the vSphere environment, leveraging PSC’s central role in v7.0+ systems. A game of hypotheticals.

Even though there is technically not a public POC, the concept of heap overflow for this activity is well documented by SonicWall’s Capture Labs Threat Research Team [3]. There have been some POCs for sale on GitHub since October.  While mere reconnaissance isn’t enough to single out vulnerability specific probing, it does give us some insight into the threat landscape.
Simply put, CVE-2024-38812 provides initial access via heap-overflow vulnerability in VMware vCenter Server that enables unauthenticated remote code execution. CVE-2024-38813, a privilege escalation flaw, allows attackers to expand their control and maintain persistence. Together, these vulnerabilities create a "vulnerability symbiosis”.

Conclusion

Interestingly, the source IPs were organizationally tied to the likes of DigitalOcean, OVH SAS, and NextGenWebs; DigitalOcean being a popular choice in the near past regarding Volt Typhoon [6]. I cannot say for certain that this is coincidence since it is somewhat popular for TAs. What is apparent is that attacker interest in mapping publicly accessible vSphere endpoints is steadily on the rise. While this is a relatively “new” disclosure, research into these vulnerabilities has also led me down the path of what-ifs. After all, the vulnerable versions were vCenter Server 7.0 (released April 2020), and vCenter Server 8.0 (released October 2022) ...only a 4.5-year-old vulnerability. In addition to that, as stated earlier, this unknown vulnerability duo was originally disclosed from Chinese security researchers in June 2024. In the game of nation states, then you know what that means [6].

What now?  Patch vCenter to the latest possible versions, await a working POC to document artifacts, hunt for suspicious behavior, and create new detections to match.  Just like Log4J, attackers will continue to find new ways to outmaneuver patching and detections.  Continue to monitor and defend.  Happy hunting.

References
[1] https://www.bleepingcomputer.com/news/security/critical-rce-bug-in-vmware-vcenter-server-now-exploited-in-attacks/
[2] https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24968
[3] https://www.sonicwall.com/blog/vmware-vcenter-server-cve-2024-38812-dcerpc-vulnerability
[4] https://www.bleepingcomputer.com/news/security/vmware-fixes-bad-patch-for-critical-vcenter-server-rce-flaw/
[5] https://www.securityweek.com/vmware-struggles-to-fix-flaw-exploited-at-chinese-hacking-contest/
[6] https://www.scworld.com/analysis/stats-say-chinese-researchers-are-not-deterred-by-chinas-vulnerability-law
[7] https://www.wired.com/story/china-vulnerability-disclosure-law/
[8] https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenter.configuration.doc/GUID-135F2607-DA51-47A5-BB7A-56AD141113D4.html
[9] https://www.sans.edu/cyber-security-programs/bachelors-degree/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu