On November 8, 2023, SysAid published an advisory expressing that their on-premise server software had a previously undisclosed vulnerability and is aware of public in-the-wild exploitation. Days prior, Microsoft had notified SysAid of this issue and that they attributed these compromises to TA505 “Lace Tempest”, often known as the cl0p ransomware gang.
Huntress has investigated recent intrusions within our partner environments, notified impacted organizations, and recreated the attack chain with a proof-of-concept exploit to develop new detection capabilities for our managed security platform.
Currently, the latest version of SysAid Server 23.3.36 is the recommended patch and update that we strongly urge you to install as soon as possible.
This critical vulnerability has been designated with the identifier CVE-2023-47246. The adversary cl0p is the same threat actor who took advantage of the MOVEit Transfer software over Memorial Day weekend this year.
The Vulnerability
The original security bulletin from SysAid refers to this vulnerability as a “previously unknown path traversal vulnerability leading to code execution within the SysAid on-prem software.” The security bulletin does not include technical details for this vulnerability and how to exploit it, but does include technical indicators of compromise for the security issue.
Specifically, it references the potential for attackers to upload and access WAR file webshells and other payloads in the webroot of the SysAid Apache Tomcat web server. It also references the full path of a webshell that was located atC:\Program Files\SysAidServer\tomcat\webapps\usersfiles\ on a compromised server.
While the original writeup did not include any technical exploitation details, the Huntress Research Team has successfully created a fully weaponized proof of concept. Exploitation of this vulnerability is covered in more detail in the Exploitation Proof of Concept section of this blog post.
The Impact
Huntress is tracking only 14 servers across our partner base with the SysAid software installed. These servers are unfortunately running a wide range of different version numbers -- some as recent as 23.3.34, a handful in the yearly range of versions 16.x or 17.x and some as old as versions 7.5.0 and 7.0.0 (P.S. please update!)
We observed only one of these instances actively compromised with the zero-day exploit.
This organization was first impacted on October 30, where we observed the same post-exploitation PowerShell code executed as suggested in the SysAid advisory. Our detectors caught the unusual PowerShell invocation (a child process spawned under java.exe), but it was not clear until the public disclosure of CVE-2023-47246 that this was related to this threat.
At this time of exploitation, there were two pertinent PowerShell invocations -- the first Base64 decoded and deobfuscated event can be found here:
This matches the original stage described by SysAid and Profero:
- Store the filesystem paths for the Tomcat webapps root directory as well the adversary-created userfilesfolder as variables
- Enumerate running processes with tasklist, and use regular expressions to match any processes beginning with “Sophos” and including .exe present in the executable name
- If any processes matching this criteria are found, this PowerShell code removes artifacts exits, to avoid detection.
- It is worth noting that this code does not use its privilege to kill the process, it just simply stopped its routine.
- If no processes match this criteria, it invokes a user.exe file that the threat actor placed inside their userfiles staging directory.
- Notably, this includes a command-line argument and parameter of a 64-character hexadecimal string. We did not see this referenced in the SysAid or Profero writeup, but this is likely an identifying number for the victim, or a unique key used by the executable (GraceWire)
- Sleep for one second, and remove the userfiles.war stager and the user.exe artifacts
Following this, we observed the second snippet of PowerShell execution (Base64 decoded and beautified):
This stages more PowerShell to be executed inside of a multi-line string. It once again stores pertinent filesystem paths in variables, but then defines regular expressions to be used to remove evidence of exploitation. These $log4jPattern and $tcPattern variables include optional components to be matched within the SysAid Server log files or the Tomcat logs, which are then removed by the cleanLL function, removing any record entries with those strings.
While it may be a clever trick for the adversary to clean up their tracks, this also leaves some breadcrumbs that help explain how this exploit is executed. We will explore that further in the Exploitation Proof of Concept section below.
This log-cleaning code runs in a while loop after some sleep commands to ensure files are deleted, and then breaks out of the loop. Ultimately, this is all invoked by a classic Invoke-Expression cmdlet.
Attack Surface
A Shodan query for the default title of SysAid servers returns over 230 instances that are accessible on the public internet. A different Shodan query for any reference of SysAid in the HTML of the analyzed page returns just under 900 results.
While this does not prove exploitability for each of these public servers, it does show the prevalence of this technology on the internet. While these queries show that SysAid is not commonly exposed to the internet, it could be in some cases and we urge our readers to identify if their SysAid servers are publicly accessible.
Exploitation Proof of Concept
The Huntress Research team was able to create a weaponized proof of concept to exploit the path traversal and file write vulnerability. At this time, we are not releasing this proof of concept to the public.
The vulnerability exists in the doPost method within the SysAid com.ilient.server.UserEntry class. By injecting a path traversal into the accountID parameter and supplying a zlib compressed WAR file webshell as the POST request body, an attacker can control where this webshell is written on the vulnerable server. The attacker can then request the webshell by browsing to the URL where it now resides to gain access to the server.
The Huntress Research Team identified the vulnerable component by decompiling the Java class files and examining the patch differential between version 23.3.35 and 23.3.36. The latest version of the software contains the following check in the doPost method of the UserEntry class:
This new error message implies the existence of a path traversal vulnerability related to the a2 variable. This variable is built from the convertParameter variable, which itself is assigned from the accountID parameter of the POST request, as shown on line 385 in the following code snippet:
The accountID parameter constructs the path where the uploaded file will be written. By injecting this parameter with a path traversal, we can adjust where this file is written. On line 421, a new file is created at the location specified by the a2 string. Following the file creation, the bytes of the inflaterInputStream from the incoming POST request are written to this location:
By controlling the location of the file and the bytes that are written, we can write the bytes of a malicious WAR file to the web server’s root directory. We can then access this WAR file by browsing or requesting the URI of the WAR file to gain access to the server.
Our recreated proof of concept aligns with the observed indicators from the original bulletins by the Microsoft Threat Intelligence team and SysAid.
Huntress has added detections for the activity reported in this blog. If you’d like to have someone else watching your back while you work on patching, feel free to start a free trial with us so our 24/7 SOC can keep an eye out for you.
Special thanks to Matt Kiely, John Hammond, Caleb Stewart, Dave Kleinatland, Harlan Carvey, Joe Slowik, Matt Anderson, Jamie Levy and many others for their contributions to this writeup.
Indicators of Compromise
