Name: Cloud Ransomware Tabletop: Unpacking an Attack from Detection to Recovery
Uploaded: 2025-08-21T17:30:41.568Z
Duration: 1 h 29 min 36 s
Description: Cloud Ransomware Tabletop: Unpacking an Attack from Detection to Recovery

Transcript for "Cloud Ransomware Tabletop: Unpacking an Attack from Detection to Recovery": Hello, everyone, and welcome. Welcome to this unique event, our cloud ransomware tabletop activity. Really excited about this, this bank, Philip. Yeah. Me too, Matt. So we wanted to do something a little bit different. So instead of walking you through slides filled with cloud transfer statistics, we do believe it's a little bit more useful to experience the story behind the numbers. Yeah. And then being able to do it through a live read through of a scripted scenario that, you know, mimic an actual attack, against the customer, I think, is gonna resonate really well. And, hopefully, our our, the folks watching this will find a lot of value in this. It's it's a cautionary tale of a retail organization, fictitious retail organization called Verizon Retail, and it really depicts what happens to an organization, a realistic depiction of what happens to an organization during a sophisticated cloud attack. Yeah. And as you sort of listen to the story unfold, we we do encourage you to pay close attention, not just to the decisions being made in the heat of the moment, but also more importantly maybe to the decisions that weren't made months or even years before the attack. So notice how quickly a technical problem cascades into a business, legal, and ultimately, financial catastrophe. Yeah. And then really listen into those key inflection points that the the moments where it starts to get worse for horizon. Right? And then and then the crisis really starts to deepen. When when those the gaps in their protecting strategy is exposed and the pain that the team has to go through in order to find that usable copy to recover from, and then the information that gets exposed along the way and and discovered, the fact that IT had no idea, that that information existed, and and and then ultimately, the no win situation that management found themselves in at the end when they realized they've run out of good options. Yeah. And then even though the story is sort of a composite of of of real world events and and challenges, we are like, it's it's it's closely matches reality. Right? So so you travel around a lot. You meet with a lot of customers. I travel around a lot, talk to a lot of customers. You know, it's a fictitious story, but it's it's very, very real. And unfortunately, it it is a real possibility that can happen to, to a lot of people out there. So with that, let's begin. Sure. I'm excited to get started. So we're gonna start with our first scene, detection. The tide is now 6AM eastern time on a Sunday morning. We are inside the Verizon Retail IT Operations Center, a room that's usually quiet at this hour. An IT Operations Analyst is starting his shift, going through a routine that's gonna become anything but. The first sign of trouble appears not as a single alert, but as porous and discordant data points on his monitoring dashboards. That's not right. It's not a DDoS attack. Our external traffic patterns are normal. It's not a bad deployment. We haven't pushed any new codes since Friday afternoon. So why is write latency on the primary EBS volumes through the roof while read input output is completely flat? It's like a single process is running wild across the entire fleet doing nothing but writing. Let me check the s three buckets that feed the analytics platform. Oh, god. Put object, put object, delete object versions. I'm seeing thousands of API calls per minute against our most critical buckets. The object names, they're all being rewritten. They have a new suffix, dot locked? This isn't a runaway script. This is hostile. This is an active attack. This is the on duty line. Tell me there's a good reason you're calling. There is. We are under active attack. I'm seeing what looks like mass encryption across our core s three buckets. I'm also getting high IO alerts from the primary RDS instance now too. The customer facing websites are throwing five zero three errors. This feels coordinated, and it's moving incredibly fast. Define coordinated. What are you seeing in CloudTrail? Is it one IAM role being used, multiple is the activity coming from a known IP range or something external? CloudTrail is flooded. It looks like thousands of unauthorized SSEC encryption calls originating from within our own VPC. They aren't trying to pull data out. They are encrypting everything in place. GuardDuty's lighting up with alerts for unusual activity from a single internal e c two instance. A QA server I've never even seen trigger an alert before. This is bad. They're inside. Alright. Star logged them to secure isolated account now before they can purge them. Then use the out of band management network. Get the CIO on the line and initiate a major incident management call for the entire crisis team. I'm on my way in. The time is now 06:30AM. A video conference is live with the CIO and the application support manager, both looking grim. Give me the situation report, and blast freeze is not an answer. I need application names, business units impacted, and a preliminary assessment of potential data loss. It's a sophisticated ransomware attack, and it appears to be centered on our US East 1 region. We've confirmed active encryption on the e c two instances hosting the web front end, the s three buckets that hold all our process data for BI analytics, metadata from store sensors and POS, as well as the primary RDS database that manages inventory and logistics. We've also found a ransom note in the root directory that does in servers. Let me be clear about what that means. If that RDS instance is compromised, the stores are operating completely blind. The handheld scanners in our warehouses that associates use for picking orders are effectively bricks. The system that optimizes truck routes for daily restocking is offline. The point of sale systems can't even validate gift card balances or process turn returns correctly. From in store staffing to deliveries and inventory intake, we have to assume every single digital service that touches a physical store is either down or about to go down. This isn't just a website outage. This is a direct, decapitating strike against our core retail operations. The East Coast stores are scheduled to open in less than ninety minutes. I'm activating the full incident response plan, get the entire crisis team assembled. I need the CISO and the general counsel on a call in the next fifteen minutes. We need to decide if we even open the stores. Megan, a word of caution. We can't just reboot the servers. This isn't a hardware failure or a simple outage. This is a hostile takeover of our environment. Every move we make has to be deliberate or we could risk accelerating the damage. So let's pause here and be clear about what just went down. Ransomware attack in the cloud doesn't just encrypt a few files off server. It really gets at the very fabric of an organization's critical applications, right, because we know that organizations are migrating critical workloads from the data center to the cloud and we just saw how the encryption of a single database can paralyze an entire organization's retail operation. And this is first lesson in this exercise that in a Cloud native world, there's no longer a distinction between operational recovery and cyber recovery. That these services that run the company from inventory to logistics to sales, they're so tightly woven together that an attack on one ends up being an attack on the entire organization. And the problem isn't just that these apps are down, the problem is that the business is down and that the applications and the databases and the cloud services support the business And, ultimately, this is the reality of Omblado and SaaS. Yeah. Absolutely. And as I've heard it on Omblado and I've seen it a lot, a lot of organizations struggle with getting, like, an up to date feel of their entire cloud, let alone if it's a multi cloud landscape, which makes it even more difficult to get context of what is really happening, during such an attack. Yeah. Alright. Let's move on to Steam two assessment. The time is 8AM eastern. The first stores on the East Coast are attempting to open their doors amidst chaos. The full crisis team, including the CISO, Charles, Caisson, and the line of business we did is now assembled on the emergency MIM call. The atmosphere to stick with tension as the team tries to understand the full scope of the attack. Our forensic analysis of the logs has given us a clear picture of the attack vector. The initial point of entry was a leaked AWS access key. We suspect a developer or a third party contractor accidentally leaked it in a shared Jupyter notebook stored in a misconfigured internal Wiki weeks ago. It was a low privilege key only allowing e c two describe instances, but that was enough for them to start their reconnaissance. They used a low privilege key to map our environment, and then what? How do they escalate privileges so fast? Our MFA policy should have stopped them from moving laterally. Our MFA is only enforced for human access to the management console. It doesn't apply to programmatic API calls made from within the VPC. The attackers use the key to find a single unpatched QA server. From there, they exploited a misconfigured IAM role that was attached to that instance. It was a legacy configuration from a project that was decommissioned two years ago. The role was never deleted. Technical debt. What did the role allow them to do? It had wild card permissions to read from a specific path in AWS secrets manager. Inside, they found credentials for our primary RDS database, but more importantly, they found a permanent access key for our primary retail ETL role. That role is effectively god mode for our core data infrastructure. Once they had that role, they deployed their scripts. They're using server side encryption with customer provided keys, SSEC. It's a nightmare scenario because it makes recovery from versions or replicas impossible without their encryption key. We're also seeing high volume egress traffic in the hours leading up to the encryption. They didn't just lock our data. They took a copy first. Hey. I just got off the phone with our regional managers over in the Northeast, part of our country of our business. Customers are banning full shopping carts at the register because of the manual checkout process. It's taking over twenty minutes per person. The media has picked it up. We have local news vans outside two of our flagship stores. Our store manager is asking if they can get rid, of of everybody and just close down. The danger to our band brand here is happening in real time. It's happening on live TV. Based on our hourly revenue rates, we're losing hundreds of thousands of dollars per hour. This is an absolute catastrophe. The time is now 11AM eastern. Situation continues to deteriorate. We have an update. Our external security consultant is now engaged. Based on the encryption methods and a specific ransom note, they believe with high confidence that this is the work of the CodeFinger group. And I can confirm that after consulting with the FBI, we have established contact with this group through the channels they provided. The demand is $4,000,000 payable in Bitcoin. The deadline is three days from now. We are not paying. This is what our disaster recovery plan is for. This is why we have backups. Aria, report on our recovery posture. The e c two instances are recoverable from AWS backup. What about the s three data? That's the core of the problem. While we do have backups for a portion of our s three data, for a critical share, we've been relying on versioning and cross region replication. As you might imagine, versioning is not a backup, and it specifically does not protect against this attack vector. Since the attacker used server side encryption to re encrypt every version of every object with their own key, The objects are there, but they're indecipherable to us. The replicas in the other region are just copies of the same useless encrypted objects. This is unacceptable. Who signed off on a policy that left our new source data so vulnerable? Well, it was a decision made during last year's capital allocation review to reduce cloud storage costs across the board. The risk was documented and formally accepted with the understanding that versioning would mitigate accidental deletion. No one anticipated an attack of this sophistication. My team filed seven tickets over the last year about inconsistent backup validation and coverage gaps in our cloud environment. They were all deprioritized in favor of new feature development. How much data are we talking about? How bad is the s three data loss? It's a severe loss. All operational data, POS, and sensor logs, and clean BI datasets for our entire fleet of stores opened in the last fiscal year. A full year of our company's growth has been effectively wiped out. It's almost like these stores have never been in operation. This moment is critical. The CIO's confidence was just chatted by a simple proof of facts. The recovery plan was based on flawed assumptions. Relying on operational features like ST versioning as a substitute for a true air gap backup strategy is a very common but dangerous mistake. The attacker understood this weakness better than the company did and exploited it perfectly. The problem we're seeing is not just a technical failure, but a failure of policy and investment. Decisions made months ago to reduce cloud storage costs to deprioritize security tickets have now created a catastrophic and recoverable data loss event. This is the consequence of not having a complete feasibility in what data exists where, what is protected, and what is truly at risk. It's the moment a company realizes its safety net has a giant hole in it. Yeah. It's it's a great observation. I think, I think what we see typically is that organizations tend to conflate, they tend to conflate continuity with resiliency. Right? And they apply a continuity problem a continuity solution to a resiliency problem. And that's a this is a perfect example. You know, relying on versioning is a continuity strategy. Relying on replication of continuity strategy, it's not a resiliency strategy. You need that true air gapped, you know, third copy. Yeah. Absolutely. And and and speaking about assumptions, like, if you look at identity, for example, especially in the cloud, it sort of still remains the the main attack factor for those for those services. And even if you're, like, looking at things like MFA, you can still buy valid credentials with active sessions token tokens on the dark web. So so we need to, like, look at this from a much more holistic point of view as well, I think. Yeah. Yep. Alright. Let's hop into scene three, the failed recovery attempt. The time is 9PM on Sunday evening. The teams in the IT operations center have been working for fifteen hours straight. The initial shock of the attack has worn off, replaced by a grim exhaustion. The mood in the room is heavy with the weight of finding a path to recovery as every attempt so far has ended in failure. I've mounted the tenth EBS snapshot from our backup vaults. I'm running a deep forensic scan on it now, but it takes nearly an hour to scan each terabyte. At this rate, it will take us days just to validate the backups for a single critical application. We're looking for a clean needle in a mountain of infected haystacks. I know it's slow, but we have to be certain. They were in our environment for more than a month. They knew our backup retention policies better than we did. They waited until they knew their malware was replicated across all of our recent restore points before they launched the main attack. We're not just fighting the encryption, we're fighting their thirty days of reconnaissance here. This is a completely manual hit or miss process. Our backup tools have served us well for operational recoveries, but I'm only realizing now that they're greatly lacking in dealing with such sophisticated attacks. They were never designed to withstand a direct malicious assault by an attacker with administrative credentials, and they can't tell us which backups are safe. Wait. I think I have something. An e c two snapshot from two weeks ago just before we believe the main malware was planted. The initial scans, they look clean. The root kit signatures aren't there. It's a risk. It could contain a time delayed payload that our scanners are missing, but it's the best lead we've had all day. And it's the only shot we have. Let's do it. Kick off the restoration process into a new completely isolated recovery environment. What's the ETA? If we push it and everything goes right, we can have a test environment of our core application up by midnight. The time is now 1AM on Monday morning. For the first time in nearly twenty four hours, there's a flicker of hope in our room. On a monitor, the core application is initializing in a clean environment. Wait a second. We're online. The app server's up. The database connected. We're running the first test transaction now. Oh my god. It worked. Well, for about five seconds, it worked. We were cheering. Wait. Wait. No. The dashboard just died. CPU utilization is pegged at a 100%, and the file system, I can see it happening. The files are being reencrypted right now. How is that possible? We scanned that snapshot. It was clean. The malware must have been dormant. It was waiting for a specific event, a connection to the database, a specific API call. It was a time bomb and we just triggered it. Shut it all down. Terminate the instances now. Time is now 2AM. Brief moment of hope has been utterly extinguished. On the video conference, the faces of the CFO and the general counsel appear and they look grim. The CIO has decided to deliver the bad news. I'll get straight to the point. The financial consequences are severe. Our financial modeling for Sunday showed a loss of over $1,000,000 Our stock is projected to open at least 8% down, which represents close to half a billion dollars in market capitalization. Are you now telling us that our only viable backup has just failed and we're essentially back to square one? Time is of the essence here. It was a significant setback. The attack is more complex than we anticipated. The team is now working to analyze much older restore points. I appreciate that we're all understandably, Tires, that your team is working incredibly hard. While I value your technical explanation, my primary concern is that the company seems to be in financial free fall, and that's worsening every hour. To put it bluntly, what's the plan here? Well, while you formulate one, I must inform you that we have received another email from the attackers. They have seen our failed recovery attempt. They are raising their ransom to $6,000,000. They feel they have the upper hand, and legally, they might. The story is now being picked up by national news outlets. We're losing control of the narrative. And what we just witnessed here is the second major failure of of a traditional recovery approach when you have a modern scenario. A traditional recovery approach when you have a modern scenario. Problem is that conventional backup systems, they were built to protect against operational, operational errors whether that's fat finger events, misconfigurations or hardware failures. They were not designed for a malicious adversary who's been in the network. And these systems have no way of knowing whether the data they're storing is clean or if it contains malware that could just go and re infect the environment. Recovery process ends up becoming this game of pick and choose, trying to find the right backup and really it being an experimental effort which is wasting time and money for these organizations. It ends up being a gamble that you could reinfect your whole environment again and of wasting precious hours and destroy what little morale the team has left in these scenarios. If you can't be certain that your backups are free of malware, then you don't have a recovery plan. You ultimately have a lottery ticket. Yeah. Absolutely. And this is often not well understood. Right? So people think I have a backup and even if it's, like, a valid backup in in the eyes of the IT team, like pushing that big red recovery button, if you will, you need to sort of have assurances that you're not going to reinfect your network and that's going to extend that recovery time so broadly that it's that's actually what's going to kill most businesses. It's not like having a backup or not, but having assurance that you have a clean backup and that you're not gonna re infect your network. Yeah. It's really critical. I I, I think I think at the end of the day, having forensic information about your backup and understanding exactly where your clean recovery points are and and knowing with certainty when you do go to recover in production that you're recovering a clean copy is what's gonna really reduce, you know, your ability, it's gonna, you know, increase your ability to get back, as quickly as you possibly can. So that's ultimately what we're trying to ensure is trying to ensure that our customers have that that easy button for recovery. Absolutely. With that, let's move on to scene four, sensitive data. It is now Tuesday afternoon, more than forty eight hours since the attack began. The company's stock has plummeted by more than 10%. The recovery efforts have been up brutal, immortalizing slop. The team now knows the attackers were inside the systems for at least thirty six days. Cyber incident response manager has called a critical meeting with the IT and legal teams to address the scariest question of all, what exactly did the attackers have? We need to get to ground truth on our data exposure. The integrity of our s three inventory is now in question, especially considering all the lost data. The legal team needs an accurate inventory of the compromised s three data, specifically what type of data was in those buckets. We must know if we are dealing with a data breach. I've been running a deep scan of our s three environment trying to reconcile our inventory with reality. I'm running a regex search for PII patterns across bucket manifests and object names. The problem is many of these buckets don't have data classification tags, so I'm flying blind. What do you see? I'm seeing files named q three rewards members full dump dot c s v and loyalty test data prod sample dot json. The file names themselves are screaming PII. And worse, our s three inventory is a mess. It shows 920 s three buckets in our production environment. My deep scan has found 965. There are 45 buckets that are completely untracked, unmonitored, and unbacked up. The group reconvinced late Tuesday night. The mood is great. The untracked buckets. They appear to have been spun up for the customer loyalty program that was in development last quarter. The customer loyalty program. Lauren, you managed that project. What was the data schema for those development buckets? It it was the development environment. It shouldn't have been production data. But to properly test the new predictive models, the development team may have well, they may have pulled a sample from the production customer database. I can confirm they did. I've decrypted a single file from the proof of life sample the attacker sent us. It's a CSV file from one of those untracked buckets. It it contains over 1,000,000 records with full names, email addresses, mailing addresses, and birth dates. This is firstly identifiable information. This is now officially a data breach. Let me make this perfectly clear for everyone on this call. The moment PII was confirmed, we moved from a business continuity crisis to a major regulatory and legal event. We likely have seventy two hours to notify California attorney general under CCPA. We have other notification deadlines in every other state and country in which we operate. We need to retain outside counsel specializing in breach notification tonight. We need to establish a budget for credit monitoring in for every customer in that database. The cost of this incident just grew by an order of magnitude, and that's before the class action lawsuits begin. Does everyone understand the gravity of the situation? Yes. We understand. This is perhaps the most dangerous blind spot for a Hmong company, not knowing what data you have or where you have it. The problem of shadow IT and dark data is rampant, especially in the cloud, where developers can easily spin up new resources without proper oversight, essentially just a credit card swipe away. So without an automated way to continuously scan for discovery and classify sensitive data across the entire estate, which could be single cloud, multi cloud, could even be SaaS and still on premises as well, the company was completely blind to its own risk. That ransomware attack didn't really create this data governance problem. Right? It it simply exposed it in the most brutal way imaginable. The discovery of a massive PII breach elevates the incident from a technical and financial crisis into an ex sense existential legal and regulatory catastrophe, one that could haunt the company for many years to come. Yeah. I think that speaks, a lot to the the long tail costs of an attack, right? And really understanding that it's not just about the short term cost of being down that there are costs that extend well beyond that months or years beyond it. And I think the problem is that sensitive data governance in general in the past has been treated as a people in process problem. We really need to apply technology to the problem, right? And ultimately, using the technology to your advantage to scan what's there, and to understand where people might be putting sensitive data is gonna be really critical to reducing risk prior to being impacted. Yeah. Absolutely. Even after it gets exfiltrated, there's still a lot of benefit to be had in understanding, like, what data did you have and what was sensitive and what was customer information versus nonconsular information. If you have to report to the regulator and if that time window to report to the regulator is is sort of it seems to be shrinking every year, then having that information at your side is is gonna be really, really helpful in in these types of scenarios as well. Yeah. Not only the time to report, but also the costs of not reporting in time, are a huge organization. Alright. So let's move on to scene five, the decision point. Time is 9AM on Wednesday morning. It has been nearly seventy two hours since the attack began and only 45% of critical systems have been restored. Company's leadership, including the CEO, is assembled for a final agonizing decision, and the air is thick with exhaustion and defeat. A full clean rebuild of our environment from the ground up will take at least three weeks. Given the sophistication of the malware we found in our backups, that is our most realistic estimate. Our direct revenue loss currently stands at $3,400,000. Our projections show that we'll continue to lose nearly a million dollars for every additional day of significant outage. We're hemorrhaging money here by the day. I must advise in the strongest possible terms against paying these criminals as rewarding their actions and funding their next attack on another company. We get a decryption key that might not even work for data that we would have to scrub and validate for weeks anyway. It does not get us any of our lost data back, and it absolutely does not remove the attackers from our environment. On top of everything, it paints a giant target on our back for every other ransomware group on the planet. We have to rebuild. It's the only way to be sure we're clean. Rebuilding is a fantasy of control that we can no longer afford. Your clean rebuild will take a month. In a month, there won't be a company left to secure it. We'll have lost massive share of our sales, our brand reputation will be in tatters, and our stock will be worthless. Principles are important, but they don't keep the light on. From a legal standpoint, our situation has fundamentally changed. We are no longer just managing an outage. We are mitigating liability. The single biggest quantifiable risk we face here is the public leak of that PII data. Aubrey is correct. Paying the ransom doesn't guarantee the attackers won't leak it. However, refusing to pay it makes it a certainty. They will leak it to maximize our pain and make an example of us. Therefore, paying a ransom is our only leverage, however small, to prevent that outcome. More importantly, we must be able to demonstrate to the courts and regulators that we took every possible step, however distasteful, to protect our customers' data after the breach was discovered. The general counsel was right. From a purely financial perspective, paying the $6,000,000, painful as it is, is the only move we've got left. It's an ugly but necessary transaction to stop the billion dollar bleeding. It's the only business decision on the table, as far as I can say. They were right. The security team, the operations now analysts, they told us our backup strategy for the cloud was flawed. They told us we needed better visibility into our data. We deprioritized the projects and the funding to meet deadlines for new features. We made this choice months ago. Not in this room, not today. Now we're just paying the bill. I agree with Caleb and Martin. We have to pay. Then it's decided. Authorize the payment, and the first nonnegotiable line item in next year's budget will be a complete overhaul of our data security and cyber security to be led by Megan's team. This will not happen again. For the record, I am formally objecting to the payment, but I have advised on the legal rationale for doing so. So I really appreciate everybody joining for this tabletop activity. I know it was not comfortable at times to be dragged through, what an organization goes through, during an attack like this. I just think at the end of the day, what we want to demonstrate to you is pain of unpreparedness. This company was not prepared, and in the end, their decision to pay the ransom, it wasn't really a choice. They had no other option. Yeah. I think, especially when you think about some of the regulatory pressure as well around paying a ransom or not paying a ransom, the theory is all nice and well. But if you're really confronted with this decision and it's costing you millions and millions of dollars and your company is sort of on the verge of bankruptcy, then you sometimes have to do the only thing that you can still do, right? So I think if you sort of look at what happened, it all starts with visibility. And I think that's usually the case when we talk to customers as well is if you ask the simple question, do you know what data do you have, who has access to it, where your data is located, the answer is usually kind of but not much delayed. And that then falls with an assumption of sort of, you know, thinking you have adequate protection, for for the data they know about at least. But some of the data they don't know about is definitely not going to be as secure as they would expect. And it's those gaps in your visibility that leave you open to attack, right? So that's the attack factor leveraged in this scenario. It sort of exposed that holding the data protection strategy led to unrecoverable data loss from from the very start. Yeah. And I think it speaks to the fact that the TTP is a changing in the cloud. Right, Philip? I mean, it's, in the past, it was let's get access on a unauthorized access to a cloud account. Maybe we'll spin up some authorized infrastructure to do things like Bitcoin mining or something like that, or maybe we'll launch a mass deletion or an exfiltration attack. I mean, this is encryption of customers' data using their own key. Right? So we're starting to see an evolution of the TTPs within the cloud, and and it's, it's really, even more, of a, of a reason why organization need to have those clean backups. And and you mentioned visibility. Ultimately, their tooling had no way to identify which of those backups were clean, right, and which of them were infected, with malware. And it turned, again, their recovery attempts into, like, guessing. They they they it ended up extending their RTOs. They ended up having a failed recovery. They just couldn't find that that clean restore point that they could trust. Yeah. Yeah. Absolutely. And then next to that, sort of it's it's the failure to understand what is the the risk, especially when it comes to data risk is very hard to really understand it as you mentioned. And also, again, like, we are not very used to hearing about cloud based ransomware. Most of the ransomware stories that we hear are still, like, people encrypting block storage and file storage from a Right. Perspective maybe. But but what we've seen is that it it jumps from the theoretical world into into the re into the real world, and and now we do have to account for for some of these problems. And as sort of pointed out before, especially in the cloud, everything is interconnected, everything is sort of an API call away, if you will. So you sort of have to understand how these things are connected together and what exposures that sort of ultimately leads to. So again, like there was a lot of compounding problems here in this scenario. Company was completely backed into a corner, ultimately another lot of opportunity except to pay, you know, millions of dollars in the ransom just for the for the mere chance to survive. Right. Right. And, you know, as I brought up earlier, I know that this was not an easy exercise for folks to go through. Also wasn't an easy exercise for our performers to bring these characters to life. So and they are not professional. So I do wanna thank them for their time and and and energy and to bring this this tabletop to life. Ultimately, there was no easy answer for this for this organization. Right? Yeah. It it it really drives home the reality of those attacks. Right? So in in reality, when they're confronted with this, there's not gonna be an easy answer. So so really what we can do is we wanna leave you with with this question. Like, did any part of the story we just shared feel feel familiar? Like, do the the the charges faced by by the team at Horizon Retail resonate with the concerns you might have about your your own cloud environment? And if the answer is no, you need to think about, about that in in in a more realistic manner. It's Yeah. For sure. I mean and if you have any concern about gaps in your data protection strategy in the cloud and, again, like, I I think one of the biggest misnomers is that organizations tend to think because my data's in the cloud, it's protected. I mean, there is there there is a shared recovery. I mean, there's a shared responsibility, paradigm when you when you put your data in the cloud. The data is still your responsibility. So, ultimately, if you have any gaps about data protection in general, you know, the lack of visibility that caused this this organization to really, have to, you know, have to put up that kind of that kind of money to get back to business, what a risk of of exposing sensitive data, you you know, do you need to mitigate these these these issues as soon as possible? You don't wanna end up in the same, impossible position that Verizon retailing up. Yeah. Absolutely. I think it's it's really also about thinking through this balance of of of cyber investments. Like what we see is the onus is still a lot on the preventative measures, right? We're trying to keep bad guys out. We're just like building ticker walls and making sure that we can keep the people out. We don't expect to go after our environment. But in reality, what we're seeing is that you sort of have to assume breach. If they really want to target you, they will figure out a way to get into your network and encrypt, exfiltrate your data or maybe even knock your company offline for other reasons. So you really have to pass prevention with recovery and that's going to lead to a cyber resilience strategy that you sort of can count on. So if you think about modern solutions like those from Rubik, they are designed specifically to address these challenges, right? It's a good solid combination of preventative measures, but definitely also the ability for you to bounce back quickly and maybe even bounce back in a better way than you were before, giving you that ultimate preparedness for the worst case scenario. So the idea is really, you know, you have to make the choice ultimately to sort of recover your data, protect your customers, and and and secure your business no matter what. Yeah. And and really combining left of boom capabilities around understanding what type of data you have in the environment so that you can reduce your risk surface area by limiting access to that that information so that when the attackers do gain access to credentials, they don't have the keys to ping. Right? And then you combine that with write a boom capabilities, the recovery capabilities, the ability to understand what happened, what type of sensitive data was caught up in this in the attack, and and, ultimately, how can I find that that safe copy to recover? These are all questions that are gonna get asked regardless of where the data is born. Whether the data is born in the data center or born in the cloud, it doesn't matter. So if if you wanna learn more about how you can avoid this outcome and and not be the next Verizon retail, we encourage you to visit us at rubric.com. If you're an existing customer looking to expand your cyber resilience in the cloud, first of all, thank you for being a customer. Second of all, please reach out to your Rubik representative. They'd be happy to help. And on behalf of my friend Philip and myself, thank you all for your time today and attention. Glad to hear you very much.