Amid the year-end lull, the following seek-and-mitigate measures should have been taken to ward off impending new Log4j attack campaigns
Hackers are now actively scanning the internet for systems vulnerable to the Log4j exploit (CVE-2021-44228), and malicious tools are even being developed to automate such attacks.
The exploit targets the Java Naming and Directory Interface (JNDI) and the Lightweight Directory Access Protocol (LDAP), enabling attackers to load arbitrary Java code on a server, allowing them to take control. This makes it a highly attractive vulnerability for cyber perpetrators.
Additionally, while not all services and products are susceptible to the Remote Code Execution (RCE) exploits, they could be vulnerable to the information leakage attack associated with the vulnerability.
In the wake of the vulnerability disclosure, financially motivated actors involved in cryptocurrency mining were among the first to exploit targets. It is anticipated that there will be more monetization-centered exploitation activities this year, including data theft, ransomware deployment and multifaceted extortion.
While services and products that leverage the Apache logging framework are working on a fix, threat actors are already moving fast to find systems vulnerable to the exploit and gain access to the networks. It is now a race against time for organizations to take proactive measures to contain the situation and safeguard themselves.
Have these immediate actions be taken?
Although affected services and products are still working to patch the vulnerability, organizations during this time of year where more staff may be away, must take immediate steps to protect themselves against exploitation and mitigate the impact. Here are the key approaches to check off:
- The vulnerability is highly exploited in the wild, with massive reconnaissance activity. Organizations should assess the use and impact of Apache log4j2 library services in their environment and infrastructure as soon as possible, and identify affected assets, starting with externally facing servers and applications.
- If third-party applications are impacted, organizations need to remain up-to-date and understand the vendor-specific recommended short-term mitigation measures, in addition to the timeframe for when a patch or update path will be made available, as the situation develops.
- Organizations should keep a lookout for the release of scanning templates to identify this vulnerability and leverage internal and external vulnerability scanning tools:
- They should scan the environment to ascertain if this vulnerability exists
- Additionally, they can use open-source vulnerability toolsets to identify vulnerable log4j instances
- Organizations must prioritize mitigation activities and patch applications as soon as the updates are released.
- For external-facing and vulnerable servers, organizations should restrict all Internet outbound traffic to the bare minimum.
- Organizations can reduce the attack surface of impacted applications and servers by limiting access to the application interfaces that could be exploited.
- Organizations should focus on enhancing their visibility to identify attackers exploiting the vulnerability.
- Organizations can also hunt for the log4Shell exploitation with the following steps:
- Search for requests containing reference to the JNDI in available logs.
- Hunt for known Indicators of Compromise (IOC).
- If an organization identifies any exploitation on the server, it should verify if the server was vulnerable to the log4Shell vulnerability during the timeframes of the suspicious access attempts.
- It should also investigate the identified payload for any malicious activity, for instance, dropped files, encoded commands, Java class loading etc.
- Organizations can check their systems to see if there are signs of compromise from 1 Dec 21 before patching (to 2.15.0).
- Organizations can search for outgoing LDAP connections to destinations not seen before 1 December. If such connections are found, they can search the host for the presence of log4j. If there were DNS queries logged, they would need to review the queries to check for any possible exfiltration via DNS protocol.
- The presence of the indicators listed above may be indicative of an attack.
- If a compromised log4j instance is identified, organizations should conduct a forensic investigation, and implement remediation measures, such as removing any potentially malicious artifacts or backdoors.
- An attacker can leverage environment variables that contain credentials or keys to obtain additional infrastructure (on-premises or cloud-based). If a compromised log4j instance is running on a server where credentials are stored, organizations need to rotate and change the passwords or keys that could have been exposed.