Ransomware Recovery: Don't Make Matters WorseCommon Mistakes Too Often Intensify Already Bad Situations
A recent incident involving a chronic care management company spotlights how paying a ransom to recover decryption keys from ransomware attackers can put sensitive data at additional risk.
Jupiter, Florida-based Health Management Concepts - which also is known as HMC Healthworks - learned on July 16 that data on a server used to share files with its clients had been infected by ransomware, according to a notification letter it sent to the New Hampshire state attorney general.
"When HMC learned about the incident, it took immediate steps to decrypt the files, provision a new server, begin an investigation and, through counsel, engage a leading forensic firm," the notification letter indicates. "HMC promptly obtained decryption keys from the attackers and decrypted the data without any impact on the services HMC provides."
On July 19, however, "HMC discovered that the attackers were inadvertently provided a file that contained personal information of [some] members, including Social Security numbers of four New Hampshire residents."
Attorney Aaron Lancaster of the law firm Baker Hostetler, who represented HMC in the matter, declined to comment on the circumstances of how a file containing personal information of some individuals was inadvertently released to attackers. He also declined to discuss how many individuals in other states were potentially impacted by the incident.
HMC did not immediately respond to ISMG's request for comment on the incident.
So what happened in this ransomware incident? In a blog, security firm Coveware surmises that the HMC file containing personal information appears to have been provided to the attackers in order for them to prove that decryption of HMC's other data would work.
"During a ransomware remediation, it is common for an attacker to demonstrate that decryption is possible," Coveware writes. "If proof is not offered, then it is standard to request proof of decryption. This is typically done by sending a small encrypted file to the attacker. The attacker then responds with a decrypted version. However, this small exchange can change the nature of the attack; now the attacker is in possession of company data."
In a statement provided to Information Security Media Group, Bill Siegel, CEO of Coveware, which was not involved in the HMC ransomware recovery effort, notes that mistakes like the ones apparently made in the HMC situation are common.
"We see them more often in situations where companies try to handle the ransom payment and decryptor tool recovery on their own, vs. where a professional incident response firm is involved," he notes. "There are dozens of tactical mistakes that companies make when making contact with an attacker holding their data for ransom. These mistakes decrease the likelihood of data recovery, and extend the duration of the incident."
The mistake made in HMC's case was avoidable, he contends.
"When a file is encrypted, you can't see what is in it, so there is always the risk that client data may be buried on a hidden tab somewhere. Our standard practice [if data is shared with ransomware attackers] is to find a small file of written content for the website that the company is confident is already public and contains no protected information," Siegel says.
Too many organizations also make the mistake of assuming that once the ransom is paid, the encrypted data will automatically be decrypted, he notes.
"In reality, the decryptor tools that the attackers provide after being paid are very difficult to use," he says. "There is a tremendous amount of nuance to using them properly. ... It is very common for the attackers to answer several follow-up questions on how the tool works. This is a business to the attackers, and if word gets out that their ransomware or decryptor tool does not work, people will stop paying."
Other security experts point out that ransomware attacks present many other challenges, including the dilemma of whether to pay the ransom. The FBI advises against paying ransoms under any circumstances.
"Trying to decide whether to pay ransom or not is never an easy decision - the best answer is 'no, never' but that's not always a decision you can make," says former healthcare CIO David Finn, executive vice president of the security consultancy CynergisTek.
"You will rarely negotiate from a position of strength with a hacker - or any criminal, for that matter. Having a well thought out plan would have helped, and certainly being able to restore the data yourself, without 'buying' decryption might have avoided the entire nasty event."
An organization that chooses to pay attackers to unlock data "should apply the decryption key itself with whatever instruction the criminals can provide - instead of sending a file to the ransomware perpetrators to decrypt as evidence the key works," suggests Keith Fricke, principal consultant at tw-Security.
"If possible, it is a good practice to have a third-party vendor pay for the decryption key on behalf of the [organization]," he adds. "First, it keeps the organization anonymous to the ransomware criminals. Second, it takes additional time to set up a digital currency account to pay the ransom if such an account is not already established. Some forensic vendors provide this service."
Alan Brill, senior managing director at Kroll Cyber Risk, stresses that there is no guarantee that criminals will deliver on any of their promises.
"There is no guarantee that even if you pay the ransom demanded that you will get a decryption key, or that whatever they send you will actually work," he says. "Also consider that some versions of ransomware actually aren't designed to encrypt files in a way that can be decrypted. Some encrypt them in a way that doesn't provide for them to be decrypted."
The encryption key may be generated randomly by the ransomware, "and the 'bad guys' might not actually be able to provide a working key," he cautions.
Brill notes that if an organization has cyber insurance that might cover a ransomware attack, "there may be a requirement that you notify your insurance carrier, either directly or through your insurance agent or broker, within a short time period, or otherwise coordinate your response with the insurer." Failing to do this can have an effect on coverage in some cases, he says.
"Remember, too, that insurers have pre-arrangements with the kind of forensic, legal and crisis communication support you might need. These companies have been pre-approved by the insurer. In a ransomware case, you don't have a lot of time to find and negotiate with vendors."
Blunders can also happen when trying to mitigate ransomware attacks without paying a ransom.
"Backup is the one thing that we rely on to bail us out of a ransomware attack," Finn notes. "It is rarely 100 percent right. We tend to take working, reliable backup for granted - until we actually need it. People shouldn't assume they have it and it works the way you think."
To illustrate the importance of regularly testing backup procedures, Finn recalls an incident in a previous job, when he asked a team to restore some specific files using backups. "There was no data on the backup except the headers," he says. "Needless to say, we changed not only our backup procedures but testing and we added staff to the backup team. And today there are much better options for backing up and much faster backup and restore functionality."
To prepare for any type of cyberattack, Fricke says, "having an incident playbook is important. Playbooks help guide response teams and make decisions under duress. Such a playbook could reduce the likelihood of costly mistakes if followed. The lack of playbook could potentially increase the opportunity for mistakes.
"The time to verify that backup jobs are executing without error is not during a ransomware incident. Periodically confirming backup jobs are completing successfully aids in relying on those backups if ransomware issues arise."