Delving Into the SparkRAT Remote Access Tool

Introduction

This article provides an analysis of the most active CVEs for April 2025, highlighting trends in exploitation activity and offering insights into mitigation strategies. Alongside this analysis we dig into topical CVEs as well as scanning observed for SparkRAT servers. The data is derived from observed traffic and includes a focus on the top 10 CVEs, their long-term trends, and their relative activity over the past year.

Trending CVEs for March 2025

CVE-2017-9841, a PHPUnit Remote Code Execution vulnerability, remains the most exploited CVE this month. Regular readers will recall our coverage from May 2024 when we first detected a huge increase in scanning for CVE-2017-9841 that later decreased. Organizations should ensure that their PHPUnit installations are updated to secure versions or are otherwise shielded from malicious requests.

CVE-2019-9082, a ThinkPHP PHP Injection vulnerability, continues to see exploitation. This flaw allows remote code execution and should be addressed by updating to the latest ThinkPHP version. As we’ve recommended before, if you're using PHP you can check for the vulnerability by running phpunit --version. If it's in the range >=5.0.10, <5.6.3 or >=4.8.19, <4.8.28 you might just want to go ahead and roll incident response.

CVE-2022-24847, a GeoServer JNDI Lookup RCE vulnerability, is being actively targeted. Exploitation can lead to remote code execution. Organizations using GeoServer should apply the latest patches and review their configurations.

CVE-2020-8958 is a Guangzhou ONU Command Injection RCE that has made the top 10 most exploited consistently in recent months. With this CVE, default or stuffed credentials enable command injection, which as always is of great interest to attackers.

CVE-2022-42475 is a heap overflow vulnerability leads to RCE in FortiOS FortiProxy’s SSL-VPN. Fortinet drew attention to exploitation in the wild on April 10^th, and we’ll have some more to say about it later in this article.

Notably, May saw a significant drop in activity for CVE-2023-1389, a RCE vulnerability in TP-Link Archer routers.

Attacker Trends for April 2025

April saw a number of high profile incidents, with a number of reports of SSL-VPN appliances being targeted.

SSL-VPN Targeting

April bore witness a sharp rise in the number of exploit attempts against remote access “SSL-VPN” appliances from several vendors. Fortinet and Ivanti were both widely reported as being targeted.

Our sensor data corroborates statements from Fortinet’s own statements. On April 10^th Fortinet warned that “a threat actor was observed using known vulnerabilities to gain access to [FortiOS FortiProxy SSL-VPN] devices (e.g. CVE-2022-42475, CVE-2023-27997, and CVE-2024-21762)”.¹ F5 Labs has observed a two-fold increase in exploitation attempts for CVE-2022-42475 starting 2025-03-25. We have not seen recent activity for CVE-2023-27997 / CVE-2024-21762, but have observed minor levels of exploitation attempts in 2025-01 and 2025-02. This somewhat echoes findings from third parties: “During incident response operations, CERT-FR became aware of compromises that took place as early as the beginning of 2023”.²

By contrast, our data does not show exploitation attempts of Ivanti Connect Secure, CVE-2025-22457, although this could be down to the nature of our passive sensor implementation. It could also be explained by complexity of exploitation. Exploiting CVE-2025-22457 requires either a detailed understanding of memory corruption exploits, or a very robust PoC available in the wild. We suspect the latter to be the most significant factor. Our data does show very low levels of scanning beginning in April for URLs containing auth/url_admin/welcome.cgi. This URL is known to fingerprint the Ivanti Connect Secure version, which, among other things, would be a pre-step for selective targeting by more stealthy actors.

SAP NetWeaver Targeting

The technical nature of the SAP NetWeaver CVE-2025-31324 (CVSS 10) presents a very low bar to adversaries and leads to Remote Code Execution. Exploitation involves simply uploading a malicious JSP, a trivial task for even the least skilled attacker. Consequently, we’ve seen low-moderate levels of exploitation attempts as of 2025-04-29. Reporting from ReliaQuest suggests that the impact of this vulnerability is severe as “[BianLian and RansomEXX are] pursuing opportunistic attacks, likely aiming to deploy ransomware or gain access to sensitive enterprise systems for extortion”.³

SparkRAT C2 Scanning

In April, we detected hundreds of identical scanning attempts across the internet on both port 80 and 443. F5 Labs deduced that this was scanning for a particular version of a particular Remote Access Trojan’s Command & Control server. As a quick refresher, a Remote Access Trojan (RAT) is malware that covertly provides an attacker with full remote control and administrative access over an infected computer. A Command & Control server (C2) is malicious infrastructure for operators to issue commands to their RATs. Diagram 1 shows the relationship between an infected host running SparkRAT, its C2 server, and an operator issuing commands to an infected host via the C2 server.

Scanning Signature

All the observed scanning was identical and of this form:

POST /api/client/update?arch=amd64&commit=08059e95dacafe0bf6e5782f8e2c8ec9cd8c5a17&os=windows HTTP/1.1

Content-Type: application/octet-stream

User-Agent: SPARK COMMIT: 08059e95dacafe0bf6e5782f8e2c8ec9cd8c5a17

Secret: 3de172c65c5204dbce4c985d6616ca6fbbf337be4ddd40746307af802fa510a2

Accept-Encoding: gzip

Content-Length: 384

<binary data of length 384>

C2 Scanning Timeline

The summary of the timeline of scanning activity is as follows, with three different IP addresses scanning at different times for around 13 hours each, each making requests to 65%-85% of our sensors (and by extension, naively speaking, scanning 65%-85% of the internet). All scanning HTTP requests originated from the same Digital Ocean ASN (14061) – a cloud provider anecdotally popular for internet scans:
 

Digging Deeper Into the C2 Scanning

Investigating, we discovered a few leads:

1. The sha hash corresponded to a Github code commit¹ of the XZB-1248/Spark² repo tagged on 2023-02-01 as v0.2.1³.
2. The request path cropped up in an automated analysis of Linux malware⁴ that flagged the SparkRAT binary as malicious on 2024-10-17.
3. Hunt.io published an analysis of SparkRAT along with IoCs for Windows on 2024-04-23,⁵ and followed up with suspected DPRK macOS activity on 2025-01-28⁶.

Hunt.io asserts in their 2024-04-23 article:

“SparkRAT is] a particularly insidious malware … [which has seen use] in sophisticated attacks attributed by industry leaders like Microsoft, SentinelOne, and AhnLab to coordinated threat actors.”

Digging into the Linux malware analysis, the Suricata rules were as follows:

1. “ETPRO MALWARE Spark RAT User-Agent Observed” [SID: 2855151]
2. “ET MALWARE Win32/SparkRAT CnC Checkin (GET)” [SID: 2046669].⁷

The latter rule was credited to Sangfor⁸ on 2024-06-23⁹, who stated¹⁰ that SparkRAT was being leveraged by Patchwork APT - thought to be associated with Operation Monsoon¹¹. Notably, SparkRAT is not listed at the time of writing as software in use by Patchwork at attack.mitre.org.¹²

Inspecting the Public SparkRAT Code

Digging into the Github repository code, we determined:

1. The repository has over 500 forks (i.e. publicly visible copies).¹³
2. The repository asserts its usage is for educational uses only.¹⁴
3. The URL being scanned for is the undocumented feature for in-place updates.¹⁵
4. SparkRAT communicates exclusively over HTTP¹⁶, communicates primarily via websocket payloads using a point-in-time copy the melody library¹⁷, and obfuscates/encrypts its HTTP payloads¹⁸.
5. The SparkRAT client embeds an its configuration within its executable as obfuscated/encrypted JSON (384 bytes of 0x19¹⁹ dynamically replaced by the server when generating client binaries²⁰).
6. SparkRAT supports all the common RAT operations such as screenshotting, starting and killing processes.²¹
7. The SparkRAT server uses no persistence mechanisms. All exfiltration is “bridged” direct to the operator’s browser without touching the filesystem.²²
8. SparkRAT supports native operations for Windows, Linux, and MacOS²³, and compiles binaries out of the box for Go architectures amd64, arm64, 386, and arm for OSes darwin, linux, and windows.²⁴
9. Notably, the publicly available SparkRAT code does not have any reverse engineering or sandboxing countermeasures in evidence. However, symbol tables and debugger tooling information is stripped by default.²⁵
10. Subjectively speaking, the code is exemplary for Open Source. The code is clean, well-written, appropriately complex, and architecturally elegant.

Drawing Conclusions on SparkRAT

In closing on our SparkRAT investigation, it appears reasonable to conclude the following:

1. A single actor scanned for SparkRAT C2 servers (all scanning requests were identical and from the same ASN).
2. SparkRAT is seeing use in the wild across Windows, macOS, and Linux (hunt.io reporting and malware analysis).
3. SparkRAT is attracting interest from actors of unclear intent (500+ public Github forks).
4. SparkRAT accommodates many of the desired features for cross-platform operational use (comprehensive features list).
5. SparkRAT’s websocket C2 communications simultaneously increase detection (as connections are persistent, it appears) as well as decrease detection (as not all security tooling has robust visibility into websocket comms).
6. Analysis countermeasures may not yet be implemented in SparkRAT, and if they are, these enhancements are not publicly shared on Github.
7. SparkRAT was written by experienced software engineers (code quality and design).

Top CVEs for April 2025

In April, CVE-2017-9841 led the activity with nearly 60,000 exploitation attempts (as shown in Table 1). The remaining CVEs saw an order of magnitude less activity and are almost exclusively RCEs with CVSS in the range 7 to 10. Notably, the AvertX CVE-2020-11625 is not an RCE, has a CVSS 5.2, and a very low EPSS (<0.01). Also of interest is that the ThinkPHP Lang Parameter LFI RCE, CVE-2022-47945 is the only CVE with a CVSS >9 that is not on the Known Exploited Vulnerability list as of end of April.
 

Long Term Targeting Trends

CVE-2017-9841 continues to dominate the top spot in April, with a significant number of exploitation attempts (see Figure 2). CVE-2019-9082 and CVE-2022-24847 maintain their positions in the top three, while CVE-2020-8958 and CVE-2022-42475 show increased activity compared to previous months.

The key long-term trend in May has been the decline of activity around TP-Link’s CVE-2023-1389 (see the highlight below in Figure 3). All other CVEs remain relatively stable in their traffic volume trends. There are some slight upticks in volume to be seen for CVE-2022-42475 and CVE-2020-8958, but nothing significant enough to be considered a change in trend at this point.

Conclusion

In April, CVE-2017-9841 remained the most actively exploited vulnerability, following the trend observed in prior months. SSL-VPN appliances from Fortinet and Ivanti saw reported targeting, however of the two only Fortinet targeting was in evidence in our data. SAP NetWeaver saw low levels of targeting, likely due to its ease of exploitation. Investigation of SparkRAT C2 scanning led to analysis of the implementation of both client and server components. TP-Link’s CVE-2023-1389 was the only significant long term trend deviation, dropping to 10^th place for the month.