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:
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:
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:
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:
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.
