Chapter 9
Recovery
To achieve great things, two things are needed; a plan, and not quite enough time.
—Leonard Bernstein
Learning Objectives
Understand strategies for effectively restoring operations
Learn about processes for recovering data
Reduce the risk of data loss and potential reinfection
Effectively transition from crisis mode back to a “new normal”
Cyber extortion attacks can have a negative impact on the victim’s operations, either as a direct consequence (for example, in ransomware cases) or indirectly as a result of the containment and response activities. Throughout the entire crisis, responders must keep in mind the ultimate end goal: recovery.
“Recovery” in the context of this book is the process of regaining normal functionality to support operations. Typically, responders work on recovery efforts in parallel along with containment, investigation, negotiation, payment, and other time-sensitive response activities. Recovery efforts typically include the following steps:
Back up important data, including key configuration settings, encrypted files, and data repositories.
Restore operations, including the following phases:
– Build your recovery environment
– Implement monitoring/logging
– Establish your process for restoring computers
– Restore functionality based on the order of operations described in Section 9.5
Restore data that may have been encrypted, deleted, or simply rendered unavailable.
Clean up any changes made during the crisis and transition to a new normal.
To restore operations as efficiently as possible, make sure to follow a methodical restoration process. Woe to the response team that skips steps and accidentally tramples on critical evidence or makes an erroneous change that can’t be reverted! There is always pressure to resume normal business operations as quickly as possible. As we will see, the order of operations and timing matter enormously. Seemingly small decisions can make or break your recovery plan.
In this chapter, we dig into logistics for rebuilding your technology environment, restoring data, evaluating and implementing improvements, and cleaning up from the response process. Along the way, we share real-life examples and point out common mistakes that can help you recover more quickly and with lower risk.
9.1 Back up Your Important Data
Expect the unexpected during a cyber extortion recovery. The process is risky, especially when you are dealing with an environment that has been compromised. Adversaries may have planted a backdoor in your environment or set up stealthy malware that detonates at predetermined times. The risk of a ransomware reinfection or follow-on compromise is high.
Compounding this is the fact that recovery during a crisis is typically unplanned, rushed, and fraught with pressure. Rarely is documentation of the previous environment complete before you are thrown into the crisis. Often, responders discover unexpected dependencies throughout the recovery and have to backtrack and redo work.
Make sure to back up and/or image important data before starting your recovery process. This may include data that isn’t immediately intuitive, such as the following items:
Configuration files: Before you modify the system or network configuration, back it up so you can reference it or roll back if needed. Configuration files may also be useful for forensic investigations (see Chapter 6 for details).
Data repositories (including encrypted data): Make sure you have a complete backup of all important data before you attempt to restore it. You should always have at least one version of important data stored offline at all times. Don’t attempt to restore data using the sole existing copy. At any point during the recovery process, your data may become corrupted or re-encrypted. Make a copy and attempt restoration from that copy. Keep the original offline and safely stored so that you can go back to it if something happens.
Make sure to include a backup of your encrypted data if you have already been hit with ransomware. If you are hit with a secondary ransomware attack during the recovery process, your data will be encrypted with new keys. You want to be able to roll back to the previous encrypted version, so that you can use keys you have already purchased or obtained. Otherwise, you may have to negotiate with the adversary, purchase new keys, and start the recovery process all over again.
Critical systems, such as domain controllers, file servers, etc. It is usually not appropriate to do a full image or backup of every single device in the environment, due to time and resource constraints. However, you may wish to make a backup or forensic image of key systems, such as the domain controller, core file servers, or others. Even if you start from scratch and build the systems anew, having backups can be invaluable for reference, or for recovering data or configurations that you might not have realized are important.
Tip: Back up Before Making Changes
One of the most common mistakes occurs when responders simply do not take the time to back up configurations, operating systems, or encrypted files. In the triage phase, the pressure to restore normal business operations quickly can sometimes trump this critical best practice. However, the risk of data loss during an unplanned and messy recovery is very high.
Never put your organization in a position where responders may make a change that cannot be reverted to the prior state. Make sure all important files in your cyber extortion incident are backed up, in case you need to get back to the starting point.
9.2 Build Your Recovery Environment
The victim’s recovery environment is a stripped-down network designed to minimize the risk of reinfection or compromise, while facilitating an efficient recovery. While it takes time to set up a recovery environment properly, the payoff in terms of risk reduction is huge. Skipping this step may lead to reinfection or an ongoing compromise.
In this section, we present a typical architecture for a recovery environment, which is used when there has been a widespread compromise of the victim’s normal production environment. The goal of the recovery environment in these cases is to provide an infrastructure to restore and monitor systems and minimize the risk of a lingering infection.
Keep in mind that every recovery is unique. This section provides general guidance, which you should thoughtfully customize as needed for a specific incident.
9.2.1 Network Segments
Typically, the recovery environment requires at least three separate, isolated network segments:
Clean network: Where the new, production environment will ultimately live. When you set up your “clean” network, make sure to minimize the attack surface by keeping services off and ports closed until they are needed. Never connect a potentially compromised system directly to your “clean” network.
Dirty network: Where responders initially connect potentially compromised systems and/or data repositories that may contain malware. The “dirty” network should be fully isolated to the greatest extent possible. If you connect a compromised system to the Internet, an adversary may continue to siphon off data or add additional malware. To the greatest extent that you can, keep the dirty network contained. Assume that everything on it is compromised. If possible, systems on the “dirty” network should not be allowed to communicate with each other.
Transition network: An intermediary subnet used for transferring data/systems between the clean and dirty networks. The transition network should be heavily instrumented and monitored, so that you can detect any unexpected malware or signs of residual compromise that may have been missed when the system was cleaned.
The precise architecture of your recovery environment will depend on your unique environment, resources, and needs. If you have the ability to segment your environment using separate virtual LANs (VLANs), this is an easy and effective approach. Recovering a cloud environment such as Azure or Amazon Web Services (AWS) can be surprisingly straightforward, since VLAN segmentation options are built in natively. At other times, it is necessary to put hands on cables and segment a network using IP addressing.
Often remote access is configured early on to support IT effort. In such a case, the access must be highly restricted and filtered, to minimize the risk of additional compromise and data exposure.
Whatever your strategy, take the time to think it through and document your setup before beginning the restoration process. Make sure to use a minimum of three separate environments, as outlined earlier: one for “dirty” systems, a transition environment for monitoring, and the final “clean” network.
9.2.2 Network Devices
The recovery environment can be much simpler than a full-scale production network. As a result, responders typically need only a few network devices to get it up and running.
If you are reusing network devices from the victim’s existing infrastructure, make sure to perform these actions:
Back up the configuration and logs from each device prior to making changes.
Simplify the configuration as much as possible to support the recovery environment only. Most of the time, you will want to erase the existing configuration (after backing it up) so that you start with a clean slate.
Change any usernames/passwords or access strings. Make sure to select strong new credentials and store them securely.
Configure the devices to support your recovery needs (i.e., three segments with limited Internet access). It is wise to start by denying all access between segments and to the Internet, and then grant access on a case-by-case basis. You will also want to configure support for detailed logging/monitoring.
Later, responders will update the network configuration to support a more complex architecture. For now, in the recovery phase, the primary goal is to create a secure, clean environment that will minimize the risk of reinfection or ongoing adversary access during the recovery process.
Tip: Improve the Technology Environment
Victims usually have no choice but to improve their technology environment when recovering from a cyber extortion attack. Typically the adversary has gained access to the environment by leveraging weaknesses that must be addressed, or else the crisis will repeat itself. In some cases, it is faster and cheaper to purchase new hardware than to fully clean and restore every system from scratch (especially if there is a strong need for evidence preservation).
In addition, the aftermath of a cyber extortion event can present a uniquely unimpeded environment for implementing changes. For example, in ransomware cases, the victim’s local network may already be offline or in a state of partial operation. This is a perfect opportunity for the victim to implement badly needed architectural improvements or infrastructure changes that might normally cause disruption.
In much the same way that forest fires clear out space for new growth, the devastation caused by a major outage can provide political capital and down-time that facilitate implementation of key technology improvements. When going this route, it is important to make changes consciously. The organization may have suddenly shifted to the cloud or personal devices in the wake of a cyber extortion event. During the response, leadership should consider whether to continue use of these new processes and technologies, or shift back to a more traditional approach. The decisions made during the recovery process will have long-lasting effects on the overall technology environment, the user experience, and the potential for additional cybersecurity incidents in the future.
Every crisis is an opportunity, and a cyber extortion event is no exception. Take advantage of it where you can.
9.3 Set up Monitoring and Logging
Once the victim has been compromised, they are at elevated risk of a future infection—and probably always will be. Why? An adversary has learned extensive details about the victim’s environment, and may have exfiltrated passwords, network information, supplier details, user lists, and other information that can be leveraged for future attacks.
In addition, the adversary may have planted malware in the environment, which may or may not be active right away. As an example, in the SolarWinds compromise (discussed in Chapter 1), the adversary installed a backdoor in the SolarWinds Orion network monitoring product, which was pushed out to 18,000 customers beginning in March 2020. The malware did not send out its first beacon until it had been installed for 12 to 14 days. Instead, it lay dormant, evading detection by security analysts or researchers who typically analyze malware in sandboxes for shorter periods of time when checking for malicious activity.1
1. Fire Eye, “Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims with SUNBURST Backdoor,” Mandiant, December 13, 2020, www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html.
Effective monitoring is critical for detecting threats early and minimizing the risk and damage of a compromise. In the following sections, we discuss the goals of monitoring (both short-term and long-term), the key components of your monitoring infrastructure, and processes for detection and response.
9.3.1 Goals of Monitoring
The importance of implementing an effective monitoring program quickly cannot be overstated. Without it, the victim may suffer additional compromises that could have been avoided by implementing appropriate detection capabilities. Monitoring is important both for short-term and long-term reasons:
Short term: During the recovery process, responders aim to detect malware and other signs of compromise on the dirty network and the transition network, to ensure that they have effectively removed any threats from systems before they are moved to the clean network. This will reduce the risk of reinfection during recovery.
Long term: An effective, ongoing monitoring program will reduce the risk of future compromise. This is especially important because, as previously discussed, after falling victim to a major cyber extortion event, the organization will typically remain at an elevated risk.
Quite often, the victim’s monitoring capabilities prior to the compromise were inadequate, which contributes to the risk. When that is the case, it is important to allocate additional budget and resources to design and implement effective monitoring.
9.3.2 Timing
Monitoring capabilities should be implemented as early as possible during the recovery process. The good news is that the beginning of the recovery process is often an ideal time to make major changes to the monitoring architecture, which might otherwise require scheduled downtime. For example, while network devices are being configured, responders have the opportunity to add logging and monitoring capabilities. There may even be a need to purchase some new network hardware, which can be carefully chosen to better support an integrated monitoring program. Since the environment is usually down during this time already, changes can be quickly tested without concern for impacting ongoing operations.
Likewise, as workstations and servers are rebuilt, the response team should consider adding or upgrading endpoint monitoring software so that it is consistently deployed and configured throughout the environment.
9.3.3 Components
An effective monitoring architecture relies on an integrated selection of complementary tools, which have been carefully chosen to provide visibility throughout the technology environment. The following areas typically should be monitored:
Individual workstations and servers
Network (internal and perimeter)
Cloud
Mobile devices
Here are some important components to include in a robust monitoring program:
Antivirus software: Make sure that effective, properly licensed antivirus software is installed on all endpoint systems. This should include both signature- and behavior-based detection methods. Ensure that antivirus software runs regularly, updates frequently, and reports back to a central location.
Flow records: These summaries of network traffic are typically already generated by network equipment, but not always collected. Flow records can be extremely useful for tracking malicious activity, identifying attempted lateral movements, and determining whether an adversary exfiltrated data.
Intrusion detection/prevention system (IDS/IPS): These security products automatically detect and prevent threats. Host-based IDS/IPS are installed on endpoints, whereas network-based IDS/IPS are designed to monitor network traffic (network). To be effective, these tools typically need to be carefully tuned to detect threats relevant to the local environment and reduce false positives.
Endpoint detection and response (EDR) software: EDR tools are designed for use by an experienced professional to hunt for malicious activity that can evade automated antivirus software. They are especially useful during the recovery process, as a means to identify more subtle malware on the dirty network and transition network, and to monitor the clean network carefully in the days and weeks following the recovery. The victim may or may not choose to integrate EDR and similar software into their environment on a long-term basis.
Logs (including firewall logs, application logs, workstation logs, and cloud systems): All modern network devices, operating systems, and major applications are designed to output activity logs, which can be extremely useful for scoping security incidents. These can include authentication logs, records of privileged use, and even logs of specific commands. Make sure that you enable appropriate logging for your environment and collect logs in one central location to facilitate quick access.
Centralized long-term storage and analysis: A centralized platform can be used to aggregate and analyze monitoring information from many sources, including all the sources just listed. Traditionally this is implemented as a SIEM or syslog server. Responders can access the centralized platform to obtain historical telemetry data and/or real-time, actionable intelligence regarding potential network threats and activities.
When selecting monitoring components, responders should consider both the immediate, short-term needs of the recovery process and the organization’s longer-term monitoring processes. Whenever possible, components should be selected to support the recovery process as well as the organization’s long-term needs, so as to minimize waste and use resources as efficiently as possible.
9.3.4 Detection and Response Processes
Setting up a monitoring program isn’t enough: Humans need to actively review alerts and investigate suspicious activity. All too often, organizations invest heavily in monitoring tools, only to skimp on the human resources required to actually analyze the intelligence and respond.
Monitoring needs to be maintained at all steps during the recovery—and beyond. It is critical during the first days and weeks, when the likelihood of an ongoing malware infection or compromise is high. Even after the recovery phase has passed, monitoring must continue as part of the daily hygiene of the technology environment. It is a new normal. (See Section 10.3.4 for more details about establishing continuous monitoring processes on a long-term basis.)
Case Study: An Ounce of Monitoring Is Worth a Pound of Reinfection
A midsized accounting firm reached out for assistance following a ransomware attack against its network. An adversary had gained access to its domain controller and used the PSEXEC toolkit to distribute the Dharma ransomware variant to the firm’s primary file servers. Backups for the network were not new enough to be valuable, so purchasing a decryptor was the only way to recover sensitive client information.
The authors were brought in to facilitate negotiation for the decryptor, test its functionality, and deliver the software to a private IT contractor who would handle decryption. Once the transaction and testing were complete, the decryptor was sent to the firm’s IT staff and decryption began. The victim was advised to back up all of its encrypted data prior to attempting to use the adversary’s tool, and thankfully it did.
The first panicked call from the victim came about 3 hours after the firm received the decryptor. Everything seemed to be working fine, but after about 30 minutes all the files they had decrypted were suddenly re-encrypted with a new encryption key.
It turned out that the victim’s IT staff, feeling pressured for time, had decided to simply run Windows Defender on the firm’s servers and then decrypt the data without setting up any additional monitoring or detection capabilities. Unfortunately, the ransomware was still active in their production environment. Absent any advanced detection capabilities, staff did not identify the residual infection until it was too late.
After three failed attempts to decrypt the data over the next two days, all data was shipped to LMG’s lab. There, staff securely decrypted the data in a recovery environment while the victim’s IT staff fully rebuilt the network from the ground up and added monitoring capabilities.
9.4 Establish Your Process for Restoring Individual Computers
Once you have built your recovery environment, it is time to start recovering individual computers. Carefully think through this process and make sure to document it, so that all responders are on the same page. Whether you are restoring servers, workstations, mobile devices, or other systems, here are some key steps to address for every system:
Preserve evidence, if needed. (See Chapter 6 for details.) Make sure to develop an evidence preservation strategy, with input from the victim’s legal counsel.
There is always a tug-of-war between the need for a fast recovery and the drive for evidence preservation. Responders need to consider the most efficient ways to gather evidence and clearly communicate the necessary tradeoffs with leadership and legal counsel. Take into account each system’s criticality and the classification of data stored on it, as well as the potential needs of a breach investigation.
For some high-priority systems, a full forensic image of the hard drive may be critically important. For other systems, responders may be able to gather a subset of evidence using targeted imaging techniques, such as Custom Content Captures in FTK.
Restore normal functionality. If you can fully rebuild the system from scratch, this minimizes the risk of reinfection. New systems should be built from the ground up on the clean network. In many cases, however, a full rebuild takes too much time. When documentation of configuration and dependencies are scarce, rebuilding from scratch can be especially challenging.
If a full rebuild is not practical, responders can restore functionality of the existing infected system and use security tools to eradicate malware, as detailed next.
Eradicate malware. All potentially infected systems should be placed on the “dirty” network segment when they are first reconnected. While on the “dirty” network, make sure to:
– Scan with effective antivirus software (it never hurts to use more than one).
– Leverage endpoint detection software, such as threat hunting tools, host-based IDS/IPS, and endpoint detection and response (EDR) toolkits.
Minimize the risk of a future security incident. Responders should proactively implement host-based security and configuration improvements, such as the following:
– Install software updates and patches.
– Change all passwords associated with the system.
– Harden the operating system, using widely accepted benchmarks and standards.
Monitor to reduce the risk of an undetected infection. Normal user workstations should be monitored on the dirty network for at least 24 hours before transfer; more critical systems such as domain controllers may be monitored for 72 hours or more.
Once the initial monitoring is complete, responders can transfer each system to the clean network, typically by way of the transition network. All systems should be subjected to careful, ongoing monitoring, particularly within the first 90 days after the infection.
9.5 Restore Based on an Order of Operations
Now you’re ready to get your technology environment back up and running! The order in which you restore devices and services is critically important for ensuring a smooth transition.
In general, responders should begin by establishing the core of the network, which will serve as the backbone for the rest of the environment. Once the core is up and running smoothly, you can configure the remaining network and bring up peripheral servers and workstations. Here is a simple restoration checklist, in order:
Domain controllers (DCs)
High-value servers
Network architecture
Workstations
There are significant benefits to restoring the environment incrementally instead of all at once. First, every recovery effort has limited resources. Breaking the restoration into chunks and taking a methodical approach enables the recovery team to stay organized and verify that each component is free of malware and operating correctly before other systems are connected.
In addition, if responders bring everything up at the same time, it can be very challenging to identify a single piece of the infrastructure that is causing an issue. Taking the time to verify that each component is functioning correctly reduces the risk of repetition and widespread reinfection.
In the subsections that follow, we provide tips for each component of the restoration. Every environment is different, and your unique needs may vary. Consider the information presented here as a foundation, and modify it as needed to suit your specific situation.
The only hard-and-fast rule is to make conscious decisions about the restoration process, rather than blindly moving forward.
9.5.1 Domain Controllers
It’s usually a good idea to start by recovering the DCs. They must be up and running if you are to properly manage your users, permissions, devices, policies, access controls, and more.
Unfortunately, because DCs are so critical, they are often targeted by the adversary. Access to a DC gives hackers the keys to the kingdom—access to all user settings, all access controls, and more. If there is any system that can traverse individual VLANs, it is the DC.
Responders must balance two competing interests: the need to get the DCs up and running fast and the risk that they may be compromised. It is wise to assume your DCs are compromised unless you have very strong evidence to the contrary. If you restore an infected DC, you will almost certainly have to rebuild the network again a second time. Play it safe and do not trust the integrity of your DCs.
Here are steps to restore a DC that may be compromised:
Preserve evidence. Image the whole operating system if you can. That way, you can check carefully for signs of compromise and trace the adversary’s access after the fact. Capture RAM and other volatile evidence, if possible.
Export data. Extract key data from the old DC, including users, groups, group policies, and any other items that your specific domain configuration will require.
Audit the configuration. Adversaries often add user accounts or leverage misconfiguration/lax permissions. Carefully review all accounts and remove any that are unnecessary or suspicious. Tighten permissions and align them with a zero-trust model whenever practical.
Change all passwords. Adversaries often steal passwords with the aim of breaking into the environment or moving laterally. A full, immediate, system-wide password reset is the safest approach. This includes every account, from system administrators to users. Ensure that old passwords cannot be reused.
Do a Kerberos reset. Adversaries will frequently compromise Kerberos tokens to elevate their privileges and maintain persistence. Responders should include a full Kerberos reset and the revocation of active access tokens. This can be done via PowerShell from the DC.
Build the new system. If possible, use new hard drives for high-priority systems to speed the recovery. Otherwise, wipe and reinstall the operating system to ensure that no malware remains. Then import key data from the old DC, after it has been carefully audited and updated.
Restore key network services. If your DC will be responsible for DNS or WINS services, begin configuration of the services so that servers and workstations in the following steps can connect to each other without requiring a static IP address.
Start by following these steps for your primary DC, and then replicate this process to build your secondary DCs. It is a time-consuming process—but far less time-consuming than dealing with a reinfection.
If the victim chooses not to fully rebuild the DC and instead opts to restore using the existing software:
Follow the steps from Section 9.4 to minimize risk of a residual infection on the system.
Audit the configuration and change passwords, as described in this section.
Perform a double Kerberos reset from the DC to avoid a “golden ticket” attack.2
2. Mike Pilkington, “Kerberos in the Crosshairs: Golden Tickets, Silver Tickets, MITM, and More,” SANS (blog), November 24, 2014, www.sans.org/blog/kerberos-in-the-crosshairs-golden-tickets-silver-tickets-mitm-and-more/.
9.5.2 High-Value Servers
The next step is to connect the victim’s high-value servers to the domain. These are the key devices and applications that the organization needs to operate. They will be different for each organization, but typically include the following servers:
Database servers
Application servers
Other peripheral servers
Take a measured and planned approach. Start by identifying high-value servers, and then recover as discussed in Section 9.4. Ensure that high-value servers are restored in a hardened, secure configuration, so as to minimize risk.
In many cases, the system may include complex dependencies that are not well documented. For example, the database server may need to be brought online first, before an application server is brought online. Review any existing documentation prior to attempting restoration, so as to minimize roadblocks. If a full map of connected servers, their dependencies, and overall network connections is not available, now is a great time to create one that can be referred to later if problems present themselves.
Tip: Preserve Evidence on High-Value Servers
Typically, it is wise to take a forensic image of high-value servers that have been running in a compromised environment, particularly if they store sensitive data or can be leveraged to access other key repositories. These systems are often primary targets of attackers.
Make sure to preserve, at a minimum, the operating system and event logs. When possible, preserve metadata and logs from any repositories containing sensitive data. This evidence can be critical during a breach investigation (see Chapter 6 for details).
Finally, if the system contains data that was encrypted by an adversary, back up the encrypted data.
9.5.3 Network Architecture
Up to this point, the recovery process has been conducted using a simple skeleton network designed specifically to facilitate restoration, with multiple segments that support monitoring and isolate potentially compromised systems. Once the core servers have been brought online and verified to be clean, it is typically a good time to fully restore the overall enterprise network that will support normal operations. This includes adding segments for workstations and servers, implementing port forwarding, establishing internal NAT, setting up VPNs, and so on.
Tip: Don’t Let a Good Crisis Go to Waste
This is a rare opportunity to review your architecture and make improvements, because the network is already down. Take advantage of it!
Often, a cyber extortion event occurs in part because an adversary was able to move laterally throughout the network undetected for an extended period of time. Now is the time to implement effective segmentation and monitoring, as a means to reduce the risk of future compromise.
Review your architecture carefully and document any changes that you intend to make, so that the recovery team is aligned. Implement proper segmentation, as well as additional monitoring capabilities that will enable you to detect any latent threats. At a minimum, make sure to capture flow records and logs for network devices, and tie these into a central monitoring service.
When bringing the network online, most responders reuse existing hardware, though they may supplement it with additional purchases as needed to support upgrades. The first decision to make is whether network devices need to be fully rebuilt or simply audited and updated. For expediency, the less you need to fully rebuild, the better. However, this convenience always needs to be balanced with risk. If there is a risk that a network device was subjected to unauthorized access, you may want to do a factory reset and reconfigure the device.
Whichever you choose:
Back up the device configuration. This is important for two reasons: (1) It can help you revert changes as needed and (2) it is important evidence that can be later used to support the investigation. See Chapter 5 for more details.
Collect any logs that may reside locally on the device.
Change device passwords and access strings to minimize the risk of ongoing compromise.
Check the configuration to identify any suspicious rules.
Configure the new device. If you are reusing existing configurations, audit them carefully to identify any suspicious rules or insecure configurations and update as needed.
Take a zero-trust approach whenever possible. As you design and configure the network, consider the scenario in which an adversary has access to a compromised workstation or server. A well-designed network architecture can limit the spread of compromise, slow down the attacker, and facilitate early detection.
9.5.4 Workstations
The victim’s fleet of workstations is normally the last part of the infrastructure to fully come back online. Up to this point, only the workstations needed to configure essential services and collect evidence have been available. Now it’s time to bring the remaining devices back online—a process that presents unique challenges due to the number of new devices that need to be cleaned and transferred. This is where the rubber hits the road.
If possible, it’s best for responders to create new workstations using a “golden” image installed on a completely formatted hard drive. It might be tempting to just start plugging in the workstations that were already on the network, but spending appropriate time here greatly reduces the chances of a follow-on infection. Computers that were potentially exposed to malicious activity during the cybersecurity incident may have undiscovered malware, backdoors, vulnerable configuration, outdated patches, and other security risks. The golden image created to build new systems should already be up-to-date on security patches, have antivirus software preinstalled, and be hardened against exploitation.
If the victim opts to bring previously active workstations back on to the network without installing a fresh operating system, make sure to install and run updated antivirus and monitoring software prior to connecting the workstations to the production network.
It’s a good idea to bring workstations online in stages. Connecting too many simultaneously can overwhelm your monitoring capabilities and malicious activity might be missed. Here is a sample order for prioritizing your workstation recovery:
Mission-critical personnel: Workstations used by critical IT and support staff. These members of the organization may be responsible for additional network and server configurations, technical support, or other essential tasks.
Executives: High-level members of the executive staff, who need to take priority. These members of the organization are responsible for maintaining business operations, making high-impact decisions, and guiding the overall direction of the organization. This step also takes pressure off IT staff members, who have undoubtedly been bombarded with questions from executives about when their workstations will be back online.
Secondary IT staff: Members of the organization who are responsible for lower-level user support. These users will need to be in place and ready when the primary workforce comes online so issues with performance and configuration can be addressed without removing resources from the response team.
Other mid/high-level staff members: Members of the organization who are necessary for maintaining day-to-day operations. This group will typically include departmental managers, service dispatchers, administrative support staff, and others who require system access to maintain organizational flow.
Everyone else: The remaining members of the organization, who may not require full access to the network as a part of their job duties. These users rely on the system only for tasks like email, general communication, and other tasks that can either be completed without network access or are not time sensitive.
Breaking the workstation recovery into these stages enables responders to test, maintain, and correct monitoring issues, antivirus alerts, connection issues, and other potential network problems. Any workstations that show indications of malicious activity need to be immediately removed from the production network and quarantined. If malware is discovered, antivirus and monitoring software can be configured with updated signatures to prevent further activity. The isolated workstation should be given to responders for evidence preservation, formatting, and installation of a new operating system.
Heads Up! Missing Documentation Is Costly
Planning a potential recovery strategy before an incident can save significant amounts of time if the network needs to be rebuilt from the ground up. Many organizations do not have a full data inventory, network map, dependency map, and other essential documentation describing how the network is configured. When responders have to figure this out in the midst of a crisis, it leads to stress, wasted time, and frustration. Work with your IT staff to develop these documents now, because you will not have time during a real emergency.
9.6 Restoring Data
Data restoration can be done in several ways depending on the type of incident, its severity, the impacts, and other factors. A balance needs to be achieved among considerations such as speed, completeness, cost, and resources required.
To effectively restore your data, you need to have a solid understanding of which data is missing. Refer to your data inventory if you maintain one.
In this section, we begin by describing techniques for transferring data while minimizing risk. Then, we discuss each of the following strategies for recovering data after a catastrophic cyber extortion incident:
Backups
Gathering from current production systems
Reentering and re-creating data
– Paper files
– Other sources (e.g., does a patient have records on file at a different nearby hospital?)
– Interviews
Decryption
9.6.1 Transferring Data
Data recovered from a “dirty” (or potentially compromised) system needs to be tested and verified before it is restored to the production environment. This careful transfer is accomplished in different ways depending on where the data in the dirty system is located. Data is commonly transferred using one of the following methods:
Physical data transfer: Data contained on physical devices in the network can be moved by transferring the data to external media (e.g., USB-connected storage) or by physically moving the drives containing data to the transition network.
Virtual device storage: Virtual hard drives containing data can be moved to a transition segment within the virtual environment by disconnecting them from their virtual host and attaching them to a scanning system. Do not move live virtual machines out of the dirty network if possible.
Cloud storage: Data contained within cloud archives can be downloaded to the transition network for scanning and verification. The data can be uploaded again after scanning is complete.
The separation between the transition environment and the clean environment should be maintained at all times. After data is scanned on the transition network, it can be moved to the clean network, assuming that no malicious items were detected. The clean network should then be monitored closely to ensure that no indicators of malicious activity are present. Make every effort possible to avoid cross-contamination.
The way data is reintroduced to the production network needs to be planned for the purposes of efficiency, as well as risk reduction. Responders will potentially be moving terabytes of data into the new environment, and just starting a top-to-bottom copy operation can take a significant amount of time. Prioritize data that has high value or is necessary for business operations first. Items such as older archived files, backup data, or other elements of the filesystem that are not immediately needed can be placed at the back of the line.
9.6.2 Restoring from Backups
If backup files are available and intact, then restoring from backups is typically the preferred approach. This is normally done right after evidence is collected.
Unfortunately, restoring from backups is not always a quick process. If your network is virtualized and you can just roll back to a previous snapshot, this will often take significantly less time than a bare-metal restoration—but it will still take time. If you have cloud-based backups, the time needed to download those backups must be factored into the recovery timeline. Some backups may be very large and will take time to prep. Responders also need media with enough space to house the files during this process.
Another consideration is the integrity of the backups. It is always wise to assume that the victim’s backups may be infected, even if responders are relatively sure they date from a time prior to the system’s compromise. An adversary could have been accessing the environment for months before deciding to pull the trigger on their extortion plot, so the backups may be laced with malware or otherwise compromised. Restoring the environment to a compromised state opens the door for a follow-on infection and the negation of all the progress made to this point.
Finally, the age and frequency of the backups need to be evaluated. In almost any restoration from backups, some data loss will be encountered. Responders need to decide if the amount of data lost is significant enough to trigger a change in the recovery strategy.
Case Study: Time Is Not on Your Side
In a 2019 case handled by the authors, a midsized municipal city government was taken offline by a Ryuk ransomware attack. Bills could not be sent or paid, taxes could not be addressed, and local residents were angry.
The government office did have full backups for all the encrypted data, so paying a ransom for decryption was not a concern. The problem was where the backups were stored.
As part of the city’ s VEEAM environment, automated cloud backups were taken frequently and uploaded to a storage location in AWS. The backups were then transferred to long-term storage for retention. The city had never done a full test of its backup system, so the time to download and prep all of the images was a complete unknown. City services were already significantly impacted and would continue to suffer until at least the core infrastructure could be brought back online, so time was of the essence.
Unfortunately, the city realized quickly that getting backups for its environment was not going to be a fast process. Between downloading the backups (1.5 weeks), transferring data between systems (5 days), and restoring servers (2 weeks), the network was offline for almost an entire month.
9.6.3 Current Production Systems
In some cases, data may still be intact on segments of your network. If the adversary was unable to fully access systems, or for whatever reason did not destroy everything, the victim may be able to simply collect the data from various sources. This does not mean you can just plug unencrypted data repositories back into the production environment, however.
This data needs to be evaluated for the presence of malicious files, as well as for integrity and completeness. Remember, any data being transferred from the dirty environment to the clean production environment should be treated as if it is potentially infected.
A data inventory should always be part of your overall response program. If data was corrupted, deleted, or otherwise compromised, responders should document any missing items and adjust the recovery plan accordingly.
9.6.4 Re-creating Data
An often-overlooked method of data recovery is the manual reentry and re-creation of data. In organizations that maintain paper copies of sensitive data, such as hospitals, the opportunity may exist to add this data back to the digital storage in the network by hand. This data may be recovered from multiple sources:
Paper files
Archive media (CDs, DVDs)
Interviews with users/clients
Other sources (e.g., does a patient have records on file at a different nearby hospital?)
This can be a very long and tedious process. If your intention is to re-create your data in this manner, consider hiring a data entry firm to do the job for you. It may cost your organization money to hire them, but your staff will be free to do their normal jobs and the time it takes to complete the process will likely be much shorter.
9.7 Decryption
Decryption is usually the last resort for recovering data from a network impacted by a ransomware incident, but it is an unfortunately common scenario. In many cases, the data that is needed to bring a victim’s environment back to life is simply not available from any other source. If primary systems are encrypted and no backup data is available, or if the backup data is old enough to lead to significant data loss, then a response team may find themselves in a situation where a decryption utility is their only hope. This approach comes with its own significant risk to the network.
Responders need to take a methodical and cautious approach to avoid potential setbacks—or even worse, a complete reinfection of the network. In this section, we discuss:
The decryption process
Types of decryption tools
Risks of decryption tools
Testing
Decryption
Tip: Backup ALL Valuable Data
Before any recovery is attempted on a network, make sure to back up all data that needs to be decrypted in its current state. This means files, folders, ransom notes … everything. This is the most commonly skipped step during recovery, but it is perhaps the most important safeguard a defender can have in play in case something goes wrong.
9.7.1 Overview of the Decryption Process
The decryption process can be divided into an easy-to-follow series of subtasks, with each providing its own unique benefit and potential tripping point. Responders need to pay close attention at each phase to make sure that appropriate steps are being taken. A missed item on the response checklist can cause delays, issues with data integrity, and other much worse issues. Overall, the steps for decryption can be broken down like this:
Obtain a decryptor.
Test the decryptor.
Decrypt! (Use an isolated dirty network.)
Transfer data to the transition network.
Verify integrity.
Check for malware.
Transfer data to the production network.
In Section 9.2.1, the concept of separated networks was introduced as a key aspect of the recovery environment. The dirty, clean, and transition components described in that section are the primary network segments that will be used to facilitate decryption, file verification, and final transfer to the clean network. Responders need to keep the following principles in mind throughout the process:
The decryptor should never touch the clean network.
Data decrypted from the dirty network should not move directly to the clean network.
Data types extracted from the dirty network after decryption should not include executable applications unless new versions of the application cannot be installed.
Data from the transition network should not move to the clean network prior to completion of multiple passes of virus and malware scanning and verification.
No network communication should exist between any of the three network segments. All data should be transferred through the use of removable media such as external hard drives.
9.7.2 Types of Decryption Tools
Decryption tools can come from a variety of sources, including the adversary, antivirus or anti-malware vendors, other victims, or law enforcement. However, not all tools can be trusted. Here is a look at the different types that may be available.
9.7.2.1 Free Decryption Tools
A Google search for free ransomware decryption software will return hundreds of thousands of results, and a search for a free utility should be the first thing a responder does. Depending on the strain of ransomware involved, there may be a solution to the encryption problem that does not involve sending copious amounts of cryptocurrency to a cybercriminal gang. Nevertheless, responders need to be careful with free decryptors and treat them the same way they would treat other malicious software, regardless of their source.
A responder will probably find two main types of free decryption utilities:
Legitimate commercial decryptors: Multiple antivirus software vendors, and the occasional government agency, may create and distribute decryption software for specific strains of ransomware. Organizations like Emsisoft, McAfee, and others may offer these products free of charge. Most of these decryptors are only effective against older ransomware that has been removed from the playing field by law enforcement, or against previous versions of ransomware that contained a programmatic flaw that allowed for breaking their encryption. For modern ransomware, this option has become exceedingly rare.
Spam/malware/infected decryptors: For every legitimate decryption utility available for free, there are several others designed to take advantage of the confusion and stress of a ransomware incident. As an example, in Chapter 3, we described a poisoned decryptor for the STOP ransomware variant. Once executed, the “decryptor” would re-encrypt files on the system.
How does a responder tell the difference between a legitimate and a potentially malicious free decryptor? The source is the most dependable piece of information a responder can evaluate. Using a service like NoMoreRansom.org3 or other similar services can provide you with information about the exact strain of ransomware responsible for encryption, and identify whether a commercial utility exists that can decrypt it. Above all else, don’t just download and run any free decryptor that pops up on the Internet!
3. No More Ransom, www.nomoreransom.org/.
9.7.2.2 Adversary Decryption Tools
The other option for obtaining a decryptor is to purchase one from the adversary who encrypted the network in the first place. This type of decryptor will be specific to the exact variant and encryption used to lock files on the network, and ideally should decrypt all files on the network.
In any scenario, the decryptor you plan to use should be treated like malicious software. Maintain network separation, proper scanning and monitoring, and secure data backups when you apply any decryption tool, even if it comes from a trusted source.
9.7.3 Risks of Decryption Tools
If you do obtain a decryption tool from an adversary and intend to use it, keep in mind that there are no guarantees that it will work correctly. In fact, the tool may be deliberately designed not to work as advertised. You’ll need to take precautions to ensure that you don’t accidentally make a bad situation worse.
Here are some potential risks to consider when using an adversary’s decryption tool:
Secondary infection
Data corruption
Delays
9.7.3.1 Secondary Infection
In some cases, the decryptor that is meant to unlock files on your system might contain additional malicious software designed to further compromise your network or provide a remote access point for an adversary to sell off to another cybercriminal.
In an interesting twist, some cases involving poisoned decryptors suggest that the adversary who deployed the ransomware may not be the one who implanted malware in the decryptor. Ransomware-as-a-Service operators will often include these malicious additions without telling their affiliates, intending to further monetize the cyberattacks that affiliates carry out by offering up follow-on remote compromise victims to other groups.
9.7.3.2 Data Corruption
The utility needed to decrypt this data will directly alter the contents of files on the computers it runs on, and there is no guarantee of quality from an adversary when it comes to the software provided for this purpose. The adversary is also not obligated to provide a fully functional decryptor. Once you have paid, the adversary often could care less about how happy you are with the performance of the decryptor. If you lose data because of a faulty decryptor, the adversary is unlikely to care. This is another reason why maintaining backups of your encrypted data is essential.
9.7.3.3 Delays
The decryptor is unlikely to be a high-performance piece of software and may take a significant amount of time to complete its decryption cycle. This can lead to serious delays in recovery if a large database is set up for decryption first, and files should not be extracted from a computer while the decryptor is running. Instead, using the data backups, selected high-value data can be extracted in its encrypted format and decrypted first. Taking this approach can save valuable time in the recovery of primary systems, while leaving less important data for subsequent decryption after essential systems are brought online.
9.7.4 Test the Decryptor
Before using the decryptor on real data, responders should thoroughly test and analyze the software. This step is necessary to ensure that any potential adverse effects associated with the software can be identified and compensated for prior to making any changes to essential files within the infected network. Failure to complete this step can lead to severely adverse effects, including potential malware reinfection and data corruption.
Testing the decryptor involves two steps:
Check for malicious or unexpected behavior.
Test functionality in an isolated environment.
If the decryptor does not function as expected, responders can take steps to modify the decryptor, or simply change tactics. In some cases, a skilled programmer may be able to decompile and remove the malicious components of the software. A more likely outcome will be that you as the responder need to be aware of the behavior and compensate for it by blocking outbound traffic to a suspicious IP address or taking other steps to neutralize the malicious activity.
9.7.4.1 Check for Malicious or Unexpected Behavior
Any decryptor to be used on the network should be treated as an infected piece of software. This software usually requires the user to disable antivirus protection and run the utility with administrative privileges. As a result, the software, once executed, can perform almost any task imaginable, including re-encrypting the files that have already been impacted, installing additional malicious backdoors, and more. Decryptors, regardless of their source, should be tested in an isolated environment and verified before they come anywhere near the real encrypted shares on the network.
Software is available to analyze behavior and check for malicious activity. For example, Cuckoo4 is an open-source toolkit that can be used to safely execute an unknown piece of software and provide a behavioral report for analysis. Online services can also perform these tasks, although caution should be exercised when using a public analysis engine. Information about the software you execute may be made available to all users, which may lead to disclosure of your incident if the software contains specific information about your environment.
4. Cuckoo Sandbox, https://cuckoosandbox.org/.
A responder needs to look out for a few specific behaviors when a decryptor is running, and the best place to spot these types of activities is a malware “sandbox.” In essence, a sandbox is an isolated and closely monitored computer system that can be used to safely execute unknown software and provide a report of specific activity. In general, the following pieces of the decryptor’s operation, at a minimum, should be evaluated:
Does the decryptor make any external network connections during operation?
Does the decryptor install any files on the computer?
Does the decryptor attempt to encrypt files on the computer?
9.7.4.2 Test Functionality in an Isolated Environment
The decryptor has one job: to decrypt files. This functionality needs to be verified, albeit very carefully. The dirty network can be used for this purpose. Using a small subset of files, execute the decryptor on an isolated computer and verify that it does, in fact, restore the files to their original condition.
Move your subset of files into a directory structure that matches their original configuration, and include a ransom note from the same folder. The ransom note may be needed to decrypt the files. Some ransomware decryptors look for the ransom note as an indicator that the contents of a folder need to be decrypted, while other ransom notes contain information necessary to decrypt files. Make sure the test environment is as close to the original file structure as possible to ensure that results are accurate.
This test can also give you an indication of how fast the decryption may work. If the decryptor runs slowly on a small subset of files, makes the computer unresponsive, uses excessive system resources, or has any other performance issues, knowing that fact early in the process can help you maximize the efficiency of decryption.
9.7.5 Decrypt!
Stage the data to be decrypted on a host within the dirty network. This data can consist of complete computer systems or simply subsets of data that are deemed to be a priority for recovery efforts. Backed-up data should not be connected. The data to be decrypted should be a copy of the original.
Next, execute the decryptor and observe its activities. It should be obvious within a few seconds if the decryptor is functioning as intended. If files are not decrypting, stop the utility and verify that the environment is configured correctly and the proper decryptor for the specific target data is being used (if more than one decryptor has been provided). Significant time can be saved by troubleshooting early instead of waiting for a full decryption cycle to complete before identifying issues.
Decryption is not particularly difficult, but it can be time consuming. It is important that proper expectations are set with management and tech staff on the amount of time it will take to complete decryption.
Remember, while an adversary may provide you with the software to decrypt your files, they have likely not put much time into optimizing this software. Plan your decryption efforts around critical data first, then move on to less important items.
9.7.6 Verify Integrity
Make sure the files you’ve recovered are complete and accurate. In most cases, changes made to files during the encryption process cannot be fully identified before the files are decrypted. That means the adversary responsible for encrypting the files could have potentially altered the contents of impacted files or planted malicious software in the file structure prior to encryption.
If the original file listing from the impacted hosts is available, verify that filenames, sizes, and any other pieces of metadata that can be identified are accurate. If these data points are not available, you will need to open the files and inspect them. If they have decrypted properly, standard file viewers should open the file contents without issue. Test a random assortment of files and file types to verify, to the greatest extent possible, that they are usable.
Be aware that custom file types, large files, database files, and other items may not decrypt correctly. Some ransomware variants will add padding or other data to files during the encryption process that may cause issues with proper recovery after decryption. If files are encountered that do not properly decrypt, copy the encrypted versions from your data backup and attempt decryption again. If the files are still not usable, you may need to contact the vendor that created the software for assistance.
9.7.7 Check for Malware
First, transfer the decrypted data to the transition network. This task is essential to maintain the integrity of the clean network. For physical networks, this may involve copying the data to external media for transfer and scanning. For virtual networks, a responder can copy the data to a mounted drive, disconnect the drive from the dirty host, and reconnect the drive to the transition host as an additional disk. This also gives the responder the opportunity to select only the data that is necessary for reintroduction to the clean network. This can greatly speed up the recovery process by eliminating unnecessary file transfer and scanning time. If the data is not needed, leave it on the dirty system and move on.
Much like decryption software, any data that has been impacted by a ransomware attack should be treated as a potential point of reinfection. The risk of infection from non-executable programs is low, but significant enough that additional verification is needed. Connect the decrypted data to the transition network and scan it with multiple antivirus software applications. If available, scan the data with both signature- and behavior-based antivirus software. The transition network should also be monitored closely at this point to determine if any malicious activity has managed to escape the dirty network.
9.7.8 Transfer Data to the Production Network
Once the data has been scanned and tested, you can begin moving the data to your production network. This process should follow the steps for transferring data to the transition network outlined in Section 9.7.7. Once data has been returned, continue monitoring for any signs of malicious activity. Malware can be very good at avoiding detection when observation times are short.
9.8 It’s Not Over
Cyber extortion is a traumatic event. It takes time for individuals, and the victim’s organization as a whole, to process and fully recover from it. The mid- and long-term effects of cyber extortion can include litigation, regulatory investigations, data loss, consequences of data exposure, negative media attention, challenges in obtaining insurance coverage, and damaged relationships with customers, shareholders, staff, and more—not to mention the personal trauma for individuals involved.
When faced with a cyber extortion incident, most victims view restoring operations as their finish line. They put all of their time, energy, budget, and effort into that one goal, but fail to look beyond it. In reality, restoration of operations is a milestone (and yes, a big one!), but it is not the finish line.
Over the long term, maintaining an appropriate response to cyber extortion may require changes to budgeting, staffing, and resource allocation. The victim may need to invest in several types of ongoing activities:
Legal response: Lawsuits are becoming increasingly common following a cyber extortion crisis. They can include data breach lawsuits filed by affected subjects, derivative lawsuits filed by shareholders, conflicts with cyber insurers that end up going to court, and other types of litigation.
Regulatory investigations: Similarly, regulatory agencies around the globe are becoming more aware of cyber extortion risks and are increasingly empowered to investigate such attacks. Following an attack, regulators may require a full analysis and demand information about the root cause, the victim’s response, and any improvements that can or should be made. If gaps are identified, this can result in steep fines, depending on the industry and regulatory agency involved.
Public relations campaigns: Cyber extortion incidents can gravely damage a victim’s reputation, particularly when the adversary has a sophisticated relationship with the media and uses it as leverage. Long-term image repair campaigns and customer relationship efforts may be needed to restore goodwill and reverse any negative impacts on sales or revenue.
9.9 Adapt
In the best-case scenario, the victim will learn from a cyber extortion crisis and adapt to reduce its risk of attacks in the future. Once an organization has been hit with a cyber extortion attack, it will always be at an elevated risk of future attack, so it becomes even more important to grow and improve.
Key activities during this phase include the following:
Conduct a postmortem analysis. Take the time to analyze the cause of the cyber extortion crisis and your response. Identify areas of success and deficiencies, and develop a prioritized action plan for improvement.
Update documentation. Update the organization’s documentation to account for any changes made to the environment during the response. In addition, update its response processes to account for any lessons learned. Once the dust has started to settle, it’s wise to formally review all changes made to the environment and ensure that they are properly documented.
Revert changes. During the emergency response, major changes may have been made to the organization’s technical infrastructure. These can include architectural changes, new security controls, updated configurations, or even completely new technology environments. Unfortunately, when faced with the hectic pace and urgency of a crisis, many responders forget to document those changes—or simply don’t have time.
Improve the cybersecurity program. Ensure that key takeaways are used to improve the victim’s cybersecurity program, and thereby to reduce the risk of future cyber extortion crises. This may include implementation of stronger controls, such as multifactor authentication, proactive threat hunting, or other updates. See Chapter 10 for a detailed discussion of cyber extortion prevention.
Fine-tune your response. Review and update the organization’s response procedures following a cyber extortion attack, ensuring that any gaps or changes have been addressed.
Remember, every crisis is an opportunity. In the best-case scenarios, victims learn from the experience and become stronger.
9.10 Conclusion
Recovering from a major cybersecurity incident is a complex and time-consuming task, which generally takes place under enormous time pressure. While speed is necessary, responders must be methodical. Failure to follow a carefully thought-out plan to recover both data and systems may lead to a secondary or reintroduction of the cyber extortion attack. Changes to configurations, processes, or images made during recovery should be documented. Ensure that sufficient monitoring and logging are in place to give you good visibility as operations come back online.
Remember that recovery from an incident is not the end of the road. It’s an important milestone, but there is still a sobering element of truth to consider: Once your organization has been the target of a cyber extortion attack, it will likely be at a higher risk for additional attacks in the future. The changes made during recovery will strengthen your organization’s cybersecurity posture, but your cybersecurity team will need to remain vigilant and ready to respond in the event of a future attack.
Even after operations return to “normal,” the organization will continue to face fallout from the incident. Recovery is a marathon, not a sprint, and the organization should be prepared to budget the appropriate time, money, and personnel to ensure success.
9.11 Your Turn!
Every cyber extortion incident is unique. The response team’s options and successful recovery will vary depending on the victim organization’s industry, size, and location, as well as the details of the incident itself.
Based on what you learned in this chapter, let’s think through key elements of the short-term and long-term recovery.
Step 1: Build Your Victim
Choose one characteristic from each of the three columns to describe your victim’s organization:
Industry | Size | Location |
|---|---|---|
Hospital | Large | Global |
Financial institution | Midsized | United States |
Manufacturer | Small | European Union |
Law firm |
| Australia |
University |
| India |
Cloud service provider |
| Country/location of your choice |
Organization of your choice |
|
|
Step 2: Choose Your Incident Scenario
Select from one of the following incident scenarios:
A | Ransomware strikes! All of the victim’s files have been locked up, including central data repositories, servers, and workstations. |
B | A well-known cyber extortion gang claims to have stolen all of the victim’s most sensitive data and threatens to release it unless the victim pays a very large ransom demand. The gang posts the victim’s name on their dark web leaks site, along with samples of supposedly stolen data. |
C | Double extortion! Both A and B occur at the same time. |
D | The victim is hit with a denial-of-service attack on its Internet-facing infrastructure that slows its access and services to a crawl. The adversary threatens to continue and even escalate the attack unless a ransom is paid. |
Step 3: Discussion Time
Your victim organization must recover from their extortion event. Given what you know about the victim and the scenario, answer the following questions:
What are four types of activities commonly included in the cyber extortion recovery process?
Describe one reason why responders might want to back up critical configuration files and data before making changes in this situation.
How long should the victim monitor their environment to ensure that it is secure?
Describe two potential long-term effects of the incident, along with ways that the victim can address them.
Name one topic that you recommend the victim organization discuss during a postmortem analysis.