Log4Shell - VMware Horizon

VMware Horizon (formerly called Horizon View) is a commercial desktop and app virtualization product developed by VMware, Inc for Microsoft Windows, Linux and macOS operating systems.

VMware Horizon provides virtual desktop and app capabilities to users utilizing VMware's virtualization technology. A desktop operating system - typically Microsoft Windows - runs within a virtual machine on a hypervisor. VMware Horizon product has a number of components which are required to provide the virtual desktops.

One of the component is Connection Server. This component is the connection broker that manages secure access to virtual desktops.

In the initial phase attackers send the crafted HTTP request with the embedded JNDI lookup path to a malicious RMI server. The Connection Server has the vulnerable log4j module that in turn send a request the attacker controlled RMI server. The response to the JRMI request contains the instructions to load the malicious class from attacker controlled server, part of the response looks like below.

The malicious class file in this case is 'RuntimeIinit' that's downloaded from the https server and loaded. The contents of the class file looks like below.

Analyzing the class file we can see that code has a large base64 encoded blob and there are certain hardcoded paths. The code does the following,

1. It creates a new file under path - "..\\broker\\webapps\\portal\\WEB-INF\\classes\\com\\vmware\\vdi\\installer\\listener\\ResourceAccessListener.class"
2. Decodes the base64 encoded data and writes it to the above file path
3. Replaces parts of web.xml, particularly "</listener-class>" to "</listener-class>\r\n      <listener-class>\r\n         com.vmware.vdi.installer.listener.ResourceAccessListener\r\n      </listener-class>"

The default contents of the web.xml (listener tags) looks like below.

The attacker also loads multiple other malicious class files using the log4shell exploit. The attacker atleast loaded 3 other class files to gather information about the target. Some of the other class files that were loaded were,

• DiaLocal.class
• Dialog.class
• LDAPAuthentication.class

The LDAPAuthentication.class file has code to extract information about

• Domain name
• Computer name
• Enumerated information from LDAP server
• Directory structure of 
• C:\Program Files
• C:\Program Files (x86)

We are yet to look at the encoded base64 blob. This base64 encoded blob is in reality a class file that gets written to "..\\broker\\webapps\\portal\\WEB-INF\\classes\\com\\vmware\\vdi\\installer\\listener\\ResourceAccessListener.class". Part of the decompiled version of the class file looks like below (only relevant code included),

Based on the cookie name (calculated using hash of userdomain & computer name which the attacker had already harvested using LDAPAuthentication.class or default hardcoded values) the assigned value can either be a full blown class file that gets loaded using ClassLoader or a malicious expression that gets executed using ScriptEngine.

Look out or block connections JRMI or LDAP requests that are bound to the internet from process "WS_TOMCATSERVICE.EXE". It probably can be a good indicator to find exploitation attempts. There are also multiple free scanner that can help find vulnerable instances of log4j on systems. Use them to find vulnerable systems and patch them ASAP.