Executive Summary OF LOG4SHELL EXPLOIT
In December 2021, a zero-day critical vulnerability was found in the Apache Log4j2 Java-based logging library. The vulnerability is now known as Log4Shell and is an unauthenticated remote code execution (RCE) flaw that allows for complete system takeover with Log4j2.0-beta9 up to 2.16.1. This means that the flaw could allow attackers to install cryptominers and steal data, as well as credentials. Almost every network security system runs on some kind of logging process and the Log4j2 logging library is extremely popular, given its vast reach. Millions of applications use Log4j2 for logging and if an attacker has the Log4j2 app, he can compromise it by logging a special string of characters.
Although conversation regarding Log4Shell has diminished, the vulnerability is still an issue for organizations and remains a permanent threat. Since the vulnerability was publicized, over 80% of Log4Shell’s exploitation attempts originated within the U.S. Because many systems are still using older versions of Log4j, the problems continue to escalate. Let’s take a look at Log4Shell and why we should continue to remain vigilant with patching devices.
background on log4shell
In January 2022, Avertium’s Cyber Threat Intelligence team published a Threat Intelligence Report detailing the Log4Shell (CVE-2021-44228) exploit. Initially seen on sites hosting Minecraft servers, attackers discovered the vulnerability could be triggered by hosting chat messages. The first attacks were observed two weeks before they were publicly disclosed, and mass exploitation began a day after the vulnerability was made public. Those exploits originated from professional crypto-mining and DDoS botnets, like Muhstik and Mirai. Additionally, Microsoft observed Log4Shell being used to deploy webshells with Cobalt Strike beacons, which are backdoors.
Major enterprises like Amazon, Apple, and Tesla were all affected by Log4Shell, and cyber security professionals were in a hurry to come up with a solution to this massive problem. The situation quickly went from bad to worse when it was discovered that the first patch Apache issued for CVE-2021-44228 didn’t exactly fix the problem. Although rated lower in severity, the new exploit (CVE-2021-45046) gave attackers the capability to craft malicious input data using a JNDI Lookup pattern, resulting in a denial of service (DOS) attack. The vulnerability was patched, but it wasn’t long before a third vulnerability reared its head.
CVE-2021-45105 addressed Apache Log4j2 version 2.15.1, which allowed for crafted input that could manipulate Context Lookup functionality that leads to a stack-overflow and crash. Soon after Apache released the patch for CVE-2021-45105, a fourth vulnerability was found, CVE-2021-44832. This vulnerability affected Log4j2 version 2.16.0 which was vulnerable to an RCE attack when a configuration uses JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
log4shell is still an issue
After the news broke about how easy it was to exploit Log4j2, threat actors made swift moves. Log4Shell resulted in massive world-wide scanning with the payloads running from miners, Unix DDoS malware, and framework stagers pushed to compromised hosts. This kind of mass scanning was expected because as with any exploit, attackers with motives will exploit anything they can in order to receive what they want (money, credentials, sensitive data, etc.). However, since December, the issues surrounding Log4Shell still persist and there is no sign of them disappearing.
In our previous report, we mentioned that several threat actors were taking advantage of the Log4Shell exploit, with one of those threat actors being Conti. Conti was the first sophisticated ransomware group to actively exploit Log4Shell. Within two days of the Log4Shell news, the group figured out a way to use Log4Shell as a new attack vector. They decided on the following attack chain: Emotet -> Cobalt Strike -> Human Exploitation -> (no ADMIN$ share) -> Kerberoast -> vCenter ESXi with log4shell scan for vCenter.
Image 1: Conti Attack Vector Timeline
Source: AdvIntel
Chinese and Iranian state threat actors were exploiting Log4Shell as well. The Iranian threat actor, DEV-0270, and Chinese threat actor, APT10, were among the first to aggressively exploit Log4Shell. Mandiant observed reconnaissance activity linked to APT10 and DEV-0270 successfully attacked multiple U.S. companies via ransomware deployments
DEV-0401
Now, there is another China based ransomware threat actor (DEV-0401) exploiting Log4Shell. Microsoft observed DEV-0401 targeting internet-facing servers running vulnerable instances of VMware’s, VMware Horizon. According to the U.K. government’s NHS Digital, DEV-0401 was observed trying to establish malicious web shells on Horizon servers. The threat actor was also observed using command and control servers to spoof domains associated with companies such as Trend Micro and Sophos.
In addition to Log4Shell, DEV-0401 has also deployed several ransomware families including: Night Sky, LockFile, Rook, and AtomSilo – while exploiting internet facing systems running Confluence (CVE-2021-26084). Researchers are not sure if DEV-0401 is a ransomware-as-a-service group or a contractor.
Linux
In March 2022, researchers at Qihoo 360’s Network Security Research Lab (360 Netlab) published a report about a botnet, which is still under development, that was attempting to use Linux systems to steal sensitive information, create reverse shells, install rootkits, and act as web traffic proxies. The malware behind the botnet was named B1txor20 and focuses its attacks on Linux ARM, X64 CPU architecture devices.
B1txor20 was initially spotted by Qihoo’s research lab in February 2022 and uses Log4Shell to infect new hosts - an appealing attack vector due to dozens of vendors using Apache’s Log4j logging library. The B1txor20 botnet stands out due to its use of DNS tunneling for communication channels with the C2 server. B1torx20 and the C2 communicate with the help of DNS protocol. The C2 sever is encrypted and once the botnet client has decrypted it, a DNS query is used to send its communications to the C2 domain. The communication includes stolen sensitive information and command execution results. This technique may be dated, but threat actors still use it to exploit the DNS protocol to tunnel malware and data via DNS queries.
Qihoo’s research lab stated that B1xtor20 has broad features, but all the features aren’t enabled. The researchers believe it’s a sign that the malware has a few bugs the developers are trying to improve. To decrypt the domain name and RC4 secret key, B1txor20 uses the following code snippet:
Image 2: B1txor20 Flow Chart
Source: Netlab 360
Qualys research
Qualys research lab recently analyzed Log4Shell and found that more than 150 million IT assets across the world had vulnerable application installations, with 80% of them being open-source applications. Of those application installations, 30% of Log4j instances were vulnerable to exploitation. Also, only 70% of the Apache Log4j applications had been patched. This means that developers are still downloading vulnerable versions of Log4j.
Log4j exploits are primarily being used for DDoS botnet attacks and over 80% of cryptomining, ransomware, and DDoS attempts have originated in the U.S. since December 2021. Threat actors like Khonsari and Conti have been successful with exploiting Log4Shell and will continue to exploit it if organizations are not patching their devices. In December 2021, CISA reported that 1,495 products were vulnerable to Log4Shell and Qualys discovered that of those products, 1,065 programs amongst 52 publishers were still in use – with over 80% of those being on Linux.
Other payloads dropped by Log4Shell include:
- BillGates malware (DDoS)
- Kinsing (cryptominer)
- XMRig (cryptominer)
- Muhstik (DDoS)
As you can see, current Log4shell exploits are primarily being used for DDoS botnet attacks. Barracuda researchers observed various payloads targeting vulnerable Log4j deployments with Mirai in the lead. Mirai focuses on publicly exposed network cameras, routers, and other devices and places them into a botnet of remotely controlled bots. As a result, attackers are able to control the botnet and perform DDoS attacks against their target. Take a look at Qualys’ Log4Shell vulnerability impact numbers from March 2022:
- 90% of Fortune 500 companies use Java
- There have been 1 million attack attempts in just 72 hours after Log4Shell was publicized
- 30% of Log4Shell instances remain vulnerable
- Globally, 150 million IT, cloud assets, and applications have been scanned
- Nearly 68,000 vulnerabilities found in cloud workloads
- 22M vulnerable application installations were flagged by Qualys
- 98 Log4j2 versions were observed in use - 55% of those were vulnerable versions
- More than 50% of Log4j2 installations were flagged as “end of support”
- Average time to remediation after detection is 17 days
ftc - legal action for failing to patch log4shell
If the above information isn’t enough to concern you, then the Federal Trade Commission (FTC) may change your stance. After the Log4Shell incident took over cyber space, the FTC issued a warning to companies who didn’t remediate Log4j security issues. The warning stated that the FTC will use its full legal authority and pursue companies who fail to patch vulnerable devices.
“When vulnerabilities are discovered and exploited, it risks a loss or breach of personal information, financial loss, and other irreversible harms. The duty to take reasonable steps to mitigate known software vulnerabilities implicates laws including, among others, the Federal Trade Commission Act and the Gramm Leach Bliley Act. It is critical that companies and their vendors relying on Log4j act now, in order to reduce the likelihood of harm to consumers, and to avoid FTC legal action. According to the complaint in Equifax, a failure to patch a known vulnerability irreversibly exposed the personal information of 147 million consumers. Equifax agreed to pay $700 million to settle actions by the Federal Trade Commission, the Consumer Financial Protection Bureau, and all fifty states. The FTC intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.” – Federal Trade Commission
Because leaving devices unpatched and vulnerable to attackers can lead to data breaches, it’s no surprise that the FTC issued such a strong warning. In a Threat Intelligence Report published in February 2022, we talked about how difficult it can be for the IT staff at organizations to keep up with patching vulnerable software and systems. However, not patching will ultimately lead to escalation of attacks. The emergence of recent botnets such as B1txor20 and Mirai is a great example of how threat actors continue to escalate months old vulnerabilities.
Also, APT41 (Bronze Atlas) was seen exploiting Log4Shell. The threat actor is based in China and is known for carrying out cyber espionage. They’ve successfully targeted and breached six U.S. state networks, which have not been named. Because of Log4Shell, APT41 was able to breach two U.S. state government networks and other organizations within the insurance and telecommunications industries.
In December 2021, Microsoft speculated that Log4j exploits may exist for many years. With major companies like Apple, Google, CloudFlare, Steam, VMware, Amazon, and IBM using Log4j2 as their logging framework, Log4Shell is an appealing opportunity for threat actors. Although the number of successful attacks remains lower than expected, analysts are certain that Log4Shell will remain a permanent vulnerability if organizations don’t patch.
improving open-source software security
Open-source software like Apache’s Log4j logging library, is software that is used extensively behind the scenes on the internet but isn’t well-known to the average person. If given access, this kind of software can be like a treasure chest for attackers. However, open-source software has many benefits such as providing people with free accessibility and giving millions of people a useful tool that could foster pioneering technologies.
While the use of open-source software has become an increasing trend, there is a lot of room for improvement when it comes to the security. Cyber security professionals must acknowledge that open-source code comes with security risks, and many open-source components are outdated or have quality control issues. There are also inexperienced developers, and “too busy” developers who are at the helm of many open-source software projects. Despite the challenges, there are ways that you can improve the security of open-source software without jeopardizing the integrity.
- Be transparent and choose the right projects. If you don’t have time for a project, give it to someone who does.
- Be accountable. Because open-source projects are primarily delivered for free, things can get lax. If there is a security flaw, there needs to be people who can be held accountable and fix it.
- There will be risks with every open-source project, analyze them, and find a way to compensate for them.
- Stay plugged in and keep your eye on any bugs or patches. If you can react immediately, you can save organizations a lot of suffering.
- Larger technology companies with big budgets could be more involved by supporting open-source programs that have the potential to cause chaos should something compromise them.
How Avertium is Protecting Our CUSTOMERS
- Avertium recommends utilizing our service for DFIR (Digital Forensics and Incident Response) to help you rapidly assess, contain, eradicate, and recover from a security incident like a cryptomining malware attack.
- We offer EDR endpoint protection through SentinelOne, Sophos, and Microsoft Defender.
- SentinelOne prevents threats and extends protection from the endpoint to beyond. Find threats and eliminate blind spots with autonomous, real-time, index-free threat ingestion and analysis that supports structured, unstructured, and semi-structured data.
- Avertium has published detectors for synchronizing IoCs of malicious scanning activity associated with the Log4Shell vulnerability to all customer SIEMs. The detections that we published for CVE-2021-44228 are still effective.
- Avertium development teams completed an inventory and assessment of all internally developed software that uses Java, to ensure the vulnerability didn’t exist or was mitigated. Avertium offers Strategic Security Assessments so your organization can get a comprehensive view of your risk surface.
Avertium’s Recommendations
All organizations scan for vulnerable applications that use Log4j2 and update them to the latest versions.
- Please patch your devices as soon as possible with the latest version of Log4j. Apache has released version 2.17.1here.
- Please follow the instructions above to mitigate CVE-2021-45046
- In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. With the release of CVE-2021-45046 this is no longer sufficient!
- For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
- Detection Methodology
- Monitor network traffic for communication with known IPs/domains exploiting this vulnerability (see IOCs section)
- Configure NIDS devices with known Log4shell snort/suricata rules
- Search Java application logs for the following regex string: \$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+
MITRE TTPs
- [T1087] Account Discovery Mitigation
- [T1110] Brute Force Mitigation
- [T1003] Credential Dumping Mitigation
- [T1486] Data Encrypted for Impact
- [T1005] Data from Local System Mitigation
- [T1087] Account Discovery Mitigation
- [T1110] Brute Force Mitigation
- [T1003] Credential Dumping Mitigation
- [T1005] Data from Local System Mitigation
- [T1211] Exploitation for Defense Evasion Mitigation
- [T1068] Exploitation for Privilege Escalation Mitigation
- [T1210] Exploitation of Remote Services Mitigation
- [T1046] Network Service Scanning Mitigation
- [T1068] Exploitation for Privilege Escalation Mitigation
- [T1210] Exploitation of Remote Services Mitigation
- [T1046] Network Service Scanning Mitigation
Indicators of Compromise (IoCs)
B1txor20
- 165.16[.24]
- 60.150[.23]
- 027d74534a32ba27f225fff6ee7a755f
- 0a0c43726fd256ad827f4108bdf5e772
- 24c49e4c75c6662365e10bbaeaeecb04
- 2e5724e968f91faaf156c48ec879bb40
- 3192e913ed0138b2de32c5e95146a24a
- 40024288c0d230c0b8ad86075bd7c678
- 43fcb5f22a53a88e726ebef46095cd6b
- 59690bd935184f2ce4b7de0a60e23f57
- 5f77c32c37ae7d25e927d91eb3b61c87
- 6b42a9f10db8b11a15006abced212fa4
- 6c05637c29b347c28d05b937e670c81e
- 7ef9d37e18b48de4b26e5d188a383ec8
- 7f4e74e15fafaf3f8b79254558019d7f
- 989dd7aa17244da78309d441d265613a
- dd4b6e2750f86f2630e3aea418d294c0
- e82135951c3d485b7133b9673194a79e
- fd84b2f06f90940cb920e20ad4a30a63
- 78.48[.7]
- http://185.220.100[.255]
- webserv[.systems]
Log4Shell (most recent IoCs listed below – previous IoCs can be found IoCs here and here)
-
https://www.microsoft-updateserver[.cf/]gadfTs55sghsSSS
-
CVE-2018-13379
-
6a2c91abf2b805365c847709215375af
-
624278ed3019a42131a3a3f6e0e2aac8d8c8b438
-
7feb4d36a33f43d7a1bb254e425ccd458d3ea921
-
d28e07d2722f771bd31c9ff90b9c64d4a188435a
-
e76e9237c49e7598f2b3f94a2b52b01002f8e862
-
7f680efadef8c0b3a192b2814077b7b5d8543d20dd24b1d8939f3fec013059a3
-
https://webhook[.site/]
-
google.onedriver-srv[.ml]
-
www.microsoft-updateserver[.cf]
-
www.service-management[.tk]
-
24.39.220[.218]
-
24.96.94[.11]
-
37.26.183[.94]
-
37.71.147[.186]
-
37.99.163[.162]
-
37.99.163[.163]
-
37.99.163[.164]
-
37.99.163[.165]
-
37.99.163[.166]
-
41.142.240[.197]
-
50.192.49[.210]
-
50.196.104[.201]
-
50.243.3[.153]
-
50.243.3[.154]
-
50.243.3[.155]
-
50.243.3[.156]
-
50.243.3[.157]
-
50.255.126[.65]
-
65.183.166[.218]
-
65.183.166[.219]
-
65.183.166[.220]
-
65.183.166[.222]
-
69.54.25[.34]
-
70.62.153[.174]
-
70.89.246[.33]
-
70.89.246[.34]
-
70.89.246[.35]
-
70.89.246[.36]
-
70.89.246[.37]
-
70.91.93[.133]
-
72.68.69[.63]
-
78.134.89[.167]
-
79.11.46[.30]
-
80.118.6[.90]
-
80.15.113[.188]
-
80.153.75[.103]
-
80.155.38.[210]
-
80.155.38[.211]
-
80.155.38[.212]
-
80.155.38[.213]
-
80.155.3[8.214]
-
81.4.177[.114]
-
81.4.177[.115]
-
81.4.177[.116]
-
81.4.177[.117]
-
81.4.177[.118]
-
82.198.72.[201]
-
82.62.143.[41]
-
87.139.213[.76]
-
87.193.135[.123]
-
90.63.245[.175]
-
90.85.224[.121]
-
90.85.224[.122]
-
90.85.224[.123]
-
90.85.224[.124]
-
90.85.224[.125]
-
93.51.177[.66]
-
93.51.177[.67]
-
93.51.177.68]
-
93.51.177[.69]
-
93.51.17[7.70]
-
96.67.145.115]
-
96.80.68[.193]
-
96.80.68[.194]
-
96.80.68[.195]
-
96.80.68[.196]
-
96.80.68[.197]
-
97.87.91[.211]
-
97.87.91[.212]
-
97.87.91[.213]
-
97.87.91[.214]
-
97.87.91[.215]
-
97.87.91[.216]
-
97.87.91[.217
-
97.87.91[.218]
-
97.87.91[.219]
-
http://2.192.67[.0]
Conti (most recent IoCs – previous IoCs can be found here)
- 61.71[.51[
- 146.38[.131]
- 214.9[.199]
- 118.252[.150]
- 62.52[.151]
- 228.48[.12]
- 146.57[.64]
- 209.228[.1]
- 242.128[.218]
- 95.92[.131]
- 102.40[.8]
- 210.165[.115]
- 232.118[.194]
- 43.143[.59]
- 218.152[.171]
- 204.54[.99]
- 31.19[.6]
- 166.48[.18]
Supporting Documentation
FTC warns companies to remediate Log4j security vulnerability | Federal Trade Commission
6 Tips for Managing Open Source Components Securely | Snyk
CISA Conti Ransomware Potential Targets - AlienVault - Open Threat Exchange
Microsoft: China-based ransomware actor exploiting Log4Shell (techtarget.com)
How To Use Open-Source Software Without Increasing Security Vulnerabilities (forbes.com)
China-backed APT41 compromised 'at least' six US state governments (yahoo.com)
30% of Apache Log4j Security Holes Remain Unpatched – The New Stack
Log4Shell Post-Mortem and What We Learned About Open-Source Security (avertium.com)
Log4shell exploits now used mostly for DDoS botnets, cryptominers (bleepingcomputer.com)
Qualys Study Reveals How Enterprises Responded to Log4Shell | Qualys Security Blog
New Linux botnet exploits Log4J, uses DNS tunneling for comms (bleepingcomputer.com)
New Threat: B1txor20, A Linux Backdoor Using DNS Tunnel (360.com)
New Linux botnet exploits Log4J, uses DNS tunneling for comms (bleepingcomputer.com)
Linux botnet spreads using Log4Shell flaw | IT PRO
APPENDIX II: Disclaimer
This document and its contents do not constitute, and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.
Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of Client's compliance with any law, regulation or standard.
COPYRIGHT: Copyright © Avertium, LLC and/or Avertium Tennessee, Inc. | All rights reserved.
Related Resource: [Threat Report] An In-Depth Look at Conti's Leaked Log Chats