MDR insights: how our SOC identified & responded to CVE-2024-3400

Security operations · 7 MIN READ · BRANDON OVERSTREET, KYLE PELLETT AND AARON WALTON · SEP 5, 2024 · TAGS: Alert / Expel Workbench / Malware / Managed security / MDR / SOC / Vulnerability

TL;DR

• CVE-2024-3400 is a Palto Alto Networks (PAN) vulnerability that allows for arbitrary file creation and access to the OS command line 
• We encountered it as a suspicious file and IP address related to the PAN firewall of a customer
• We cover how we remediated it for our customer, and walk you through our identification and response process at a technical, SOC level 

What it was and why it matters

In the world of cybersecurity, it’s crucial to stay vigilant and constantly monitor for any potential threats within your network. This includes awareness of early-stage CVE-2024-3400 PAN-OS arbitrary file creation, which can lead to an OS command line injection. 

Critical vulnerability and exploitation (CVE) 2024-3400 is a vulnerability within Palo Alto Networks (PAN) PAN-OS. It allows unauthenticated users to create an arbitrary file and execute code that grants root privileges to the bad actor.

At Expel, our SOC has encountered and resolved this CVE for our customers, and we’re sharing how we traced activity back to the CVE even with limited visibility. 

Initial CVE detection 

The initial lead for this CVE was an “anomalous file EXE from a rare external location,” originating ‌from the PAN firewall IP address. One thing to note from the lead alert: it’s uncommon to see a two-letter file downloaded, let alone a two-letter file downloaded from the PAN firewall device. Initially, we were unaware that the file was downloaded to the PAN firewall appliance itself, but  we also noticed suspicious SMB scanning activity, which was another sign that deeper investigation was required. 

This screenshot shows the initial alert our SOC received on the rare file download attempt. The name of the file was dl.txt. Because a two-letter name is rare, it generated an alert for an anomalous file from a rare location.

Investigating the suspicious file

Our next step in the investigation was to acquire and evaluate a copy of the dl.txt file. We unpacked the malicious ELF binary dl.txt, and the contents related to the Sliver framework, which is an open source cross-platform adversary emulation/red team framework. Normally, it’s used to simulate an attack for security testing. But because of its suspicious nature, we investigated further to reveal that the dl.txt binary was specifically designed to act as a backdoor, allowing attackers to gain remote access and control over compromised systems. 

Next, we reviewed the network (DarkTrace) log files and identified outbound connections to a suspicious IP address. Expel’s SOC uncovered the bad actor hosting what appears to be the first stage payload. This connection shows the bad actor’s first stage of attack, where they check to see if process log_r (from the malicious file) is running. 

Then we reviewed the log_r file. This file was determined to be associated with the attacker’s first stage payload, and was identified from information gathered via the outbound connections to the unknown IP address. 

The log_r is the file the attacker transplanted into the system, and the command context from log_r showed it was used as a way to keep a persistent backdoor connection to carry out the next stage of the attack—using the Sliver framework in the dl.txt file to advance within the environment. ‌If it isn’t running yet, the bad actor will download the dl.txt file and execute it every hour. The crontab is a form of persistence for the attacker that completes the execution on the bad actor’s behalf, so they don’t have to manually execute the file every hour. 

After unpacking dl.txt, VirusTotal was used for hash analysis, uncovering that the binary being used was from Sliver Framework.

This is confirmation of the attacker payload hosted on the IP address.

The next step was for the SOC team to check the version history of PAN-OS running since we had access to the PAN appliance. The firewall showed that PAN-OS 11.1.0-h2 was running, which was another affirmative sign of CVE-2024-3400. PAN suggests that any version less than 11.1.0-h3 is affected by the CVE and should be updated immediately, which was the recommendation shared with the customer after discovery of the vulnerability. 

Checking the firewall revealed that PAN-OS 11.1.0-h2 was running. This OS version was affected by CVE-2024-3400 according to PAN, so this operating system version was more confirmation the CVE was being exploited for this customer.

Additional evidence of exploitation 

Once the exploitation was identified and remediated, we gathered additional evidence of the attempted exploitation to confirm what happened to justify the action needed from the customer. According to our research, there were multiple logs that showed signs of attempted exploitation and persistence. 

Gpsvc.log 

This log is located in the /var/log/pan/ directory, and was investigated because this log contained entries related to the vulnerability. According to Palo Alto, if the session cookie GUID (“session(“SESSID cookie GUID”)”) doesn’t resemble a GUID and instead contains a file system path or embedded shell command, it could be related to an attempted exploitation of CVE-2024-3400. In this particular case, the log included a file system path instead of the expected SESSID cookie GUID, shown below. 

Device_telemetry_send.log

The Device_telemetry_send.log is another place to look for exploitation evidence related to this particular CVE. Device telemetry in PAN-OS 11.0 collects data from the firewall (or Panorama) and uploads it to Cortex Data Lake. This data powers telemetry apps, which help monitor and manage device health, performance, and configuration. It also enhances threat intelligence, intrusion prevention, and malware detection. 

This log contained evidence of injected commands and unusual patterns in the telemetry data, which was additional evidence of the exploitation. The log data is shown below. 

Within the Device_telemetry_send.log we also identified command injection related to the device telemetry functionality. At first glance, it looks standard, but after using Base64 decoding, the true nature of the data showed the bad actor attempting to pull down a file called r.sh from an IP address associated with internet service provider Guadalupe Valley Telephone Cooperative, Inc. This kind of technique is often used to hide the purpose of the string, which is why ‌decoding is necessary. 

After Base64 decoding, this string in the Device_telemetry_send.log showed evidence of suspicious behavior, where the bad actor attempted to download an unknown file from an unknown IP address.

Evidence of persistence 

After we located and found evidence of the attacker’s first payload, and found additional evidence of persistence, we went back and searched the log for more log_r entries. The results are shown below. 

And what do you know? In doing so, we found evidence within the mp-monitor.log of established connections to command and control which revealed connections between the firewall and the attacker’s IP address. This log provides statistics of a PAN firewall device, including active network connections, running processes, and incoming log rate. We used this to confirm our suspicions. 

Another search within the syslog-system.log revealed the execution of the hourly cron job setup by the attacker we initially found evidence of in the initial investigation.

And what do you know? In doing so, we found evidence within the mp-monitor.log of established connections to command and control which revealed connections between the firewall and the attacker’s IP address. This log provides statistics of a PAN firewall device, including active network connections, running processes, and incoming log rate. We used this to confirm our suspicions. 

Another search within the syslog-system.log revealed the execution of the hourly cron job setup by the attacker we initially found evidence of in the initial investigation.

These weren’t the only two logs we analyzed, but they’re great examples of how we search for evidence of attacks. Once the vulnerability was identified, we were able to retroactively search related logs for key phrases–like the IP address and file names–related to the specifics of the attack to identify indicators of compromise. 

The goal of this retroactive search is to identify all the indicators of compromise within the customer’s environment, so we can use the data to identify potentially compromised systems. 

Conclusion 

The biggest takeaway is the critical nature of this vulnerability. It lets attackers who don’t have a password run any commands with root access on the devices they’re attacking. This can lead to a system compromise. This problem in Palo Alto Networks’ PAN-OS software is the worst-case scenario and is being used in the wild. Immediate patching and thorough investigation of affected systems are crucial to minimizing the risk. It’s also important for companies to improve their security. Here at Expel, we have the knowledge to help you do just that.