CyberWire Daily - Walking through the anatomy of a cyberattack. [CyberWire-X]

Episode Date: April 12, 2026

What does a modern cyberattack really look like from the inside? In this CyberWire-X episode, Dave Bittner speaks with John Anthony Smith, Founder and Chief Security Officer of Fenix24. This conversation takes us step by step as an attacker breaks into a target environment – probing for weaknesses, exploiting entry points, escalating privileges, and moving laterally until they reach their objective. While the attack unfolds, listeners are privy to a behind-the-scenes commentary that reveals the tradecraft: the scripts, misconfigurations, overlooked alerts, and the moments defenders could have stopped the intrusion and, most importantly, prepared for the day through a defense that locks down data and enables a quick and full recovery. This is not a theoretical review or a highlight reel. It's a candid, technical, and eye-opening journey through the full kill chain that will reshape listeners think about detection, incident readiness, and resilience. Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyberwire Network, powered by N2K. What does a modern cyber attack actually look like from the inside? In this edition of CyberwireX, 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 trade craft behind the intrusion, the scripts, the missed alerts, and the moment's defenders could have stopped the attack. Our guide is John Anthony Smith, founder and chief security officer of Phoenix 24, bringing more than 16 years of breach response experience across health care, 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. 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? 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. And 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. You know, 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.

And you make the point that everybody thinks their backups are going to survive, but maybe that's not always the case. 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, and 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.

And so threat actors, if they're so willing, they can't. There is a technical way commonly for a threat actor to destroy organizations' recovery capabilities. And this is what we and coalition, of course, see playing out in breach. 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? Yeah, I would certainly say at this moment, Hindala, I believe it's 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?

It's 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 Hindala and also Scattered Spider. Namely, I think it's probably because they use fewer knowledge. model 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 more off-the-shelf tools, which maybe makes it easier for them to blend in. Is that fair to say? No, Akira in particular, they love to target vulnerabilities and firewalls, specifically Sonakwal. 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 Sonic Wall commonly.

Matter of fact, I would commonly say on stages that if your organization is using Sonic Wall, you should probably think twice about whether you actually truly do have a secure perimeter. And I hate to pick on a specific product. But Sonic Wall comes up a lot with Akira. Can we go through some of the tactics that you're tracking here, you and your colleagues? Are there patterns that you're following? 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 tendency. 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 health. 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 ScatterSpotter 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 Service Now instance as well. With the Service Now 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 credit. And I would just say if I were to 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 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 editors are simply going to use it. And 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 the users 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, I've 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's, and that's is not what we commonly see organizations doing. Can we talk about persistence? I mean, once they've gained access,

how do they maintain their presence there? 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.

If you, if an administrator cred can connect to Omnessa's Horizon or Citrix or your VPN, Cisco AnyConnect as an example, or even your Fortinette, Forticlint VPN, or your Palo Alto, Global Protect VPN, if a privileged Craig can even log into those things, you've got a major problem. Privileged credit 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 team viewer.

They use any desk. Certainly, if you've read much breached news, you certainly will probably know. any desk comes up a lot. There's also a product from Connectwise called ScreenProtect. Sorry, yeah, Screen Connect, sorry, I think it's what it's called. These tools come up a lot. 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? I love this question, because to, 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. 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 a privileged account can log into VIEC, 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 CyberArc 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.

Can you walk me through the process by which they elevate their own access and then shift to lateral movement? 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 a scattered spider event. They just called the help desk leveraging the documentation they obtained from service now on how to reset a privileged cred. They just got the privileged credit reset by the help desk. They logged into Cisco IneConnect VPN. Once on the Cisco Anyconnect VPN, they opened V-Center. And they logged into V-Center with that same privileged cred across the VPN.

And once they were into V-Center, 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 Octa breach that happened last, I would say to you that their CSA 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, right? They can get privileged credits 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 cash 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 on 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 cash credds into OneDrive by default, right? So it is not a significant leap for a threat actor to gain access to credits, 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 SISVAL 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 SISVAL share on active directory, harvest a cred, and then they leverage that cred to log into V-center, and then the rest is history. They encrypted basically all the servers directly at the VMDK level.

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? 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, you know, things like V-Center 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 any desk or team viewer 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 V-Center, 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 V center, et cetera, and then you put those creds in your cyber arc instance, which is still connected to the Production Act of directory domain, then effectively V center and your San are still in the domain, right? The threat actors just have to log into your cyber arc instance, your one password instance, your keeper instance, wherever it is that you're putting these crads to then harvest them and then still orchestrate destruction. So to your question, lateral movement is very easy. Once they get a crad and they're on the VPN or on Citrix or they're on an endpoint,

the TV or any desk, the leak for lateral movement and then ultimately to destruction is very short and frankly very easy. We'll be right back. Before we get to data destruction, it strikes me that there's probably an ex-filtration attempt in the middle there. How does that typically play out? What does that look like? Threatctors 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 X-fill 50-terabyte of data,

at least by their own reports, they exfilled 50 terabyte. We do commonly see groups attempting exfiltration. To actually prevent exfiltration is very, very difficult, right? If I were to call out something that an 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 shouldn't 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 ex-fill. X-Fill 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. So 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. Let's talk about the destruction of the backups themselves. I mean, how does this play out? 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, 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 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 one, two, three, four copies of the backups, then there are 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. If you really want your backups to survive, you have got to do so based on what threat actors are able and will. 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 Securitus suma, 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. 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, big they're left coming up short there's a few reasons right if you were just to look at the industry as a whole right uh the resistance industry meaning the defensive the prevention industry for cyber incident is about a 200 billion dollar industry the recovery focused portion of our industry is a 20 billion dollar 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. In matter of fact, organizations are only going to tolerate so much user inconvenience before they will simply start undermining all the controls. and 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-tasuma 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 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 VIM 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 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 award was only keeping one copy of their backups. Their synology was co-joined to the domain. Their Veem 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. Yeah. What are the takehomes for you? In terms of advice for our listeners here today, what sort of things would you recommend that they focus their attention on?

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 Phoenix 24. We call the RBRA, the ransomware backup and resiliency assessment. It is an assessment of your recovery capability to those 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 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 brief. 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, Secure to 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. 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 back up survivability and timely recoverability. I think all three of those things have to be done in concert together with excellence. 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 Phoenix 24, check out the link in our show notes or visit our website thecyberwire.com.