It has been 31 days since the initial public disclosure of a remote code execution (RCE) critical vulnerability in the Apache Log4j logging library that upended enterprise security at the close of 2021. In that time, since the initial CVE-2021-44228 (critical), we’ve already seen five more related CVEs

• CVE-2021-45046 (critical)
• CVE-2021-4104 (high)
• CVE-2021-42550 (moderate)
• CVE-2021-45105 (moderate)
• CVE-2021-44832 (moderate))

and several updates to the library from 2.15.01 on December 9th to 2.17.1 on December 28th.

The importance of this class of vulnerabilities in such a ubiquitous library must not be forgotten with the next spin of the cyber news cycle: with millions of vulnerable devices, attacks are likely to continue for as long as such devices running unpatched software can be found by threat actors.

In this post, we round up all the activity to date concerning Log4Shell exploits to underscore the importance of timely discovery and patching of affected systems.

Log4j Initial Impact | Criminals and Researchers Equally Alert

As described in more detail here, there are two novel characteristics of a Log4j attack:

1. The attacking string can be injected into any user input that will be logged such as an http header, a username, or a file name.
2. The server the attacker communicates with and the server being attacked can be completely different and even located within different networks. In this case, internal logging servers located within trusted networks can suddenly communicate with attackers on the internet.

These characteristics provide a simple and potent tool and it took less than 24 hours after public disclosure of CVE-2021-44228 for attackers to generate over 60 permutations of the attack string.

Within hours of the public disclosure, we saw discussion and adoption of the issue within well-known underground Russian crime forums.

Researchers in the Chinese hacking community also claimed to have seen evidence of fast-automated exploitation tools Log4j_RCE_Tool, ReverseShell PoCs and an increasing number of articles on exploiting additional JNDI vulnerabilities in IBM WebLogic servers.

Meanwhile, researchers found that their Log4j honeypots were lighting up with alarming speed within 24 hours of the initial disclosure.

December 2021 | Log4Shell Attacks In the Wild

The first wave of attacks using the Log4Shell exploit were relatively unsophisticated actors dropping various cryptominers on victims. Perhaps most audacious of these was a reported 8-day long hack of HP AMD-based 9000 EYPC servers that was used to mine around 3.4 million Raptoreum coins, with an approximate value of $110,000. It is thought that the attackers were able to cash-out about half of the coins they mined before the operation was shut down.

Miner attacks were quickly followed with the appearance of a number of new ransomware families taking advantage of Log4j as a means of initial access, such as Khonsari ransomware. Attackers exploited Log4j to download and launch a malicious Java class file, which then retrieved the Khonsari ransomware payload from a C2.

Additional ransomware families soon followed, including TellYouThePass. This family had been relatively dormant prior to the Log4j vulnerability disclosure. TellYouThePass has both Windows and Linux variants, allowing it to attack the majority of servers likely to be vulnerable to Log4j exploitation.

Conti Attacks Log4j-Vulnerable Devices Not Exposed to the Public Internet

Within days of the flaw being disclosed, Conti ransomware campaigns were reportedly observed taking advantage of the vulnerability, with multiple campaigns focused on high-value vCenter environments. This development is noteworthy as the target machines were not necessarily exposed to the public internet. Rather, where the Conti operators had already gained an initial foothold into a target’s network, they exploited Log4j to compromise and encrypt vulnerable vCenter servers within the network.

Naturally, the Emotet crew has been taking advantage of Log4j as well. For example, vulnerable servers were quickly compromised and used for staging and payload hosting within the greater Emotet network. While we fully expect Emotet to embrace Log4j for direct delivery, we have yet to observe this development. However, we do currently see the use of Log4j to deliver Cobalt Strike Beacons, which can then be followed by any number of payloads.

In mid-December, Vietnamese crypto-exchange ONUS was attacked via exploitation of Log4j. The attack likely occurred within two to three days of the initial Log4j disclosure. The company patched their vulnerable servers sometime after the 13th of December, by which time the company had already been breached. The attackers later attempted to extort the company out of $5 million. For that amount, the attackers offered not to leak a cache of stolen data including PII. After the Fintech firm refused to pay, the attackers attempted to sell this data on a well-known hacking forum on December 25th:

Ransomware operators and extortionists are not the only ones getting in on the action. The actors behind Dridex have also expediently adopted the use of this exploit for their own nefarious purposes. In mid to late December, we saw mass distribution of Dridex by way of Log4j. In most cases, the exploit was used to load a malicious Java class, followed by a .HTA file containing a VBScript. From there we see more of a standard DLL-based flow.

January 2022 | Regulators and CISA Add Pressure to Remediate Log4j

On January 4th, the pressure for enterprises to ensure they have taken appropriate steps to remediate assets running vulnerable Log4j libraries was ramped up even further by the FTC.

Noting that Log4j “poses a severe risk to millions of consumer products” and that the vulnerability is being widely exploited by a growing set of threat actors, the FTC said on January 4 that it will

Meanwhile, on Jan 6, 2022 CISA noted that, based on submissions to the agency’s catalog, there are at least 2800 distinct products that contain Log4j. The agency estimates that despite the determined action by many admins and security teams during December 2021, there are likely still “hundreds of millions” of individual devices still affected by the Log4j vulnerabilities.

What Comes After Log4j?

Log4j could be just the the beginning of a whole new class of bugs. It turns out that the JNDI API is very attractive as a means of compromise as it allows simple unauthenticated remote code execution. A new JNDI-based “Log4j-like” critical vulnerability was disclosed on Jan 7, 2022. Tracked as CVE-2021-42392, this related RCE flaw was discovered in H2 database consoles, an open-source relational database management system written in Java. Although far from as widespread as the Log4j vulnerability, it is estimated to affect almost 7000 assets including popular frameworks like JHipster, Play framework and Spring Boot.

Conclusion

Unfortunately for overworked admins and security teams, a new year doesn’t mean an end to old problems, and exploitation of the Log4j and related JNDI vulnerabilities is going to be haunting many defenders for some time to come. Again, we urge all to stay ahead of the Log4j situation and ensure vulnerable software is patched to the latest version of Log4j or removed where that is not possible.

If there’s any silver lining to this dark cloud it is that in order for threat actors to capitalize on vulnerabilities, they need to engage in malicious behaviour, and that’s where on-device, AI-powered endpoint protection comes into its own. Whether its cryptominers or malware loaders, ransomware or banking trojans, deploying an autonomous detection and mitigation solution is an essential part of defending the modern organization from compromise.

If you would like to see how SentinelOne can help defend your organization, contact us or request a free demo.

Cybersecurity can seem like a bit of a zoo these days. There are myriad problems to solve as the landscape changes under our feet with new technologies, evolving business needs, and an attack surface that continues to expand. Into this mix, add more vendors, more consultants and more experts, each with bold statements on how to win the war against cyber threat actors.

Unfortunately, while many of these attempts to make enterprises safer may be genuine, there are a lot of blanket statements out there that can undermine a CISO’s efforts to secure the business. In this post, I will try to tackle the most oft-repeated cybersecurity misconceptions we see thrown at CISOs.

1. Windows Security Is Enough To Secure Your Microsoft Endpoints

Who is the biggest security vendor of them all? Before taking a mental inventory of the major 3rd party players that no doubt immediately spring to mind, it might come as a surprise to realize that they are all outstripped by Microsoft, with its unique position as both OS vendor and vendor of security software for its own OS, variously known as ‘Microsoft Defender’, ‘Windows Defender’, and now ‘Windows Security’.

2021 was another bumper year of Microsoft vulnerabilities, exploits, and breaches, with threat actors taking quick and merciless advantage of Microsoft vulnerabilities in Exchange Server like ProxyLogon and ProxyShell. Those vulnerabilities were followed by PrintNightmare, which in turn was followed by HiveNightmare.

Microsoft Defender did little to halt any of the ransomware attacks by Hafnium and Conti gangs that exploited such vulnerabilities, and the product was itself also in the wars after it was revealed Defender contained a privilege escalation vulnerability for over 12 years.

Recent history suggests that CISOs that rely on an OS vendor to win a fight against ransomware are going to be on the losing side of the battle.

2. Macs are Safe ‘By Design’

Unlike Microsoft, Apple is not in the business of selling security software in an attempt to protect its own products, but it still actively promotes the security of macOS as one of the unique selling points of Macs over other hardware. Accordingly, Apple has a vested interest in discouraging the perception that third party security controls are required for Macs in the enterprise just as much as they are for other endpoints.

Apple admitted earlier this year that macOS does have a problem with malware, and while few companies use Macs as servers or network controllers, thus sparing them the attention of ransomware operators, they are extremely popular among both C-Suite executives and developers. This makes enterprise Macs juicy targets for threat actors interested in high-value targets, and the new macOS malware seen appearing over the last 12 months has mostly been espionage and backdoors directed at specific targets.

Meanwhile, Mac users themselves are largely unaware of the many ways that malware can and does beat the built-in security technologies used by Apple. The Mac’s built-in security relies heavily on code-signing, certificate revocation checks and legacy file signatures. Threat actors have little trouble in bypassing these, and like Microsoft Windows, the complexity of operating system software ensures that critical bugs are patched on an increasingly more frequent basis.

On top of that, the Mac’s built-in security controls offer no visibility to users or admins. As a CISO, how would your admins know if any of the Macs in your fleet were infected with a backdoor, spyware or other macOS malware without external security software to offer that visibility?

3. Prevention Isn’t Possible, and Detection Is Enough

It’s become a trope among legacy AV vendors in their attempts to excuse the failures of AV Suites and EPP to claim that prevention is impossible, and post-infection detection and quarantine is the only realistic goal.

But we are in 2022, we have had machine learning and AI at our disposal for years now, and there is no reason why any CISO should accept that a vendor cannot prevent file-based malware pre-execution or on-execution.

Vendors that rely entirely on signature-based detection should supplement or replace their detection engines with static AI engines that can prevent most types of malicious PE files. More importantly, CISOs should reject vendors that tell them prevention isn’t possible.

4. Zero Trust Is Achievable For Most Organizations

The tried-and-trusted adage that “You are only as strong as your weakest link” gains new poignancy in today’s move to Zero Trust environments. While embracing Zero Trust is part of the right direction in which to travel to reduce your attack surface, the reality is that most organizations cannot effectively implement a complete Zero Trust Architecture (ZTA) across multiple assets and security systems.

Organizations should exercise caution when vendors offer a “Zero Trust SKU”. Beyond the marketing spiel, achieving a ZTA security model requires integration across all technologies. There’s no “plug-and-play” way to transform your organization overnight. Indeed, moving from a legacy perimeter-based security model to a ZTA security model is a multi-year journey, while attacks on businesses occur on a daily basis.

Like many developments in enterprise security, ZTA offers promise but it is no panacea. CISOs should beware vendors that tell them ZTA is a magic bullet that can solve all their security headaches.

5. Mobile Security Is Not a Must

Incredibly, there are vendors (and security practitioners) that still haven’t woken up to the reality of mobile devices in the enterprise. Sometimes, humans act like something doesn’t exist if they simply refuse to see it, but we have been checking our business emails and accessing work data from our mobile devices for years now. Most organizations understand that attempts to stop users conducting work tasks on their mobile devices leads to an unacceptable impact on productivity.

The mobile space is dominated by two main OS vendors, Google and Apple, and both understand the necessity of mobile security, although they take very different approaches to it. Recently, Google explained how an iOS zero-day, zero-click vulnerability had compromised Apple users. The technical level is beyond most skilled programmers and security professionals, let alone ordinary users.

Despite that sophistication, that exploit wasn’t developed by a nation-state actor but by the NSO Group, a private enterprise. In such a climate, where profit-driven attackers can invest that level of expertise into compromising our mobile devices, what business with intellectual property to defend, customer data to protect (and regulatory fines to avoid) can afford to pretend that mobile security is optional?

Mobile attacks are real and CISOs should apply mobile threat defense measures to keep track of user and device behavior and actions.

6. Backups Will Protect You Against Ransomware

The world of information security moves fast, and what was true yesterday (or, to be frank, a few years ago now) is not necessarily true today. Cast your mind back to NotPetya and WannaCry in 2017, and the hard-learned lesson that businesses without backups were setting themselves up as hostages to fortune, or rather the misfortune of being hit by ransomware.

The lesson didn’t go unheeded either by businesses or attackers, and by 2019 we saw the first human-operated ransomware gangs – Maze and DoppelPaymer – pivot to the double-extortion method: denial-of-access to files via encryption with the threat of public data leaks on top. Now, backups didn’t get companies off the hook if they valued the privacy of their data.

Double extortion soon became the standard MO for the majority of ransomware gangs, and some even went so far as to threaten to leak the data of clients or to ransom the clients of victim organizations.

Even so, some organizations were prepared to bite the bullet, risk data leakage, recover from backups and deny criminals a pay-day. Unfortunately, this only led the criminals to raise the stakes to triple extortion: on top of the threat of leaked data and file encryption, they started flooding victim companies with DDoS attacks to force them back to the negotiation table.

The lesson for CISOs is this: ransomware operators are flush with cash from previous victims. They can afford to buy large-scale botnets and hit your network with DDoS till you pay; they can afford to buy Initial Access from other criminals, and they can afford to pay human operators (aka “affiliates”) to carry out attacks. Backups mean nothing in today’s double and triple extortion ransomware threatscape. What matters is preventing compromise in the first place.

7. The Ransomware Threat Can Be Solved By Government

We’ve seen multiple worthy and valiant attempts to fight the growing surge in ransomware coming out of the U.S. government’s new focus on cybercrime.

The Colonial Pipeline attack, the JBS meat-supplier attack and others have created a growing concern for enterprises, as they feel they are left alone in the battle to keep our way of life safe. As laudable as the government’s efforts to take action are, cybercriminals are – by their very nature – undeterred by law enforcement.

No sooner had Biden and Putin discussed a crackdown on criminals that attacked healthcare and other critical infrastructure organizations than new groups emerged specifically to do just that. Where some criminals fear to tread, others will happily take their place if they sniff an opportunity to make money. Federal laws don’t exempt us from locking our own doors.

Yes, government help is always welcome. No, government help isn’t going to alleviate the need for enterprises to protect their businesses against crime.

8. You Don’t Need Humans If You Implement Automation

The cybersecurity skills shortage is real, but while automation can make valuable contributions to productivity and efficacy, automation will never replace the human element in the cybersecurity equation.

Risk is not static, and the risk surface constantly grows and changes as organizations mature and expand their businesses. More services, more production servers, more flow, and more customer data make the challenge to reduce risk an ongoing journey rather than a single task that can be completed with some consolidated effort. As there is no silver bullet to understand enterprise risk or quantify the means to keep a business safe, there will always be a need for cybersecurity talent that can innovate, assess and close these gaps.

Attack vectors are also constantly evolving. Three years ago, organizations relied on static analysis of PEs and other executable files to detect and prevent malware. Soon after, we started seeing fileless, script-based attacks, and lateral movement attempts successfully penetrating enterprise networks. A massive storm of supply chain attacks, like SolarWinds, Kaseya, and more have added yet another dimension to risk management. Meanwhile, the ransomware economy created a massive network of affiliates that used new spam techniques to bypass traditional solutions.

Yes, humans need technology to help scale, maximize productivity, eliminate mundane tasks, and create focus on critical items needing attention, but the best case scenario is that cybersecurity automation will reduce the growing landscape and attack surface.

CISOs will still need smart people who can connect, operate and triage all that attackers (with their own automation tools to hand) will continue to throw at us.

9. MDR Is All You Need To Stay Safe

While automation will never replace the need for human analysts, there is a converse to that, too: humans will never be able to detect, respond and remediate identifiable attacks as fast as computers. We need to use our human and computer resources in ways that are appropriate to the tasks each is best suited to.

Humans will do far better at triaging the edge cases, unknowns and false positives, but on-device AI that never sleeps and works at the speed of your CPU will beat attackers much faster than a remote MDR analyst in the cloud getting a delayed and partial feed of your network telemetry.

Yes, MDR offers added-value to a good next-gen AI endpoint protection agent. No, MDR is no substitute for on-device, autonomous protection, as the 2020 MITRE results convincingly proved.

Conclusion

There’s no escaping the fact that cybersecurity is a complex business, but getting the basics right is the first step. Reduce your dependencies on OS vendors, deploy on-device endpoint protection that offers visibility across your entire estate, and retain cybersecurity talent: these are all sound starting points for every CISO.

Meanwhile, try to see through the misconceptions that are passed around on a regular basis. I’ve called out nine of the most common ones I hear in this post, but there are undoubtedly far more howling in the wind. What other well-intentioned statements that do more harm than good are out there? We’d love to hear your thoughts on LinkedIn, Twitter, and Facebook!