Log4j and Defender for Endpoint
Post credit: Joe Anich
It is no surprise to anyone that the Log4j is still very much top of mind for security teams, and likely will be for some time as this type of vulnerability is almost a commodity. Also, referred to as Log4Shell or one of a few CVE assignments. The image we are all used to seeing, quickly turned into a cringe image in all our minds.
This one as you could imagine, turned into a broad range of attacks, as the attack vectors are nearly endless. Looking at what the industry has seen so far though, it has been mainly global scanning of systems, coin mining has risen in popularity, remote shells, and general offensive security activities. The mass scanning has been threat actors trying to do something called thumbprinting systems. This is a tactic they use to discover information about devices susceptible to the Log4J vulnerability. This is often tied to a DNS logging system which would fingerprint the device returning the log response. Of course, we can expect the types of attacks to increase as threat actors continue to learn what is vulnerable and figure out crafty ways to take advantage of it.
One concerning thing we can expect is that a lot of this scanning will result in opportunities for access brokers to gain initial access to networks, to then sell that off to ransomware groups to deploy their payloads and continue the attack that way. Other attacks being observed are Remote Administration Tools or RAT payloads, which deliver remote access toolkits and reverse shells. Of course, when you start talking about reverse shells, you can expect Meterpreter. Webtoos malware has also been seen using this, which can deliver DDoS-like attacks as well as persistence tools.
The moral of the story is to identify anything you have in your environments that are internet-facing and ensure its use of the Log4j logging framework. Other systems to identify if you have them are systems running VMware Horizon, there is a ransomware campaign called Night Sky being deployed right now. Ransomware notes for this campaign have been as high as $800,000! For patching information on VMware Horizon systems, please see the following link
For workarounds see this – Log4j CVE-2021-44228 and CVE-2021-45046 in VMware Horizon and VMware Horizon Agent (on-premises) (87073)
If you are not familiar with it already, please check out the Microsoft Security Response Center (MSRC) blog to see Microsoft’s continually updated response to this attack and the mitigations for it per service. This will be updated as soon as the MSRC team identifies a service or application in the Microsoft ecosystem that is deemed vulnerable or can support applications that would be. If we see anything in a customer’s tenant that would pose a threat, they will be contacted and notified of such. That blog mentions can be found at the following link- https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/.
The main part that I wanted to call out in this week’s article is the new mitigation section for devices in the Vulnerability management > Weaknesses section of your Microsoft M365 Defender portal. The direct link can be found here – https://security.microsoft.com/vulnerabilities/vulnerability/CVE-2021-44228/exposedDevices. Here you will find assessments on how each CVE is affecting your environment:
And recently added is the mitigation component, especially for devices vulnerable to CVE-2021-44228, so you can see which devices fall under and select which ones will be mitigated. See the figure below for an example of what that looks like:
Select all devices exposed or specific devices that can get remediated immediately while others must wait, whatever your case might be. When this get’s applied, it does the following:
- The mitigation action will set the environment variable ‘LOG4J_FORMAT_MSG_NO_LOOKUPS’ to ‘True’. This will prevent JNDI lookups on Log4j versions 2.10 – 2.14.1 with default configurations.
- Any applications that use JNDI lookups will have their log strings affected, and log analytics products using this data could potentially be affected as well.
- Note that for certain non-default configurations, JNDI lookups might still be possible even after applying the mitigation. We recommend updating all instances of Log4J to the latest version and applying the latest security updates.
- Once applied, the mitigation can only be undone using endpoint management solutions.
This is being done by the Defender for Endpoint client on each device, which is great! Refer to the blog posts if these changes need to be reverted, there is some PowerShell you can run to revert, which I’ll also post here:
- Open an elevated PowerShell window
- Run the following command:
[Environment]::SetEnvironmentVariable(“LOG4J_FORMAT_MSG_NO_LOOKUPS”, $null, [EnvironmentVariableTarget]::Machine)
So if you’re already taking advantage of Defender for Endpoint, check this out as it can both bring light to where you may be exposed as well as lighten the administrative workload. See you next week!
