Surviving a Ransomware Attack

Surviving a One-Two Punch Ransomware Attack

Earlier this year, Kivu took on a ransomware case in which the client – we will call them Company A – was hit by not one, but two separate ransomware variants within the course of a few weeks. Initially, the victim was not aware they were infected, with device files being encrypted for nearly a month before they noticed something was amiss. This is a story about asset inventory, and more broadly the importance of knowing your operational environment. The organization had remained oblivious to the breach because they lacked clear oversight of their IT environment – essentially, no one had noticed anything because no one was looking for anything.

Preparation against cyber threats within any environment must start with defining the environment itself. This means conducting inventories of all connected devices, both physical and virtual, the information systems the devices support, and their associated security controls. It is no small feat.

Prior to the incident, Company A had acquired Company B. Company B ran its operations off two physical servers located at their office and owned five other devices which had been set up to link Company A and Company B’s networks. Due to the acquisition, an employee from Company A was regularly logging into Company B’s servers remotely. When the two companies merged, they did not align their individual security postures and controls with the new business needs. This discrepancy in security practices led to a Dharma ransomware attack followed by a second attack by LockBit one week later.

The first sign of infiltration was seen on a shared webserver – we’ll call this Server #1. Server #1 was used as a customer-facing portal and not separated from the remainder of the internal business network. At 02:23 AM EST, Server #1 was accessed by an Administrator account which ran an Advanced Port Scanner (APS) to map out all open communication channels between devices on the network. At 02:27 AM EST, the threat actor executed Mimikatz, an credential harvesting tool. With the use of both tools, and in the span of fewer than 5 minutes, the attacker was able to move laterally on a mapped-out network using real and authenticated employee accounts. Immediately afterward, the threat actor accessed Server #2 (the internal, non-customer facing server) and another connected device. At 02:36 AM EST – at this point they had been in the network for less than 15 minutes – the threat actor downloaded the Dharma ransomware strain and injected it into an illegitimate process called svhost.exe. Normally, the process would be titled svchost.exe (notice the additional ‘c’ in the name), a legitimate process grouping multiple applications into one to reduce computing power. The failure to inject the malware into a legitimate process suggests the threat actor was either too inexperienced or careless to remain undetected. By 02:40 AM, the svhost.exe was executed, deleting system logs and encrypting the infiltrated devices using Administrator level privilege. Having successfully infiltrated Server #1, Server #2, and the third device within less than three hours, the threat actor logged off at 04:52 AM. However, wanting to remain on the system, the threat actor left the svhost.exe file within the startup folder, ensuring it would execute each time the affected device was powered on.

A week later there was a second unauthorized access to Server #1, allegedly by LockBit, based on a deleted ransom note forensics was later able to recover. This time, the threat actor came in with a toolkit of over 50 programs to deliver a second punch to the victim’s network. It is unclear why another threat actor attempted an additional attack on the same network, but we speculate that the first attackers sold on the harvested credentials to the LockBit actors, or that the compromised credentials were initially sold to two separate parties. LockBit started their attack delivery at 11:12 AM EST, downloading their weapons toolkit. At 11:19 AM EST, all system logs were deleted to hide evidence of LockBit’s malicious activity. With the use of forensic tools, we were able to see all the programs that were eventually removed, including a deleted folder with approximately 82 encrypted files with the “.lockbit” extension, including the Restore-My-Files.txt ransom note. Due to this large-scale scrubbing, it is unclear what exactly LockBit was able to accomplish in the seven minutes they were in Server #1. We suspect LockBit noticed the inflicted damage by Dharma, became discouraged, and chose to reverse their course of action by deleting all traces of activity.

The unauthorized access by two threat actors was only noticed one month later when an employee logged on to Server #1 remotely and unwittingly caused encryption of the remaining files by activating the previously set up svhost.exe process from startup.

At this point, the system logs on every device within the network were deleted, which left a large gap of evidence in triaging infiltration, lateral movement, and accessed content. This all-too-common behavior leaves digital forensic analysts with far more speculation than answers, which is why the safeguarding of logs is so essential. Log preservation policies and security controls to safeguard the logs allow security professionals to not only trace and triage the series of events but help build threat actor profiles which can assist in subsequent cases.

This is not a unique story, though double-attacks like this are currently quite rare. In an acquisition, the proper sanitizing of connected network devices, as well as a thorough inventory and regular monitoring process all too often fall by the wayside and get much less attention than the financial accounting and other due diligence required for a merger. An organization seeking to strengthen and build on its security practices may need to build its asset inventory from scratch. As a starter, at Kivu we consider the following to be a few of the assets worth considering:

• Buildings and property, in this scenario the two physical office locations
• IT equipment, including all devices connected to the network
• Virtual assets, such as virtual machines and servers
• Records, ranging from system logs to visitor logs
• Digital information, such as files, emails, and databases
• Reputation: an internal understanding of the organization’s reputation, its competitors, and the potential impact of a breach on customers will all make a difference when a data breach occurs.

An organization cannot effectively protect what it does not know – or in the famous quotes of Sun Tzu: “If you know the enemy, and know yourself, you need not fear the result of a hundred battles.” For help with getting started, we recommend the Center for Internet Security’s guiding framework: Critical Security Controls.