Thread by @SophosLabs

NEW on #Log4Shell

Logjam: #Log4j exploit attempts continue in globally distributed scans, attacks

China and Russia, Kinsing miner botnet dominate sources of exploit attempts...

1/16

Since the first vulnerability in the Apache Foundation’s Log4j logging tool was revealed on December 10, three sets of fixes to the Java library have been released as additional vulnerabilities were uncovered. 2/16

This rapid iteration of fixes has left software developers and organizations worldwide scrambling to assess and mitigate their exposure with nearly daily-changing guidance.

In the meantime, we’ve seen attempts to detect or exploit the vulnerability continue non-stop. 3/16

As we pass the first week since the exposure of the first vulnerability, SophosLabs has continued to track attempts against our customers’ networks to exploit Log4Shell. 4/16

The traffic we’ve observed includes benign scans by security researchers and penetration testers as well as malicious activity, and it does not directly reflect the state of criminal and state actor attempts to exploit the vulnerability. 5/16

But from portions of the data, we can see enough about the requests to gain some insight into the infrastructure involved in these attempts, and in some cases the intent behind them. 6/16

We have not seen a significant reduction in exploit attempts since they peaked on December 15, and that these probes and exploits are coming from a globally distributed infrastructure...

We have seen MILLIONS of incoming attempts to exploit #Log4j in customer telemetry. 7/16

While we cannot distinguish the intent of every request, the segment of our telemetry that provided traffic details provides a snapshot.

Looking at the source of attempted abusive packets thus far, the vast majority come from IP addresses in Russia and China. 8/16

Because of the way Log4j exploits work—by prompting “lookups” to remote servers via LDAP, DNS, and other Java Name and Directory Interface (JNDI) supported protocols—the lookup requests can be directed to a different location than the source of the exploit. 9/16

Nearly two-thirds of these requests had URLs for infrastructure in India. And over 40% had URLs directed to infrastructure in the US. Over seven percent of exploit requests were directed to the Interactsh tool’s domain—18% of all the traffic to US infrastructure. 10/16

Because Interactsh has been used by researchers AND malicious actors, it’s difficult to separate the benign from the bad—just as it is with other traffic we’re detecting and blocking.

But it is clear that malicious exploit attempts remain a majority of this traffic. 11/16

The only sure way to protect against exploitation—either to gain remote code execution or to cause denial of service—is to update software to use the current “safe” versions of Log4j (2.17.0 for Java 8, 2.12.3 for Java 7). 12/16

Where fixes are not yet available, network filtering definitions will protect against a large percentage of existing exploit traffic—but do not guarantee protection against emerging threats and highly targeted attacks. 13/16

@Sophos continues to identify new methods of obfuscation for exploiting traffic, and new payloads being deployed via Log4j exploits. The following are current Signature IDs published to Sophos intrusion protection products (latest in bold), by product, as of December 20. 14/16

The following is a list as of December 20 of all payloads Sophos has detected as part of Log4j exploit attempts (new payloads in bold): 15/16

Read the full article from @thepacketrat...

news.sophos.com/en-us/2021/12/…

16/16