How to check if the server is attacked by Log4j (Log4Shell) or not

A critical exploit in the Java library was found not long ago, disrupting much of the Internet causing server administrators to try to fix it. The very vulnerable library, log4j, is used everywhere, so you’ll need to check your servers and make sure they’re up to date.

How to check if your server is vulnerable to log4j (Log4Shell) attacks

How does the Log4J vulnerability work?

As it turns out, the log4j vulnerability is by far one of the worst of the past few years, scoring a rare 10/10 on the CVSS scale and will haunt the entire internet for years to come.

What’s worse is that log4j isn’t an application — it’s an open source library used by many other applications. You can’t install it directly; it can be included in other .jar files or installed by other applications as a dependency.

It basically allows attackers to send text to your application, and if it logs this text somewhere, your server will execute malicious code. The format of the text looks like this: an extremely simple string containing a link to a remote address.


The vulnerable components in log4j are Java Naming and the Directory Interface, which allows the logging framework to make remote requests. Except it also decrypts the file at the endpoint and can load .class files that contain remote malware.

Is the server vulnerable to the Log4J bug?

This vulnerability was quickly patched in the latest release of log4j, 2.16.0, but the issue remains unresolved. Since log4j is a dependency, finding its specific version on your system may not be straightforward. And, because Java is so popular, many third-party tools and components can use it, so you might not even know if you’re running vulnerable Java software on your machine. Are not.

Even if you think you’re not vulnerable, you still need to double-check. This vulnerability affects so many systems that it’s likely that you’re running log4j or Java without realizing it.

Fortunately, JDK versions greater than 6u211, 7u201, 8u191 and 11.0.1 are not affected by the main attack vector (using LDAP) that is currently being exploited the most. You still need to patch it, as it can easily be used with other attack vectors as well. Also, the simple act of making a request to an endpoint can expose data about machines on your network, which is also not a good thing.

The vulnerability also tells you why it’s important to keep the Software Bill of Materials (SBOM), which is basically a list of all the software on your system, where it came from, and the software it was made of. from where. In the future, this information can help you quickly patch attacks like this.

For now, you just need to be concerned with scanning your system for log4j versions used by the software and making a list of all vulnerable components.

How to check if the server is attacked by Log4j (Log4Shell) or not

Many people have created scripts to automatically scan the system and find vulnerable installations, such as this popular script written in Python and this script from security company LunaSec. One of the easiest to use is this simple bash script, it can scan your packages and identify log4j versions and can also tell you if your system is using Java . In most cases you will need to run multiple scans with different scripts, as there is no guarantee that these scripts will be 100% effective in identifying every vulnerable system.

You can download and run it with a few commands. You also need to run the command as root to scan your entire system.

wget -q

chmod +x

sudo ./

The results from this script will tell you why this log4j vulnerability is so terrible — running this script on a server shows that it is very vulnerable, even though I think I haven’t installed it yet Java on this machine because I’m not running any Java software.

Elasticsearch is running in the background on this machine, written in Java. You don’t have to install Java manually to have Elasticsearch; it includes a bundled version of OpenJDK. And it’s stuck to log4j so it’s very easy to exploit.

How to check if the server is attacked by Log4j (Log4Shell) 5

To patch Elasticsearch, you need to update all packages and follow the mitigation instructions. This can happen with any software you’re running; you will need to update log4j directly, update the software that comes with it, or fix the bug with whatever mitigation method other people are using.

If you can’t patch the jar for some reason, you can use this JVM flag to mitigate the problem, which simply tells log4j to never do any lookups when formatting messages. However, this is not recommended and you should try to install log4j 2.16.0 wherever possible to completely fix the problem.


Leave a Reply