Rapid7 is investigating two separate events affecting Fortinet firewall customers:
Zero-day exploitation of CVE-2024-55591, an authentication bypass vulnerability in FortiOS and FortiProxy disclosed earlier this week. Successful exploitation could allow remote attackers to gain super-admin privileges via crafted requests to the Node.js websocket module.
A January 15, 2025 dark web post from a threat actor who looks to have published IPs, passwords, and configuration data from 15,000 FortiGate firewalls. The data leaked online appears to be several years old (2022). Rapid7 has not attributed any CVEs to the leaked data at this time.
FortiGate data leak
On Wednesday, January 15, 2025, a threat actor named “Belsen Group” published a trove of Fortinet FortiGate firewall data on the dark web, allegedly from 15,000 organizations. The data released included IP addresses, passwords, and firewall configuration information — a potentially significant risk for organizations whose data was leaked.
Security researcher Kevin Beaumont has an initial analysis of the leaked data, along with his assessment that the data leaked this week appears to be from 2022. After conducting our own outreach to potentially affected organizations, Rapid7 has also confirmed that at least some of the leaked data originated from 2022 incidents where customer firewalls were compromised. Based on Beaumont’s analysis and observations from our own investigations, it’s likely that the data dump published by the threat actor contains primarily or entirely older data.
Rapid7 has not attributed the data leak to a specific CVE at this time. Beaumont said his observations from incident responses indicate that CVE-2022-40684 (a Fortinet firewall zero-day flaw from 2022) may have been the initial access vector that allowed for the large-scale firewall data leak.
New Fortinet zero-day CVE also exploited in the wild
Separately, on Tuesday, January 14, 2025, Fortinet disclosed CVE-2024-55591, a new zero-day vulnerability affecting FortiOS and FortiProxy. Security firm Arctic Wolf had previously published a blog on threat activity targeting Fortinet firewall management interfaces exposed to the public internet, saying that “a zero-day vulnerability is likely” but an initial access vector had not been confirmed. According to Arctic Wolf, the campaign “involved unauthorized administrative logins on management interfaces of firewalls, creation of new accounts, SSL VPN authentication through those accounts, and various other configuration changes.”
Fortinet’s advisory for CVE-2024-55591 includes indicators of compromise (IOCs) and notes that the vulnerability was reported as exploited in the wild at time of disclosure. No individual or firm is explicitly credited for discovering the vulnerability in Fortinet’s advisory, and Fortinet has not confirmed that CVE-2024-55591 is the zero-day vulnerability Arctic Wolf speculated was being leveraged threat activity.
Rapid7 MDR threat hunters have observed activity from IP addresses publicly attributed to the threat campaign targeting CVE-2024-55591, but our team has so far only noted connections consistent with scanning or reconnaissance activity and not exploitation.
Zero-day vulnerabilities in Fortinet FortiOS, the operating system that runs on FortiGate firewalls, have been a relatively common occurrence in recent years and have been leveraged in a wide range of financially motivated, state-sponsored, and other attacks. In addition to CVE-2024-55591, prominent FortiOS zero-day flaws have included:
CVE-2018-13379, while not a zero-day, was disclosed in 2019 and allowed attackers to download SSL-VPN system files and steal credentials. It was consistentlyexploited in the years following disclosure despite a wide range of warnings and publicly available information on known threat activity.
Like CVE-2022-40684, CVE-2024-55591 is an authentication bypass using an alternate path or channel (CWE-288). While it does not currently appear likely that CVE-2024-55591 is the vulnerability that enabled the collection and release of FortiGate firewall configuration data on January 15, 2025, the vulnerability is nevertheless being exploited in the wild and should be treated with urgency.
Mitigation guidance
According to Fortinet’s advisory, the following products and versions are vulnerable to CVE-2024-55591:
Fortinet FortiOS 7.0.0 through 7.0.16 (fixed in 7.0.17 or above)
Fortinet FortiProxy 7.2.0 through 7.2.12 (fixed in 7.2.13 or above)
Fortinet FortiProxy 7.0.0 through 7.0.19 (fixed in 7.0.20 or above)
Per Fortinet, other versions of FortiOS (6.4, 7.2, 7.4, 7.6) and FortiProxy (2.0, 7.4, 7.6) are not affected. Customers should update to a fixed version immediately, without waiting for a regular patch cycle to occur, and review Fortinet’s IOCs to aid investigations into suspicious activity. Indicators include examples of administrative or local users added by adversaries.
Customers should also ensure that firewall management interfaces are not exposed to the public internet and limit IP addresses that can reach administrative interfaces. If your organization was impacted by the January 15, 2025 FortiGate firewall data leak, you should change administrative and local user passwords immediately. FortiOS also supports multi-factor authentication (MFA) for local user accounts, which Rapid7 strongly recommends implementing.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to CVE-2024-55591 with vulnerability checks available in the January 15, 2025 content release. Customers already have coverage for all other FortiOS vulnerabilities mentioned in this blog from past content releases.
Many thanks to Rapid7 MDR and incident response teams for their contributions to this analysis.
While investigating incidents related to Cleo software exploitation, Rapid7 Labs and MDR observed a novel, multi-stage attack that deploys an encoded Java Archive (JAR) payload. Our investigation revealed that the JAR file was part of a modular, Java-based Remote Access Trojan (RAT) system. This RAT facilitated system reconnaissance, file exfiltration, command execution, and encrypted communication with the attacker’s command-and-control (C2) server. Its modular architecture includes components for dynamic decryption, network management, and staged data transfer.
It’s worthwhile to note that this isn’t necessarily the only payload that has or will be deployed in attacks targeting Cleo software — it’s entirely possible an alternate payload could be leveraged. This underscores the importance of timely detection and response capabilities, as well as the critical role of monitoring assets that may be impacted by unknown zero-day threats.
At a high level, the attack flow can be visualized like so:
As Huntress pointed out in their blog on this threat campaign, part of the attack chain involves uploading and executing an XML file as part of a ZIP. When analyzing the XML file that contains the PowerShell code, we looked at the code to understand how the code would trigger in line with the known CVE (CVE-2024-50623) and the new CVE (still pending) for the unauthenticated malicious hosts vulnerability in Cleo software.
The XML snippet appears to define a "Host" and "Mailbox" configuration in Cleo Integration Suite (e.g., Harmony, VLTrader, or LexiCom). Cleo software often uses XML-based configuration files for trading partner setups, hosts, mailboxes, and scheduled actions or commands. Each <Host> element represents a communication endpoint, and each <Mailbox> often represents a sub-endpoint or logical folder.
The <Action> elements define which tasks (commands, scripts, or transfers) should be performed. Looking at the code of our XML, we observed a suspicious element.
Under <Mailbox> there is an <Action> element with actiontype="Commands". Inside this action, there's a <Commands> tag that runs:
SYSTEM cmd.exe /c "powershell -NonInteractive -EncodedCommand <base64_data>" > webserver/temp/webserver-<GUID>.swp
The <Commands> directive is invoking cmd.exe which runs PowerShell with an encoded command. The command is outputting to a .swp file, possibly to hide or store results locally.
By embedding this script within the <Action> element of the XML, if the CLEO system imports this configuration and executes the defined action by combining the vulnerability mentioned in CVE-2024-50623, the malicious code will run on the server. This could completely compromise the system running CLEO, given that CLEO often runs with significant privileges and access to internal systems and file shares.
Analyzing the malicious PowerShell script content
The script in question was originally invoked as remote code execution (RCE) during suspected CVE-2024-50623 exploitation:
This is a common technique used by attackers to obfuscate their malicious code. Decoding the Base64 string reveals a PowerShell snippet that:
Establishes a TCP connection to a suspicious external host (185.181.230.103) on port 443. (See additional external host indicators in the IOCs section.)
Retrieves and decrypts data from the remote server using a custom XOR-based routine.
Writes the decrypted output as a JAR file named cleo.2853.
Executes the malicious JAR using the embedded Java runtime of Cleo LexiCom (jre\bin\java.exe -jar cleo.2853).
Step-by-step analysis
Network connection setup The script begins by creating a Net.Sockets.TcpClient object and connecting it to the remote server:
A StreamWriter $w is then created, allowing the script to send initial data to the server. The malware sends the “TLS v3 <string.>” and processes the response. This serves as a form of handshake or protocol initialization.
2. XOR decryption setup Before reading any payload from the server, the script sets up key variables for decrypting data:
It continuously reads data from the remote server into $a.
For each byte, it calculates an index $j into $k (cycling through the key bytes).
It XORs the received byte with $k[$j] and a running state variable $g.
$g and $k[$j] evolve dynamically, meaning the key changes with every byte processed, making static detection harder.
Decrypted bytes are then written directly into the file cleo.2853.
The number behind the “cleo.*” differs in the cases we observed. By the end of this loop, the attacker’s encrypted payload is stored locally as a decrypted file.
4. Final steps: Executing the malicious JAR After fetching and decrypting the data, the script closes all streams and sets some environment variables:
The $env:QUERY variable appears to include additional IP addresses and contains the AES key used to decrypt the next stage and the string to send to the C2 server to receive the next payload. Finally, the script runs the malicious JAR file:
This leverages the Cleo environment’s embedded Java runtime. Since Cleo’s file transfer products come bundled with their own Java environment, the attackers don’t need to rely on a system-wide installation — they can simply run their malicious JAR directly. In one of our IR cases, the “cleo.xxxx” file was written to the C:\VLTrader\ directory.
Inside the JAR file The core functionality revolves around a custom class loader named "start".
Instead of loading classes from the file system, this loader accepts a byte array representing a compressed archive of class files. It then extracts each entry and stores them in a map, ready to be defined as Java classes on demand.
What does this custom class loader do?
Extracts classes from a byte array: The constructor of the start class takes a byte array (like a JAR) and reads the class using a ZipInputStream. Each entry is unpacked and stored in a map keyed by the entry name. For example:
ZipInputStream zis = new ZipInputStream(new ByteArrayInputStream(byteArray));
ZipEntry entry;
while ((entry = zis.getNextEntry()) != null) {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
int read;
while ((read = zis.read(buffer)) > 0) {
bos.write(buffer, 0, read);
}
cs.put(entry.getName(), bos.toByteArray());
}
Defining Classes at Runtime: Later, when a class is requested, the findClass method checks the map. If found, it uses defineClass to load that class directly from the in-memory bytes:
if (cs.containsKey(className)) {
byte[] classData = (byte[]) cs.get(className);
return defineClass(className, classData, 0, classData.length);
2. Fetches and decrypts class data remotely. The main method doesn’t just run local code — it also does the following:
Reads configuration and keys from environment variables.
Connects to a remote host over port 443 and sends a "TLS v3" handshake-like message.
Receives encrypted data, which it then decrypts using AES keys derived from the environment-provided values.
Once decrypted, this data is treated like a JAR file, passed into a new start instance, and thus new classes are loaded at runtime.
3. Executes a specific class (Cli): With the new classes loaded, the code uses reflection to instantiate a particular class named "Cli" and invoke its constructor.
This mechanism allows the JAR to remain small and stealthy, as it doesn't contain all its logic up front. Instead, it fetches critical code at runtime, decrypts it, and executes it dynamically. But it didn't stop here — after executing this first JAR file, which acts as a loader, it downloads a zip file that contains multiple JAR files:
File name
MD5
Cli
fa0ffca3597af31fc196ca27283aa038
Dwn
510a7fa9d425f1c3a38ad81d813b3f17
DwnLevel
7dcaffc9c26fe9e08e9b66e05c644cfc
Mos
ee7acd7a8a5795308942f094c950de6f
Proc
37a761f4d02577cf6789676f87cb9fc6
ScSlot
6ff85e7bec211869073b969dbd10c8eb
SFile
ca3de6f055f94acc87c6d335d9cc5c04
Slot
d924ffd1f2952a03da29c0a7a33e6a54
SrvSlot
bcc1bf75e0be3efabbd616cc8cfa8c35
Overall this is how the modules work together and what their function is:
The Cli class appears to be a key component of a remote backdoor mechanism. On startup, it determines the operating system and sets flags accordingly before attempting to connect to a remote host over port 443 using Java’s non-blocking I/O. Once connected, it can manage data streams via asynchronous event loops, handle received data, and potentially issue commands. After initialization, the code instructs the system to delete its own initial file to remove evidence of its presence.
In Rapid7 MDR investigations into exploitation of Cleo software, we observed commands being executed that we would categorize as reconnaissance attempts.
The DWN class appears to facilitate the packaging and transmission of files from the local system to a remote server. It assembles files (and directories) into a ZIP archive on the fly, splitting them into multiple ZIP chunks if they exceed a certain size threshold. Using a SrvSlot reference, it sends compressed file data over a network channel, carefully managing buffers and limiting throughput to avoid overwhelming the connection. The code iterates through directories, queues files, and processes them incrementally, updating statistics and retrying if conditions are not ideal. Through this mechanism, this class effectively automates and streamlines the mass transfer of local files, hinting at a data exfiltration or remote backup process. It’s designed to run quietly in the background, handle large file sets, and provide periodic progress updates to its server counterpart.
The DwnLevel class is a simple helper structure that represents a single level in a file traversal hierarchy. It holds an array of file objects, along with an index and a state variable to track the current processing position. As the Dwn class iterates through directories, the DwnLevel Java class instance keeps track of which files have been processed and which remain, helping the file packaging and transfer process proceed smoothly through potentially nested directories.
The Mos class acts as a custom output stream for sending ZIP data through Dwn. Instead of writing to disk, it buffers data in memory, attaches metadata like the job ID and packet offsets, and then hands the chunks off to Dwn to send out. This setup allows code that writes ZIP entries to operate as if it were writing to a normal output stream, while the Mos and Dwn classes handle the network transmission details behind the scenes.
Proc is a thread that runs external commands on the system, captures their output, and sends it back through SrvSlot. It can launch interactive shells, parse configuration files, and handle input given before the process starts.
In the code of this class, we also can discover that it is cross platform designed, either executing a cmd (Windows) or bash (*nix) shell:
ScSlot manages a network connection for a specific channel. It handles connecting, reading data, and relaying it to the SrvSlot class. If the connection fails or no data is received, it signals the server to close the channel. Its tick method processes incoming data in chunks to ensure smooth communication.
The SFile class handles file reading and writing operations. It can both read from an existing file or write to a new file, depending on the flags provided. The class tracks the file size, saved size and handles errors by setting status messages.
The Slot class manages the network connection using the Java network IO class. It handles connecting, reading, and writing, ensuring a smooth data transfer.
Last but not least, since it is a core component of this Java RAT, is the SrvSlot class. It interacts with other classes as described before and is the central node for handling encrypted communications and data transfer — it handles the ZIP transfer traffic. Besides traffic handling, a small component in the code of this class appears to be for debugging purposes (i.e., providing diagnostics and session statistics).
Overall this set of Java classes provide a modular multi-stage system (Java-RAT) designed to communicate with a C2, has file-transfer and management functionality, can execute commands and applies packet level encryption/decryption.
In multiple attack chains, after initial exploitation, the adversary executed the following enumeration commands via cmd to gather user, group and system information from the impacted system and display domain trust relationships.
systeminfo
net group /domain
whoami
wmic logicaldisk get name,size
nltest /domain_trusts
Rapid7 also observed post-exploitation activity in the form of an "OverPass-The-Hash" attack, in which the adversary leverages the NTLM hash of an account to obtain a Kerberos ticket that can be used to access additional network resources within the impacted environment.
MITRE ATT&CK Enterprise Techniques
Initial access
Exploit Public-Facing Application (T1190)
Execution
Command and Scripting Interpreter (T1059)
Discovery
System Owner/User Discovery (T1033)
System Information Discovery (T1082)
Domain Trust Discovery (T1482)
Permission Groups Discovery (T1069)
Lateral movement
Use Alternate Authentication Material: Pass the Hash (T1550/002)
On Monday, December 9, multiple security firms began privately circulating reports of in-the-wild exploitation targeting Cleo file transfer software. Late the evening of December 9, security firm Huntress published a blog on active exploitation of three different Cleo products (docs):
Cleo VLTrader, a server-side solution for “mid-enterprise organizations”
Cleo Harmony, which provides file transfer capabilities for “large enterprises”
Cleo LexiCom, a desktop-based client for communication with major trading networks
Huntress’s blog says the exploitation they’re seeing across Cleo products results from an insufficient patch for CVE-2024-50623, a vulnerability disclosed in Cleo VLTrader, Cleo Harmony, and Cleo LexiCom in October 2024. Cleo indicated that the vulnerability was fixed in version 5.8.0.21 of all three solutions, but according to Huntress, 5.8.0.21 remains vulnerable to exploitation. CVE-2024-50623 is a cross-site scripting issue (CWE-79) that allows for unauthenticated remote code execution on target systems.
Update: Cleo evidently communicated with customers on December 10 acknowledging a "critical vulnerability in Cleo Harmony, VLTrader, and LexiCom that could allow an unauthenticated user to import and execute arbitrary bash or PowerShell commands on the host system by leveraging the default settings of the Autorun directory."
As of December 10, Rapid7 MDR has confirmed successful exploitation of this issue in customer environments; similar to Huntress, our team has observed enumeration and post-exploitation activity and is investigating multiple incidents.
File transfer software continues to be a target for adversaries, and for financially motivated threat actors in particular. Rapid7 recommends taking emergency action to mitigate risk related to this threat.
Mitigation guidance
The following products and versions are vulnerable to CVE-2024-50623. The information below contradicts previous vendor guidance, which indicated that 5.8.0.21 resolved the issue. Cleo has updated their advisory as of December 10, 2024 to confirm 5.8.0.21 is still vulnerable.
Cleo Harmony before and including version 5.8.0.21
Cleo VLTrader before and including version 5.8.0.21
Cleo LexiCom before and including version 5.8.0.21
According to Huntress, “Cleo is preparing a new CVE designation and expects a new patch to be released mid-week.”
In the absence of an effective patch for CVE-2024-50623 (and any other CVEs that may be assigned to this exploit), Cleo customers should remove affected products from the public internet, ensuring they are behind a firewall. Per Huntress’s investigation, disabling Cleo’s Autorun Directory, which allows command files to be automatically processed, may also prevent the latter part of the attack chain from being executed.
Huntress’s blog has several descriptions of post-exploitation activity, including attack chain artifacts, commands run, and files dropped for persistence. Rapid7 recommends that affected customers review these indicators and investigate their environments for suspicious activity dating back to at least December 3, 2024.
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2024-50623 on Windows with an authenticated vulnerability check expected to be available in today’s (Tuesday, December 10) content release. Please note that content releases are typically available late in the evening ET on Patch Tuesday.
InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of rules deployed and alerting on behavior related to this threat:
Suspicious Process - XORed Data in PowerShell
Suspicious Process - PowerShell System.Net.Sockets.TcpClient
Attacker Behavior - Possible Cleo MFT Exploitation 2024
Beginning in early October, Rapid7 has observed a resurgence of activity related to the ongoing social engineering campaign being conducted by Black Basta ransomware operators. Rapid7 initially reported the discovery of the novel social engineering campaign back in May, 2024, followed by an update in August 2024, when the operators updated their tactics and malware payloads and began sending lures via Microsoft Teams. Now, the procedures followed by the threat actors in the early stages of the social engineering attacks have been refined again, with new malware payloads, improved delivery, and increased defense evasion.
Overview
The social engineering attacks are still initiated in a similar manner. Users within the target environment will be email bombed by the threat actor, which is often achieved by signing up the user’s email to numerous mailing lists simultaneously. After the email bomb, the threat actor will reach out to the impacted users. Rapid7 has observed the initial contact still occurs primarily through usage of Microsoft Teams, by which the threat actor, as an external user, will attempt to call or message the impacted user to offer assistance. The account domains in use include both Azure/Entra tenant subdomains (e.g., username[@]tenantsubdomain[.]onmicrosoft[.]com) and custom domains (e.g., username[@]cofincafe[.]com).
In many cases, Rapid7 has observed that the threat actor will pretend to be a member of the target organization’s help desk, support team, or otherwise present themself as IT staff. Below are examples of Microsoft Teams display names observed, by Rapid7, to be in use by operators. The display names may or may not be padded with whitespace characters. Rapid7 has also observed threat actors use a first and last name, as the chat display name and/or account username, to impersonate an IT staff member within the targeted organization.
Operator Chat Display Name
Help Desk
HELP DESK
Help Desk Manager
Technical Support
Administracion
If the user interacts with the lure, either by answering the call or messaging back, the threat actor will attempt to get the user to install or execute a remote management (RMM) tool, including, but not limited to, QuickAssist, AnyDesk, TeamViewer, Level, or ScreenConnect. Rapid7 has also observed attempts to leverage the OpenSSH client, a native Windows utility, to establish a reverse shell. In at least one instance, the threat actor shared a QR code with the targeted user. The purpose of the QR code is unconfirmed but appears to be an attempt to bypass MFA after stealing a user’s credentials. The URL embedded within the QR code adheres to the following format: hxxps://<company_name>[.]qr-<letter><number>[.]com.
Figure 1. A QR code (obfuscation by Rapid7) sent by an operator.
In a majority of cases, Rapid7 has observed that the operator, after gaining access to the user’s asset via RMM tool, will then attempt to download and execute additional malware payloads. In one case handled by Rapid7, the operator requested more time — potentially to hand off the access to another member of the group.
Figure 2. An operator stalls for time.
The payload delivery methods vary per case, but have included external compromised SharePoint instances, common file sharing websites, servers rented through hosting providers, or even direct upload to the compromised asset in the case of RMM tool remote control. In one case, the operator used the group’s custom credential harvester to dump the user’s credentials, the results for which were subsequently uploaded to a file sharing site — publicly exposing the stolen credentials. SharePoint has been used to distribute copies of AnyDesk portable, likely to circumvent security measures that would prevent the user from downloading it directly from anydesk[.]com. Such attempts have been blocked by web proxy in previous cases.
The overall goal following initial access appears to be the same: to quickly enumerate the environment and dump the user’s credentials. When possible, operators will also still attempt to steal any available VPN configuration files. With the user’s credentials, organization VPN information, and potential MFA bypass, it may be possible for them to authenticate directly to the target environment.
Rapid7 has observed usage of the same credential harvesting executable, previously reported as AntiSpam.exe, though it is now delivered in the form of a DLL and most commonly executed via rundll32.exe. Whereas before it was an unobfuscated .NET executable, the program is now commonly contained within a compiled 64-bit DLL loader. Rapid7 has analyzed at least one sample that has also been obfuscated using the group’s custom packer. The newest versions of the credential harvester now save output to the file 123.txt in the user’s %TEMP% directory, an update from the previous qwertyuio.txt file, though versions of the DLL distributed earlier in the campaign would still output to the previous file.
Figure 3. The credential harvesting prompt shown to the user upon executing the DLL (redaction by Rapid7).
The credential harvester is most commonly followed by the execution of a loader such as Zbot (a.k.a. Zloader) or DarkGate. This can then serve as a gateway to the execution of subsequent payloads in memory, facilitate data theft, or otherwise perform malicious actions. Rapid7 has also observed operators distributing alternate payload archives containing Cobalt Strike beacon loaders and a pair of Java payloads containing a user credential harvester variant and a custom multi-threaded beacon by which to remotely execute PowerShell commands. In some cases, operators have sent the user a short command, via Teams, which will then begin an infection chain after execution by the targeted user.
Rapid7 continues to observe inconsistent usage of the group’s custom packer to deliver various malware payloads, including their custom credential harvester. A YARA rule is now publicly available that can be used to detect the packer. For example, this packer was used to deliver several obfuscated versions of Black Basta ransomware, obtained via open source intelligence, which directly links operators to the ongoing social engineering campaign.
At the time of writing, the threat actors behind the campaign continue to update both their strategy for gaining initial access and the tools subsequently used. For example, around the time the most recent campaign activity began, Rapid7 observed the delivery of a timestamped and versioned payload archive, 171024_V1US.zip (2024-10-17, version 1, US), which, when compared to a more recently delivered archive, 171124_V15.zip (2024-11-17, version 15), highlights the rapid iteration being undertaken. Many of the payloads being delivered follow a similar pattern as previous activity and often consist of a legitimate file where an export or function entry point has been overwritten to jump to malicious code, and the result is signed with a likely stolen code signing certificate.
Intrusions related to the campaign should be taken seriously — the intent goes beyond typical phishing activity. Past campaign activity has led to the deployment of Black Basta ransomware. While Rapid7 has handled a high volume of incidents related to the current social engineering campaign across a variety of customer environments, to date, every case has been contained before the operator was able to move laterally beyond the targeted user’s asset.
Technical Analysis
Initial Access
Each attack is preceded by the targeted user receiving an often overwhelming amount of emails. An operator will then attempt to contact the user via Microsoft Teams, either via messaging or calling, by which they will pretend to offer assistance. Operators will attempt to impersonate the organization’s help desk, such as using the names of existing staff members.
During this social engineering stage, operators often need to troubleshoot with the user to establish remote control of the user’s asset. Based on the environment, for example, RMM tool downloads or execution may be blocked (often some, but not all) or QuickAssist may be disabled, causing the operator to cycle through their options at establishing a foothold. One of the most common first steps after gaining either the confidence of the user, or remote access, is to execute a custom credential harvester.
Credential Harvesting
The credential harvester used by operators, for example SafeStore.dll (SHA256: 3B7E06F1CCAA207DC331AFD6F91E284FEC4B826C3C427DFFD0432FDC48D55176), is an updated version of the previously analyzed program AntiSpam.exe. The DLL variant of the credential harvester is executed by a command like the following example:
rundll32.exe SafeStore.dll,epaas_request_clone
The module will quickly execute three enumeration commands to gather system information — systeminfo, route print, ipconfig /all — and then prompt the user for their password. The user’s credentials are appended onto a new line of the text file 123.txt with each attempt, after the enumeration command output, regardless of whether the credentials are correct. If the user enters the wrong password, they will be prompted to try again. The output for the enumeration commands and the user’s credentials were saved to the file qwertyuio.txt in older versions of the harvester, but are now saved to 123.txt, within the user’s %TEMP% directory. The enumeration commands within the updated version are executed via successive calls to CreateProcessA.
Figure 4. Success and failure messages for the credential harvester.
Based on analysis of one credential harvester sample, EventCloud.dll, the program was present in shellcode form. The shellcode is decrypted from the Cursor Group 880 resource embedded within the executable, using the XOR key 5A 3C 77 6E 33 30 4D 38 4F 38 40 78 41 58 51 30 42 5F 3F 67 71 00, and then injected locally. The following strings which were extracted from the shellcode show the output file and list dynamically loaded libraries:
Credential Harvester Strings
-
-
-
-
cmd.exe /c
%s%s
%s%s%s%s
123.txt
ooki
Update
filter kb_outl
Need credentials to update...
Username:
Password:
ntdll.dll
Gdi32.dll
user32.dll
msvcrt.dll
ucrtbase.dll
Comctl32.dll
Advapi32.dll
kernel32.dll
-
-
The Java variant of the credential harvester, identity.jar, provides a similar prompt to the user, though when a password is entered it is appended, without the username, to a .txt file with a random 10-letter alphabetic name to the current working directory. The cancel button on the prompt, shown below, is not functional and the prompt is drawn on top of other windows, meaning that it will not close until the user has entered their password correctly.
Figure 5. The credential harvesting prompt created by `identity.jar`.
Malware Payloads
Following execution of a credential harvester, an operator will typically infect the asset with Zbot or DarkGate. One of the Zbot samples delivered after initial access, SyncSuite.exe (SHA256: DB34E255AA4D9F4E54461571469B9DD53E49FEED3D238B6CFB49082DE0AFB1E4) contains similar functionality and strings to other Zbot/Zloader samples previously reported by ZScaler. However, in addition to previously observed strings, the sample also contains encrypted strings for an embedded command help menu, error messages, and more. Rapid7 observed the embedded malware version was 2.9.4.0.
Upon execution, the malware will copy itself to a random folder within the %APPDATA% directory. If the file does not have its original filename however, the process will immediately exit. The malware also contains the functionality to establish persistence either via a Run key at HKCU\Software\Microsoft\Windows\CurrentVersion\Run or a scheduled task named after the executable, which executes the malware copy in %APPDATA% whenever the user logs on. After collecting the hostname, username, and the installation date from the InstallDate value contained within the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion, this data is concatenated (delimited by underscore characters) and encrypted, along with other config information. It is then stored within the user’s registry inside a random key created at HKCU\Software\Microsoft\. The analyzed sample will also load a fresh copy of ntdll.dll to avoid hooking, which is then used to perform calls to NTAPI functions. SyncSuite.exe ultimately injects itself into a suspended instance of msedge.exe, created using NtCreateUserProcess and executed via ResumeThread, a technique known as Process Hollowing.
All of the strings used by the malware are stored encrypted within the .rdata section along with the configuration. The strings are decrypted using an obfuscated loop that is ultimately a simple XOR operation with the hard coded key 16 EB D5 3E AA E6 51 09 14 D3 DF 18 AD D6 1B BD BE, which is also stored in the .rdata section. The configuration is decrypted using an RC4 key, F3 F9 F7 FB FA F3 F7 F7 FF F5 F2 F3 FA FD FE F2 for this sample. The decrypted configuration for SyncSuite.exe can be seen below, with empty rows removed. The configuration contains a different public RSA key and botnet ID than the one previously shared by ThreatLabz, indicating that the campaign is being run by a different affiliate. All decrypted strings from SyncSuite.exe can be seen in the Zbot Strings section following other Indicators of Compromise.
Figure 6. The decrypted Zbot configuration for `SyncSuite.exe` (1264 bytes).
Rapid7 has also observed the delivery of DarkGate malware following initial access. One payload archive contained both a DarkGate infection initiation script, test.vbs, and an executable copy of the DarkGate malware itself, SafeFilter.exe (SHA256: EF28A572CDA7319047FBC918D60F71C124A038CD18A02000C7AB413677C5C161 ), though this copy is packed using the group’s custom packer. The final payload containing the DarkGate malware, after several layers of decrypting and loading, contains the version string 7.0.6. If the folder c:\debugg exists on the system when the malware is executed it will display the version number via MessageBoxA. The configuration for this sample can be seen below along with hard coded commands. Notably, the campaign ID for the sample appears to be drk2.
Figure 7. DarkGate displays its version using a debug message box.
The configuration is decrypted with the key ckcilIcconnh within a customized XOR loop near the beginning of execution to reveal CRLF delimited options. However, due to the implementation of the decryption loop, the keyspace is effectively reduced to that of a single byte (0-255), after the first byte. This makes the XOR key for the majority of the config 0x60, for this sample allowing for the encrypted data to be trivially bruteforced.
| SafeFilter.exe DarkGate Config |-|
Key-Value Pair
Description
0=179.60.149[.]194|
C2 domains or IP addresses, delimited with ‘|’ characters
8=No
If enabled and the file C:\ProgramData\hedfdfd\Autoit3.exe does not exist, call MessageBoxTimeoutA using keys 11 and 12 and a timeout of 1770ms.
11=Error
Used by key 8 as a message box title.
12=PyKtS5Q
The string Error, base64 encoded with the custom alphabet zLAxuU0kQKf3sWE7ePRO2imyg9GSpVoYC6rhlX48ZHnvjJDBNFtMd1I5acwbqT+=. Used by key 8 as a message box caption.
13=6
Unknown
14=Yes
Unknown
15=80
C2 communication port.
1=Yes
Enables infection.
32=Yes
If enabled, attempt bypass of detected security products. For example, enables calls to RtlAdjustPrivilege and NtRaiseHardError to cause a crash if hdkcgae is not present in C:\temp\ and a Kaspersky product has been detected.
3=No
If disabled, do an anti-vm display check.
4=No
If enabled, compare system drive size to key 18. If below, exit.
18=100
Minimum drive size in GB.
6=No
If enabled and key 3 is disabled, check the display for known virtual machine display strings using EnumDisplayDevicesA. If matched, exit. Failed to match properly when tested.
7=No
If enabled, compare system RAM to key 19. If below, exit.
19=4096
Minimum RAM size in MB.
5=No
If enabled, check the registry key ProcessorNameString at HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 for xeon. If found, exit.
21=No
Unknown
22
Not present in the config for this sample, but is still checked for in the code. If enabled, set the variant string to DLL, otherwise ?.
23=Yes
If enabled, set the variant string to AU3 for Autoit3 payloads.
31=No
If enabled, set the variant string to AHK for AutoHotKey payloads.
25=drk2
Campaign ID
26=No
Unknown
27=rsFxMyDX
Decryption key, also used to bound/find payloads stored within other files.
/c cd /d "C:\Users\User\AppData\Roaming<browser_dir>" && move <browser_name> <browser_name><random_alphabet_string>
/c cd /d "C:\Users\User\AppData\Local" && move <browser_name> <browser_name><random_alphabet_string>
/c cmdkey /delete:
/c cmdkey /list > c:\temp\cred.txt
/c del /q /f /s C:\Users\User\AppData\Roaming\Mozilla\firefox*
/c ping 127.0.0.1 & del /q /f /s c:\temp & del /q /f /s C:\ProgramData\hedfdfd\ & rmdir /s /q C:\ProgramData\hedfdfd\
/c shutdown -f -r -t 0
/c shutdown -f -s -t 0
/c wmic ComputerSystem get domain > C:\ProgramData\hedfdfd\fcadaab
During execution, DarkGate will hash certain strings and use the result to create or check files at the directories C:\ProgramData\hedfdfd(mainfolder) and C:\temp\. The hashing algorithm uses a randomized key generated at runtime, so the hashes across infections will be different. Commonly used strings and their resultant hash, for the analysis environment, are shown below.
Path String
DarkGate Custom Hash
mainfolder
hedfdfd
logsfolder
fhhcfhh
settings
dhkbbfc
domain
fcadaab
mutex0
hfgdced
mutex1
cekchde
au3
dgfeabe
c.txt
adfcbdd
cc.txt
dehgaba
script
daaadeh
fs.txt
hdkcgae
DarkGate may also change its behavior if a known security product is detected. This is achieved by using CreateToolhelp32Snapshot and related functions to loop through running processes which are compared to a hard-coded list. The malware will also check for known installation directories using GetFileAttributesA. If a security product is found, a flag will be set which may alter the execution path. Only the following products had associated flags:
DarkGate “Supported” Security Products
-
-
-
-
Windows Defender
Sophos
Quick Heal
MalwareBytes
Panda Security
Norton/Symantec
ESET/Nod32
Kaspersky
Avast
SentinelOne
Bitdefender
-
-
-
-
At the end of the first execution of the DarkGate payload, it will then attempt to inject itself into a host process. First, DarkGate will select the injection target by searching a list of hard coded directories for any executable that contains the string updatecore.exe, subdirectories included. The path C:\Program Files (x86)\Microsoft\EdgeUpdate\ is searched first, with the fallback being C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe. If a matching Edge executable is not found, the path C:\Program Files (x86)\Google\Update\ is then searched. If that also fails, the malware will attempt to use C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe.
After successfully choosing the injection target, DarkGate will then inject itself into the target process using shellcode, terminating the original instance of the final DarkGate payload after executing the shellcode. When creating an instance of the target process to inject, DarkGate will also attempt to spoof the parent process ID (PPID) of the injection target by enumerating running processes for accessibility using OpenProcess and then randomly selecting one from an assembled list. The PPID of the target is then updated using UpdateProcThreadAttribute prior to creation with CreateProcessA.
Execution of the injected process is coordinated by checking for the presence of two file based mutexes within C:\ProgramData\hedfdfd\ (mainfolder). Each instance of the DarkGate malware checks both of the file-based mutexes. The file mutex usage is checked via calls to CreateFileA using an exclusive share mode flag (0) and a creation disposition of CREATE_ALWAYS, which means that if the mutex is already in usage by another DarkGate instance the call will fail. If the call to both mutexes created by DarkGate, hfgdced and cekchde, fails, DarkGate will exit. As a result of having two mutexes, DarkGate will typically run within two injected process instances at the same time, so if one process is terminated, the remaining instance will spawn another. If a DarkGate instance is spawned and both calls to open the file based mutexes fail, indicating two existing DarkGate instances, the new instance will terminate. This technique is rarely used by malware developers and highlights the sophistication of DarkGate malware.
DarkGate will unconditionally log keystrokes as well as clipboard data that is under 1024 bytes. The logged data is stored encrypted at C:\ProgramData\hedfdfd\fhhcfhh (mainfolder\logsfolder) within files named <date>.log. The logged data may be sent directly to the C2 address contained within the config. A thread is also created to persist on infected systems by creating the Run key daaadeh (script) at HKCU\Software\Microsoft\Windows\CurrentVersion\Run. The Run key will point to the copies of Autoit3.exe and the compiled AU3 script payload dgfeabe.a3x (au3) created at C:\ProgramData\hedfdfd (mainfolder), with the former executing the latter every time the user logs on. When the AU3 script is executed, DarkGate reinfects the system. The thread continuously monitors the text within the infected user’s active window however, sleeping 1500ms between checks, and will delete the registry key if a blacklisted application is detected. This list includes popular analysis tools such as Process Hacker, Process Monitor, Task Manager, and even the Windows Registry Editor.
The DarkGate sample executed by SafeFilter.exe contains 78 remote commands, some of which can be seen below with their intended function. Every loop, the malware will re-send the text of the active window, user idle time, and whether or not the malware instance has admin rights, before checking for a command.
Command ID
Function
1000
Sleep for a randomized amount of time.
1004
Use MessageBoxA to display the message test msg.
1044,1045,1046
Click the user’s mouse at specified screen coordinates using SetCursorPos and successive calls to mouse_event. 1044 for double left-click. 1045 for single left click. 1046 for single right click.
1049
Create a remote shell via powershell.exe.
1059
Terminate process by PID.
1061
Inject DarkGate shellcode into a specified process or an Edge/Chrome process if none is selected. The shellcode is then executed via ResumeThread.
1062,1063,1064
Inject DarkGate shellcode into a specified process or cmd.exe if none is selected. The shellcode is then executed via CreateRemoteThread.
1066
Remove infection files by using cmd.exe to delete the staging directories C:\ProgramData\hedfdfd and c:\temp\.
1071
Steal sitemanager.xml and recentservers.xml from %APPDATA%\FileZilla\ if present.
1079
If admin, delete stored credentials found using cmdkey.
1080
Rename browser directories for Firefox, Chrome, and Brave if present after terminating the related browser executable. Attempt to steal Opera cookies if present, after terminating the process.
1081
Use NTAPI calls RtlAdjustPrivilege and NtRaiseHardError to crash the system.
1083
Use the shutdown command to turn the system off.
1084
Use the shutdown command to restart the system.
1089
If 1=Yes in config, reinfect system with AU3 payloads.
1093
Create a remote shell via cmd.exe.
1097
Infect system with AU3 variant. Creates the files script.a3x and Autoit3.exe in c:\temp and then executes script.a3x via Autoit3.exe using CreateProcessA.
1104
Infect system with AHK variant. Creates the files script.ahk, test.txt, and AutoHotkey.exe in c:\temp and then executes script.ahk via AutoHotkey.exe using CreateProcessA.
1108
Infect system with DLL variant. Creates the files libcurl.dll, test.txt, and GUP.exe in c:\temp and then executes GUP.exe via CreateProcessA.
1111
Create the files ransom.txt and decrypter.exe in c:\temp. Terminate decrypter.exe if already running and then execute decrypter.exe using CreateProcessA. Likely ransomware deployment method.
DarkGate Remote Command Related Strings
-
-
-
-
U_Binder
U_BotUpdate
U_Constantes
U_FTPRecovery
U_FileManager
U_FileManagerMisc
U_GetScreens
U_HVNC
U_HVNC_7
U_HWID
U_InfoRecovery
U_InjectOnFly
U_Keylogger
U_LNKStartup
U_MemExecute
U_MemExecuteMisc
U_RemoteScreen
U_SysApi
U_SysNtReadWrite
U_miniclipboard
u_AntiAntiStartup
u_Antis
u_AudioRecord
u_CustomBase64
u_ExtraMisc
u_HollowInstall
u_InjectEP
u_InvokeBSOD
u_RDPRecovery
u_Ransomware
u_ReadCookies
u_ReverseShell
u_RootkitMutex
u_Settings
u_SettingsPad
u_ShellcodeEP
u_UnlockCookies
u_loadpe
hxxps://ipinfo[.]io/ip
Mitigation Guidance
Rapid7 recommends taking the following precautions to limit exposure to these types of attacks:
Restrict the ability for external users to contact users via Microsoft Teams to the greatest extent possible. This can be done for example by blocking all external domains or creating a white/black list. Microsoft Teams will allow all external requests by default. For more information, see this reference.
Standardize remote management tools within the environment. For unapproved tools, block known hashes and domains to prevent usage. Hash blocking can be done, for example, via Windows AppLocker or an endpoint protection solution.
Provide user awareness training regarding the social engineering campaign. Familiarize users with official help desk and support procedures to enable them to spot and report suspicious requests.
Standardize VPN access. Traffic from known low cost VPN solutions should be blocked at a firewall level if there is no business use case.
Rapid7 Customers
InsightIDR, Managed Detection and Response, and Managed Threat Complete customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this activity:
Detections
Suspicious Chat Request - Potential Social Engineering Attempt
Initial Access - Potential Social Engineering Session Initiated Following Chat Request
Suspicious Conversation - Potential Social Engineering Message Interaction
Attacker Technique - Process Executed Using Nt Object Path
Suspicious Process - Enumeration Burst via ShellExecute
Rapid7’s Incident Response team recently investigated a Microsoft Exchange service account with domain administrator privileges. Our investigation uncovered an attacker who accessed a server without authorization and moved laterally across the network, compromising the entire domain. The attacker remained undetected for two weeks. Rapid7 determined the initial access vector to be the exploitation of a vulnerability, CVE 2024-38094, within the on-premise SharePoint server.
Exploitation for initial access has been a common theme in 2024, often requiring security tooling and efficient response procedures to avoid major impact. The attacker’s tactics, techniques, and procedures (TTPs) are showcased in this blog, along with some twists and turns we encountered when handling the investigation.
Observed attacker behavior
Rapid7 began exploring suspicious activity that involved process executions tied to a Microsoft Exchange service account. This involved the service account installing the Horoung Antivirus (AV) software, which was not an authorized software in the environment. For context, Horoung Antivirus is a popular AV software in China that can be installed from Microsoft Store. Most notably, the installation of Horoung caused a conflict with active security products on the system. This resulted in a crash of these services. Stopping the system’s current security solutions allowed the attacker freedom to pursue follow-on objectives thus relating this malicious activity to Impairing Defenses (T1562).
Zooming out from the specific event to look at the surrounding activity paints a clear picture of the attacker’s intended goal. Shortly before installing Horoung AV, the attacker used Python to install Impacket from GitHub and then attempted to execute it. Impacket is a collection of open-source Python scripts to interact with network protocols, typically utilized to facilitate lateral movement and other post-exploitation objectives. The system’s security tooling blocked the Impacket execution, which led to the download via browser and installation of this AV product to circumvent defenses.
As with many incident response investigations, identified clues are not always chronological, thus requiring a timeline to be constructed to understand the narrative. We must attempt to discover how the attacker compromised the system or accessed the environment in the first place. In this specific investigation, the attacker had a dwell time of two weeks. The attacker’s actions are detailed chronologically in the figure below.
Figure 1: MITRE Timeline
A great resource for identifying lateral movement involves analysis of authentication event logs from the domain controllers, specifically event ID 4624. Evidence indicated that malicious activity for this compromised Exchange service account involved more than just this single system. The source of unauthorized activity went back a week prior on a domain controller.
Analysis of the domain controller revealed that the attacker used this Exchange service account to authenticate via Remote Desktop Protocol (RDP). The attacker went on to disable Windows Defender Threat Detection (WDTD) on the system and added an exclusion for a malicious binary called msvrp.exe using the GUI. The malicious binary was placed in the C:\ProgramData\VMware\ folder but was not related to VMware. This binary is a tool called Fast Reverse Proxy (FRP), which allows external access to the system through a NAT-configured firewall. The FRP tool requires an .ini file to provide the necessary network configuration to establish an outbound connection. The .ini file’s external IP address has been provided in the Indicators of Compromise (IoCs) table in this blog post. Persistence was established for the FRP via scheduled tasks on the domain controller. Review of the C:\ProgramData\VMware\ folder used by the attacker revealed additional malicious binaries such as ADExplorer64.exe, NTDSUtil.exe, and nxc.exe. These tools were utilized to map the Active Directory environment, gather credentials, and scan systems.
Further analysis of authentication events from the domain controller indicated this malicious activity was sourced from a public-facing SharePoint server. Evidence indicated that the attacker executed Mimikatz, and there were signs of log tampering on the SharePoint server. It also indicated that a majority of system logging was disabled, and several key event log sources were absent during the investigation timeframe. Mimikatz has the ability to clear event logs and disable system logging. These malicious executions were tied to the local administrator account on the system. This would provide the necessary privileges for log tampering on the SharePoint server. However, some logs were spared, such as RDP log evidence. This indicated all authentication for the local administrator account was sourced from the local system to the local system during the in-scope time frame. The authentication information indicated that the potential initial access vector (IAV) would be tied to this SharePoint server. In light of this evidence, Rapid7 dug deeper into potential exploitation of the SharePoint services for an answer.
Rapid7 reviewed available SharePoint inetpub logs and identified the following GET and POST requests indicative of CVE-2024-38094 being exploited from the external IP address 18.195.61[.]200.
POST /_vti_bin/client.svc/web/GetFolderByServerRelativeUrl('/BusinessDataMetadataC atalog/')/Files/add(url='/BusinessDataMetadataCatalog/BDCMetadata.bdcm
POST /_vti_bin/DelveApi.ashx/config/ghostfile93.aspx
This vulnerability allows for remote code execution (RCE) on systems running Microsoft SharePoint from an external source. The proof-of-concept (PoC) code identified here was observed in available SharePoint log evidence. A great resource that explains the PoC code on Github can be found here. Utilizing this vulnerability, the attacker dropped a webshell on the system. The webshell was called ghostfile93.aspx, which generated numerous HTTP POST requests from the same external IP address tied to the exploit string within log evidence. After several hours of using the webshell, the attacker authenticated into the system using the local administrator account.
Initial access occurred two weeks prior to the start of the investigation. The attacker performed other notable TTPs during the dwell time. These TTPs involved utilizing several binaries to include everything.exe, kerbrute_windows_amd64.exe, 66.exe, Certify.exe, and attempts to destroy third-party backups. The binary everything.exe can index the NTFS file system for efficient searching across files, such as recently used files and network shares. Some of the most notable binaries include 66.exe, a renamed version of Mimikatz, and Certify.exe, which creates an ADFS certificate to utilize for elevated actions within the Active Directory environment. The remaining binary kerbrute_windows_amd64.exe has extensive capability for brute-forcing Active Directory Kerberos tickets. The attacker failed to compromise the third-party backup solution but attempted multiple methods, including access via the browser using compromised credentials and connecting over SSH.
As discussed previously, the installation of external AV products to disable security tooling was an interesting TTP identified during this investigation. Shortly after being blocked for attempted Impacket execution, Rapid7 identified the attacker leveraging an installation batch script called hrsword install.bat. The contents of this script indicate that the Huorong AntiVirus (AV) security solution was being installed. This script involved a service creation called sysdiag to execute the driver file sysdiag_win10.sys, which creates a VBS script execution parameter to execute HRSword.exe. Rapid7 observed this installation causing errors for security products on the system, potentially leading to a scenario in which the service or application would crash. These install files and all IOCs identified during this investigation have been provided in the IOC table contained within this blog.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to the Microsoft SharePoint CVE-2024-38094 with authenticated vulnerability checks added in the July 09, 2024 content release.
Rapid7 used Velociraptor during this investigation to allow for remote triage and collection of forensic artifacts on the endpoint. A Velociraptor artifact has been created to hunt for strings related to the public PoC and log evidence identified during the investigation. The artifact can be found within the Rapid7 Labs VQL Repo here
InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to exploitation of this vulnerability.
Suspicious Commands Launched by Webserver
IIS Launching Discovery Commands
IIS Spawns PowerShell
Attacker Tool - Impacket
Attacker Tool - MimiKatz
Attacker Technique - Hash Dumping With NTDSUtil
Attacker Technique - Clearing Event Logs
Defense Evasion - Disabling Multiple Security or Backup Products
Rapid7 also recommends ensuring that SharePoint is patched to the latest version.
MITRE ATT&CK techniques
Tactic
Technique
Details
Initial Access
Exploit Public-Facing Application (T1190)
CVE-2024-38094: Microsoft SharePoint Remote Code Execution Vulnerability
Defense Evasion
Impair Defense (T1562)
AV solution being utilized to disable or degrade security tools on systems.
Discovery
Account Discovery (T1087)
Usage of AD enumeration tools
Command and Control
Proxy (T1090)
Fast Reverse Proxy being used to establish outbound connection
Discovery
File and Directory Discovery (T1083)
Everything.exe being observed on in-scope systems.
Discovery
Network Share Discovery (T1135)
nxc.exe being observed on in-scope systems.
Credential Access
OS Credential Dumping (T1003)
Various credential harvesting tools observed on in-scope systems
Persistence
Scheduled Task/Job (T1053)
Scheduled tasks observed on in-scope systems to execute the FRP tool.
POST /_vti_bin/client.svc/web/GetFolderByServerRelativeUrl('/BusinessDataMetadataC atalog/')/Files/add(url='/BusinessDataMetadataCatalog/BDCMetadata.bdcm
POC code identified in SharePoint logs.
Log-Based IOC
POST /_vti_bin/DelveApi.ashx/config/ghostfile93.aspx
Webshell identified within SharePoint logs.
IP Address
54.255.89[.]118
IP address from .ini file for Fast Reverse Proxy tool
IP Address
18.195.61[.]200
Source IP address from exploitation and webshell communications
It should come as little surprise to most security professionals that keeping pace with the evolution of threat actors has become harder and harder. Maintaining visibility into the threat landscape and on top of external risk vectors is more than a matter of incorporating more point solutions. It takes a concerted risk-based approach, where the tools you choose are just one leg of the tripod.
In a report released earlier this summer, Gartner analysts offer three recommendations for fostering an environment of risk-based threat detection, investigation, and response that includes a deeper understanding of your organization’s risk profile by more than just the security team. Below are our three main takeaways from the Gartner® 3 Ways to Apply a Risk-Based Approach to Threat Detection, Investigation, and Response.
Takeaway 1: Better alignment and clearer objectives
The need to break silos between teams is a time-honored proposition that holds even more weight now than it ever has. Gartner suggests creating a quorum of business leaders from across the entire organization to be read into the state of your security and the needs going forward. Prioritize accurate and regular reporting of security metrics to build trust and create a consistent atmosphere of effective transparency. This group should be diverse, with decision makers and specialists from core departments. According to Gartner, the goal should be to:
“Allow the business to be part of the conversation and therefore champions of the capability, elevating the security program to a business function rather than an I&O underpinning.”
Takeaway 2: Integrated risk context
Giving incident responders as much information (and the right information) they need to quickly and efficiently respond to threats requires a complex layering of risk information that includes prioritization for the businesses key assets. Gartner recommends the use of cyber-risk information elements directly implemented into an IR program, layering in asset-based and business-risk information that gives responders the context they require to appropriately triage what can often be a large volume of data.
Gartner says:
“Incident responders should have as much information at their disposal as needed to be effective at finding a needle in a haystack.”
Takeaway 3: Fully enriched business context from jump
Too much information can often be as detrimental to a security team as too little. SecOps needs to have access to the right information in the most efficient way possible in order to find the signal through the noise. Gartner recommends reducing investigative delays through enriched information complete with business context (see, they are all connected). This transparency can be accomplished in part through SIEM, CAASM, and threat intelligence tools and a robust vulnerability management program, but it is worth noting that Gartner prioritizes providing the right information, not the most information; hence, utilizing the right tools.
All three of these recommendations combine to create a risk-based approach to detection, investigation, and response that Gartner says: “...organizations can expect to create measurable efficiency gains in threat detection and increase their ability to respond to threats in a timely manner.”
The Gartner® 3 Ways to Apply a Risk-Based Approach to Threat Detection, Investigation, and Response, report goes into even greater detail on the best approaches for implementing a risk-based approach to D&R.
On Monday, July 29, Microsoft published an extensive threat intelligence blog on observed exploitation of CVE-2024-37085, an Active Directory integration authentication bypass vulnerability affecting Broadcom VMware ESXi hypervisors. The vulnerability, according to Redmond, was identified in zero-day attacks and has evidently been used by at least half a dozen ransomware operations to obtain full administrative permissions on domain-joined ESXi hypervisors (which, in turn, enables attackers to encrypt downstream file systems). CVE-2024-37085 was one of multiple issues fixed in a June 25 advisory from Broadcom; it appears to have been exploited as a zero-day vulnerability.
Per Broadcom’s advisory, successful exploitation of CVE-2024-37085 allows attackers “with sufficient Active Directory (AD) permissions to gain full access to an ESXi host that was previously configured to use AD for user management by re-creating the configured AD group (‘ESXi Admins’ by default) after it was deleted from Active Directory.”
Notably, Broadcom’s advisory differs from Microsoft’s description, which says: “VMware ESXi hypervisors joined to an Active Directory domain consider any member of a domain group named "ESX Admins" to have full administrative access by default. This group is not a built-in group in Active Directory and does not exist by default. ESXi hypervisors do not validate that such a group exists when the server is joined to a domain and still treats any members of a group with this name with full administrative access, even if the group did not originally exist.”
Also of note: While the VMware advisory indicates ESXi Admins is the default AD group, the Microsoft observations quoted in this blog all indicate use of ESX Admins rather than ESXi Admins.
ESXi hypervisors have been a popular target for ransomware groups in years past. Notably, since ESXi should not be internet-exposed, we would not expect CVE-2024-37085 to be an initial access vector — adversaries will typically need to have already obtained a foothold in target environments to be able to exploit the vulnerability to escalate privileges.
Exploitation
Microsoft researchers discovered CVE-2024-37085 after it was used as a post-compromise attack technique used by a number of ransomware operators, including Storm-0506, Storm-1175, Octo Tempest, and Manatee Tempest. The attacks Microsoft observed included use of the following commands, which first create a group named “ESX Admins” in the domain and then adds a user to that group:
net group “ESX Admins” /domain /add net group “ESX Admins” username /domain /add
Microsoft identified three methods for exploiting CVE-2024-37085, including the in-the-wild technique described above:
Adding the “ESX Admins” group to the domain and adding a user to it (observed in the wild): If the “ESX Admins” group doesn’t exist, any domain user with the ability to create a group can escalate privileges to full administrative access to domain-joined ESXi hypervisors by creating such a group, and then adding themselves, or other users in their control, to the group.
Renaming any group in the domain to “ESX Admins” and adding a user to the group or using an existing group member: This requires an attacker to have access to a user that has the capability to rename arbitrary groups (i.e., by renaming one of them “ESX Admins”). The threat actor can then add a user, or leverage a user that already exists in the group, to escalate privileges to full administrative access.
ESXi hypervisor privileges refresh: Even if the network administrator assigns any other group in the domain to be the management group for the ESXi hypervisor, the full administrative privileges to members of the “ESX Admins” group are not immediately removed and threat actors still could abuse it.
Mitigation guidance
The following products and versions are vulnerable to CVE-2024-37085:
The Broadcom advisory on CVE-2024-37085 links to a workaround that modifies several advanced ESXi settings to be more secure; the workaround page notes that for all versions of ESXi (prior to ESXi 8.0 U3), “several ESXi advanced settings have default values that are not secure by default. The AD group "ESX Admins" is automatically given the VIM Admin role when an ESXi host is joined to an Active Directory domain.”
Broadcom VMware ESXi and Cloud Foundation customers should update to a supported fixed version as soon as possible. Administrators who are unable to update should implement workaround recommendations in the interim. ESXi servers should never be exposed to the public internet. Microsoft has additional recommendations on mitigating risk of exploitation in their blog.
Rapid7 customers
InsightVM and Nexpose customers who use ESXi hypervisors within their environments can assess their exposure to CVE-2024-37085 for the 8.x version stream with a vulnerability check available since June 2024. Support for scanning 7.0 is expected to be available in the July 30 content release.
InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this vulnerability:
Attacker Technique - Creation of "ESX Admins" Domain Group using Net.exe
The following Rapid7 analysts contributed to this research: Leo Gutierrez, Tyler McGraw, Sarah Lee, and Thomas Elkins.
Executive Summary
On Tuesday, June 18th, 2024, Rapid7 initiated an investigation into suspicious activity in a customer environment. Our investigation identified that the suspicious behavior was emanating from the installation of Notezilla, a program that allows for the creation of sticky notes on a Windows desktop. Installers for Notezilla, along with tools called RecentX and Copywhiz, are distributed by the India-based company Conceptworld at the official domain conceptworld[.]com. After analyzing the installation packages for all three programs, Rapid7 discovered that the installers had been trojanized to execute information-stealing malware that has the capability to download and execute additional payloads.
Disclosure
On Monday, June 24th, 2024, Rapid7 contacted Conceptworld to disclose the backdoored installers being hosted on conceptworld[.]com in accordance with Rapid7’s vulnerability disclosure policy. Within 12 hours, Conceptworld confirmed and remediated the issue by removing the malicious installers from conceptworld[.]com and replacing them with legitimate, signed copies. Rapid7 is grateful to Conceptworld for their prompt action on this issue.
Overview
Conceptworld is an India-based company offering three different software products: Notezilla, which allows users to create sticky notes on a Windows desktop; RecentX, which stores recently used files/applications/clipboard data; and Copywhiz, which improves file copying and backup operations. A free trial download is available on the official conceptworld[.]com site for each software package.
The installation packages being served by conceptworld[.]com at the time of investigation, however, executed malware alongside the legitimate installer, were not signed, and did not match the file size stated on the download page. The differences in the file sizes are due to the malware and its dependencies, which increases the size of the compromised installation packages.
The malware Rapid7 observed contains the functionality to steal browser credentials and crypto currency wallet information, log clipboard contents and keystrokes, and download and execute additional payloads. After infecting a system, the malware persists via a scheduled task that executes the primary payload every three hours.
Based on file submissions to VirusTotal, the malicious copies of the installers have existed since early June of 2024. The malware payloads delivered by the trojanized installers, however, seem to belong to a nameless malware family that has been in distribution since at least January of 2024. Rapid7 internally refers to this malware family as dllFake because of the naming scheme used for several of the malware payloads.
Malicious installer name
VirusTotal First Submission
NotezillaSetup.exe
2024-06-10 06:43:34 UTC
RecentXSetup.exe
2024-06-07 21:38:11 UTC
CopywhizSetup.exe
2024-06-08 07:25:17 UTC
Technical analysis
To take a deeper look at the malware payloads, we will analyze the malicious installer that was served for Notezilla.
Initial Access
Rapid7 determined that trojanized installers for the 32-bit and 64-bit versions of Notezilla, Copywhiz, and RecentX were, at the time of investigation, being served from the official website conceptworld[.]com. Any users searching for this software via a popular search engine at the time were most likely to find the official domain as the first result, which would then have directed them to download the malware.
Execution
The installer served by conceptworld[.]com for Notezilla at the time of investigation was NotezillaSetup.exe, which, based on static analysis, is packed using software called Smart Install Maker(5.04).
Figure 1. Software Properties of NotezillaSetup.exe.
Using the sim_unpacker plugin for the tool UniExtract2, we were able to unpack and acquire most of the contents of the installation package, such as the embedded files and configuration information. The configuration file contains references to the legitimate software installer for Notezilla, which is dropped into %TEMP% during execution, and multiple files that are dropped into the installation directory (i.e., staging folder) %LOCALAPPDATA%\Microsoft\WindowsApps\ during execution.
Installer Files
curl.exe
7z.exe
dllBus.bat
dllBus32.exe
dllCrt.bat
dllCrt.xml
dllCrt32.exe
dll_apps.txt
dll_srv.txt
dll_updt.txt
NotezillaSetup.exe
Figure 2. Output from Using the sim-unpacker tool.
Figure 3. Contents of installer.config.
Once executed, NotezillaSetup.exe will then execute the file dllCrt32.exe from the staging directory %LOCALAPPDATA%\Microsoft\WindowsApps\ via a WINAPI call to ShellExecuteA with the verb open. A second call is then made to ShellExecuteA to execute the file NotezillaSetup.exe, a copy of the legitimate installer, from %TEMP%. As a result, the only thing seen by the end user after initial execution is the installation window pop-up for the legitimate installer, prompting the user to proceed with the installation process for Notezilla.
Figure 4. Typical Process Tree for Initial Execution of the Trojanized Installer.
Figure 5. The User’s View after the Infection has Already Begun in the Background.
The file dllCrt32.exe is a relatively small (~10KB) program that only serves as a wrapper to call CreateProcessA to execute the file dllCrt.bat.
Figure 6. The Contents of dllCrt.bat.
The batch file dllCrt.bat will then create a hidden scheduled task named Check dllHourly32 using schtasks.exe and an XML file that was previously dropped into the staging directory at %LOCALAPPDATA%\Microsoft\WindowsApps\dllCrt.xml. The scheduled task Check dllHourly32 will then execute the file %LOCALAPPDATA%\Microsoft\WindowsApps\dllBus32.exe every three hours after being initially created, which means that the primary malware payload will not be executed until at least three hours after the user originally executed the trojanized installer.
Figure 7. Command Line Assembly within dllBus32.exe.
When dllBus32.exe is executed, it also serves as a small wrapper for calling CreateProcessA, though it initially retrieves several important command line parameters. First, a call to the CRT library function sprintf concatenates a hard-coded IPv4 address. Then, a second call to sprintf concatenates the assembled IPv4 address with several other arguments to be passed to the batch file dllBus.bat. Finally, CreateProcessA is called with the fully assembled command line.
Figure 8. The Initial Lines of dllBus.bat.
The command line arguments passed to dllBus.bat via dllBus32.exe contain an IPv4 address, an SFTP port, a password for ZIP archive payloads, two sets of SFTP credentials, and the staging directory where the majority of the malware’s files are located.
Argument #
Purpose
Value
Notes
1
C2 IPv4 Address
212.70.149[.]210
Stored within dllBus32.exe.
2
SFTP Port
2265
Used for all curl requests regardless of the IPv4 address.
3
ZIP password
MnX!8fsGt0@
Used to decrypt/extract downloaded archives.
4
SFTP Username
phn_sys
The SFTP credentials used for uploading stolen data.
5
SFTP Password
Password for phn_sys.
6
SFTP Username
phn_prj
The SFTP credentials used for downloading payloads.
7
SFTP Password
Password for phn_prj
The batch file dllBus.bat contains functionality to facilitate the theft of information from Google Chrome, Mozilla Firefox, and multiple cryptocurrency wallets. The copy of curl.exe dropped by the installer is also used to connect to a list of command-and-control (C2) addresses hosting SFTP servers. The curl commands are used to download an updated list of C2 addresses, stored as plaintext within the file dll_srv.txt, and to download and execute additional payloads saved within encrypted ZIP archives named Updt.zip, Apps.zip, and BB.zip. The batch script will also attempt to compress all files on the infected system that have specific file extensions and exist in directories that are not on a hardcoded blacklist (for exfiltration). All stolen data is ultimately compressed using 7z.exe and uploaded directly to the selected C2 SFTP server using curl.
The payloads Apps.zip and Updt.zip both contain executables created using PyInstaller, which means the original Python script used to create the executables can be recovered trivially using a publicly available extractor. The payload dllChrome32.exe, contained within Updt.zip, is used to facilitate theft of credentials from Google Chrome’s database that are then saved into the file %TEMP%\chrm.txt with the format: URL, Username, Password.
Figure 9. Primary Functionality of dllChrome32.exe.
The payloads dllTemp32.exe and dllCache32.exe stored within Apps.zip contain a clipboard stealer and a keylogger, where the results are saved to the files cl.txt and kl.txt, respectively, within the staging directory at %LOCALAPPDATA%\Microsoft\WindowsApps\.
Figure 10. All Data Copied to the Clipboard is Dumped to cl.txt when dllTemp32.exe is Running.
Figure 11. dllCache32.exe Logs Keystrokes to kl.txt when Running.
Rapid7 did not observe any of the identified SFTP servers hosting the third payload, BB.zip, at the time of writing, although the contents of dllBus.bat indicate that it contains the executables srvBus32.exe and srvCrt32.exe, which serve an unknown function.
Mitigation Guidance
Rapid7 recommends verifying the file integrity of freely available software. Check that the file hash and properties of the downloaded file(s) match those provided by the official distributor and/or that they contain a valid and relevant signature. The malicious installers observed in this case are unsigned and have a file size that is inconsistent with copies of the legitimate installer, even as noted on the official download page.
If an installer for Notezilla, RecentX, or Copywhiz has been executed on a system within the last month, Rapid7 recommends checking for signs of compromise due to the malicious installers detailed in this blog. The primary indicators of infection include the hidden scheduled task Check dllHourly32 and a persistent running instance of the Windows Command Prompt, cmd.exe, which makes outbound network connections via curl.exe.
If evidence of compromise is found, Rapid7 recommends re-imaging affected systems to a known good baseline to eradicate any changes made by the malware.
Rapid7 Customers
InsightIDR, Managed Detection and Response, and Managed Threat Complete customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this activity:
Detections
Persistence - SchTasks Creating A Task Pointed At Users Temp Or Roaming Directory
Attacker - Extraction Of 7zip Archive With Password
Suspicious Process - 7zip Executed From Users Directory
Suspicious Process - TaskKill Executed Successively In Short Time Period
Attacker Technique - Curl or Wget To Public IP Address With Non Standard Port
The following analysts contributed to this blog: Thomas Elkins, Daniel Thiede, Josh Lockwood, Tyler McGraw, and Sasha Kovalev.
Executive Summary
Rapid7 has observed a recent malvertising campaign that lures users into downloading malicious installers for popular software such as Google Chrome and Microsoft Teams. The installers were being used to drop a backdoor identified as Oyster, aka Broomstick. Following execution of the backdoor, we have observed enumeration commands indicative of hands-on-keyboard activity as well as the deployment of additional payloads.
In this blog post, we will examine the delivery methods of the Oyster backdoor, provide an in-depth analysis of its components, and offer a Python script to help extract its obfuscated configuration.
Overview
Initial Access
In three separate incidents, Rapid7 observed users downloading supposed Microsoft Teams installers from typo-squatted websites. Users were directed to these websites after using search engines such as Google and Bing for Microsoft Teams software downloads. Rapid7 observed that the websites were masquerading as Microsoft Teams websites, enticing users into believing they were downloading legitimate software when, in reality, they were downloading the threat actor’s malicious software.
Figure 1 - Fake Microsoft Teams Website
In one case, a user was observed navigating to the URL hxxps://micrsoft-teams-download[.]com/, which led to the download of the binary MSTeamsSetup_c_l_.exe. Initial analysis of the binary MSTeamsSetup_c_l_.exe showed that the binary was assigned by an Authenticode certificate issued to “Shanxi Yanghua HOME Furnishings Ltd”.
Figure 2 - MSTeamsSetup_c_l_.exe File Information
Searching VirusTotal for other files signed by “Shanxi Yanghua HOME Furnishings Ltd” showed the following:
Figure 3 - VirusTotal Signature Search Results
The results indicated other versions of the installer, each impersonating as a legitimate software installer. We observed that the first installer was submitted to VirusTotal around mid-May 2024.
In a related incident that occurred on May 29, 2024, we observed another binary posing as a Microsoft Teams setup file, TMSSetup.exe, which was assigned a valid certificate issued to “Shanghai Ruikang Decoration Co., Ltd”. As of May 30, 2024, that certificate has been revoked.
VirusTotal analysis of the binary MSTeamsSetup_c_l_.exe indicates it is associated with a malware family known as Oyster, dubbed Broomstick by IBM.
What is Oyster/Broomstick?
Oyster aka Broomstick aka CleanUpLoader is a family of malware first spotted in September of 2023 by researchers at IBM. While not much is known about the malware, it was delivered via a loader called Oyster Installer, which masqueraded as a browser installer. The installer was responsible for dropping the backdoor component, Oyster Main. Oyster Main was responsible for gathering information about the compromised host, handling communication with the hard-coded command-and-control (C2) addresses, and providing the capability for remote code execution.
In February, researchers on Twitter observed the same backdoor component and started to name the Oyster Main backdoor, CleanUpLoader.
In recent incidents, Rapid7 has observed Oyster Main being delivered without the Oyster Installer.
Technical Analysis
Initial analysis of the binary MSTeamsSetup_c_l_.exe revealed that two binaries were stored within the resource section. During execution, a function was observed using FindResourceA to locate the binaries, followed by LoadResource to access them. These binaries were then subsequently dropped into the Temp folder. We observed that the intended names of the two binaries dropped by MSTeamsSetup_c_l_.exe were CleanUp30.dll and MSTeamsSetup_c_l_.exe (the legitimate Microsoft Teams installer).
After dropping the binary CleanUp30.dll into the Temp directory, the program executes the DLL, passing the string rundll32.exe %s,Test to the function CreateProcessA, where %s stores the value CleanUp30.dll.
Figure 4 - Execution of CleanUp30.dll
After the execution of CleanUp30.dll, the program proceeds to initiate the legitimate Microsoft Teams installer, MSTeamsSetup_c_l_.exe, also located within the Temp directory. This tactic is employed to avoid raising suspicion from the user.
CleanUp30.dll Analysis
During the execution of CleanUp30.dll, Rapid7 observed that the binary starts by attempting to create the hard coded mutual exclusion (mutex) ITrkfSaV-4c7KwdfnC-Ds165XU4C-lH6R9pk1. Mutex creation is often used by programs in order to determine if the program is already running another instance. If the program is already running, the program will terminate the new instance.
After creating the mutex, the binary determines its execution path by calling the function GetModuleFilenameA. The value is stored as a string and used as a parameter for the creation of a scheduled task, ClearMngs. The scheduled task is created using the function ShellExecuteExW, passing the following as the command line:
The purpose of the scheduled task ClearMngs is to execute the binary <location of binary>\CleanUp30.dll with the exported function of Test using rundll32.exe every three hours.
After the creation of the scheduled task, the binary then proceeds to decode its C2 servers using a unique decoding function. The decoding function begins by taking in a string of encoded characters, and its length is in bytes. The decoding function then proceeds to read in each byte, starting from the end of the encoded string.
Figure 5 - The DLL’s Decoding Loop
Each byte of the encoded string is used as an index location to retrieve the decoded byte from a hard-coded byte map. A byte map is a byte array containing 256 bytes in a randomized order, one for each possible byte value from 1 to 256. Malware authors sometimes use this technique to obfuscate strings and other data. The iteration counter (i) used within the condition for the decoding loop is compared to half of the encoded string’s length as the decoding loop swaps two bytes at a time. The bytes of the encoded string are decoded and swapped beginning at the start and end bytes of the string and the decoding loop then progresses towards the center of the string from each end.
The loop swaps the bytes to reverse the decoded string, as the original plaintext strings stored in the malware were reversed prior to encoding. When the center of the string is reached, the decoding process is complete. Due to this algorithm, all the encoded strings that are passed must be of even length to avoid further processing. Immediately after the decoded string is loaded onto the stack, the malware then re-encodes the string using a similar loop. The final result for the first decoded string is a carriage return line feed (CRLF) delimited list of C2 domains.
We constructed a Python script that can decode all the encoded strings contained within the CleanUp.dll binaries, including previous versions. The Python script can be found in our GitHub repository.
Figure 6 - Sample Output from Python Script
Using our Python script, it revealed some of the C2 functionality, along with several JSON fields that are used to build a fingerprint of the infected system:
After the binary decodes the C2 addresses, the program proceeds to fingerprint the infected machine, using the following functions:
Function
Description
DsRoleGetPrimaryDomainInformation
Used to gather information about the domain the compromised machine resides in. In particular, the function returns the domain name.
GetUserNameW
Provides the name of the user in which the program is running under.
NetUserGetInfo
Provides details of the user under which the program is running. In this case, the program is querying if the user is admin or user.
GetComputerNameW
Provides the name of the compromised machine in which the binary is running on.
RtlGetVersion
Returns version information about the currently running operating system including name and version number.
Figure 7 - A Selection of Contents of the CleanUp30.dll Code that Outline the Collection of System Information
While enumerating information about the host, the information is stored in the JSON fields uncovered from the encoded strings identified above.
Figure 8 - Example of the Data Collected and Sent via HTTP POST to the Malicious Domains
The fingerprint information is encoded using the same loop previously discussed, where the data string is reversed and encoded using a byte map before being sent.
After the information is encoded, it is sent to the domains whereverhomebe[.]com/, supfoundrysettlers[.]us/, and retdirectyourman[.]eu/ via HTTP POST method. Rapid7 determined that CleanUp30.dll uses the open-source C++ library Boost.Beast to communicate with the observed C2 domains via HTTP and web sockets.
Figure 9 - Captured Network Traffic Attempting to Send POST Requests to whereverhomebe[.]com/ and supfoundrysettlers[.]us/ Following the Execution of CleanUp30.dll
Follow-on Activity
In one of the incidents Rapid7 observed, a PowerShell script was spawned following the execution of another version of CleanUp30.dll, CleanUp.dll. CleanUp.dll, similar to CleanUp30.dll, was originally dropped by the other fake Microsoft Teams installer, TMSSetup.exe, which dropped the binary into the AppData/Local/Temp directory as well.
The purpose of the PowerShell script was to create a shortcut LNK file named DiskCleanUp.lnk within C:\Users\<User>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\. By doing so, this ensured that the LNK file DiskCleanUp.lnk would be run each time the user logged in. The shortcut LNK file was responsible for executing the binary CleanUp.dll using rundll32.exe, passing the export Test.
Following the execution of the PowerShell script, Rapid7 observed execution of additional payloads:
k1.ps1
main.dll
getresult.exe
Unfortunately, during the incident, we were unable to acquire the additional payloads. During the incidents, Rapid7 also observed execution of the following enumeration commands:
Enumeration
Description
systeminfo
Provides information about the system's software and hardware configuration
arp -a
Shows a list of all IP addresses that the local computer has recently interacted with, along with their corresponding MAC addresses
net group 'domain computers' /domain
Lists the "Domain Computers" group within an Active Directory domain
Queries the registry to find information about installed software
findstr "DisplayName"
Used to filter information, showing only items contained under "DisplayName"
Rapid7 Customers
InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this malware campaign:
Persistence - SchTasks Creating A Task Pointed At Users Temp Or Roaming Directory
Suspicious Process: RunDLL32 launching CMD or PowerShell
Persistence - Schtasks.exe Creating Task That Executes RunDLL32
*The following Rapid7 team members contributed to this blog: Ipek Solak, Thomas Elkins, Evan McCann, Matthew Smith, Jake McMahon, Tyler McGraw, Ryan Emmons, Stephen Fewer, and John Fenninger*
Overview
Justice AV Solutions (JAVS) is a U.S.-based company specializing in digital audio-visual recording solutions for courtroom environments. According to the vendor’s website, JAVS technologies are used in courtrooms, chambers and jury rooms, jail and prison facilities, and council, hearing, and lecture rooms. Their company website cites over 10,000 installations of their technologies worldwide.
Rapid7 has determined that users with JAVS Viewer v8.3.7 installed are at high risk and should take immediate action. This version contains a backdoored installer that allows attackers to gain full control of affected systems. Completely re-imaging affected endpoints and resetting associated credentials is critical to ensure attackers have not persisted through backdoors or stolen credentials. Users should install the latest version of JAVS Viewer (8.3.8 or higher) after re-imaging affected systems. These findings were identified through an investigation performed by Rapid7 analysts.
On Friday, May 10, 2024, Rapid7 initiated an investigation into an incident involving the execution of a binary named fffmpeg.exe from within the file path C:\Program Files (x86)\JAVS\Viewer 8\. The investigation traced the infection back to the download of a binary named JAVS Viewer Setup 8.3.7.250-1.exe that was downloaded from the official JAVS site on March 5th. Analysis of the installer JAVS Viewer Setup 8.3.7.250-1.exe showed that it was signed with an unexpected Authenticode signature and contained the binary fffmpeg.exe. During the investigation, Rapid7 observed encoded PowerShell scripts being executed by the binary fffmpeg.exe.
Based on open-source intelligence, Rapid7 determined that the binary fffmpeg.exe is associated with the GateDoor/Rustdoor family of malware discovered by researchers at security firm S2W.
Product Description
JAVS Suite 8 is a portfolio of audio/video recording, viewing, and management software for government organizations and businesses. The affected “JAVS Viewer” software is designed to open media and log files created by other pieces of JAVS Suite software. It is available to download via the vendor's website, and it’s shipped as a Windows-based installer package that prompts for high privileges upon execution.
Credit
This issue was discovered and documented by Ipek Solak, Detection and Response Analyst at Rapid7. Rapid7 is grateful to the U.S. Cybersecurity and Infrastructure Security Agency (CISA) for their prompt assistance coordinating disclosure of this issue, and to Justice AV Solutions for their quick response.
A full vendor statement from Justice AV Solutions is available at the end of this blog and includes information about the actions JAVS has taken.
You can find Rapid7’s coordinated disclosure policy here.
Rapid7-Observed Attacker Behavior
The malicious Windows installer JAVS.Viewer8.Setup_8.3.7.250-1.exe contains an unexpected binary file fffmpeg.exe (1.4 MB, SHA1: e41ec15f2bac76914b4a86cade3a0f4619167f52). Note the three f characters in the binary name; the expected ffmpeg.exe binary only has two f characters.
Searching VirusTotal for this binary’s SHA1 reveals that several vendors classify this binary as a malicious dropper:
Figure 1 - The Dropper’s VirusTotal Details
VirusTotal reports this binary was first seen on the VT platform May 3, 2024.
Both the fffmpeg.exe binary and the installer binary are signed by an Authenticode certificate issued to “Vanguard Tech Limited”. This is unexpected, as it was noted that other JAVS binaries which appear legitimate are signed by a certificate issued to “Justice AV Solutions Inc”. Searching VirusTotal for other files signed by “Vanguard Tech Limited” shows the following.
Figure 2- VirusTotal Vanguard Certificate Results
The above suggests that there may be one other version of the malicious installer (SHA1: b8e97333fc1b5cd29a71299a8f82a541cabf4d59) and one other malicious fffmpeg.exe (SHA1: b9d13055766d792abaf1d11f18c6ee7618155a0e). These binaries were first seen on the VirusTotal platform April 1, 2024.
The Windows Installer file (b8e97333fc1b5cd29a71299a8f82a541cabf4d59) contains multiple bundled files, including a file called Dll2.dll (SHA1: cd60955033d1da273a3fda61f69d76f6271e7e4c). The file contains a string called “HelloWorld” and from the execution path perspective, this looks like a test. From an OPSEC point of view, the file was not ‘cleaned’ but contains the compilation information, in this case the full PDB path: C:\Users\User\source\repos\Dll2\x64\Debug\Dll2.pdb
Exploitation Timeline
Feb 10, 2024: A certificate is issued for the subject Vanguard Tech Limited, which the certificate indicates is based in London.
Feb 21, 2024: The first of the two malicious JAVS Viewer packages is signed with the Vanguard certificate.
April 2, 2024: The Twitter user @2RunJack2 tweets about malware being served by the official JAVS downloads page. It’s not stated whether the vendor was notified.
Mar 12, 2024: The second of the two malicious JAVS Viewer packages is signed with the Vanguard certificate.
May 10, 2024: Rapid7 investigates a new alert in a Managed Detection and Response customer environment. The source of the infection is traced back to an installer that was downloaded from the official JAVS site. The malware file that was downloaded by the victim, the first Viewer package, is not observed to be accessible on the vendor’s download page. It’s unknown who removed the malicious package from the downloads page (i.e., the vendor or the threat actor).
May 12, 2024: Rapid7 discovers three additional malicious payloads being hosted on the threat actor’s C2 infrastructure over port 8000: chrome_installer.exe, firefox_updater.exe, and OneDriveStandaloneUpdater.exe.
May 13, 2024: Rapid7 identifies an unlinked installer file containing malware, the second Viewer package, still being served by the official vendor site. This confirms that the vendor site was the source of the initial infection.
May 17, 2024: Rapid7 discovers that the threat actor removed the binary OneDriveStandaloneUpdater.exe from C2 infrastructure and replaced it with a new binary, ChromeDiscovery.exe. This indicates that the threat actor is actively updating their C2 infrastructure.
Impact
During Rapid7’s initial examination of the binary fffmpeg.exe, it became evident that the program facilitates unauthorized remote access. Upon execution, fffmpeg.exe persistently communicates with a command-and-control (C2) server using Windows sockets and WinHTTP requests. Once successfully connected, fffmpeg.exe transmits data about the compromised host, including hostname, operating system details, processor architecture, program working directory and the user name to the C2.
Figure 3 - Sample Network Traffic Containing Information About the Host
Subsequently, a persistent connection is established, with the binary poised to receive commands from the C2.
While investigating an incident regarding the binary fffmpeg.exe, Rapid7 observed the execution of two obfuscated PowerShell scripts.
Figure 4 - Encoded PowerShell Script Spawned by fffmpeg.exe
Rapid7 deobfuscated the PowerShell scripts executed by fffmpeg.exe and determined the script will attempt to bypass the Anti-Malware Scan Interface (AMSI) and disable Event Tracing for Windows (ETW) for the launched PowerShell session, before executing a command to download an additional payload.
Figure 5 - De-obfuscated PowerShell Script Spawned by fffmpeg.exe
During analysis of chrome_installer.exe, Rapid7 observed that the binary contained code to drop Python scripts and a binary named main.exe within the Temp folder, passing the string {TEMP}\\onefile_{PID}_{TIME} as an argument to a function whose responsibility was to build out the file path.
Figure 6 - Temp Folder Creation Using String {TEMP}\onefile_{PID}_{TIME}
Once the new software was dropped, chrome_installer.exe was responsible for executing the binary main.exe using the function CreateProcessW. After analysis of main.exe, Rapid7 observed that it contained compiled Python code within the resource section whose purpose was to scrape browsers’ credentials. We also observed that main.exe was compiled using Nuitka, a Python program designed to compile Python scripts into standalone executables. During the investigation, Rapid7 observed that main.exe did not execute properly, indicating an issue in the original source code.
Figure 7 - Code References to Nuitka
IOCs
IOC
Description
SHA256
JAVS.Viewer8.Setup_8.3.7.250-1.exe
JAVS Viewer 8.3.7 installer downloaded from the domain javs[.]com
Shown as having a valid signature: Subject: Vanguard Tech Limited
Found hosted on C2 over port 8000. Binary is packed with a Go binary, similar to the fffmpeg.exe backdoor. Communicates to the same C2 identified from fffmpeg.exe.
Shown as having a valid signature: Subject: Vanguard Tech Limited
Found hosted on C2 over port 8000. Binary is packed with a Go binary, similar to the fffmpeg.exe backdoor. Communicates to the same C2 identified from fffmpeg.exe.
Note: This binary was later removed from the C2 and replaced with ChromeDiscovery.exe
Users who have version 8.3.7 of the JAVS Viewer executable installed are at high risk and should take immediate action. This version contains a backdoored installer that allows attackers to gain full control of affected systems.
To remediate this issue, affected users should:
Reimage any endpoints where JAVS Viewer 8.3.7 was installed. Simply uninstalling the software is insufficient, as attackers may have implanted additional backdoors or malware. Re-imaging provides a clean slate.
Reset credentials for any accounts that were logged into affected endpoints. This includes local accounts on the endpoint itself as well as any remote accounts accessed during the period when JAVS Viewer 8.3.7 was installed. Attackers may have stolen credentials from compromised systems.
Reset credentials used in web browsers on affected endpoints. Browser sessions may have been hijacked to steal cookies, stored passwords, or other sensitive information.
Install the latest version of JAVS Viewer (8.3.8 or higher) after re-imaging affected systems. The new version does not contain the backdoor present in 8.3.7.
Completely re-imaging affected endpoints and resetting associated credentials is critical to ensure attackers have not persisted through backdoors or stolen credentials. All organizations running JAVS Viewer 8.3.7 should take these steps immediately to address the compromise.
Rapid7 Customers
InsightIDR, Managed Detection and Response, and Managed Threat Complete customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this activity:
Suspicious Process - Execution From Root of ProgramData
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2024-4978 with a vulnerability check expected to be available in today’s (Thursday, May 23) content release.
Vendor Statement
Justice AV Solutions provided the following statement to Rapid7 on Wednesday, May 22, 2024. According to JAVS:
“Justice AV Solutions (JAVS) is committed to providing our clients with secure and reliable software solutions. We recently identified a potential security issue with a previous version of our JAVS Viewer software (Version 8.3.7).
Through ongoing monitoring and collaboration with cyber authorities, we identified attempts to replace our Viewer 8.3.7 software with a compromised file. We pulled all versions of Viewer 8.3.7 from the JAVS website, reset all passwords, and conducted a full internal audit of all JAVS systems. We confirmed all currently available files on the JAVS.com website are genuine and malware-free. We further verified that no JAVS Source code, certificates, systems, or other software releases were compromised in this incident.
The file in question did not originate from JAVS or any 3rd party associated with JAVS. We highly encourage all users to verify that JAVS has digitally signed any JAVS software they install. Any files found signed by other parties should be considered suspect. We are revisiting our release process to strengthen file certification. We strongly suggest that customers keep updated with all software releases and security patches and use robust security measures, such as firewalls and malware protection.
JAVS service technicians typically install the Viewer software in question. We have all members of our service team validating installations of Viewer software on any potentially affected systems, specifically checking for the presence of the malicious file in question - fffmpeg.exe with three “f’s.” Note, the JAVS file ffmpeg.exe with two “f’s” is a legitimate file.
What You Should Do:
Manually check for file fffmeg.exe: If the malicious file is found or detected, we recommend a full re-image of the PC and a reset of any credentials used by the user on that computer. If Viewer 8.3.7.250 is the version currently installed, but no malicious files are found, we advise uninstalling the Viewer software and performing a full Anti-Virus/malware scan. Please reset any passwords used on the affected system before upgrading to a newer version of Viewer 8.
Upgrade Your JAVS Viewer: We strongly recommend that all users of JAVS Viewer software upgrade to the latest version (Version 8.3.9 or higher). Upgrading is simple and can be completed by following the instructions included in the software update notification or by visiting our website at https://www.javs.com/downloads/
We appreciate your understanding and cooperation in maintaining a secure environment for all our users. If you have any questions or concerns, please do not hesitate to contact our support team at 1-877-JAVSHLP (877-528-7457).
Sincerely,
The Justice AV Solutions Security Team”
