The majority of ransomware victims continue to be stymied in their efforts to recover by immature backup software and strategies. 

That’s according to the incident response team at KPMG, which says that in “most” ransomware incidents it responds to, “backups were either encrypted by attackers, deleted, or entangled in complications involving third-party IT services, leaving organizations with no means of recovery.”

“Some organizations had offline backups but were unable to access them due to lost passwords, while others mistakenly assumed that their backups were intact—only to realize too late that they were not properly  maintained or tested,” the multinational consultancy’s IR team reported.

Tell us something new?

That will not be news to most people working in the information security space, but the level of complacency surrounding backups and the ability to back up from them, continues to plague many organisations. 

This is, arguably, in large part in many companies, due to backups being part of a disaster recovery (DR) or backup function that was historically primed to help restore systems after a natural disaster, not one in which threat actors have aggressively gone after domain-joined backups. 

“You don’t rise to the occasion in incident response; you fall to the level of your preparation” as one expert, Bill Siegel of Coveware earlier noted. 

He told The Stack last year that in many organisations the first encounter backup managers might have with security teams is when the latter comes asking for restoration after an incident. Bringing backup managers in early into tabletop exercises and more regular engagements with cybersecurity leaders is critical to improving incident response, he said.

(Veeam’s 2024 ransomware report showed that backup repositories “are targeted in 96% of attacks and successfully compromised in 76% of cases.”

The comments came in an annual review of KPMG’s IR engagements.

It features case studies that are a sharp reminder that “cyber hygiene” remains a major issue; one incident saw a attackers exploit an externally facing remote management tool on which an admin account did not have MFA set up; another saw a development environment breached that was “not secured with the same controls as the production environment” – it lacked EDR whilst the SIEM only monitored production systems.

The link has been copied!