Good day all! For a lot of you, this weekend was busy, sometimes confusing, and definitely demanding due to the Log4j crisis.
As you know this newsletter delivers every Friday - except, as noted last issue
that the newsletter would not deliver until the new year due to the holidays and my taking time off to spend time with family and friends.
So, this newsletter issue is definitely an out-of-band experience. But with the ongoing effort to identify and control the Log4J outbreak, I believe it’s important to deliver this newsletter now instead of waiting until January 7th.
There’s still a lot of awesome, accumulated and curated content in this newsletter issue below, but the focus here is more about getting all of you the necessary information about how to deal with Log4j with Microsoft Sentinel.
I absolutely love this community. There’s been a mighty effort by this community to get a handle on this outbreak and many, many people have dedicated their time over the weekend to create and offer solutions for everyone. It just doesn’t get any better than that.
What is it?
In its simplest terms, a zero day vulnerability in Log4j (also now known as “Log4Shell”) can allow unauthenticated remote code execution and access to servers. Researchers have reported that there are 100 attempts to exploit this vulnerability a minute, leading to hundreds of thousands of attempts since it was discovered just a few days ago - but that it has probably been an active exploit for some time before it was publicly disclosed.
Almost every bit of software you use will keep records of errors and other important events, known as logs. Rather than creating their own logging system, many software developers use the open source Log4j, making it one of the most common logging packages in the world.
Not having to reinvent the wheel is a huge benefit, but the popularity of Log4j has now become a global security headache. The flaw affects millions of pieces of software, running on millions of machines, which we all interact with.
And the impact could be huge, producing crypto mining malware or installing Cobalt Strike on vulnerable systems which would lead to the mass theft of usernames and passwords. But that’s just a sampling of the potential for impact.
What people seem to miss:
The #Log4Shell vulnerability isn’t just a RCE 0day.
It’s a vulnerability that causes hundreds and thousands of 0-days in all kinds of software products.
It’s a 0-day cluster bomb.
Log4j is used by millions of web servers, which also relates to the apps that rely on those web servers’ services. For example, anyone using Okta for identity services should be aware that the Radius Server agent is vulnerable
. VMware, another example, has a long list of impacted products
. So, don’t think you’re safe just because you don’t run a web server.
With that, here’s some highlights for your Microsoft Sentinel (and other Defender products) environments.
Our own guidance provides information about the vulnerability, and talks about how Defender, Defender for Endpoint, Defender for Cloud, and Microsoft Sentinel can be used to detect and alert on it.
Microsoft MVP and Cloud IR, Eli Shlomo
, has provided an amazing diagram of the exploit (originally provided by the National Cyber Security Centre (NCSC
), Computer Security Incident Response Team of the Swiss Government), recommendations, and a lab environment to simulate the exploit for detections.
, the purveyor of the #365daysofkql
operation, has posted a KQL query to show how to use parsing to create your own detections.
P.S. As of today, Matt is up to day 66. If you’re interested in KQL, you should follow the hashtag on Twitter
For those customers that are using Microsoft Sentinel alongside another SIEM, SOC Prime has multi SIEM detections, including Microsoft Sentinel (though SOC Prime is still stuck on the old “Azure” Sentinel name in most places)
The following hunting query looks for possible attempts to exploit a remote code execution vulnerability in the Log4j component of Apache:
, from FalconForce, has provided several KQL queries for detecting the vulnerability in LDAP, DNS, Zscaler, Fortinet, Check Point, Application Gateway and others.
I hope this newsletter issue provides value for you instead of leaving you with further questions around Log4j and its potential impact.
As noted last issue, I’m taking time off for the holidays and this newsletter will return in force in January. But who knows? You may see and hear from me again if I’m needed.
The rest of this newsletter issue is the normal fare.