Name: Full Access: Identity Recovery Tabletop
Uploaded: 2026-10-28T11:16:19.254Z
Duration: 1 h 4 s
Description: Full Access: Identity Recovery Tabletop

Transcript for "Full Access: Identity Recovery Tabletop": Hello, everyone. I am Mark Grant, from Rubrik. I work in the Rubrik x team in EMEA, and, I act as a director. I'm responsible for our identity and artificial intelligence portfolio. Hi, everyone. My name is Ant Perry. I'm one of the technical leads, within Rx working alongside Mark. My core focus is, our platform and our integration with, some of the identity products that you may have in your environment. Thanks, Anne. So, look, I wanna welcome everyone. Right? Thank you so much for taking the time and joining this session. We we we... We've been thinking about this long and hard, and we're gonna try something very different. Okay? So instead of me and Anne walking you through slides, endless slides maybe even of breach statistics, we actually want you to really experience a real world attack. Absolutely, Mark. So what you're about to watch, is a read through of a of a scripted attack. It's played by colleagues from within our own Rubik team. To be clear, it is fictional. But every step reflects, certainly what from Mark and I have seen over the last two years or so is is how identity attacks do unfold. So it's a practical exercise. It's not a test. So it's part of these, dialogue that you will see is there's no real wrong answers. Yeah. And the company in question are basically called ADG. Right? They're a 6,400,000,000 aerospace and defense manufacturer. They've got 20,000 employees. They're based in London. And effectively, they hold classified contracts with the US Department of Defense and also the UK Ministry of Defense. So if you think about that, you know, regulations and compliance really matter a lot for those guys. Yeah. And that's that's quite a key point here is is that, I mean, like any organization, they are investing heavily in their cybersecurity tooling. But, given the size and scale they operate at, their their identity ecosystem setup is split. So, the the AD that they operate is not just, you know, in the in the EMEA region where, obviously, London's part of. It's also, founded and operational and running in The US as well as other regions, across the world that they need to to service as part of the industry that they operate in. EnterID is also a key and critical part about identity fabric. And as many organizations, this end is also very intrinsically linked with Microsoft three six five itself. From an identity standpoint, yeah, they, you know, they're utilizing tooling such as push based MFA. And the the triage, the security operation side of things is one of the things that is important to consider here. That investment in security tooling is one thing, but there's the people to operate it, is another. So they have a mixture of both insourcing, that security operations as well as using a... An outsourced kind of level one, if you'd like, triage capability. Further to what Mark was saying, around that adherence to, kind of regulatory and, standards and and being compliant, a lot of their investment in this tooling is is absolutely gauged towards meeting those frameworks that they are contractually required to follow. So that's that's really critical. That's something that a business absolutely needs to do. The fact that that's the principle here is that they can't just keep going, with regards to the the expense that it would then incur if they wanted to really build this aspirational kind of strong cybersecurity model behind them. So it's very much about being compliant and meeting those standards, and this then really means that maturity is not necessarily the same thing. But many organizations, ADG has a gap, between the two, and that gap also then comes into how they operate their identity fabric. So there's multiple teams as it relates to security operations, but we also see is that there's one team that's responsible for the, the on prem identity side of things, for one of a better way of putting it, as it relates to AD. But the cloud team actually then has a responsibility for Entra. And, again, as we see as we go through this, there's no tested plan of what that recovery looks like across both of those environments. Thanks, Sam. So look. We're gonna join the story part way through, and I think it's important to kind of understand what happened before. So effectively, a hobbyist cat forum was hacked. A payroll specialist called Sally Jones at ADG had used her work password there. Now the attacker had basically matched it to her LinkedIn profile. She'd seen that she'd actually worked for a defense manufacturer, and then obviously gone into the dark web, Bryte, and then brought that for £500. So for effectively for the attacker, it was game on. They had access. She had the information. They've done their intelligence, and they're ready to come and attack the environment with that credential. Yeah. And so we'll we'll walk through the the the following scenes is basically following on from that Monday morning. So Sally's been, unwell, and left her phone unattended, so that she can rest. As part of this, sequence, the attacker has has kept sending her her logging requests. The the the partner trying to stop the the threat actor, you know, creating these MFA, approvals has basically accepted that. Obviously, unbeknown that this is some form of attack that's, that's in progress. And whilst we've mentioned the cap forum, that is fictitious. The second piece I've just described to you in terms of the scenario, someone being unwell actually is... Has actually happened. I don't know of an organization that's experienced this type of scenario. It's really just really emphasizing the fact that continuing to invest in security tooling, ultimately, it's done its job in this particular scenario is one thing, but it is really still revealing the fact that humans are, you know, part of the, part of the issue here. And it's almost by proxy that our partner has been part of this cybersecurity event as well. Yeah. I couldn't agree more, Anne. So, look, there's three things to listen out for. Right? Who's in charge? What's actually known? And also, importantly, right, what's assumed? And also, what questions does nobody ask? We're gonna come back to each one after every single scene and effectively use the polls and the chat and effectively pick up the answers as we go. We found a strange login event just at 08:45 this morning. It's, Sally Jones' account, and MFA approved it. But the location is an unfamiliar IP in Eastern Europe. Normally, we'd just let this go through automatic review, but the volume and type of activity the session immediately generated triggered, sort of, internal critical alert. Okay. What happened exactly? Did they actually get in, or was it just a failed try? The identity platform generates a lot of noise, especially first first thing on a Monday morning with everyone logging in remotely. I don't want to recall a critical incident over nothing. It's it's definitely not nothing. Look. The session has been active over an hour now. It's not doing pay work... Payroll work at all. It's searching our local EMEA active directory for high privileged names, group memberships, and login history for our IAM team, our UK domains, and key cloud admins. It looks like a highly sophisticated account discovery activity rapidly mapping our identity hierarchy to find the path of least resistance and the privilege of escalation. This looks planned, focused on identity, and nothing to do with the data yet. That worries me. If they're mapping privileged accounts, they already know who to target next, and they're moving with extreme focus. We need to know what classified files Sally Jones has got access to right now. Has she accessed any network shares containing classified information in the last hour? We need an immediate audit of her file system access. If any of it touches classified defense data, we could be in serious legal trouble if this breaches any of our US, DOD, or NATO compliance requirements. Wait. Hold on. Let's not jump the data loss immediately. Regulatory fines until we have confirmation. What I care about is whether this affects operations. All of our manufacturing sites are still running. Right? My real worry is service distribution and whether the plant control system stays online. Now if they do deploy encryption, we've tested our immutable backups. We can recover all of application and data quickly. But right now, I need to know one thing. What is the risk that they move from the payroll segment to domain controller? Right now, it's stuck on Sally segment, but the risk is growing fast. They're hunting for something stronger, maybe a hash or a cash token to pivot into on prem AD itself. If they compromise domain admin or control of the identity provider, they don't just get her account. They get authentication for everything, including the systems that run on our physical plant, And we just don't have proof of lateral movement yet, but the way they're searching tells me they're just one step away from it. Then com... Containment is the real question. And, honestly, you haven't given me enough yet to know how deep this goes. Did they touch group policy objects and new domain trust? We need a clear timeline of every call that session made inside Active Directory. Because right now, I can tell how far they've gotten. And if they have already grabbed the password, of Sally's machine, logging her account after the fact won't stop anything. I need all the data now, especially, whether they try to reach a domain controller. This is escalating too quickly. Based only on initial search logs, we don't have, confirmed data logs. No confirmed system impact beyond the searching itself. As far as we know, they are still just looking around. But if they get admin access, none of it matters, not even the backups, because our entire security model rests on trusting our identities and logins. If we can't trust that, we cannot operate. So I need SecOps to provide an immediate actual recommendation. How do we stop them moving from payroll to core infrastructure? We need to shut this down now. This... Look. This this won't fix it, but it buys us some time. We isolate the segment Sally's machine sits on. That should cut the path into on prem active directory and stop them from reaching a domain controller or pulling credentials off that segment. It will disrupt finance and HR for a while, but it's the only way to contain what we can see right now. And because this is touching privileged accounts, this has to go to the global council. You know, we're a defense contractor. If this touches classified data, that's a regulatory problem too, and that's above what we can decide on our own. I agree with isolating, but we have to assume the worst, that a credential is already stolen. Isolating cuts off their path in, but at the same time, we need to start going through every group policy change to every privileged account on both our US and European side. If it contains the network, we can put all our forensic efforts into finding that stolen credential before they get to use it. Isolation isn't optional here. Protecting the identity provider itself has to come first. If the attacker reaches domain admin, we're not talking about hours to recover anymore. We're talking weeks. We need to stop this lateral movement right now. Agreed. I'm raising a critical incident now. SecOps isolated finance segment. For now, only tell the finance director and the head of workspace technology. No wider notice to employees yet. We act now before this gets worse. Let's pause there. The team did a lot. Right? Somebody noticed the login that looked normal on paper, behaved wrong. They escalated it. They isolated finance within the hour. So this is where we need to look at, essentially what they knew and and what the teams, only assumed. So we we know that there was one verified session. We also know that they, the... That the actor in the environment was searching for for admin accounts. What there wasn't any proof of yet was the fact that there had been any kind of move or, privilege escalation to a domain controller. Some of the things though that came out in that, kind of scene were, like, there was the assumptions that there was no data that had been taken. There was also, you know, an assumption that manufacturing was safe because it was still operational. The third and kind of probably most critical one here was that the the assumption was that the problem sat on prem. And this is kind of really reinforced that at kind of quite senior level with the fact that the, the VP said and confirming that there'd been no data loss. You know, I'm not sure any organization really can think about the fact that two hours and in to an instant like this, they can absolutely kind of hang their hat on that being, you know, a confirmation. So more of a assumption, not really a finding. Yeah. Indeed. So question here is who's in charge. Right? The VP leads the call. The I'm team, they absolutely own active directory. It seems the cloud team own entry ID. And look, they're not on the call. So nobody in the room has authority. It's all over the place. And actually, the attacker is. So in many real incidents, that's not the true answer is who's in charge. The truth is, nobody. And that... And that's really something which is playing itself out, in this scenario and the scene is that the the the kind of management of the of the of the event overall. What we're also seeing as part of this is, you know, it's it's not just a technical kind of discussion to be had. The InfoSec analyst is also probably considered quite rightly to be offering their opinions into the situation as well. So that's turned a technical discussion into a legal one by, in this instance, raising, you know, the The US defense rules straight away. And, obviously, they got global presence, so across Europe and things like that, but also be having their own kind of regulations that would need to be adhered to. The key point here is in a regulated business, the the legal and technical response really should have to be considered run together, not the technical one first and then thinking about the legal piece afterwards. Great. So I guess the question is what what didn't get asked. Right? Is there anything about the cloud? Right? How was MFA satisfied? Is the attacker even still in? And then I guess the most important thing for us is gonna be, is there a clean recovery point to go back to? The I'm admin also asked sharp questions, right, on group policy, domain trust. They didn't get an answer. You know, also, Mark, just on that is that the team did a great job in terms of being able to... They get the signals in terms of something that may have been malicious in that environment. They isolated finance. The question here is is, like, again, there's a process and people part of that is that they isolate finance, but they didn't actually let them know that wasn't gonna happen. And and the questions also need to be considered as a part of an incident and how that's managed. You know, is that a fair call? If this scenario or the incident itself gets any worse, would that, you know, lose that part of the business's trust for the for the rest of the exercise? But really, it only closes the on prem door. And as that closing line said, the attacker, as we know, especially with those that have a knowledge and awareness that organizations like ADG operate hybrid environments that are very cloud focused as well as still maintaining some heavy on prem, infrastructure. The the real target here is is is going to be outside of that initial vector that they've gone after with the the on prem estate. So, question for those of you, on the call today. In this type of scenario, who owns the the containment from an identity compromise standpoint in your organization? And second part of that is, what is step one for you? Yeah. And make sure you put an answer in the poll. And then for me, I guess, let's see what happens next. Right? The fragmented recovery. Right, guys. Status update. We're eight hours into the partial AD recovery. Can the AM team tell me how close we are on getting the new domain controllers ready for sync? I need to give the CEO real progress. And right now, all I have to report is the help desk tickets are spiking globally. Look. We are moving as fast as we can. Okay? Restoring the EMEA domain controllers and repairing necessary objects is a long time consuming Microsoft comp... Process. Completely clean before we bring the sync back up. If if it's not, we were extending malware and corrupted security settings straight back into the cloud. And I'm completely stuck until you're done. We've got thousands of user identities waiting to be restored in the cloud, but their Entre ID accounts are basically empty right now. The head of workplace technologies, on my case, every five minutes because none of these are recovered users, can reach their SaaS apps, HR tools, or even parts of m three six five. The recovery process wiped out their access, to the apps because the source... The objects were wiped and rebuilt. I understand the pressure. But if we rush this, we could bring back the very problem we isolated her machine for in the first place. You need to wait for my sign off before we resync. This has to be precise. Getting the foundation right matters more than the speed here. So the process is slow for a reason. While the recovery is underway, I've had to expand my scope really dramatically. So I'm now actively monitoring three environments at once. The initial compromised segment in case there's still activity there, the new AD being rebuilt, and the cloud estate, which is only half configured. And I still haven't finished running the root cause analysis, so we don't fully understand any persistency attack again, to be honest. This is exactly what worried me when the council chose to partial recover. We got two separate teams, on prem and cloud, trying to fix one problem from two different directions. Cloud team, I need an estimate from you. Once sync goes live and the new identities are flowing, how long to get those policies and app access working again by hand? Well, realistically, another twelve to sixteen hours just to reapply critical policies and app access, assuming that the data is still there and nothing breaks during the sync. And there's delay that's already hitting the whole EMEA region, very hard. Teams cannot work together properly because the isolated finance staff cannot reach the users who have been recovered, and the recovered users still can't access critical tools. This is so frustrating. We gave up the certainty of field rebuild from speed, and now we're getting neither. But switching plans now would cause total chaos, and we lose the eight hours we've already put in. So we need to keep going. IMT, keep going. Cloud team, get everything ready to move the second we get the green card. SecOps, keep monitoring all three environments, but put your attention on anything unusual in EMEA first. Okay. The fragmented recovery. We're sixteen hours in. Nobody here is doing a really bad job. Right? Everyone's working hard. But let's look at the picture. The on prem team is rebuilding AD carefully. The cloud team is waiting. And if you look at SecOps, they're watching three environments and they still really haven't worked out what the attacker actually did. Yeah. And for me, two things, stand out here. As as this... Is it in a hybrid environment? Restoring that that AD is not necessarily restoring the the trust in the cloud. For those of you aware... Who are aware of these types of hybrid kind of setups, the... Those users have accounts, but essentially parts of their application access, and policies that would be associated to those accounts, are essentially going to be wiped, when the the Active Directory environment pieces get get rebuilt, which really kinda lends itself to the the other problems here is that, you know, the the other part is that the recovery process in that type of hybrid environment is only, you know, is gonna be as fast as the the slowest step within it. And given the fact that they're already fragmented in terms of the teams that run the entry environment, to the teams that run the AD environment, that entry cloud team can't start doing anything until the AD team signs off from the fact that they're happy to move forward. Which brings us to who's in charge. Right? The VP chairs the call, but listen to his big decision. Right? It's to keep going with the current plan. Right? Even though it's fragmented. So that's decision basically not to decide. The I'm infrastructure admin controls is basically the next phase then starts. And the reason is the process. Right? Nobody gives the finish time. Yeah. I mean, I'm absolutely welcome. On top of that, we're talking about the kind of the people here as well as the process. We've already kind of been speaking about some of those things that are responsible for, you know, working within the scenario. And the cloud administrator here is, unfortunately, to put it in quite blunt, is they're responsible for everything in terms of how this scenario and the the incident plays out, but they're they're not really in charge of anything yet. And on top of that, as part of that kind of read through that the the team ran is that you're the... You've heard that the head of workplace technology is chasing, that cloud admin every five minutes. And, actually, that's... That person isn't even part of the incident chain. So outside of the kind of technology aspect to this, and I'm sure that for those of you in the call, you might you might, you know, think about or might might have a wry smile when you think about people that do act like this, within your organization. Ultimately, they... We see this that happens all the time. Right? And it's gonna really only really make things worse. Agreed. So now for the impact. Right? Should you restore users at all if you can't restore their security controls with them? Those identities are effectively naked. Right? The the identity team treats them... The identity team treats them... I gotta stop that again. Now the impact. Should you restore users at all if you can't restore the security controls with them? Those identities are effectively naked. The team treats that as a productivity problem. Also, it's a live security problem, and that's something to seriously consider. And... Yeah. I mean, the other thing about this is that they've started to, you know, exercise the recovery. But like many organizations, and we would have seen this, you know, in the instance last year where you are kind of torn between this decision of how long do we spend investigating root cause and running that forensic analysis versus bringing up something to run so that we can keep our, you know, core elements of our business, operational. So So the question really is, can you actually say that restore point is clean if you don't, you know, if you don't know the root cause? And if you're checking against what you already know, then essentially that just is, you know, bad and, for... As a due diligence exercise. And if you do recover something, and let's just say, you know, for a few days you do operate and nothing is a problem, that's also then gonna create, you know, a false sense of confidence if you like. Agree. And and one more thing as well. Right? What's missing from this call? Well, guess what? It's the VP of identity and access management. Right? It's been treated as an infrastructure incident. And look, identity sits in a different reporting line. You've really got to keep that in mind as well. Yeah. And just along along the, again, the people and process side of things, but more this is about the the time and impact. So what we've seen here is between hour two and hour sixteen, ADG has learned a lot about what their recovery is costing, and that's something they can put a number on. But they've really not learned much at all about what the threat actor is... Has been doing it or about to do with them in their environment. So the good thing is, if you wanna put it that way, is that they do have some form of a capability to apply cost to the incident, but what they don't have visibility of is the threat. And, again, back to those of you on the call today, I guess this really is a is a open ended one if you like. If if you were involved in this type of situation, do you really think there's an end in sight once a recovery effort like this has has started slipping? Is refusing to pivot, you know, steadfast in terms of your approach, is that a good thing, or is this a sunk cost fallacy? So we'll open the polls up again for you. Oh, and while they've been revealed, the attack has been basically sitting in the cloud as a global administrator for hours, and this leads to the reckoning, I'd say. What just happened? My phone, my laptop, my emergency tablet, everything just logged out. My credentials are gone. I can't sign in to anything. SecOps, report. I need an explanation immediately for this complete system failure. We have a system wide denial of service event. All 20,000 user tokens have been revoked globally, and sign in is blocked across the whole tenant. Everything is frozen. This came through the identity provider itself. We're we're locked out of our own admin portals. I just had a screenshot of the ransom email forwarded to me by the CEO. It confirms they have global administrator control in Enter ID, and they have already exfiltrated the r and d data. Our AD recovery did nothing against this. This threat was never just on prem. It's cloud native, and they probably built that in while we were busy chasing the on prem side. Global admin? That... That's exactly what I was afraid of. It means our whole effort to restore on prem active directory was a massive expensive distraction. Okay. We need to stop the AD recovery right now, pull the plug if we have to. Every resource goes to intra ID containment globally. We have to leave this from the cloud side now. I think we missed some sort of persistence. Ugh. This is a disaster. I spent sixteen hours telling the global council that our thorough AD recovery was the right call. I'm team, where is the persistence coming from? SecOps. Find out where the token revocation script came from and track down whatever infrastructure or application they used. We need some control back before manufacturing shuts down completely. Two out of our free manufacturing sites are already offline. Global admin access. They must have found something like a hard coded application access token, like the can we use for m three six five sync scripts. Those tokens have elevated application only access, and the cloud team is the only one who's supposed to see them. They bypass normal user controls, but now I'm worried about what else they got changed, not just the sign in block. We need to check for changes to federation settings, credential keys, and any new service accounts. Confirming that r and d data got taken from Seattle and our Bristol site in The UK is a serious compliance failure. This breaks our export control obligations. We're legally exposed now and looking at the heavy fines and lost contracts. This isn't only a technical problem anymore. It's a legal one. We need to start preparing full, honest reports for the regulators immediately. We also need to think about the sync engine here. That's the bridge between the clean AD environment we just rebuilt and the enter ID environment, which is now compromised. If they used their global admin access to change the sync rules, then the moment we restart the sync engine, any cloud native malware or malicious applications could get pulled straight back into the AD we just cleaned. We could end up reinfecting ourselves over and over. Preventing that reinfection is our main technical priority right now. IAM team, kill the AD recovery process and make sure a sync engine is disconnected. Cloud team, work with SecOps and check for stolen sync tokens being the likely cause. I need audit logs immediately, permission changes, or malicious application activity, starting with any new application only accounts. We need to find that persistence mechanism and shut it down before we even think about turning the authentication back on. This is now a full scale cloud identity containment situation, and protecting our most secure tenants comes first. Our next call needs to include the chief legal officer and the CISO just for the regulatory side. Okay. The retuning. Let's take a breath. We're twenty hours in. Everything goes dark for 20,000 people. So for those of you who are really following this scenario through, let's just get this giant elephant that's in the room out there. So what you would have heard is that every instruction at the end of that scene needs some form of admin access to a tenant that's just been blocked, from all sign ins. The VP in this in this in this instance opens up the scene, they're locked out of everything, but they still start giving orders. Nobody mentions it. So how would you actually carry any of it out? Yeah. And who's in charge? Right? You got two VPs giving orders to the same people. Right? Neither acknowledges the other. Nobody says I have command. Nobody says they understood. The VP of I am, the person missing in the last scene arrives holding an email nobody else has read, forwarded by someone who's not on the call. I I mean, it's chaos. Absolutely, Mark. And the... That that that that chaos, relating to kind of who made the call to stop the recovery here. Right? So this really goes back to, outside of the the breach itself or the methodology that's used is what we have at this point is an engineer that's in New York saying stop, a VP ratifying it, and then you had a global council that's just had all of their decision making and plan reverse. So that incident command really is, obviously, quite quite lacking in this particular scenario. In regulators, the infosec analyst wants full honest reports out immediately. The VP of I'm quietly sends that to the chief legal officer in the CISO, who owns the tell regulators question. Yep. Absolutely. The outside of that piece also, I was thinking about, who made the stop, the call to stop the recovery. We we spoke on... And highlight... I just alluded to this a bit earlier in the, the previous discussion about the the cloud admin that offered a theory about, you know, what the problem was. That almost like that Ultimately, it was an admission of guilt in some, circumstances that they were, you know, really asking these questions around a hard coded token, being part of a sync script. Again, going back to that instant management, it's also the people element of this as well. So if that person in your organization made that type of a mission, what... What's gonna happen to those people is... And if your honest answer is, you know, they they may get managed out or open to another position, ultimately, you're gonna have an organization where next time nobody owns up to that. And then just following on from that, we're, you know, outside of the, you know, that that problem that's been... That causes the the impact to that. Yeah. Mark, you referenced the 20,000 sign ins that are are now blocked. The team is locked out. Two or three manufacturing sites are offline. Granted, these are serious situations. Some of the impact is is absolutely very visible, you know, with... You know, in terms of the lockout, for example. But they're also relying on the evidence that's been provided by the threat actuary. So this is claimed by them and essentially not proven, but it's still influencing a decision making process. Alluding to the fact that global admin has been compromised and data has been stolen. The ransom note here is not necessarily the confirmation, but it's still driving, kind of, decision making process and the lack of evidence. I guess I guess the question is, right, was was the sixteen hours wasted? Right? One view probably says yes, and another says we need we need a clean AD anyway. Right? So you have to work, on the basis, was it badly timed or not worthless? And is the lockout an impact of exactly what the defender would do? You'd have to shut everything down before the attacker did, basically. Yeah. Absolutely. It's not... I mean, it's a... It's a timing, like you said. They're they're gonna have to go through this exercise at some point, but it's it's also putting that exercise and, aligning that to the potential, you know, reinfection risk or reintroduction of a threat actor. Recovering and having that, kind of assessed as as up and running and there's no damage to be seen is... Do you just accept that risk? The problem the problem here was... And it was raised really early on, is that the SecOps, engineer said that they didn't know yet what the persistence attacker had. And and and as we went through the entire scenario here, so far, that that unanswered question turns out to be, ultimately what the whole story is. Yeah. Great. So here's the pattern. Earlier, they had an estimate of twelve to sixteen more hours. Now, nobody can give a time at all. At two hours, the impact was unmeasured. At at hour sixteen, it was unchanged. At hour twenty, it's being explained to them by the person who's actually caused it. And again, for those of you on the call, this is, before we wrap this, is that for you, has anything about this type of attack different from from what you've been preparing for? The poll's over. So conclusions. Right? Let's step back. We bought twenty hours of one incident. It took one improved login, one path into the cloud that nobody checked, and one recovery plan that only covered half the problem. Yeah. And there's a final chapter here that we're not gonna gonna show today. This is kind of what happens, over the next few weeks or so. So like many organizations, they they find a a way to survive. So eight weeks in, this is found to cost the organization approximately £350,000,000. That partial recovery costs two months of of full operation. And and and Mark and I have have personally seen this in in organizations that we've worked with over the last, or at least over the last year or two. In the end, this fictitious organization ended up having to wipe and and essentially rebuild their whole identity environment from scratch. Really, the reasons being being that is that they've never practiced recovering that identity recovery and how that maps to the on prem as well as the cloud environments and and being rec... You know, recognizing how each depend intrinsically on each other. The people side was heavy too, and this is one of the areas that never really gets considered. Wiping devices for 20,000 employees completely destroyed trust and caused serious burnout for the individuals concerned. Also, the stolen propulsion and avionics designs led to investigations on both sides of The Atlantic with their security clearance status at risk, which is a huge problem for them. Yeah. And I think just to to add add add something on here, it just goes back to what I said about ADG at the beginning of this session is that that adherence to those frameworks and being able to tick boxes as it relates to, you know, the compliance and record fee standards that they are kind of, you know, beholden to is that the backups that they had worked perfectly, that they could recover their data. And, again, we see this day to day is that there is still this assumption that identity is there to start with before you start having to get a hold of these critical applications, whether they be on on prem or cloud. The key thing here is that nobody had rehearsed getting the trusted and and the clean state for that identity environment back. So the decision for making this partial recovery ultimately ended up costing more than a completely, you know, a full rebuild would have done in the first place. Yeah. It's a very good point. So so questions to take away. Alright. One, who owns the 350,000,000? The attacker or ADG? Who owns the decisions? The backups that were perfectly count as success if they didn't change the outcome? And I guess, you know, would this have really been stopped? The reused password, the MFA approval, the group policy question that nobody answered, the cloud that nobody checked, the hard coded token, the untested plan, the partial recovery, it's hugely problematic. Yeah. Well, I can... I kind of... I'm kinda grinning because it's always my favorite question when we run sessions like this is, the... What would it have taken to produce, that 350,000,000 pound number on day one? And, you know, ultimately, would that decision have been different had that number been known? Now let's connect this to what you can actually do. Now using three moments from the scenes. Sure. So there's a few things here. So just, from regards to Rubrik's position and and what we, can offer from a platform and service capability. So first of all, let's go back to that that initial piece relating to the alert. So the I'm admin is asking for a a timeline of of of what that session, had done inside the environment... The AD environment. So Rubik's Security Cloud, watches active directory. So we have integrations with the domain controllers, not just through the the Windows event logs and, an attack can can tamper with. So outside of that in terms of full state IDP, we could also see, the behaviors within that. It alerts on things such as group policy, previous group changes, where you choose to have that. Those changes can also be automatically, rolled back. But the the key thing here, and and to be completely clear, is that Rubik's not looking to replace, the internal or external security stack, you know, like like ADG would have invested heavily in tools such as your EDR, for example, Microsoft Defender, CrowdStrike, other tools in the market today. Spotting those first first, searches is is their job. But Rubrik acts as the before and after view of of what's changed, ultimately expediting the investigation and helping close that loop. And for the fragmented recovery, the team checking the restore points by hand, I guess, with Rubrik, the guided clean recovery scans every single domain controller and effectively starts looking at that snapshot against things like CrowdStrike strike and broogles for intelligence that we support and integrate with the platform. Effectively then, we tag everyone as as clean, we can detect the threats, or even we can quarantine that. And for the cloud team, stuck with the naked identities, enter ID recovery brings back the relationships, not just the objects. Group memberships, roles, app assignments, conditional access references, everything can be recovered in the right order. And I think this is super important. Hybrid recovery, that that recovery between AD and NTRAC can be brought back together even with the sync capability. So it's one track, right, not two. And that saves time and a huge amount of effort. Yeah. Thanks, Mark. And the the, the last pieces of, of this scenario related to the the reckoning where, you know, ADG were were locked out, whilst the the attacker held back global admin, rights on their on their cloud environment from a rubric perspective. In the same way that we support the orchestrated recovery to an isolated recovery environment for for active directory, allow organizations to essentially secure and store that, backup data outside of all of the production, or authentication domains within an organization such as ADGs and such that they can rely on recovery. We also provide a similar capability as it relates to entry ID. So these backups are kept completely outside of your tenants in in our isolated, managed storage. So regardless of the rights of the attacker, can claim or gain, the admin rights don't reach them. And by extending that kind of use of that data to support a cross tenant recovery capability, I e recovering to a separate entry tenant, you can then start to think about what it means for your organization to be able to stand up those kind of minimum viable elements as it relates to critical enterprise applications, users, groups, roles, additional access policies. But at the same time, think about how that then relates to the hybrid environment of that AD that you just recovered into that into that environment as well. So bringing that together, end to end is a is a really important capability and speeds up that time to a no clean, but also be able to get to the trusted state where you can enable your critical users to be accessing those enterprise apps. Outside of that, the holistic kind of total recovery, we also support the capability to be able to get down to single object objects, sorry, or attribute levels and and merge that with live state. So you can rather go for the big red button and recover. If you can get ahead of it, you can start to be removing, reverting, persist, or attempts to gain persistence, before the attacker really gains that foothold within your organization, which, again, is really important, from, kind of keeping things operational. And that's not just done by ourselves. We've mentioned the the integrations with, you know, the security tools. But at the same time, is... We know that when recovering, the identity environments, especially for organizations such as ADG, there are a ton of legitimate changes that are also made to those environments. So the joiners, the movers, the levers, if I'm recovering my IDP environment and I need to then... From, like, I don't know, five days ago, for example, but I then need to incorporate the people that have left, the people that have been contracted in for a couple of days and left. If I'm recovering all of those, again, that's a massive amount of effort to tidy up before you then start opening up the access to those applications that you, have, within the business. Cool. Thanks, Alan. So I guess the big question is if you wanna see it hands on, there's an interactive tour of identity resilience at the enclosed link. And if you could also book some of your rubric team, we'd be happy to engage and talk to you more about our capabilities and all the information we've shared with you today. Yep. Thanks, Mark. So, a big thank you to all of our cast who, put their time into, the scenes for you... For for ADG. Everybody, obviously, today who's who's joined the call. And as we wrap up, if there's any questions that you have, then we'd like to take them now.