hgm 0 Posted January 11, 2022 Posted January 11, 2022 Hello, We began seeing "Security vulnerability exploitation attempts: JAVA/Exploit.CVE-2021-44228", and I'm wondering if anyone can help me understand what is occurring with these alerts? Product: Endpoint Antivirus 8.1.2037.2 OS: Windows 10.0.19044.1415 The detection includes the following (simplified, obfuscated numbers): Process name C:\Program Files (x86)\Internet Explorer\iexplore.exe Source address 10.1.2.3 Source port 59876 Target address 117.2.3.4 Target port 80 Inbound Communication no Protocol TCP Action Blocked Is the following understanding correct: this computer, using process iexplore.exe, made a call from 10.1.2.3 on port 59876 to 117.2.3.4 which was blocked? Or was the traffic from 117.2.3.4 on port 80 blocked, with the target of 10.1.2.3? It is the "Inbound Communication: no" part that is tripping me up. What part of the communication was blocked, the part from the ESET protected endpoint to a server, or a server to the ESET protected endpoint?
itman 1,799 Posted January 11, 2022 Posted January 11, 2022 (edited) 20 minutes ago, hgm said: Is the following understanding correct: this computer, using process iexplore.exe, made a call from 10.1.2.3 on port 59876 to 117.2.3.4 which was blocked? Yes. Since this was outbound communication which Eset allows all by default, I assume this IP address, 117.2.3.4, is on the Eset IP address blacklist. Have you applied all Log4Shell Apache server and related software vulnerability patches? Edited January 11, 2022 by itman hgm 1
itman 1,799 Posted January 11, 2022 Posted January 11, 2022 Also, IP address, 117.2.3.4 is located in Hanoi, Vietnam,
hgm 0 Posted January 12, 2022 Author Posted January 12, 2022 2 hours ago, itman said: Have you applied all Log4Shell Apache server and related software vulnerability patches? Thank you @itman for the prompt reply! I am aware of update information from this link: https://support.eset.com/en/kb3580-upgrade-eset-business-products Regarding Apache server, are you referring to Apache that was installed with ESET Protect, or other non-ESET related instances of Apache? It is our understanding that Apache which runs with Protect is not vulnerable. Is this correct? Another question on the topic of this post, I don't see anything in the detection report that points to how or why the blocked traffic occurred. Performing the script searches outlined in this post (link below) doesn't turn up any instance of .jar archive files on the system. And I am unaware of any other installed software that would do this either. So I'm trying to figure out what is the root of the offending traffic? Is this something that ESET can provide? https://www.welivesecurity.com/2021/12/13/log4shell-vulnerability-what-we-know-so-far/
ESET Insiders NewbyUser 74 Posted January 12, 2022 ESET Insiders Posted January 12, 2022 (edited) Allegedly Internet Explorer is attemtping the connection. As an aside I don't even have this file on my systems. Edited January 12, 2022 by NewbyUser
Solution itman 1,799 Posted January 12, 2022 Solution Posted January 12, 2022 (edited) 13 hours ago, hgm said: Regarding Apache server, are you referring to Apache that was installed with ESET Protect, or other non-ESET related instances of Apache? It is our understanding that Apache which runs with Protect is not vulnerable. Is this correct? Refer to this: https://forum.eset.com/topic/30842-apache-http-proxy-version-2452/ if applicable to your installation. Also, it is not just Apache server that is affected by this vulnerability, but many other products: https://github.com/NCSC-NL/log4shell/blob/main/software/README.md . Here is the Github web page with comprehensive information on this vulnerability including scripts that can scan devices for vulnerable software: https://github.com/NCSC-NL/log4shell . 13 hours ago, hgm said: Another question on the topic of this post, I don't see anything in the detection report that points to how or why the blocked traffic occurred. It is possible that IE11 accessed a compromised web site and was redirected to a known attacker server trying to exploit the Log4Shell vulnerability. In other words, this was an initial exploratory attempt against the source device. Since Eset blocked this access, there is nothing to be concerned about at the current time in regards to this particular incident. Edited January 12, 2022 by itman hgm 1
Sec-C 6 Posted January 13, 2022 Posted January 13, 2022 Some of our Eset users see this notification when opening Internet Explorer. Eset blocks an outgoing IE connection with Detection Name "JAVA/Exploit.CVE-2021-44228". Event Description is not "Blacklisted IP" but "Security vulnerability exploitation attempt". It does not happen every time IE is started. I suspect it's caused by something that is embedded in IE's default start page "www.msn.com". Maybe an advert.
Administrators Marcos 5,441 Posted January 13, 2022 Administrators Posted January 13, 2022 5 hours ago, Sec-C said: Some of our Eset users see this notification when opening Internet Explorer. Eset blocks an outgoing IE connection with Detection Name "JAVA/Exploit.CVE-2021-44228". Event Description is not "Blacklisted IP" but "Security vulnerability exploitation attempt". It does not happen every time IE is started. Please check if the detection is still being triggered. Today the detection was fine-tuned to avoid certain false positives. hgm and Sec-C 2
Bardahl_IT 0 Posted January 14, 2022 Posted January 14, 2022 Hello, Searching for info about similar alerts in Eset Endpoint Antivirus, I came across this thread. We had similar alerts on differents posts starting last friday up until yesterday. The difference is it was the svchost.exe that was the application logged. We had an alert every 4 minutes for 15 hours straight then it would stop for 9 hours to restart again following a similar pattern. Does it seem linked to the tweak you did to avoid false positives ? Kind regards, François
Administrators Marcos 5,441 Posted January 14, 2022 Administrators Posted January 14, 2022 2 minutes ago, Bardahl_IT said: Does it seem linked to the tweak you did to avoid false positives ? Since it's no longer reported, most likely it was the FP that was fixed.
Recommended Posts