⭐ SOC287 — Arbitrary File Read on Checkpoint Security Gateway [CVE-2024–24919] (EventID: 263) —…

Today, we are analyzing a web exploitation incident targeting a Check Point Security Gateway identified as CP-Spark-Gateway-01 (172.16.20.146). The alert was triggered on June 06, 2024, at 03:12 PM, when an external IP address 203.160.68.12 initiated a suspicious HTTP POST request to the VPN portal endpoint /clients/MyCRL, containing a directory traversal payload (aCSHELL/../../../../etc/passwd). This activity is associated with CVE-2024–24919, a critical vulnerability that allows unauthenticated attackers to read sensitive files from affected Check Point devices by exploiting improper input validation in the web-based VPN interface, potentially leading to credential exposure and further network compromise.

EventID :_ 263 Event Time : Jun, 06, 2024, 03:12 PM Rule : SOC287 — Arbitrary File Read on Checkpoint Security Gateway [CVE-2024–24919] Level : Security Analyst Hostname : CP-Spark-Gateway-01 Destination IP Address : 172.16.20.146 Source IP Address : 203.160.68.12 HTTP Request Method : POST Requested URL : 172.16.20.146/clients/MyCRL Request : aCSHELL/../../../../../../../../../../etc/passwd User-Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0 Alert Trigger Reason : Characteristics exploit pattern Detected on Request, indicative exploitation of the CVE-2024–24919. Device Action : Allowed Type : Web Attack_

First, let us understand what the CVE-2024–24919 vulnerability is about.

Technical Details of CVE-2024–24919

Product:_ Check Point Software Technologies Security Gateways (VPN / Remote Access Portal, including CloudGuard and on-prem appliances) Type: Information Disclosure (Arbitrary File Read via Path Traversal) CVSS: 8.6 (High) Attack Vector: Network-based, no authentication required Core Flaw: Improper input validation in VPN web portal endpoints allowing path traversal Root Cause: The application fails to properly sanitize user-supplied input in HTTP requests. Attackers can manipulate file path parameters using directory traversal sequences (like moving outside intended directories), causing the system to access arbitrary files on the underlying filesystem._

What is CVE-2024–24919 ?

CVE-2024–24919 is a vulnerability in Check Point Security Gateways (especially VPN-enabled devices) that allows attackers to read sensitive files from the system without logging in. The issue is caused by a path traversal flaw in the web-based VPN portal, where an attacker can send a specially crafted HTTP request often targeting a specific endpoint like /clients/MyCRL and manipulate file paths using sequences like ../ to access files outside the intended directory. By doing this, they can retrieve critical data such as password hashes, VPN configuration files, or cached credentials stored on the device. Attackers typically start by scanning the internet for exposed Check Point devices, then send these malicious requests to extract data; once they obtain credentials or hashes, they may crack them offline or reuse them to gain legitimate VPN access, effectively compromising the network.

Overall Attack Flow of CVE-2024–24919

1. Attackers begin by scanning the internet for publicly exposed Check Point Security Gateways, especially those with Remote Access VPN or web portals enabled. Tools like mass scanners or search engines (e.g., Shodan-like platforms) are commonly used to identify reachable targets over HTTPS.
2. Once a target is identified, the attacker sends specially crafted HTTPS requests to specific VPN web portal endpoints. These requests attempt to exploit improper input validation in how the device handles file path parameters.
3. By abusing a path traversal weakness, the attacker tricks the system into returning files from unintended directories. Instead of just accessing allowed resources, the system responds with sensitive internal files. No authentication is required at this stage.
4. The attacker downloads valuable data such as: Password hashes (local or LDAP-related), VPN configuration files, Cached credentials or session-related data. This step is critical because it provides the foothold needed for deeper access.
5. The attacker attempts to crack stolen password hashes offline or reuse credentials directly (password spraying / credential stuffing). If successful, they gain legitimate VPN access as a valid user.
6. Using compromised credentials, the attacker logs into the VPN portal like a normal user. At this point, the attack transitions from exploitation to a standard authenticated intrusion.
7. Inside the network, the attacker enumerates systems, users, shares, and services. They may query Active Directory, scan internal IP ranges, and identify high-value assets.
8. The attacker moves deeper into the network using stolen credentials or additional exploits. They may establish persistence (new accounts, scheduled tasks, or backdoors) to maintain access even if the original vulnerability is patched.
9. Final goals vary depending on the threat actor: Data exfiltration, Ransomware deployment and Long-term espionage / access maintenance.

How CVE-2024–24919 exploit works?

This script is essentially a basic scanner for CVE-2024–24919 that tests whether a target Check Point VPN gateway is vulnerable to an unauthenticated file-read issue. From an investigation perspective, it loops through a list of IPs and sends crafted HTTPS POST requests to a specific VPN portal endpoint (/clients/MyCRL), embedding a manipulated file path in the request body to try to access sensitive system files (like /etc/passwd). If the server responds with recognizable content (e.g., usernames such as "root"), the script flags the target as vulnerable, indicating that the gateway is improperly returning local file contents. After identifying a vulnerable host, it optionally allows further probing by requesting different file paths to see what else can be accessed. In practice, if successful, this confirms that an attacker could extract sensitive data from the device, which could then be used for credential theft and deeper network compromise.

We began the investigation by reviewing all logs related to the source IP 203.160.68.12 communicating with the destination host 172.16.20.146. This included firewall logs, OS logs, and device telemetry.

Firewall Logs

As per the incident details the attack started from '203.160.68.12' source ip, so let's search logs for the source ip. so we found total 3 web requests firewall logs from "203.160.68.12" source to "172.16.20.146" destination.

The first log is observed at Jun, 06, 2024, 03:12 PM where POST "aCSHELL/../../../../../../../../../../etc/passwd" http web request sent from source to 172.16.20.146 is interacting with the internal gateway 172.16.20.146 over port 4433, which strongly indicates exposure of a Check Point VPN or Mobile Access service. a POST request to /clients/MyCRL containing a directory traversal payload targeting /etc/passwd. This is a strong indicator of an exploitation attempt associated with CVE-2024–24919. The attacker is likely verifying whether the target is vulnerable by attempting to read a non-sensitive but structured system file. Access to /etc/passwd allows enumeration of valid system users, which is typically the first step in a controlled exploitation sequence. The use of multiple ../ sequences confirms an intentional attempt to break out of the web root and access underlying OS-level files. At this stage, the attacker is performing validation of file read capability, not yet full exploitation.

Second log observed at Jun, 06, 2024, 03:14 PM. The second log escalates the activity, where the attacker targets /etc/shadow, a highly sensitive file containing password hashes. This indicates that the attacker has likely confirmed the vulnerability in the previous step and is now attempting credential extraction. If successful, this step enables offline password cracking and potential reuse of credentials for VPN or internal access. The reuse of the same user-agent string and close timing between requests also indicate a single attack session.

Third log observed at Jun, 06, 2024, 03:15 PM. The third log shows a POST request to the root endpoint / without any visible payload. This likely represents a follow-up action after the exploitation attempts. The attacker may be checking server response behavior, validating session persistence, or preparing for further interaction depending on the success of earlier requests. In some cases, this type of request is used to confirm connectivity, test for additional vulnerabilities, or maintain interaction with the service.

Web Server Access Logs

The web server access log provides additional confirmation of a targeted exploitation attempt against the /clients/MyCRL endpoint linked to CVE-2024–24919, and also helps validate the likelihood of partial success. The sequence starts with a GET request from 203.160.68.12 at 15:12:43, which appears to be a reconnaissance step to confirm endpoint availability, followed almost immediately by a POST request carrying a directory traversal payload targeting /etc/passwd. Notably, this request receives a 200 response with a significantly larger response size (1256 bytes) compared to the initial request, which strongly indicates that the server may have returned actual file content. The presence of the aCSHELL marker along with deep traversal sequences (../../) reinforces that this is a crafted exploit attempt rather than malformed traffic, and the successful response suggests that sensitive file disclosure may have occurred at this stage.

A few moments later, at 15:14:02, a similar exploitation attempt is made from a slightly different external IP (203.160.68.13), this time targeting /etc/shadow. Unlike the previous request, this attempt results in a 403 response, indicating that access was denied or blocked, possibly due to security controls or partial mitigation being triggered after the earlier successful request. This transition from a successful /etc/passwd access attempt to a blocked /etc/shadow request suggests that the attacker was able to validate the vulnerability and partially exploit it before controls intervened, which raises concerns about what data may have already been exposed.

The final notable activity occurs at 15:15:01, where the original attacking IP sends a POST request to the root path / and receives a 200 response, indicating continued interaction with the server after the exploitation attempts.

Source IP Address Information

The source IP address 203.160.68.12 belongs to China Unicom (Hong Kong) Operations Limited and originates from Hong Kong. It has been reported as malicious across multiple threat intelligence platforms, with several entries categorizing it under port scanning and web application attacks.

The same IP is also mentioned in the advisory titled "Active exploitation of Check Point Remote Access VPN vulnerability (CVE-2024–24919)" published by mnemonic, where it is listed under the IOC section as an exploitation source.

Additionally, in AlienVault, this IP is associated with Check Point VPN zero-day exploitation activity.

In the Let's Defend threat intelligence database, the IP was added on Jun 06, 2024, 01:44 PM and tagged under [CVE-2024–24919], further confirming its involvement in active exploitation campaigns.

Machine level investigation

While checking the destination IP 172.16.20.146 in the Endpoint Security section, we found that the host is identified as CP-Spark-Gateway-01 and is running Check Point R80.20 Gaia OS, which is vulnerable to this zero-day attack. The last recorded login on the system was Jun 05, 2024, 09:05 AM.

The process execution chain shows a continuous sequence of Check Point services spawning under the root context, which in itself is expected for core gateway operations. processes like vpnd -> fglog -> fglogread -> dmp -> securexl indicate log handling, packet acceleration, and core inspection activity, which may reflect internal processing triggered by abnormal or high-volume crafted requests. The presence of cpstop followed by cpstart within the same execution chain is a strong indicator that core services were restarted, which is not typical during stable operations. This could be due to multiple reasons: administrative intervention, automated recovery, or instability caused by exploitation attempts.

The presence of multiple sequential IP addresses (203.160.68.10 to 203.160.68.20) within a very short time window, all originating from the same geolocation (China), strongly indicates distributed scanning or coordinated exploitation activity, rather than normal user traffic. this IP rotation suggests an organized attempt to repeatedly test or exploit the vulnerable endpoint using different source identities. Such behavior typically indicates that the system was under active external reconnaissance or exploitation campaign, and not isolated manual probing.

The overall investigation shows that a targeted exploitation attempt of CVE-2024–24919 against the Check Point gateway CP-Spark-Gateway-01 (172.16.20.146) originating from the external IP 203.160.68.12, later supported by nearby IPs in the same range, indicating coordinated activity. The attacker began with reconnaissance by accessing the VPN endpoint /clients/MyCRL, followed by crafted POST requests containing a directory traversal payload (aCSHELL/../../../../…/etc/passwd), a known indicator of this vulnerability. The server responded with HTTP 200 and a larger response size, strongly suggesting successful file disclosure of /etc/passwd, confirming the gateway was vulnerable. Shortly after, the attacker escalated by attempting to access /etc/shadow to extract password hashes, which was blocked with a 403 response indicating partial mitigation or access control enforcement. Additional follow-up requests to the root endpoint (/) showed continued interaction, likely to validate access or maintain session activity. Supporting evidence from firewall and web logs, consistent user-agent strings, repeated use of the vulnerable endpoint, and threat intelligence linking the source IP to active exploitation campaigns all confirm malicious intent. Overall, the attack was partially successful, resulting in sensitive file exposure, and represents a clear case of unauthenticated file read leading toward credential theft and potential VPN compromise.

Attack Timeline

1. 06-Jun-2024, 03:12 PM — External IP 203.160.68.12 initiated a connection to the Check Point gateway CP-Spark-Gateway-01 (172.16.20.146) over HTTPS (port 4433), confirming exposure of the VPN portal.
2. 06-Jun-2024, 03:12 PM — The attacker sent a crafted POST request to /clients/MyCRL containing a directory traversal payload targeting /etc/passwd, indicating an attempt to validate file read access.
3. 06-Jun-2024, 03:12 PM — The server responded with HTTP 200 and a larger response size, suggesting successful retrieval of /etc/passwd and confirming the vulnerability.
4. 06-Jun-2024, 03:14 PM — A follow-up POST request was sent targeting /etc/shadow, showing escalation from validation to credential extraction.
5. 06-Jun-2024, 03:14 PM — The /etc/shadow request was blocked with a 403 response, indicating partial mitigation or access restriction after initial exposure.
6. 06-Jun-2024, 03:15 PM — Additional POST request to / endpoint observed from the same source, likely to verify connectivity or maintain interaction with the service.
7. 06-Jun-2024, 03:15 PM — Multiple similar requests observed from nearby IPs (203.160.68.10–20 range), suggesting coordinated scanning or exploitation activity.
8. 06-Jun-2024, 03:17 PM — No confirmed VPN login observed, but successful file disclosure indicates risk of credential exposure and potential follow-on compromise.

MITRE Attack Mapping

Let's Defend Playbook Answer

1. Is Traffic Malicious? Malicious
2. What Is The Attack Type? LFI & RFI
3. Check If It Is a Planned Test. Is the malicious traffic caused by a planned test? Not Planned
4. What Is the Direction of Traffic? Internet -> Company network
5. Was the Attack Successful? Yes
6. Do You Need Tier 2 Escalation? Yes

Containment Actions

1. The machine 'gateway CP-Spark-Gateway-01 (172.16.20.146)' is isolated from the network.
2. Block all identified malicious IPs (e.g., 203.160.68.12 and related range 203.160.68.10–20) at the firewall perimeter.
3. Temporarily disable the Remote Access VPN / Mobile Access portal if not business-critical.
4. Apply IPS/IDS protections or enable Threat Prevention blades to block known CVE-2024–24919 exploit patterns.
5. Terminate all active VPN sessions and force logout of connected users. Perform network-wide scan to identify other exposed or vulnerable Check Point gateways.

Eradication Actions

1. Immediately apply the official security patch / hotfix released by Check Point Software Technologies for CVE-2024–24919.
2. Rotate all credentials that may have been exposed: VPN user credentials, Local system accounts and LDAP / Active Directory integrated accounts.
3. Force password reset for all VPN users.
4. Revoke and reissue certificates if used for VPN authentication.
5. Review and clean up unauthorized accounts or suspicious changes.
6. Rebuild or reimage the gateway if compromise is strongly suspected.

Incident Artifacts

Source IP Address:_ 203.160.68.12 Additional IP Range Observed: 203.160.68.10–203.160.68.20 Destination IP Address: 172.16.20.146 Hostname: CP-Spark-Gateway-01 Vulnerable Endpoint: /clients/MyCRL Malicious Payload Pattern: aCSHELL/../../../../../../../../../../etc/passwd, aCSHELL/../../../../../../../../../../etc/shadow User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0_

Conclusion

In this incident, we observed active exploitation of the CVE-2024–24919 vulnerability targeting a Check Point Security Gateway, where an external attacker leveraged a crafted directory traversal request to access sensitive system files via the VPN web portal. The investigation confirmed that the attacker successfully retrieved /etc/passwd, validating the vulnerability, and subsequently attempted to access /etc/shadow for credential extraction, which was blocked. The activity was clearly automated and part of a coordinated campaign, supported by multiple source IPs and threat intelligence matches. This case highlights the critical importance of timely patching, restricting external access to VPN services and respond to such exploitation attempts before they lead to deeper network compromise.