Are you Ready for Stage 2 of the Log4Shell Attacks?

The tidal waves from the newly discovered Log4Shell zero-day attack are yet to be determined. Many organizations have hurried to patch their servers, making them immune to the massive attacks that were reported. However, patching your servers alone is not enough to ensure that this critical attack surface has been covered. While running the updated log4j version indeed secures against future attacks, one should also address the possibility that some servers may have been compromised prior to the patch. In this article, we’ll explain the feasibility of this scenario and follow up with actionable recommendations to proactively mitigate it.

Log4Shell-In-the-Wild Activity Recap

Apache Log4j is an open-source, Java-based logging utility widely used by enterprise applications. The initial reports on Log4Shell (CVE-2021-44228) date to December 9. These reports were quickly followed by extremely rapid development of new exploit variants with new variations of the original exploit being introduced rapidly- over 60 in less than 24 hours.[1] Also, within these 24 hours alone, attacks on organizations worldwide have surged, with various security providers reporting that vast portions of their customers were targeted by hackers attempting to exploit the vulnerability. [2] Currently the exploit is now rapidly integrated into the arsenal of common malware[3] and is also reported to be in use by advanced nation-state attack groups.

Assume Breach – Attacked Until Proved Otherwise

The enormous volume of these attacks presents a challenge to any security stakeholder who has patched their vulnerable servers. The rapid development and usage pace of the vulnerability exploitation mean that there is at least a viable probability that your servers might have been targeted by the exploit prior to the patching taking place. We strongly believe that security best practice, in this case, is to act as if your servers have been compromised until this threat is reliably disproven. Let’s review the various implications of such a compromise in order to best understand how to efficiently confront this threat.

Possible Stage 2 Threat Scenarios Following a Silent Compromise

Laying Low Until the Time is Right

Log4Shell by itself enables attackers to establish an initial foothold in your environment. This foothold is not the attackers’ goal but rather an essential preliminary stage. That means that if attackers have indeed exploited the vulnerability and gained a presence in one of your web-facing servers, there is no incentive for them to draw attention to themselves. Rather, they are more likely to operate low and slow, harvesting additional credentials and perhaps expanding to additional machines in your network before attempting to execute the attack’s actual objective. To judge from the common exploits that we see, there is a good chance that this objective is a ransomware attack that would shut down your operations, but it also can be theft of your intellectual property or PII of your employees or customers.

Sell the Access

Alternatively, the attacker may not utilize access to the network themselves. Rather, they could sell their server access to a third party on the dark web.

End-Result: Exposure to Lateral Movement and Ransomware Propagation

One way or another, there very well may be attackers with the keys to your kingdom, namely the usernames and credentials of your standard and admin users. This is bad because while the initial compromise damages a single machine, it’s the lateral movement part that turns a local event into an enterprise-wide risk. Compromised credentials enable attackers to do just that.

The Christmas Effect

Let’s not forget that attackers typically opt for holidays and weekends. The coming Christmas holidays are an especially bad time for your employees’ credentials to be in the wrong hands. We believe that attackers of both types described above will stay silent in the meantime, waiting for the right hour – Christmas can be the perfect timing.

Silverfort Best Practice Recommendations for Compromised Credentials

In light of all the above, we’ve compiled a set of actionable best practices to proactively confront the possibility that some of your servers were and maybe are still compromised by attackers that exploited the Log4Shell vulnerability:

• Patch End-to-End
  • Ensure that all vulnerable systems are patched with special attention to your internet-facing servers.

• • Isolate the applications you can’t patch both at the network level and at the identity layer.

• Prevent Attackers’ Ability to Utilize the Compromised Credentials for Further Malicious Access

• • Require MFA for all admin accounts for all resources in the environment. Also ensure that the MFA protection applies to access interfaces, including command lines utilities such as PsExec, PowerShell etc., and not just to RDP and desktop login.
  • Restrict service accounts to operate only from permitted computers. You should base this on these accounts’ predictable and repetitive behavior.
  • Monitor your environment closely for suspicious and malicious events such as a surge in simultaneous access requests from a single user, or any other deviation from your user account’s standard activity.

Following these recommendations will highly increase your resilience to a pre-existing Log4Shell based compromise and would void the attacker’s ability to leverage their stolen credentials for further malicious access.

The Silverfort Unified Identity Protection platform enables its users to extend Risk-Based Authentication and MFA to any user, service or system, providing proactive protection against identity-based attacks that utilize compromised credentials to access targeted resources. This includes end-to-end MFA protection, as well as continuous monitoring of all authentications both on-prem and in the cloud. Learn more about Silverfort here.