Ransomware moves fast—so fast that there’s a new statistic that security companies are using, called “Time-to-Ransom,” or TTR. This can be defined as the time between initial compromise of the first system and the execution of ransomware.
Ransomware executables, for example, can be programmed to worm through environments using system exploits like BlueKeep or leveraging stolen credentials. Attackers can leverage their privileged access to push their ransomware executable to other systems with PsExec and a batch script. Sometimes, threat actors will use their access to manually log in to systems within the environment and manually execute the ransomware. Some of these tactics are faster than others.
As mentioned, TTR can be measured by the time of initial point of compromise to the time of first encrypted file. But what are the organizational priorities in the event of an attack? Is it to disconnect the internet? Is it to disconnect that one system? What about identifying how the attacker got access to the system?
Planning the intricacies of what to do when suspicious activity is identified is already a daunting task, but the added pressure of responding to a ransomware attack requires careful prioritization.
For instance, keeping the business up and running while launching an investigation to root out the cause is often not the best balancing act when it comes to responding to a ransomware attack. Organizations are successful at recovering from ransomware when a prioritized list of systems and accounts is created in preparation for a ransomware event.
When creating your prioritization lists, consider these common concerns:
- Is this system/account critical to keeping the environment operational?
- If this system/account was to be unrecoverable, would the environment be operational with a rebuild or a newly provisioned account?
- What is the impact on operations for a particular system to be offline? For instance, a financial system responsible for processing customer transactions would be prioritized for recovery over a financial system that stores historical data for financial statements/statistics.
- Identify and establish consensus among stakeholders to limit the amount of back-and-forth discussion about priority. (This is also a great tabletop activity.)
This list of systems will aid in the prioritization of backups and understanding what systems will need to be restored first to keep the environment operational. Once you have a realistic list of systems, start documenting the following:
- Function of the system
- Data that resides on the system (business critical application, intellectual property, protected information, and so on.)
- Network connectivity and system routes
- System business owner
This type of systems information will help the incident response team quickly pinpoint the right course of action. Once this information is identified and documented, the next step is to develop solid revision processes.
This is important since system information regularly needs updating due to changes—the environment and team grows, systems are decommissioned or migrated, patches applied, and so on. Tracking these changes can be done a number of ways, including using commercial products, or manual tracking via a spreadsheet for small or less mature environments.
This information is critical to the recovery process, because it will aid in answering questions about competing priorities. These priorities could include the collection of forensic data during an investigation, or allowing the investigating team to identify which systems should be prioritized for investigation and recovery.
But in a ransomware event, these systems can also be taken out, so it’s crucial to verify that there is some type of out-of-band workaround to keep operations running in a worst-case scenario.
During a ransomware investigation, accounts will be identified as “suspicious.” When an account is identified as being used for nefarious purposes, there should be a documented process for containing the account. Containment steps for compromised accounts include, but are not limited to:
- Deactivate the account
- Reset the password/access keys
- De-privilege access or permissions
- Revoke authentication tokens/keys
Identifying which accounts are used, and where, is imperative for moving quickly through the containment process. Before any systems can be restored or rebuilt, containment of compromised user accounts needs to be followed through to completion. A good place to start is to identify what users have privileges in what areas. This review process can include:
- Periodically reviewing all accounts, roles, and policies
- Providing system, application, and data owners with the necessary information to identify if privilege levels are appropriate for each account
- A process to reduce or remove access based on the results of the review
- Identifying unknown service or system accounts
- Providing documented guidance to administrators and system owners on the proper IAM processes
Over-privileged users and flat networks often give an attacker the advantage when it comes to deploying ransomware. The proactive process of validating a user’s business needs for specific access to an area on a regular basis can help strengthen security, and also make it harder for an attacker to move around the environment.
