Over the last 48 hours, a lot of information has surfaced about the log4j vulnerability. This post serves as the update on the information gathered by the Triskele Labs team as more information has come to light. The Triskele Labs team will keep releasing information via regular blog posts. Thanks to https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j for the below graphic on how the attack functions.
- Threat Actors have started to release capabilities to bypass Web Application Firewalls (WAFs). This will no longer protect your organisation.
- According to security researcher Greg Linares, there is also evidence to suggest that a self-propagating worm will be developed to target Log4j 2 vulnerable systems. This aligns with Triskele CTI’s assessment that while many organisations are focused on externally facing devices, internal devices should also be audited for the vulnerability and addressed.
#Log4J based on what I've seen, there is evidence that a worm will be developed for this in the next 24 to 48 hours.— Greg Linares (@Laughing_Mantis) December 12, 2021
Self propagating with the ability to stand up a self hosted server on compromised endpoints.
In addition to spraying traffic, dropping files, it will have c2c
- Triskele Labs is aware of RaaS gangs currently working on this exploit and we expect a considerable amount of ransomware attacks targeting log4j in the near future. Impacted organisations will either be directly targeted, or have access sold to Ransomware as a Service (RaaS) gangs.
- https://github.com/OWASP/Nettacker - to test your susceptibility to log4j
- 'Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC. That suggests it was in the wild at least 9 days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure.' - Matthew Price (CloudFlare)
- Our friends at Security Blue Team have curated an awesome list for hunting - https://securityblue.team/log4j-hunting-and-indicators/
-You can find IOCs here https://github.com/curated-intel/Log4Shell-IOCs and track new IOCs by using the following twitter feed tool shared by security analyst Daniel López:
- Details on canaries and detections can be found here: https://www.linkedin.com/posts/andrewgrealy_log4shell-log4j-log4shell-activity-6875511520835575808-9aFM/
The Triskele Labs CTI team advises that Proof-of-Concept (POC) code exploiting the vulnerability was made available on 10 December 2021 on a public Github located at https://github.com/tangxiaofeng7/apache-log4j-poc. The Triskele Labs CTI team has observed multiple researchers and threat actors adapting this POC code with obfuscation techniques to bypass detection, alongside exploring adaptation of the POC to various mediums, for example including malicious code in items from the following list shared by cybersecurity researcher Patrik Fehrenbach:
As the attack surface for log4J 2 is steadily growing, a Github repository maintained by YfryTchsGD contains an incomplete list located here: https://github.com/YfryTchsGD/Log4jAttackSurface. A more robust public list is currently in development by various security researchers.
The Triskele Labs CTI team has identified ransomware operators currently exploiting the Log42j 2 vulnerability against a plethora of security-based products. Additionally, endpoint security company Crowdstrike has observed that threat actors are engaging in targeted intrusion consistent with advanced attackers, such as deploying web shells and conducting lateral movement.
The Triskele Labs CTI team is also monitoring attempts by Mirai, Kinseng, and Muhstik botnets to exploit exposed infrastructure with the Log4j 2 vulnerability. The CTI team assesses that ‘spray and pray’ targeting is occurring in these instances. According to security researcher Greg Linares, there is also evidence to suggest that a self-propagating worm will be developed to target Log4j 2 vulnerable systems. This aligns with Triskele CTI’s assessment that while many organisations are focused on externally facing devices, internal devices should also be audited for the vulnerability and addressed.
Triskele Labs also advises that attacks should be prevented on a network level. Affected systems should be limited to communicating only with trusted hosts and protocols to prevent malicious class files from being downloaded with LDAP.
Organisations can check for vulnerable versions of this library by checking for hashes present in software inventories, listed on: https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes.
Detection of exploitation can be performed by following the guide located here: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
Bypasses are continually being developed, the POC code GitHub repository lists common techniques and is located here: https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce
Network logs should be checked for indicators of compromise (IOCs). IOC lists from various organisations are fast developing and being shared across multiple platforms. A collection of IOC lists from multiple organisations is being maintained by cybersecurity company Curated Intel and can be located here: https://github.com/curated-intel/Log4Shell-IOCs
Triskele Labs DefenceShield customers with Assess (our Vulnerability Scanning service) are being continually assessed for this event. All customers with our Monitor (our 24x7x365 SIEM) are - as always - being monitored for Shells and Lateral Movement. Triskele Labs has conducted external and internal IP and web application scans for all clients and continues to monitor the situation closely.
References used for the generation of this release: