2 min

Tags in this article

, ,

The severity of the vulnerability in Log4j is anything but theoretical. Cybercriminals are scanning ports worldwide to find entry points for abuse. Security researchers observed hundreds of thousands of attacks.

In the past few days, Check Point Research recognized 470,000 network scan attempts. The scans are frequently performed to find servers that allow external HTTP requests. Such servers are susceptible to abuse of the notorious vulnerability in Java library Log4j.

If a server allows HTTP requests, a malicious party can ping the server with a single string directing to a remote server with Java instructions for malware execution. If the targeted server is connected to a Java application that incorporates a vulnerable version of Log4j, the Java application processes the string to execute the malware.

At the bottom line, the victim’s server executes what an attacker commands. Security organization Sophos says it recognized hundreds of thousands of attacks.

Familiar faces

Earlier, we wrote a clarifying article on the technical workings mentioned above. The most significant prerequisite for abuse of Log4j is the ability to communicate with Java applications that incorporate the library. In some cases, this is child’s play. For example, Apple iCloud used Log4j to record the names of iPhones. Changing the model name of an iPhone to a string proved viable for cracking Apple’s servers.

In other cases, applications are less easily affected. The biggest threat comes from attackers with experience, knowledge and existing techniques. Security researchers at Netlab360 set up two decoy systems (honeypots, ed.) to invite attacks on Java applications with Log4j. In doing so, the researchers lured nine new variations of well-known malware, including MIRAI and Muhstik.

The malware families have been spearheaded to abuse Log4j. A common goal is to strengthen botnets for cryptomining and DDoS attacks. Check Point Software conducted a similar study on a larger scale, recording 846.000 attacks in the past few days.


It is abundantly clear that cybercriminals seek out and abuse vulnerable versions of Log4j. Taking inventory of all Log4j applications in an environment remains the most viable defence. If the supplier of the application in which Log4j is used released an updated version, patching is the way to go. If not, shutting the application down is the safest bet.

At this time, it is anything but advisable to develop your own software measures or adapt the function of Log4j instances. The vulnerability has variations. Microsoft, among others, detected multiple variants of the string used to instruct Java applications to execute malware. Check Point recognized more than 60 mutations.