Log4j security messages (12/28/2021)

Sicherheit (Pexels, allgemeine Nutzung)[German]It looks like the big wave of hacks via the log4j vulnerability failed to materialize over Christmas. But there are cases, like at the Belgian Ministry of Defense, which were attacked via log4j. However, the attacks will possibly follow in January 2022. Microsoft has created a status indicator for Defender 365 that lists vulnerable devices on a network. Here is a brief overview of the information as of Dec. 28, 2021.


Microsoft  lists log4j vulnerabilities

Microsoft  just launched a new consolidated Log4j threat and vulnerability management dashboard in the Microsoft 365 Defender portal. This is designed to help customers identify and remediate files, software and devices affected by log4j vulnerabilities.

Microsoft Log4j-Dashboard

In addition to Windows and Windows Server, these threat and vulnerability features are also supported on Linux, but require Microsoft Defender for Endpoint Linux client to be updated to version 101.52.57 (30.121092.15257.0) or later.  Meanwhile, Microsoft Defender for Containers discovers images affected by the Log4j vulnerability. Microsoft has published a document Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability.

CISA releases log4j scanner

The US CISA has published a scanner for the Log4j vulnerability on Github. The repository provides a scanning solution for the log4j remote code execution vulnerabilities (CVE-2021-44228 & CVE-2021-45046). The information and code in this repository is compiled on an as-is basis with the help of the open source community and updated by CISA in collaboration with the broader cybersecurity community. This is not a 100% positive solution; false negatives may occur.

Belgian Ministry of Defense log4j victim

In the blog post Belgian Ministry of Defense affected by Log4j?, I had reported on December 20, 2021, that the Belgian defense ministry had probably shut down its networks after a severe cyberattack. It was suspected to be related to the log4j vulnerability CVE-2021-44228.


Now, according to this report from The Register, the Belgian Ministry of Defense has likely admitted. Belgian Defense Ministry spokesman Olivier Severin said in a prepared statement obtained by The Register: 

The Defense Department on Thursday discovered an attack on its computer network with Internet access. Quarantine measures were quickly taken to isolate the affected parts. The priority is to keep the defense network operational.

This attack follows the exploitation of the Log4j vulnerability, which was disclosed last week and for which IT specialists around the world are scrambling.

So the next confirmed prominent victim of the log4j vulnerability.

Further findings and info about log4j

I have received further information about the log4j vulnerability from security vendors. The provider Check Point, for example, has already sent me the following figures on attacks for Germany in mid-December 2021.

  • In Germany, 45 percent of all company networks recorded by Check Point were attacked.
  • In Austria, the figure is 46 percent, and in Switzerland, 40 percent.
  • Worldwide, the average is 40 percent. In Europe, the figure is 42.2 percent.
  • At one point, the security researchers even register 100 attacks per minute.
  • Check Point has now registered around 846,000 attacks, 72 hours after the first attack.
  • 46 percent of the attacks came from known hacker groups.
  • After 72 hours, there were already more than 60 new variants of the attack.

Check Point published the key findings in this post and updated the whole thing again as of Dec. 20, 2021. Security vendor Tenable sent me a note on 12/23/2021 that 30 percent of organizations have not yet taken precautions against Log4j attacks. Amit Yoran explains:  

According to Tenable's telemetry data, as of December 21, 2021, only 70 percent of organizations have even scanned for the vulnerability! Of the assets scanned, Log4Shell was found in about ten percent, including a variety of servers, web applications, containers, and IoT devices. Log4Shell is prevalent across all industries and geographies.

I'm concerned that history is repeating itself, but this time the damage could be uncontrollable. While years ago EternalBlue  caused widespread attacks like WannaCry, the potential here is much greater because Log4j is widely used in both infrastructure and applications. No single vulnerability in history has cried out so blatantly for remediation.

Log4Shell has been identified as one of the biggest cybersecurity risks we've ever seen, but many organizations are still not taking sufficient action. According to our data, 30 percent of organizations have not even begun to scan their environments for Log4Shell, let alone patch it.

Log4Shell will redefine computing as we know it. It will separate those who make the effort to protect themselves from those who are comfortable being careless."

Vendor OTORIO has compiled the following guidance on how to address the security vulnerability for networks:

  1. Fast hardening – Block IOCs (Indication of Compromise) in perimeter solutions such as firewalls, IDS, IPS, WAFs, etc.). An example of Microsoft's IoC list can be found here. It is important to ensure that your WAFs are automatically updated and loaded with Log4j detection and prevention updates (this does not guarantee exploit prevention as it is based on behavior and signatures).
  2. Identification
    a. Reduce your global attack surface by scanning with a tool like OTORIO's ReconOT, which automatically and passively performs OT-IoT IT reconnaissance to detect assets as soon as they are discovered by a potential attacker. Recently, OTORIO has equipped ReconOT with the non-invasive ability to detect applications that may be vulnerable to Log4j.
    b. Use your asset/software inventory to identify known applications that have been published as vulnerable to Log4j. It is recommended to follow https://github.com/cisagov/log4j-affected-db#software-list as it contains a maintained list of vulnerable software. OTORIO's technology (both RAM2 and spOT) can best assist you in this process. enthält. Die Technologie von OTORIO (sowohl  als auch )
    c. Scan packages. Tools, such as the one from CERTCC (published by cisa), could also be useful, both for Linux and Windows, if there is no other SBOM tool available.
  3. Mitigation and patching – update to the latest Log4j version (https://logging.apache.org/log4j/2.x/download.html). If patching is not possible, isolate the affected system as much as possible. If OT systems are involved, make sure the above steps are coordinated with the system vendor. 
  4. Monitoring
    Detect exploit attempts on Linux hosts by searching the log4j jndi logs: sudo egrep -i -r '\$\ jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/
    Snort rules for IDS/IPS systems – https://rules.emergingthreatspro.com/open/
    Finding and blocking IOCs of known attackers exploiting systems in the wild:




If you are deploying EDR on DMZ systems, monitor them for suspicious curl, wget, or similar commands.

In addition, organizations are strongly encouraged to   check the Apache Log4j Security Vulnerabilities web page for updates and mitigation advisories, and to work closely with their providers and vendors to monitor any updates on affected systems. 

Similar articles:
0-day CVE-2021-44228 in Java library log4j puts many projects at risk
log4j vulnerability CVE-2021-44228: Patch your Minecraft
VMware products threatened by log4j vulnerability CVE-2021-44228
log4j FAQ and Repository
Log4j-News (2021/12/18)
Belgian Ministry of Defense affected by Log4j?
QNAP firmware update version QTS build 20211221 and log4j vulnerability

Cookies helps to fund this blog: Cookie settings

This entry was posted in Security and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *