Many detections of JAVA/Exploit.CVE-2021-44228 on machine with ESET Protect Server installed

[LukiD 0]

Hi,

We have Windows Server 2019 with ESET Protect Server (10.0.1128.0), ESET PROTECT Web Console (10.0.132.0), ESET Management Agent (10.0.1126.0) and ESET Rogue Detection Sensor (1.1.693.1) installed on it. There are no other applications which could use Log4j - no other Apache or Tomcat based products.

In ESET Protect console I discovered 9 alerts in last 10 days - all alerts are detections of JAVA/Exploit.CVE-2021-44228 with following details:
Process name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Hash: 6CBCE4A295C163791B60FC23D285E6D84F28EE4C
Source address: 127.0.0.1
Source port:
Target address: 127.0.0.1
Target port:
Inbound Communication: no
Protocol: TCP
Action: Blocked
User: NT AUTHORITY\LOCAL SERVICE

How to interpret this alert and how to stop it occur?

Best regards

 

[itman 1,659]

On 1/5/2023 at 12:25 PM, LukiD said:

There are no other applications which could use Log4j - no other Apache or Tomcat based products.

Other apps can employ it.

Here's an article on the vulnerability/exploit: https://sysdig.com/blog/exploit-detect-mitigate-log4j-cve/ .

Mitigations are:

Quote

Mitigating CVE-2021-44228

If you’re impacted by this CVE, you should update the application to the newest version, or at least to the 2.17.0 version, immediately. If that isn’t possible in your environment, you can evaluate three options:

• If you are using Log4j v2.10 or above, you can set the property: log4j2.formatMsgNoLookups=true
• An environment variable can be set for these same affected versions: LOG4J_FORMAT_MSG_NO_LOOKUPS=true
• If the version is older, remove the JndiLookup class from the log4j-core on the filesystem.

Even though you might have already upgraded your library or applied one of the other mitigations on containers affected by the vulnerability, you need to detect any exploitation attempts and post-breach activities in your environment.

You can detect this vulnerability at three different phases of the application lifecycle:

• During the build, with an image scanner.
• During the deployment, thanks to an image scanner on the admission controller.
• During the run and response phase, using a runtime detection engine to detect malicious behaviors in already deployed hosts or pods.

Let’s now dig deeper into each of them.

Edited January 6, 2023 by itman

[itman 1,659]

This Github article lists all software that uses Log4j and whether it is vulnerable: https://github.com/NCSC-NL/log4shell/blob/main/software/software_list.md .

Edited January 7, 2023 by itman

[LukiD 0]

Hi,

I've found source of alerts - we have Windows Defender Advanced Threat Protection enabled on this server and I discovered that this solution runs different PowerShell scripts to scan possible vulnerabilities among others JAVA/Exploit.CVE-2021-44228. I correlated running of one of these scripts with Alerts timestamps.

When I've found which script could cause alert I've copied it from its original location (which is not accessible for admin accounts) and analyzed its content. The line which caused Alerts is:

Scan-CVE-2021-44228 -LocalIP $null -RemoteIP "127.0.0.1" -RemoteMac $null

Interesting details are: what about running rest of ATP scripts - why they do not cause alerts and what about other our machines secured by ESET Server Secure - I'm almost sure that they should have same ATP configuration as our EPS server. I will investigate it and lets you know if result will be interesting.

Bye

ATP scripts events.txt

[Marcos 5,074]

Yeah, it's https://learn.microsoft.com/en-us/microsoft-365/security/defender-vulnerability-management/tvm-manage-log4shell-guidance?view=o365-worldwide related.