CypherCon 2024

Immutable Data, Not Immutable Servers

Ryan Kane & Rushank Shetty

Abstract:

As organizations are becoming more concerned about being hit with ransomware, security teams and vendors are investigating more secure methods of preventing the destruction of backups. The concerning thing is that these implementations for “immutable backups” are not always as secure as they’re purported to be.

As red teamers and pen testers, we try to perform the same actions that real attackers might pull off. In the case of deploying ransomware in an organization, we can’t perform that activity during an engagement (like, c’mon, we want to keep our jobs). Instead, we must depend on protecting data backups and trust that it can be done effectively.

Smart vendors and organizations that do put an emphasis on protecting data should include WORM (Write Once, Read Many) or immutable backups and storage. For these types of backups there is often a retention period set, where once the backup is created it cannot be modified until the retention period has elapsed. This may be implemented in different ways (in different vendor products), but the end-result should be data that cannot be modified for a pre-configured amount of time. This is useful in the event of a ransomware attack or other catastrophic outage (i.e., data center gets hit by an asteroid). Since this data is immutable (and SHOULD be stored in a different location from the data of which it is a backup), it should be unaffected by the emergency and can be used for restoration of data. The entire point being for an organization to secure a backup that cannot be deleted with the rest of their data in the event of an attack.

At our organization, instead of performing a simulated ransomware attack we were tasked with ensuring our immutable backup data was protected. This included testing that it was, in fact, immutable. We decided that trying to break the immutability of the data itself was likely to prove futile. Seeing as how that’s the entire point of these products and what the vendors would spend all their focus on getting right in their various implementations, targeting something else made more sense.

Instead, we attempted to attack the infrastructure hosting the backup data, since they’re just servers at the end of the day (albeit servers built for a unique purpose). This strategy proved much more fruitful. Why attack the untouchable data when you can just attack the server that it’s hosted on? In this talk, we will discuss our processes, failures, and ultimate successes from tests of immutable backups in three vendor solutions.

Ryan Kane & Rushank Shetty

Just a Turtle

Ryan Kane has been a pen tester/red teamer for 10+ years (almost 9 of them at Northwestern Mutual), after having begun his career as a software developer. He has helped out at CypherCon’s Lock Picking Village since the first one at the Pfister/Safehouse.

 

Rushank Shetty doesn’t know anything. He’s just a turtle!