Walking through the anatomy of a cyberattack.

Dave Bittner: What does a modern cyberattack actually look like from the inside? In this edition of CyberWire-X, we follow an attacker step-by-step as they move through a target environment, probing weaknesses, exploiting entry points, escalating privileges, and moving laterally toward their objective. Along the way, you'll see the tradecraft behind the intrusion, the scripts, the missed alerts, and the moments defenders could have stopped the attack. Our guide is John Anthony Smith, Founder and Chief Security Officer of Fenix24, bringing more than 16 years of breach response experience across healthcare, financial services, and legal sectors. He's helped investigate and recover from incidents affecting hundreds of organizations worldwide. This is a practical conversation at how teams can strengthen detection, readiness, and recovery before the next incident arrives. [ Music ] Before we dig in, I'd love to just know a little bit about you, yourself, here. You are the Founder and Chief Security Officer of your company there. What led you to where you are today?

John Anthony Smith: What has led me to where I am at this moment? Certainly, about 14 years ago or so, I got pulled into a significant breach for a significant manufacturer that's regionally located to where I live, and that forever changed the trajectory of my professional career. That moment actually informed me, clearly, that all defensive strategies must be informed by what threat actors are able and willing to do. It also informed me, frankly, that the world was changing and breach behavior was significantly shifting and that, frankly, there needed to be some organization that could help companies recover from these types of events. So while I have had a very storied career, I would say that particular moment about 14 years ago(ish) now was a big deal. It changed my trajectory.

Dave Bittner: Yeah, just a few days ago, I was chatting with another cybersecurity professional who was really emphasizing the importance of backups when it comes to people being able to restore after a breach here. You make the point that everybody thinks their backups are going to survive, but maybe that's not always the case.

John Anthony Smith: It is definitely not always the case. As a matter of fact, in a previous podcast, I think with you, actually, I quoted a statistic from Coalition, which is a cyber liability carrier. Actually, their analyst there, named Daniel Woods, actually, can be quoted as saying that 58% of organizations who find themselves in a significant event, cyber event, discover a partial or full failure of their backup and recovery capabilities during the event itself. What I would say to you, our statistic is a little different. Our statistic actually measures could the threat actor have technically destroyed the backups in the way that they were actually orchestrated? Our statistic states that 84% of organizations do not have a survivable recovery facility. Threat actors, if they're so willing -- they can. There is a technical way, commonly, for a threat actor to destroy an organization's recovery capabilities. This is what we and Coalition, of course, see playing out in breach.

Dave Bittner: Can you take us through the types of activity that you've been seeing here? Who's largely responsible for the attacks that people are seeing these days?

John Anthony Smith: Yeah, I would certainly say at this moment, Handala, 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, certainly because of what they did in Las Vegas and what they have recently done in the UK and beyond. Scattered Spider has certainly been in the press. 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. Mainly, 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.

Dave Bittner: And they're using more off-the-shelf tools, which maybe makes it easier for them to blend in, is that fair to say?

John Anthony Smith: 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 and their VPN products are some of the most commonly targeted. Certainly, in the context of Scattered Spider and what we see play out with that group, they do commonly target Cisco AnyConnect. 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. As a 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 secure perimeter. I hate to pick on a specific product, but SonicWall comes up a lot with Akira.

Dave Bittner: Can we go through some of the tactics that you're tracking here, that you and your colleagues -- are there patterns that you're following?

John Anthony Smith: 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. 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. 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, 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 Scattered 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 privileged cred. 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. 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. Frankly, if you don't have a breach context, you couldn't even get close to what threat actors are commonly able to abuse. Some things I 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 issue device and there's not something regulating that, governing, blocking it from being able to be used that way, then the threat actors are simply going to use it. The second thing I would say is if your SaaS tools are publicly exposed, and SaaS 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 SaaS tools should also have device trust established, meaning they shouldn't be able to be logged into, except they're from users coming from an approved device and/or an approved network. Thirdly, I would say in the context of the help desk, the 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. Lastly, in that same bucket, I would just say the help desk should never, under any circumstances, 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. That is not what we commonly see organizations doing.

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

John Anthony Smith: That's a great question. In the context of once they've obviously done an MFA reset and they've gained initial access with Scattered Spider, 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 Omnissa'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 circumstances, 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 ScreenProtect that -- sorry, yeah, ScreenConnect, sorry, I think is what it's called. These tools come up a lot.

Dave Bittner: 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?

John Anthony Smith: 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 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. 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 a privileged account can log into VPN, sometimes it's because the 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 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 CyberArk 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. As a matter of fact, more than half of the breaches we work involve direct access to vCenter and direct encryption to the VMDKs.

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

John Anthony Smith: Yeah, 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 the Scattered Spider event, they just called the help desk, leveraging the documentation they obtained from ServiceNow on how to reset a privileged cred. They just got the privileged cred reset by the help desk. They logged into Cisco AnyConnect VPN, and once on the Cisco AnyConnect VPN, they opened vCenter, and they logged into vCenter with that same privileged cred across the VPN. Once they were into vCenter, they were able to encrypt all the VMDKs. Now, it gets a little more complicated than that. But how do 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 in a host of other ways, right? They can get privileged creds from Gmail, right? 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? 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 cache creds into OneDrive by default, right? 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. 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 leveraged that cred to log into vCenter, and then the rest is history. They encrypted, basically, all the servers directly at the VMDK level.

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

John Anthony Smith: Yeah, lateral movement, I guess the punchline of all of that is really just to say that lateral movement is very easy, right? If they're on the VPN, and your critical consoles, 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 all they have to do is get on the VPN, or if all they have to do is get a user, coerce a user, to allow a remote session to their endpoint with AnyDesk or TeamViewer or ScreenConnect, to then open vCenter directly from that VPN or directly from that end user's workstation, then the link 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 an 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 leak 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 things that undermine them. 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, etc., and then you put those creds in your CyberArk instance, which is still connected to the production Active Directory domain, then, effectively, vCenter and your SAN are still in the domain, right? The threat actors just have to log into your CyberArk 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 TeamViewer or AnyDesk, the leap for lateral movement and then, ultimately. to destruction is very short and, frankly, very easy. [ Music ]

Dave Bittner: We'll be right back. [ Music ] Well, before we get to data destruction, 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?

John Anthony Smith: Threat actors do commonly attempt exfiltration, right? I mean, Scattered 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 Handala breach of Stryker, or the supposed one, at least as the public media is reporting, it seems that they were able to exfil 50 terabytes of data. At least by their own reports, they exfiled 50 terabytes. We do commonly see groups attempting exfiltration, right? To actually prevent exfiltration is very, very difficult, right? 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, a 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, and then 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, and frankly, most users are simply not going to tolerate. I would say, first, an easy first step is to monitor. Figure out what your threshold is, monitor, create an alert, and then go and research those alerts timely.

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

John Anthony Smith: 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 expires. Think of more of, like, a time-lock safe, right? You can't open the safe until the timer expires, right? I mean, even if you typed in the right codes, you have to wait for the time lockout before the safe will open. The same has to be true of your backups, right? If what you mean by immutability -- what we commonly call quorum or two-person rule -- if what you mean by immutability is that one person requests a configuration change and another approves it, that is not true immutability. 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 one, two, three, four copies of the backups, then they're still effectively all vulnerable to destruction. 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, but 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, Securitas 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.

Dave Bittner: 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. Yet, when it comes down to it, they're left coming up short.

John Anthony Smith: There's a few reasons, right? If you were just to look at the industry as a whole, right, the resistance industry -- meaning the defensive, the prevention industry for cyber incidents -- 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 are still 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. As a matter of fact, organizations are only going to tolerate so much user inconvenience before they will simply start undermining all the controls, right, and then yielding the spend useless. What I would say instead is organizations really need to focus on the 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 Securitas Summa platform, the orchestration of administrative identity to reduce the blast radius, the number of things that a TA could actually destroy. Then secondarily to that, orchestrate backups with multiple copies, multiple segments, multiple infrastructures, multiple identities, multiple immutability algorithms, etc., to prevent those from being destroyed. 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. 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 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. Then lastly, they're commonly looking to their product vendors to tell them what they need to do. 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. As a 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. 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 in 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.

Dave Bittner: 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?

John Anthony Smith: 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 Fenix24 we call the RBRA, Ransomware Backup and Resiliency Assessment. It is an assessment of your recovery capability to those capabilities that are borne 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. Since backup and recoverability don't commonly survive, I would say that most tabletop exercises are not borne from reality. So firstly, I would say -- or, sorry, secondly, I would say that not only 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 breach. Lastly, I would just say that you have got to complicate IT access to systems. In our solution, Securitas Summa, 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. 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. [ Music ]

Dave Bittner: Our thanks to John Anthony Smith, Founder and Chief Security Officer at Fenix24 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 Fenix24, check out the link in our show notes or visit our website at thecyberwire.com. [ Music ]