B (3:52)

Can you take us through the types of activity that you've been seeing here? I mean, who's largely responsible for the attacks that people are seeing these days?

A (4:01)

Yeah, certainly say at this moment, Hindala, I believe is how you pronounce the threat group is obviously all over the news due to what they've recently done to Stryker. I would say before that of course Scattered Spider takes a lot of press, right? Certainly because of what they did in Las Vegas, what they have recently done in the UK and beyond. Scatter Spider has certainly been in the press. But I would say to you, I mean based on our own statistics, we certainly work a lot more breaches for the threat group Akira. Now Akira has been in the media, but I would say they certainly are not taking as much press as it seems that other groups have, like Handala and also Scattered Spider. Namely I think it's probably because they use fewer novel methods, right? They're certainly commonly using vulnerabilities and firewalls to gain initial access. But Akira beyond a doubt is who we face the most. I think about 16% of our sample last year was Akira and they're using

B (5:02)

more off the shelf tools which maybe makes it easier for them to blend in. Is that fair to say?

A (5:09)

No. Akira in particular, they love to target vulnerabilities in firewalls, specifically Sonicwall. Actually, you know, I mentioned Coalition. Coalition does produce all kinds of statistics. And interestingly enough, when I last attended their session at Black Hat last year, they actually pointed out that Cisco is Cisco and their VPN products are some of the most commonly targeted. And certainly in the context of Scattered Spider and what we see play out with that group, they do commonly target Cisco anyconnect and I can unpack that in a minute. But with Akira in particular, their initial access, how they compromise initial creds or essentially establish access initially is through vulnerabilities in Fortinet and Sonicwall commonly. Matter of fact, I would commonly say on stages that if your organization is using SonicWall, you should probably think twice about whether you actually truly do have a secured perimeter. And I hate to pick on a specific product, but SonicWall comes up a lot with Akira.

B (6:12)

Can we go through some of the tactics that you're tracking Here you and your colleagues, are there patterns that you're following?

A (6:20)

Oh yeah. In the context of Scattered Spider, certainly they're in the news a lot. We have seen many events where they have actually used self service password reset against organizations. You may or may not know that Microsoft so graciously turns on self service password reset for administrator accounts, privileged accounts by default in Office 365. So you don't actually have to do anything for that weakness to be enabled in your tenancy. Microsoft has so graciously done that for you and Scattered Spider abuses it. And we've also of course seen Scattered Spider of course manipulate the help desk that's been all over the press, Right. I would say to you, especially large organizations, it is impossible to know the user, right? And so the threat actors effectively use the convenience of the help desk against organizations and their lack of identity verification there to actually get the help desk to reset MFA to reset credentials. In a recent event, actually we saw Scatter Spider actually call the help desk. They reset a credential for a non privileged user, a normal user. Leveraging that credential reset and that MFA reset, they then connected to Cisco AnyConnect VPN and they accessed the ServiceNow instance as well. With the ServiceNow instance they were able to obtain the documentation for how to actually reset a privileged account because the organization had so graciously used their IT service management tool to actually put their documentation in there. And the threat actors discovered it and used it to actually call the help desk again to reset a privilege cred. And I would just say if I were to like unpack some of the flaws here, there's a lot, right. Technical flaws that come up a lot in breach. And this is why we commonly say resistance is very difficult. And frankly it's not a matter of if but when you will have a breach. Because to actually do these things with perfection is nearly impossible. And frankly, if you don't have breach context, you couldn't even get close to what threat actors are commonly able to abuse. Some things I'd just point out, like if you're not establishing device trust on your Cisco anyconnect vpn, frankly any VPN product, meaning if it can be used from a non corporate issued device and there's not something regulating that governing blocking it from being able to be used that way, then the threat editors are simply going to use it. And second thing I would say is if your SAS tools are publicly exposed, and SAS tools are commonly publicly exposed, threat actors are commonly able to log into those tools and actually use your tooling against you. We would commonly say that your SAS tools should also have device trust established, meaning they shouldn't be able to be logged into, except they're from the user's coming from an approved device and or approved network. And thirdly, I would say in the context of the help desk, help desk must have identity verification steps and they can't be so simplistic as what is your employee id? What's your extension number? I seriously have heard organizations still using these methodologies for identity verification. This is just a flawed strategy. It does not hold up in the modern context anymore. You've got to go much deeper. And lastly, in that same bucket, I would just say the help desk should never under any circumstance technically be able to reset a privileged credential. Your help desk should not have the access necessary to reset the MFA and to reset the password on a privileged cred. That should require additional hoops and hurdles and additional approvals to actually do that. And that is not what we commonly see organizations doing.

B (10:06)

Can we talk about persistence? I mean, once they've gained access, how do they maintain their presence there?

A (10:13)

That's a great question in the context of once they've obviously done an MFA reset and they've gained initial access with Scatterspotter and one particular event that comes to mind most immediately, I mean, they just logged into Cisco AnyConnect. I mean, if I were to unpack, a flaw with persistent access is that organizations do commonly permit privileged credentials to connect to remote access platforms, right? If an administrator cred can connect to Omnesa's Horizon or Citrix, or Your VPN Cisco AnyConnect as an example, or even your Fortinet Forticlient VPN or your Palo Alto Global Protect vpn, if a privileged cred can even log into those things, you've got a major problem. Privileged creds should under no circumstance be permitted to log into remote access platforms. But honestly, basically all organizations are allowing this, and that is commonly what threat actors abuse to gain persistent access. I would say that that's not what all groups do. Certainly they do other things too. I mean, they use RMM platforms, they use TeamViewer, they use AnyDesk. Certainly if you've read much breach news, you certainly will probably know anydesk comes up a lot. There's also a product from ConnectWise called Screen Protect that. Sorry, yeah, Screen. Screen, Screen Connect, sorry, I think is what it's called. These tools come up a lot.

B (11:46)

Well, in terms of an organization allowing that Access? To what degree is it for the convenience of the users? To what degree is it an oversight or even neglect?

A (11:59)

I love this question because to be frank, I would say to you that IT has been led to believe that they should have easy means of administration. I would say that IT professionals commonly focus their security efforts on inconveniencing the user rather than inconveniencing themselves. I would say to you that IT is IT access to systems that are leveraged, being leveraged by threat actors for destruction, right? The goal here has to be to frustrate the attacker. You have to frustrate the attacker to the point of them giving up or you detecting them. And until IT professionals are able and willing to complicate their own access to systems, these breaches are going to continue happening at the scale and quantity that they are IT is IT access that's permitting this to happen. So the reasons why, you know, a privileged account can log into vpn, sometimes it's because IT staff want the convenience of it, other times it's just a lack of knowledge, right? They simply didn't know better or they didn't consider it. I would say, you know, what we commonly see threat actors doing is if once they're on the vpn, if they can get to what we call critical consoles from the vpn, you've got even another problem, right? Not only could they log into the VPN with a normal user or log into the VPN with a privileged cred, but once they're on the VPN, if they can open VMware VCenter, if they can open your Azure administration console, they can open your Cyber ARC instance, your secret server instance, they can get to your SAN administration, your storage area network, administration sites. If they can do any of those things directly from the vpn, you also have another significant issue, right? Again, back to complicating it. Access to systems. There should be no direct access to critical consoles from VPN because in doing so you're just making it easy on the threat actor, right? They don't have to go, they don't have to do anything really novel to gain initial access and then of course, to leverage that initial access to open a critical console that they will leverage for destruction. Matter of fact, more than half of the breaches we work involve direct access to VCenter and direct encryption to the VMDKs.

B (14:23)

Can you walk me through the process by which they elevate their own access and then shift to lateral movement?

A (14:31)

Yeah, that's a great, that's a great question. I would say that the way they do this and in the case of the event I've been unpacking here from scattered spider event, they just called the help desk leveraging the documentation they obtained from ServiceNow and how to reset a privileged cred. They just got the privileged cred reset by the help desk. They logged into Cisco AnyConnect VPN. Once on the Cisco AnyConnect VPN they opened VCenter and they logged into VCenter with that same privileged cred across the VPN. And once they were into VCenter they were able to encrypt all the VMDKs. Now it gets a little more complicated than that. But how did they elevate? Well, one way is they can just call the help desk and have the cred reset. Another way is if you've unpacked the okta breach that happened last and I would say to you that their CISO so graciously did release into the public sphere the fingerprints of their breach. I would say to you that they do Threat actors do commonly elevate permission a host of other ways they can get privileged creds from Gmail if your IT users are using Chrome and are permitted to access any apps from personally owned devices or even able to use Chrome at work while also being able to use Gmail at work. Chrome has a beautiful little feature of synchronizing any cached creds into Gmail. Right? And so they could privilege escalate by compromising one of your IT users Gmail accounts, they could harvest a token from a personally owned device. A session token, Right? If you're allowing your users to log into your SaaS apps like Office 365 from personally owned devices, it isn't a large leap to elevate permission if you're allowing your SaaS apps to be publicly exposed and publicly logged into from non trusted devices. Very simple to make that leap if you're allowing your users to cache creds in their browsers. Even Edge I believe now will synchronize cached creds into OneDrive by default. Right? So it is not a significant leap for a threat actor to gain access to creds privileged creds. I would also say to you we worked a breach where the threat actors were able to encrypt over 5,000 VMs. The cred that they used to gain access to VCenter they actually harvested from the sysvol share on an active directory server. The password was actually in a script and scripts are publicly exposed to the whole domain. So once they got on the VPN with a non privileged cred, they were able to go to the sysvol share on active directory, harvest a cred, and then they leverage that cred to log into VCenter and then the rest is history. They encrypted basically all the servers directly at the VMDK level.

B (17:22)

And is that really an overview of what we're talking about with lateral movement here? I mean, to what degree once they're in, are they able to freely go where they want or need to go?

A (17:36)

Yeah, lateral movement. I guess the punchline of all of that is to really just to say that lateral movement is very easy, right? If they're on the VPN and your critical consoles, you know, things like vcenter are accessible from the vpn, then what I would say, if they are accessible from user segments, I would take it one step further, then the lateral movement is super, super easy, right? I mean if they, if all they have to do is get on the VPN or if all they have to do is get a user coercer user to allow a remote session to their endpoint with AnyDesk or TeamViewer or Screen Connect to then open VCenter directly from that VPN or directly from that end user's workstation, then the leak to destruction is quite easy. The lateral movement is quite easy. It's all happening right there from the end user's workstation or directly from the vpn. What I would say here is that additional complication that we commonly see is that administrative identity is not commonly being managed well. Organizations as they've been trained, as Microsoft has frankly trained us all, really commonly put all these things in the domain. If you can log into your vCenter, if you can log into CyberArk with your production active directory credentials, you've got a significant problem. The leap to lateral movement. From lateral movement to destruction is very short and frankly very easy. Actually we have a construct we call admin identity. We have a methodology that we have created and we've been employing now for years to actually harden critical consoles, critical environments away from user segments and away from production active directory identity. I would say to you that even when organizations have attempted these forms of segmentation, they commonly do do things that undermine them, right? If you just as a simple example, if you were to segment identity away from production ad for your critical consoles like the storage area network, your VCenter, et cetera, and then you put those creds in your cyber arc instance, which is still connected to the production active directory domain, then effectively vcenter and your san are still in the domain. The threat actors just have to log into your cyberarc instance, your one password instance, your keeper instance, wherever it is that you're putting these creds to, then harvest them and then still orchestrate destruction. So to your question, lateral movement is very easy. Once they get a cred and they're on the VPN or on Citrix or they're on an endpoint with TeamView or any desk, the leap for lateral movement and then ultimately to destruction is very short and frankly, very easy.

B (20:20)

We'll be right back. Well, before we get to data disruption, it strikes me that there's probably an exfiltration attempt in the middle there. How does that typically play out? What does that look like?

A (20:57)

Threat actors do commonly attempt exfiltration, right? I mean, scatter spider as an example, is commonly known to do double extortion, which is where they exfil and of course also destroy, as we've seen play out here in the Hondala breach of Stryker, or the supposed one. At least as the public media is reporting, it seems that they were able to exfill 50 terabyte of data. least by their own reports, they exfilled 50 terabyte. We do commonly see groups attempting exfiltration. To actually prevent exfiltration is very, very difficult. If I were to call out something that org could do that is relatively simplistic, I find it shocking that an organization didn't notice, say, 50 terabyte leakage. Right? I mean, I would say that a simple thing that could be done is just creating monitored alerts of significant data leaving the enterprise. You know, you said you figure out what your threshold is, but there should be a threshold that creates an alert that requires analysis, then hopefully, hopefully detect these behaviors before they've caused significant damage. But yes, most groups are attempting exfil. Exfil is far more difficult to prevent. It's easier to monitor than prevent. To actually prevent it requires extensive tooling and frankly, extensive inconvenience that most organizations and most IT departments, frankly, most users are simply not going to tolerate. So I would say first, an easy first step is to monitor. First, figure out what your threshold is, monitor, create an alert, and then go and research those alerts. Timely.

B (22:40)

Let's talk about the destruction of the backups themselves. I mean, how does this play out?

A (22:46)

The way it plays out is that most orgs do commonly believe that they have immutable backups. Immutable by our definition, meaning survivable. Right? Just because your vendor, your backup vendor, says that your backups are immutable. Doesn't really mean they're safe. Every backup vendor uses a different definition of this word, immutable. If they're employing any definition other than the one I'm about to give you, your backups, probably, frankly highly likely, are not truly immutable. Essentially, immutability has to mean that there is no administrative override that would allow the deletion of a backup. Except that a timer first expire. Think of more like a timed lock safe, right? You can't open the safe until the timer expires, right? I mean, that's even if you typed in the right codes, you have to wait the time lockout before the safe will open. Same has to be true of your backups, right? If, if, if what you mean by immutability, what we commonly call quorum or two person rule. If, if what you mean by immutability is that one person request a configuration change and another approves it, that is not true immutability. And I would say to you that beyond what your product vendors are commonly telling you, orchestration of survivable backups is frankly more than just employing the immutability algorithm provided by said product vendor. What we know from breach is that survivability is truly a factor of the number of backup copies kept, the locations that you actually keep them, meaning they have to be segmented. And thirdly, that the number of identity planes that you store those copies in, meaning they can't be all collapsed into the same identity plane, meaning if there's one credential that can still get to all 1, 2, 3, 4 copies of the backups, then they're still effectively all vulnerable to destruction. And lastly, I would say that it does also require the orchestration of more than one immutability algorithm. You should never trust your survivability to one product, one method, one algorithm, because frankly, everything is flawed. We know that all technology has some flaw, that we all don't know what it is yet, right? It'll come out eventually. But essentially this is why I fervently am an advocate for organizations to get out of the recovery business. Organizations are at a disadvantage as it comes to breach and recovery because they are only as good as the data that they're able to receive from their product vendors. And product vendors have one goal in mind, unfortunately, it's to sell a product, right? I mean, that's what they're trying to do. And that's not a bad thing. But it's not born from breach, right? If you really want your backups to survive, you have got to do so based on what threat actors are able and willing to do. And this is why I commonly say that orgs really need to get out of the recovery business. You need to relegate that to a trusted methodology where you can have the assurance of recovery. We actually call this in our product suite Securita Summa, meaning security above all else. So we have a methodology of assured recovery that we recommend companies adopt. And frankly, the reasons why are the ones I just unpacked. It's very complicated to orchestrate an assured recovery.

B (26:19)

Can you help me understand the disconnect here? I am so often left scratching my head because it seems to me like many people feel as though successfully backing up their data is a lot easier than it actually is. And they feel as though they've confidently checked that box and yet when it comes down to it, they're left coming up short.

A (26:47)

There's a few reasons, right? If you were to just to look at the industry as a whole, right? The resistance industry, meaning the defensive, the prevention industry for cyber incident is about a $200 billion industry. The recovery focused portion of our industry is a $20 billion industry. I fervently believe with all of my being, and I see this playing out every single day, that most orgs convinced that they can actually prevent all breaches. Certainly that's where they're spending their time, their money and their energy is to prevent breach. The truth, however, is very different, right? You cannot prevent all breaches. And matter of fact, organizations are only going to tolerate so much user inconvenience before they will simply start undermining all the controls and write this, then yielding the spend. Useless. What I would say instead is organizations really need to focus on disruption of the breach pattern in reverse. You need to start at your data and work your way backwards. And if you were starting there, you would essentially focus on reducing the blast radius, right? Attempting through the orchestration of administrative identity, which by the way is built into our secure Tsuma platform, the orchestration of administrative identity to reduce the blast radius, the number of things that a TA could actually destroy, and then secondarily to that orchestrate backups with multiple copies, multiple segments, multiple infrastructures, multiple identities, multiple immutability algorithms, et cetera, to prevent those from being destroyed. And only after you've done those things, essentially complicating access and assuring recovery, should you then double down more on resistance. But that's not what orgs are doing. And so commonly the backups are largely being ignored. The professionals that are responsible for them, it's just one of their many duties. IT professionals are slanted toward, you know, satisfying the org and the running of the actual business. And this is why backup controls are commonly undermined, because they're, they're not one orchestrated from the context of breach. And the professionals that do it don't even know what that means really. Secondly, it's only one of their many responsibilities. It's not their sole job to make sure the org can recover from a breach. And then lastly, they're commonly looking to their product vendors to tell them what they need to do. And while there are many good products on the market, if you listen to their guidance, which also is not commonly informed by breach, your backups are commonly going to be destroyed. Matter of fact, we just got into a breach yesterday. This particular organization was using VEEAM to write their backups to a synology unit and they were convinced that their backups were immutable. Those two products alone normally would lend themselves to non immutable backups. Right? My first reaction just by hearing the products employed would be that their backups aren't going to survive. Just based on our history and what we commonly see play out in the public sphere and breach, it's not that any one of those products is fundamentally bad, it's just that they're fundamentally commonly not orchestrated. Well, so when we hear these things, we pretty much know they're going to be destroyed. That org was only keeping one copy of their backups. Their synology was co joined to the domain. Their VEEAM instances were in the active directory production domain. They had not orchestrated or even complicated it access to systems in any way. So the threat actors of course were able to delete their backups without much issue at all.

B (30:38)

Yeah. What are the take homes for you in terms of advice for our listeners here today? What sort of things would you recommend that they focus their attention on?

A (30:49)

Firstly, you really need to assess your recoverability. I would say that what you probably believe to be true is not true. We actually have a process at Phoenix24 we call the RBRA, the ransomware backup and Resiliency Assessment. It is an assessment of your recovery capability capabilities that are born directly from what threat actors are commonly able and willing to do. I would also say that most orgs frankly won't have any assurance of recovery, or at least timely recovery, because they've never actually practiced recovery from a real context. Most tabletop exercises make an assumption of backup and recoverability survival. And since backup and recoverability don't commonly survive, I would say that most tabletop exercises are not born from reality. So firstly I would say or sorry. Secondly I would say that not only do should you assess, you should establish good partnerships for both data forensics and recovery. Certainly we have a recovery practice. We are the fastest on earth to recover from a breach. Whether we knew you or not before the breach. We are still the fastest on earth to my knowledge to recover from a breach. So you need a good partner. Thirdly, I would say that you've got to prioritize survivability and that might mean that you need to get out of the practice of attempting to orchestrate your own recovery. I would say that breach context is hard to come by in order to prioritize it with excellence. You really need a professional organization that this is what they do, this is what they focus on and it's born from from breach. Lastly, I would just say that you have got to complicate IT access to systems in our solution secure Tsuma we certainly do that with you. And for you it is more complicated than what I'm able to explain here in a short form podcast. But if you're not frustrating, for lack of better words, or inconveniencing your own IT access to systems, then you are making it incredibly easy for a threat actor to level your entire environment. If it's easy for an IT administrator to do, it's easy for a threat actor to do. And so in closing, I would just say complication of admin identity and IT access to systems must be at the forefront and or equal, if you will, to backup survivability and timely recoverability. I think all three of those things have to be done in concert together with excellence.

B (33:33)

Our thanks to John Anthony Smith, Founder and Chief security officer at Phoenix 24, for joining us and walking us through what a real attack looks like from the inside and where defenders still have opportunities to stop it. To learn more about Phoenix24, check out the link in our show notes or visit our website thecyberwire. Com.