While many articles explain how to fix the Log4j zero-day flaw, very few guide you through the process of recovering from a Log4Shell exploit if it is successful. If a bad actor can exploit this vulnerability, they can extract sensitive data, upload files to the server (like malware), jump to other servers, and delete data (like backup files). One concern is that these exploits can go undetected for years, even after patching the software. A bad actor can plant the malware and wait for months to activate it.
Understanding Log4Shell
The first step is to understand what products in the data center use the Log4j service, which may be difficult. The Log4j utility is an open-source Apache framework that is a commonly used component for logging error messages. It is a software product developed by volunteers of Apache Software Foundation, which is a non-profit.
Products from companies like Oracle, IBM, VMware, and Cisco use Log4j, and these companies have all issued patches. Recent reports show that bad actors are aggressively trying to find vulnerable instances to exploit, logging close to one million attempts.
Protecting from Log4Shell
The first step is to update software that uses the Log4j utility aggressively. The second step is to monitor your networks to see if you are scanned for Log4j vulnerabilities. The NCC Group has an excellent site set up to help detect a scan and identify vulnerable versions of Log4j on your systems.
The challenge is that you may not get to all the instances before being exploited. Also, it may take a long time for vendors, especially smaller vendors, to issue updates to their software. If one of the bad actors can upload malware onto your servers, then you need to have a well thought out ransomware recovery strategy in-place
Preparing for Log4Shell or what’s next
In most cases, because of the limitation of legacy production storage systems, snapshots won’t protect you from malware downloaded onto your servers by the Log4j flaw. They can’t execute them with a high enough frequency or retain them long enough to deter a slow-moving attack effectively.
Your next recovery point is the backup process. Since the ransomware can trigger almost anytime, the first step is to ensure the backup infrastructure can sustain frequent backups. The goal is to lower the recovery point objective as much as possible, thereby reducing data exposure. However, these frequent backups require a backup storage target with a flash tier to keep pace with this bursty semi-sequential workload. The backup storage target needs to extract full performance from the few flash drives to remain cost-effective.
Most modern backup solutions do an excellent job of identifying that an attack is underway, and they are doing a better job of protecting the data they create, like indexes.
The problem is the actual backup data is typically mounted via NFS or SMB, and the path to that data is common to the vendor. The bad actor only needs to know how backup vendor “A” mounts backup data. They can then easily mount the backup repository and delete it, making it impossible to recover.
The backup storage target needs to store data in an immutable format so that any external force, like ransomware, can’t alter it. To recover from a rolling attack, you may need several months’ worth of backups. The backup storage target should retain tens of thousands of immutable snapshots without impacting performance.
Recovering From a Log4Shell Exploit
Recovering from a Log4Shell Exploit is like recovering from any other ransomware attack. As we discuss in our webinar, “Ransomware’s Three Attacks on Backup and How to Neutralize Them,” recovery speed is critical to help the organization avoid the temptation pay the ransom. It seems faster, but there is no guarantee that the bad actor will provide the keys after payment. There is also the concern of not being 100% sure that the malware is wholly eradicated from the data center.
Rapid recovery speed involves three capabilities:
- Continuous or frequent backups, mentioned above, ensure almost no data loss.
- The ability to move data into position quickly. Most backup software today has a feature that enables the VM’s and applications to mount on the backup storage device, saving the transfer time over the network to production storage.
- The backup storage target, now that it is hosting the application, must deliver production-class performance so IT can take the time necessary to clean production storage. If the backup storage target is immutable, it is clean by definition.
Log4Shell is another in a long line of exploits that enable bad actors to plant malware so they can hold your data for ransom. It won’t stop with the round of patches that are sure to come due to the vulnerability. In another couple of weeks or months, there will be another vulnerability. The time is now to prepare your environment for whatever comes next.
Download our Three-Step Ransomware Recovery guide to learn more.
