To Pay or Not to Pay — That is the Ransomware Question
The words, “Ransomware Attack” have become a regular occurrence in headlines across many fields such as Health Care, Government, Police Agencies, big techs, and even the smaller folks. It has become one of the most active and profound threats that an organization can face today:
January 2021 recorded a total of 19 attacks. Amongst these attacks:
- Apex Laboratory which had to disclose after stolen data was leaked online
- Hackney Council in London were subjected to a double extortion style attack on significant amount of PII(where you pay once to decrypt your encrypted data, and another payment to ensure the data isn’t published online)
- SEPA had databases, contracts and strategy documents stolen and published online when the organization refused to pay the ransom
- Dairy Farm were ransomed for $30 million, and continued to have threat actors active within their network after the attack
February 2021 recorded 23 attacks, which included two major utility companies, the Ministry of Finance and Ecuador’s largest bank — KIA continues to dispute the attack.
March 2021 recorded 25 attacks; Acer received the largest ransom demand in history at $50 million; Sierra Wireless and Molson Coors also fell victim of a ransom attack.
April 2021 was active with a concerning 31 ransomware attacks; Home hardware fell victim to Darkside, NBA was targeted by Babuk, and REvil demanded $25 million from French pharma, Pierre Fabre.
Are Playbooks too basic?
Many of these companies have a ransomware playbook that they have either created, or adopted via some standard, and these playbooks will address the basic requirements:
- Remediate (Contain, Eradicate, and Recover)
Playbooks can be as detailed as the teams want them to be- they can even have different playbooks depending on the TYPE of ransomware/malware (i.e.: manual vs automated propagation, single-host vs domain controllers infections, etc.). But the above listed addresses the main headers.
These playbooks address the functionality of the Incident Response team, their accountability and responsibility, and can even tag other teams such as Legal, Policy, Governance, other technical and non-technical support bodies. But there are some things that some of these playbooks fail to address.
Let’s first take a look at the risks a company may face during a ransomware attack, prior to the threat actor sending their demands.
Risk of immediate containment before scope and identification
- This could tip off the threat actors that you know they’re in your systems, and might know where;
- Threat actors may attack other pieces of the environment/infrastructure;
- Threat actors may increase their ransom demands;
- You’ll essentially be playing whack-a-mole as threat actors may continue to pop up in various areas of your network.
Risk of scope and identification prior to the containment
- Threat actors are still roaming your network;
- The team spends more time uncovering something that they may never find, aka: rabbit holes.
Ransom is Demanded- What now?
You’re either aware of the attack, or not, but you’ve just received an email from a threat actor saying that they’ve successfully encrypted your data, and are demanding a payment to be made in exchange for a decryption key; there’s also the chance they have also exfiltrated the data and are asking for a second payment for the insurance of the data not being published, a term called “public shaming”.
A few action items come to mind as soon as this type of email comes in (in no particular order):
- Notify the Team Lead and CIRT Manager
- Contact Legal/Policy
- Inform IT/Network/BU owners so that they are ready to engage the Data Recovery plan and are aware of the situation; do not let them touch the systems (see risks above)
- Update the executives/C-Suite of the situation and open a technical bridge for communication between teams
- Try to verify the data presented by the threat actors
- Engage your Cyber Threat Intel team for intelligence and dark web monitoring, as well as published data
- Find answers regarding trusted backup availability
- Contact your Insurer for Ransomware if you have purchased a policy
- Bring in your ransomware expert and negotiator
Negotiation is Expected
Yes — You are allowed to negotiate the terms and payments of the ransom demand, in fact, it is expected. It’s important to know who your ransomware expert is, who will be in contact with the threat actor, and who contacts your ransomware insurer.
The decision to pay or not pay each come with their own set of risks
Risk of paying the ransom
- After paying, there is a chance the data may not be truly wiped and/or data will still be posted online (that makes for bad business, but its still a risk);
- Down the line, the company may become a larger target by same/other group since the company is now know to pay out;
- The decryption key might not work — it is important to exercise “proof of life”. Proof of life means sending the threat actor an encrypted file, having them decrypt it and send it back to you; proving they have the capabilities of decrypting your data. Saves you from paying for a decryption key that doesn’t work;
- Inserting an unverified decryptor into a non-isolated environment could introduce more malware;
- Advanced custom solutions might be required to decrypt the data once the key is received;
- You might receive the correct key, but the decryption utility might not be compatible on your systems;
- The decryption key might no longer work on your files due to file corruption;
- The company faces a social dilemma where they are viewed to be funding the cyber crime economy.
Another risk is that paying for the ransom sets a precedent that now this company will pay, and that notion will be passed on to consumers — these ransom demands can sit in the millions, which is money that could have been used to upgrade and harden the very systems that were responsible for the breach. Consumers and clients will ask the question, “Why wasn’t it invested into the infrastructure of their systems to being with?”
Risk of not paying the ransom
- The data being held hostage will remain encrypted on the systems, and companies will be forced to recover and possibly rebuild (see Baltimore story);
- The data could also be published and thus publicly shame and cause some reputable damage to the company;
- The stolen credentials will be shared/sold to other groups.
It’s also important to understand your company’s threshold in this situation. There are certain situations where not paying, and just simply rebuilding/recovering the data is better than paying. However, the TYPE of data might have a company paying for the sole purpose of it not being released to the public.
Deeper Questions to Ask Your Teams
Now that you are aware of the risks of paying or not paying, and some additional action items that may not be laid out in your company’s ransomware playbook, here are some additional questions to ask:
- Who response to the threat actor end-to-end? Do you have a designated correspondent?
- Who contact the breach response vendor/insurer, and when/how do you initialize communication?
- Are there written policies that currently state either or not your company negotiates a ransom?
- If given the chance, who deletes the data after paying the ransom? (Some threat actors will do it themselves and send a screenshot, and other will give a link to allow whomever to delete it.)
Ransomware Attack — What does that mean to you now?