Zivaro joins Trace3 and is now Zivaro, a Trace3 Company! 

Combined businesses promise to deliver greater value for clients, create new opportunities for employees, and improve value within the partner ecosystem.

Thank you for watching: "The Ransomware Dilemma: Prevention Is Not Enough"

More information:

Webinar Insights:

  • Understand why EDRs and other preventive measures fall short against ransomware.
  • Learn how to enhance your defense with a comprehensive approach that includes detection, prevention, response, and recovery.
  • Discover how automation can bolster your security stance in the face of an attack.

Transcript

Sean McCroskey:
Well, thank you all so very much for taking the time to join us. Greatly appreciate it. We’re here today with the BullWall team to really discuss how best to prevent ransomware from not only a BullWall perspective, but from kind of a Zivaro-BullWall perspective. So we greatly appreciate your time. And with that, I want to do some quick introductions. As far as the folks that are on the call today, or that will be speaking or presenting during the call today, I’ll kick it off.

My name is Sean McCroskey. I am the Director of the State, Local, and Education Practice here at Zivaro. I’ve been here a little over seven years, and I’m happy to be with you all today. And then in addition to that, we have with us today Mark Campbell, who is from Global Medical Response. BullWall and Zivaro are fortunate enough to have GMR as a client today, and they are an industry leader as far as emergency and medical transportation is concerned. Mark Campbell is their CISO, and he is responsible for their overall security posture as well as global cybersecurity for the entirety of their environment. We also have on the call with us today from BullWall, Mr. Steve Hahn. Steve Hahn is the Executive Vice President of American Sales. And then in addition to that, we have Don McGraw. Don is the System Engineer Lead at BullWall. And we thank you all so much for taking the time, especially Mark. Greatly appreciate your willingness to join and talk about your experience from a BullWall perspective.

And then let’s see if we want to kind of go to… yeah, this slide. Perfect. So I wanted to share just a little perspective from kind of a Zivaro standpoint. Right. Zivaro is, you know, primarily stationed in the federal market as well as state, local, education, and commercial and healthcare. And really what we’ve seen across these verticals is just this: a 232% increase in attacks. And so it is becoming more and more prevalent, unfortunately. You may all have heard, I know some of you are in Colorado, some are in Wyoming. Most recently, the Colorado Public Defender’s Office was attacked by ransomware and is still currently down. So these are real-time scenarios that are happening, not if, but when. And what we’re seeing is the average cost recovery for these things is $4.62 million. So you can imagine what that might do to an entity like a public defender’s office, small business, state, local government, et cetera. And the interesting part is that 80% of these attacks are zero-day with zero-day methods. And so really, what we’re going to take the next 45 minutes to an hour to discuss is how we can prevent that from a BullWall standpoint. And with that, I’m going to turn it over to Steve. So thank you all very much.

Steve Hahn:
Well, thank you very much, Sean. Yeah, those numbers really jive with everything you’ll see in the industry. I encourage everyone right now to pull up a Google browser, type in “is ransomware growing?” And you’ll see definitively through a number of sources—Sophos, Gartner, whoever—that the number of successful attacks has more than doubled in the last two years. So despite all this growth in all of these great next-gen sort of preventative tools that are out there, the threat actors continue to outpace the good guys. That means just like you saw in that last stat, they’re using a variety of techniques to circumvent all of these preventative measures. The 80% are using zero-day attacks, which is very logical. It’s very easy to take a known malware exploit and turn that into a zero-day just by changing some of the code itself. And of course, EDRs are not great at picking up zero days. They really need those signatures to detect a ransomware event.

We also know that the threat actors don’t just throw ransomware at systems. They methodically come in to circumvent all of your security controls before they launch their attack. And we’re seeing that play out in the market today. So, Mark, I want to get your perspective on this as well. I have just a couple of slides here. We’re going to talk about some data, talk about what you’re seeing. Really love to get your perspective on things. And then we’re going to get into a really fun demo where we throw live ransomware at endpoints. You’re going to see how it behaves in real-time and how our solution comes in a completely unique way, not as a preventative solution, but as a rapid containment solution within milliseconds of a live ransomware outbreak. But Mark, what I saw here, we surveyed hundreds and hundreds of customers who were professionals in the cybersecurity space. Not necessarily CISOs, but professionals. And this number makes a lot of sense to me. About 80% said they’re likely to be attacked, but about 40% said they’re either extremely confident or very confident that their tools will be able to prevent such an attack. What’s your perspective here as a CISO?

Mark Campbell:
That’s an interesting chart, if you ask me. I’ve been around the business doing IT and cybersecurity for 33 years—I was 34—and personally, just my personal view, I think 40% of respondents who are confident might be a bit high. Individuals typically don’t like to admit that they are not confident. It shows in a sign of weakness, more or less. It’s kind of human nature. But as we all know, and as was mentioned a few seconds ago, that we’re living in a “not if, but when” world, and when it comes down to a breach occurring, regardless of the size, right? So, threat actors will eventually be successful at some level, you know, be that via successful phishing, staging of attack, breaking boxes in your environment, or even exfiltrating data.

And if you don’t mind, Steve, I’d like to just touch real quick on cyber insurance, just so that people understand how that kind of fits into the game here and how it plays with BullWall. And hopefully, you’re not using or having to use cyber insurance. And as a quick statement, many live under the assumption that if you have cyber insurance, you’re covered from the damages of an attack. You may have, I’d say, $15 to $20 million or more in coverage, but you could end up paying basically $2 million from a cash-out perspective, which is what the cyber insurance may pay out. So I would just be cautious with expectations that, do you need $15 to $20 million in coverage? Just understand how the cyber insurance world does work. I’ve had many conversations with other CISOs whose environments have been breached and what to expect in this. So I’d basically challenge anybody to, and I’ve done this with my cyber insurance provider, to set up a hypothetical situation with your cyber insurance provider and conduct a tabletop exercise, and you might be surprised at the outcome. And then if you’re thinking about a solution such as BullWall, or like we did with BullWall, you can kind of sell, and I would say upsell BullWall to say, this is how it would help our environment, and then look for additional discounts when it comes to how they pay out or don’t pay out.

Steve Hahn:
That’s a great point, Mark. We see that a lot. BullWall is brought in after events. In a lot of instances, it’s a little frustrating because we know we could have prevented some of the damages that occurred. But oftentimes we hear that same thing, which is essentially that they thought they recovered, from a financial perspective, from the ransomware event, from their provider. But as they got into the negotiation, they missed a caveat that said, well, you have to have MFA to every single server, every single session. You didn’t have that. Therefore, we’re not paying out. So they’re looking for those sorts of caveats. But also, even if you cover the costs of, let’s say, the ransom, your company was still down. They tend to not just encrypt your data, but they take down your infrastructure in the process of doing that. Also, the blackmail and extortion, which they tend to do now through the exfiltration of data prior to the encryption, is a second component that they try to use to get that ransom. So it’s more than just thinking, well, I’ve got backups. You’re going to take maybe weeks to recover from such a backup or using backups. I’ve got cyber insurance. Yeah, you don’t want to rely on that. It’s like saying the house burned down, and now you have money from the company to rebuild it, and you have the blueprints from the backup company to go restore it. It’s better to not have your building burnt down.

Here’s another one that’s kind of in that same vein. What’s more interesting here on the right side is, do you think your endpoint security solutions can protect you against ransomware attacks? And of course, endpoints are not the only attack vector, but they’re one of the primary attack vectors for a ransomware attack. What we’re actually seeing right now is kind of the workflow from some of the big threat actors like BlackCat, is that you actually, the threat actor, will methodically kind of get their way in through using the typical kind of cyber kill chain, and then they’re actually setting up a fresh VM. Once they’ve been able to scrape admin credentials through Mimikatz or Cobalt Strike or other tools, they’ll get admin credentials, and then they kind of do whatever they want, right? They can set up a virtual machine to launch their attack from that doesn’t have EDR products on it. But I guess, just without leading the witness here, what’s your perspective? How effective are EDRs at really stopping those zero-day attacks?

Mark Campbell:
If we just look at it from the base level, I think we all need to accept that these criminals are extremely resourceful and constantly find innovative ways to get in, right? And that’s as the graphic reflects. So they’re not always coming in through the endpoint, as you stated. And as an example, we see new articles and threat intel every day related to how generative AI is being capitalized and utilized as a rising threat factor. It’s here, it’s real-time. And again, we all realize how easy, you know, a properly crafted, let’s just be simple, phishing, email or campaign can be used to track our end users, or I should say, trick our end users or customers into clicking on the bait, right? Some of those are extremely successful. We’ve seen quite a few of those come through our environment, and we’ve been lucky enough to stop a lot of those. But we all have layers of security that can address reducing the chances of phishing emails being successful, education being a large part of that success. But people still do dumb things, right? It’s caring and feeding of those devices that they have and how they’re coming. And I’m more worried about actors attacking vectors such as VM, ESXi hosts, or RDP sessions, which threat groups such as Sprite Spider target quite often. We’ve seen that actually on our side. Not that we’ve been hit, but we’ve seen a lot of activity coming from that space. And like you said, with the kill chain, they enter the environment using elevated credentials, maybe harvested from phishing campaigns. They move laterally and continue to harvest creds data. They weaponize as they go through, and they prepare for the exploit, typically through establishing that command and control without you knowing behind the scenes. And maybe that’s done through, as you mentioned, a zero-day exploit. Then the fun really begins, right? With the goal that they have of encrypting as much as they can as fast as possible. They drop a ransom note on your desktop and wait in hopes of getting paid. But those threat actors, I mean, the goal is—it used to be crippling the victims right into submission, versus now they’re not only crippling, but they’re very successful in exfiltrating data, as we see in a lot of the headlines.

Steve Hahn:
Yeah, that’s great insight. And, folks, this is not staged here. I didn’t know his response there, but we actually have seen the same thing on the ESXi host and RDP sessions. We have a solution coming out that addresses both of those attack vectors by the wave arc. So we’re not talking about that here today, but we’ll save that time. We’ve seen the exact same thing from the threat actors this year. About 95% of all the attacks that we analyzed over the last year have used RDP, scheduled task manager, or an ESXi sort of attack as one of their main attack vectors before the ransomware is deployed. So, interesting.

All right, so what do all these companies have in common? Well, all of these companies have had the best-in-breed preventative tools that are out there, but all of them have been hit, and they’re doing the right things from a preventative side, but it’s sort of the unknown unknowns. If you know that expression that you have to worry about, right? In security, we can’t control everything. We can’t control what a person does that’s behind the firewall that can wreak havoc through either mal intent or just simply making an error or getting tricked. We may have shadow IT that we’re not aware of, that the threat actors find has happened to Microsoft here recently for their ransomware attack that they had. But IoT devices, all of these things, it’s literally impossible for cybersecurity to be 100% or to bat a thousand at all times. You need more than just prevention. You need a strategy for containment and recovery as well.

So why is ransomware still a threat? Well, preventative solutions have always been deployed, and they require that you have this kind of unreasonable amount of efficacy. You have to be 100% effective 100% of the time, 100% of your attack surface against every threat that could ever exist, zero-day or not. And we all know that’s simply not possible. The one time they get through is more than enough to deploy a ransomware payload and take down your infrastructure. So since we all know you can’t have 100% protection 100% of the time against every threat that could ever exist, you need more than just prevention. A containment strategy works, and it works really well. And Mark, you know, I know through this quote, we’ve used this in a few instances, but just kind of get your feedback on this, why you went with a containment solution rather than just relying on prevention.

Mark Campbell:
Yeah, you’re right here, Steve. Relying solely on a prevention-based strategy, it’s not a guarantee. I mean, if I could identify somewhere that’s 100% covered across the board, that’s where I want to go work probably next, just to help them out and sit around and twirl my thumbs. But that’s not the real world, right? And again, it’s not a matter of if a threat actor, you know, gets through, it’s a matter of when, regardless of the vector and how much damage is actually done to your brand ultimately. And that’s why we chose to go with BullWall. It was, you know, everybody’s looking for a silver bullet. There is no silver bullet. The silver bullet that we’re trying to build here is your entire cyber program, and BullWall for GMR just adds another significant defensive layer to GMR’s cybersecurity program. And it’s designed to stop an attack that may have penetrated our environment and leverage this solution as a last line of defense strategy to help stop the bleeding when there is an active attack.

I’d love to say that I fit in the “extremely confident” category due to my team’s expertise, the tools, policies, processes that we can provide. But it does provide in itself a false sense of security and confidence. But the bad guys and girls are known just for that unknown variable as they too are extremely smart and often their finances are better than a lot of us. When it comes down to it, our hands are tied. We can only do so much at one time. But BullWall honestly has allowed my team and me to rest a bit easier knowing that we have the ability to quickly identify a threat campaign that is active in our environment, identify that patient zero, quarantine and identify the device, disable associated credentials with that, all in a matter of milliseconds. Basically, I was questioning that at first that they could do it that fast. But actually, you’ll see in the demo that it’s the same one I received. It’s very impressive. And when that suspicious encryption activity happens, that’s when BullWall comes in and does what they do best. They save us as a last line of defense when something does sneak through and it does happen.

Steve Hahn:
That’s right. And that’s exactly how we see ourselves because we’re actually looking at what the payload does. Ransomware is always going to do the same thing. It’s always going to try to encrypt all of your file shares. So it doesn’t matter what the signature is or the behavior of it or how it gets through or what layer of prevention failed. Ultimately, when that payload’s delivered, it always does the same thing. And what we do is so simple that every time I present it to people, and you’re going to see the demo here in just a second, but every time I present it to people, the most common question is, “Why isn’t every company doing this? Why is it like every security company has this product?” It makes so much sense. We’re looking at the file shares, we’re looking at the things they’re actually after. And when we see that encryption, we contain the event.

So we’ll show you that in just a moment. Two more quick things here and then we’re onto the demo. But, whoops. We are a 24/7 automated containment solution. That means it sits in a corner. It does its thing. You don’t need hands on it. You don’t even need to be on our console that often. You can manage it mostly through the SIEM. It sits in your environment. We’ll show you that it’s an agentless solution, because we don’t care about the attack vector, we don’t have anything on the endpoints themselves. Nothing. No application at all, no agent, no sentinel, no trickery. It’s literally nothing because they’re not after the endpoints, they’re after the file shares. And that’s what we’re protecting and that’s what we’re monitoring.

So before I turn it over to Don, I wanted to show what a typical infrastructure looks like from our perspective. Of course, out here you have all these preventative layers, the perimeter layers. These are your Ciscos, and they do a great job here. Your email gateways, maybe their Proofpoint or Microsoft, your Cisco firewalls and web gateways, those sorts of things. Palo Alto Networks, and below that, you have your IT infrastructure, of course, and on these, you’ll have a variety of security tools. We see large stacks of products that are really aimed at protecting these endpoints and network devices, but also as additional ATT&CK vectors. You have personal devices, you have IoT devices. Talked to a casino here recently that was hit, and one of their initial attack vectors was a thermometer that was connected in a fish tank. That was the initial attack vector. And then, of course, they spread methodically from there.

Now, below that, you have what they’re actually after, which is the file shares. And what do I mean by file shares? Everything. We’re talking G Drive, OneDrive, SharePoint O365, your on-prem file shares, even your database servers, and we’ll show that here in just a minute. Now, when an attack happens, it really doesn’t matter how it’s delivered or where it’s delivered. We’re showing it coming in from here. It always does the same thing, and it starts encrypting this local device. But this local device has its shares mapped to the file shares themselves. So when that synchronization begins and it begins trying to encrypt the file shares themselves, it starts encrypting fast. We’re talking 50,000 files per minute, or some of these new payloads, and then also additional payloads are delivered to all of these other devices to bring them into the ATT&CK. And what you’ll find is very quickly, your entire infrastructure is down. So even if you think you have good backups and maybe they’re air-gapped and they didn’t get to them, you still have the whole challenge of rebuilding all this infrastructure and restoring these devices. The stats on this also show that whether you pay the encryption or you restore from backup, it’s kind of the same. You’re going to get about 80% of all your data recovered. You’re never going to get 100%. So that’s where we come into play.

So again, the same infrastructure, but we’ve created, as Mark said, you need defense in depth. We’ve created a whole new line of defense here. We are the last line of defense over what the ransomware is actually after. So if you think about it, we’re really, as I said, we’re not on the endpoints at all. You have EDRs and all these great products here to protect that, and they’re still absolutely necessary. We don’t compete with those at all. We are a new thing. So you install us on a couple of servers, whether those are physical servers in your environment, or cloud servers, whatever they are, and you point us, you run our application on those servers. So as we’re pointed to these file shares, we have read-only access to them. And with that read-only access, we can see when an illegitimate encryption event begins. And how do we see that? Well, since we have read-only access, we can monitor the SMB traffic, the traffic that’s already generated. Every time a file is added, moved, changed, or deleted, or encrypted. Anytime a ransomware note is left, that kicks off a file event notification, and we’re monitoring those and we can see when it’s an illegitimate encryption. Well, how do you know? Well, humans don’t encrypt at 50,000 files per minute. They don’t encrypt from the top of file structures down and from the bottom up. Those are not human behaviors. We have 28 different ways over the last eight years we’ve developed to ensure that this is an illegitimate encryption event. But when we see it, we take action.

So once again, I’ll kind of illustrate that same thing here again, it doesn’t matter how it comes in or how the payload was delivered, it begins encrypting on the local device. Once that synchronization begins, let’s say it’s the OneDrive, that synchronization begins to the file shares. We see the file event notifications kick off. We say that’s an illegitimate event, and we send either a PowerShell script command to the endpoint to shut it down. We disable that user in Active Directory and/or we can connect to the EDR tool through two-way RESTful API. We connect to all of them—CrowdStrike, SentinelOne, you name it, Microsoft Defender. And through that two-way RESTful API connection, we can take additional isolation actions.

So the slides are over. Now is kind of the fun part. I’m just going to hand it over to Don and let him show you the product in action.

Don McGraw:
Steve, if you wouldn’t mind, could you just unshare?

Steve Hahn:
Yep. All right.

Don McGraw:
All right. Can you see my screen okay now?

Steve Hahn:
Yes, sir. We got it.

Don McGraw:
Okay, so everybody, what I’m just sharing out is our ransomware containment dashboard. And from this point forward, you’re just going to hear me refer to it as RC. As we go through the demo and for the demonstrations today, I will break it into a couple of different parts. The first attack I’m going to show you is going to be on this laptop, and it’s just connected to one within my lab environment. And then for the second part, I’m just going to turn on the camera, share the entire lab, and then I’ll show you a couple more of the demos through there as well.

But before I do go through the demonstrations, I’m going to show you how we configure the different shares that we can monitor within an environment to show you how we put that protection in place. So with my RC server that I’m sharing here, I just have it sitting on a single virtual server. This sits somewhere within your environment. And as Steve was mentioning, if you prefer, you can use a physical device, you can put it on a virtual machine, you can even place it in the cloud. In terms of resources, it is pretty lightweight, so it means it’s rather easy to spin up in any environment that we have out there.

So let me take you in and show you where we actually configure the shares that we can monitor. And this is what we call the monitoring zone. And you can actually configure this to monitor and protect your on-premise file shares, your DFS namespaces, your SharePoint team sites, OneDrive, Google Drive, and depending on the Azure license that a customer may have, we can tie in additional O365 connectors. And to add the shares in, it is rather simple. We just enter them into that bar right there. They can be added one by one. Or if you already have a full listing of them, you can paste them all in here at one time and hit add, or you can import them via a CSV file. Once they’ve been added, as you guys can see, they will appear in our window right down here towards the bottom. And RC just needs to have that top-level share as it will automatically monitor everything underneath that top level. And like Steve was mentioning, we just need to have read access to the shares so that RC can perform its monitoring job.

You don’t have to worry. RC is not recursively scanning your file shares the way most endpoint solutions typically do. It’s just monitoring. It’s listening into your network broadcast and it’s listening in for those file event notifications that already exist within your environment.

So I’m going to take us back to the dashboard, and I’m going to generate some traffic so you can just see what it would look like if it was live within an environment. And over here on the left-hand side, this is what we call the live log. And this is a simulation of users performing their day-to-day type activities, such as modifying, creating, deleting, and renaming files. And while they’re performing those activities, RC is listening in for those file event notifications. Basically, as it sees somebody access a file, RC is going to go in and take a really quick look at the heuristics of that file. And again, it’s just looking to ensure that we don’t see any illegitimate encryption taking place. So as soon as RC is satisfied that everything is okay, it’s right back out again. Now, don’t worry, it’s not going to impact your users accessing the files. It will not slow them down in any way. They’ll never even notice we did it. It’s not going to have any impact on your network traffic either because everything that you see in this live log, that’s pre-existing data on your network. That means we’re also not going to add any extra overhead to your network traffic either.

I mentioned I was connected to a laptop earlier, so I’ll go ahead and bring that laptop up. And you can see there in the background that I have a share open on that laptop and my RC is monitoring that share. Anything I do—modify, create, rename, delete—RC is going to take a look at it just to show you I actually do have data in here. I’ll open up a couple of files. It’s just an image we usually have on a presentation. And regardless of the extension, every last one of my files is the same exact image.

I’m going to take one of these files and I’m going to rename the extension, just modify it, give it one like a known value, like a .lockbit. I’m not encrypting the file, nothing like that. Just changing the extension just to see how RC picks up on that change. As soon as I do hit yes here… And we can see in the background RC has already picked that change up for us. It raised my alert status up to 25%. And then down here it gave me a breakdown of exactly what it just saw. So it picked up a known bad extension. So that .lockbit that we added in there, it sees the user that changed the file is my John Doe user. And I can see the on-prem file share server that he is connected to.

Now, my event log gives me just a little bit more detail. I can still see who it is and what it was, but I do have the full path of where this file is located, and I can also see what it was renamed to. And as we all just saw, I was just playing around with one file. I didn’t touch anything else. So right now, this is a low-level alert. RC is not going to take any additional actions at this moment. It just gives the IT staff maybe a chance to go have a conversation with that user to see why they would do something like this. And since nothing else new is coming in at the moment, you can see my alert status is already dropping down. It will return to zero, and that’s exactly where we like it to be.

But I will change that for all of us. So if I reset that dashboard and then I reconnect my laptop, this time, I have an application on here that has ransomware that we have collected over time. Now, it is live ransomware, and it will deliver its payload. But of course, we clean it up a little bit. It’s not going to go where I do not want it to. And we did remove all the warming capabilities for the first demo. I’m going to use one here called DMA Locker. DMA has been out there for a number of years. It used to be one of the more devastating ones in the environment. It does encrypt up to about 10,000 files per minute. Now, like Steve was mentioning, the Contis, the LockBits, the BlackCats, those guys do around 20 to 25. There’s even a new one called ROKR that does closer to 50. The whole point is the more they modify the code, the faster they get.

What makes DMA a little bit more challenging, though? This one does not change the extensions of the files once they’re encrypted. It only changes the heuristics of it. So you could probably imagine if it got released within your environment, how many of your resources would it take to open up each and every file to figure out which ones were or maybe were not impacted by the attack itself? I will stay on the laptop for as long as I can so you can see everything take place here, but I also ask you to kind of watch behind the scenes as RC begins to detect the attack as well. I have DMA chosen as the ransomware. I’m going to go ahead and initiate the attack. As soon as I tell it, yes, we’ll see encryption beginning to come in on the right-hand side. On the left-hand side, you can see RC picked up. I’ll turn that off for everybody so hopefully everyone could hear that siren going off in the background.

You can imagine if it’s sitting in a data center in a SOC or even just in the IT admin office. It’s going to make you pay attention to that screen. You can see my alert status has hit 100%. Before we swapped over, that PC was already going down. And if I bring up my Active Directory, this is my John Doe user. Let me refresh the screen real quick. You can see my John Doe now has a down arrow which means we have disabled his account. I also updated his description to say that he was isolated by BullWall so that hopefully no one will just re-enable his account without actually taking a look at it.

Now, those are just a couple of the isolation steps that we can carry out in response to an alert like this. There are a number of different things that we can do. We can do pop-up messages on the PC. If they’re connected via VPN, we can sever that VPN session. We can disable their Wi-Fi, we can disable their SMB share rights permissions as well. The point is, we’re not limited by any means here. Everything we share with all of our customers, they are predefined PowerShell scripts, and pretty much anything you can script with PowerShell we can use as an isolation step.

But as Steve was mentioning earlier, we also have a two-way RESTful API. And what that means is we have the ability to integrate RC into existing solutions that you may already have investments in, such as maybe a SIEM solution or maybe an endpoint solution. And I’ll show you a demo on that here shortly.

Now, if we look at this attack and we take a look at the breakdown that RC identified, it told us that DMA, we had a mismatch on heuristics. Remember, it doesn’t change the extensions. We can see that John was the attacker, the on-prem file share server. He’s connected to my event logs, identifying those files that got targeted. That triggered the alert to 100% to begin with. But I can also see some of the commands behind the scenes here that RC was executing to perform the isolation of that end user and of that device.

Now, for everybody to know, RC, the way it works is it has to see a small amount of encryption before it can react. But as we all just saw, RC’s reaction time is pretty quick. So the number of files that may get impacted, it’s kept to a minimum—somewhere between maybe ten and fifty files—before we’ll shut that user down. And that user, John, is going to have a bad day. He does have encrypted data on his local PC and we did disable his account. But you know, the worst-case scenario is you might have to reimage that device, potentially replace it. However, the rest of your users, maybe more important, the rest of your data is still very much intact and it is up and running. And that is the continuity that RC brings you here. It allows us to isolate that troublesome user, or if you’re being attacked by multiple bad actors at the same time, we will isolate each and every one of them at the same time. While everybody else within your environment, they’re up and running. It’s business as usual for them. They’ll never even know an attack took place.

Now, with everything we have to be able to recover. So if we come into our recovery here, this is the attack that we just captured. And you may notice that we have about 460 files. That is not how many were encrypted, but how many were in play across the user base at the time of the attack. But I do know from the breakdown of the dashboard that John was my attacker. So if I go ahead and filter on John, you can see that now. I only have 20 files that were encrypted. All I have to do is export that into a CSV, go to my backup solution, help recover. We can get John up and running rather quickly.

And with everything out there, everybody has to report. Nowadays, RC automatically generates a minor incident report for you. This report is fully customizable. We can add company logos and move fields around. What I believe is more important is 99% of the report is filled out for you. The only thing that is not is our summary section here, but with the breakdown that the dashboard gives us, we have the details required to fill out that summary. So we can enter that data here, but we have the start as well as the stop time of the alert. I can see the number of endpoints attacked, how many files were encrypted, who initiated the attack, the IP of their machine. I have a summary of the files that were also encrypted. But if I go to the appendix, I have a full listing of those files that were encrypted. So once again, fill out that summary from the breakdown, ship that report out to whoever needs a copy of it, and then we get to focus on the more important stuff—that is, cleaning up the environment and helping get our user back up and running as quickly as possible.

All I’m doing right now is I’m moving my dashboard into my lab environment. I’m going to turn my lab on in just a second. Steve, if you wouldn’t mind, could you let me know when you can see my lab and I will do a couple more through there.

Steve Hahn:
All right, Don, we can see you. Thank you, sir.

Don McGraw:
So, hello, everybody. So I’ve got my lab or my dashboard pushed to the back here. I did stop the simulated traffic from coming in. However, I do have RC monitoring all my different shares in the background sitting here with me as well, and I’ll introduce them in a second. When it comes to your shares, RC can perform a couple of different things. Number one, we can put kill switches in place, and that’s exactly what I did for John Doe. Or if you have sensitive shares, maybe don’t want us to shut something down but just notify you. Of course, we can customize it to meet your needs with that as well.

Speaking of monitoring, let me introduce the other laptops real quick. My first laptop is protected by SentinelOne. It’s connected to another on-prem file share that my RC is monitoring in the background. My second laptop is protected by McAfee. This is connected to my Google Drive, and my RC is monitoring that Google Drive environment in the background. And my final device is protected by Microsoft Defender. This is my O365 environment, and my RC is monitoring that O365 environment in the background as well.

So I’ll go ahead and start from the end and move in. So when it comes to the cloud, it doesn’t matter if it’s O365 or if it’s Google. Again, RC is not recursively scanning your file shares. However, every 10 seconds it is looking at the delta changes that are coming in to see if there are any action that RC needs to take on that device. I’m going to run one called Babuk. It came out about two years ago. It was used against the Washington Metropolitan Police Department. It does encrypt up to about 8,000 files per minute. It does change the extensions to an .nist extension. So we’re going to watch Defender pick up on the attack as well as RC.

I have my device set up with my OneDrive pretty much like everybody else. I have a local copy, I synchronize it into the cloud, and that is exactly where RC is monitoring it. I am in a lab environment, which means my lab network is a little bit slower than most out there, which means my synchronization process could be between 30 to 60 seconds before RC sees the data, analyzes it, and then determines if there’s any action that needs to take. So I’m going to swap to a device as we run the attack. So I have my OneDrive open here, I have the same attack software, and then I’ll show you that I have Defender up and running. I have all green check marks as I’m fine, nothing to worry about.

Before I launch, once again, I’ll open a file just to show you I do have actual data in here, same as the other. If you notice down here at the bottom it says we have 25 items in our folder here. I have Babuk chosen. I’m going to go ahead and initiate the attack. As soon as I do, we’ll see encryption on the left-hand side. If you look to my OneDrive, you can see I have files now being encrypted, given the .nist extension from top all the way down to the bottom. You might also notice now I have 27 files, which means a couple of new ones have been added. It does need to synchronize into the cloud. I just noticed that it just continued that process, so it’s already making its way up.

So keep in mind I’ve already delivered the attack. The local hard drive is already being encrypted. Now it’s spreading and making its way into the cloud. And if I bring up Defender, it still tells me everything is fine, I’m protected, I don’t have anything I need to worry about here. Well, with that being said, let’s take a look at that OneDrive then. So we have a new file, CryptoInfo.txt. And a little bit further down here we have another one called HowToRestore. I open up HowToRestore. That’s your basic ransomware note that’s been left behind. Of our 28 different detection sensors that we have within RC, one of them specifically looks for a buildup of these files. We will isolate a user just on that information alone.

I can also come up and take a look at this other one, CryptoInfo. That is a secondary note they like to leave behind. Of course, they want to make sure that you know how to reach out and contact them so that they can receive a payment. And then finally, let’s see if we can open up one of our .nists. I’m not quick enough. RC has already caught this attack. If I swap back to our view, you can see the PC is in the process of shutting down. I did turn the alert of the siren off, and then RC has pretty much lit up. So the breakdown that RC has given us for this attack is it picked up on some known bad extensions that were coming in. We’re also going to be seeing some known bad artifacts in a minute. So those known bad extensions were the .nists that were created. There’s the known bad artifacts, the ransomware notes that are being left behind. There’s the O365 account that was hijacked to perform the attack. Again, the event log identifies the files that got targeted. That triggered my alert. And I can also see the commands we’re performing to isolate that user within a minute or two.

If you go back into recovery, that report is available for you. Just use the breakdown from the dashboard to fill out that summary. Don’t forget we’re also telling you exactly what files that user has encrypted so you can easily recover those from your backup solution.

Now I’ll reset that dashboard one more time and then we’ll go over to our Google device here. Now on this device, again, we’re not recursively scanning anything. I’m going to run one that everybody’s heard about—WannaCry. It’s been out there for a number of years. Everybody should have definitions and signatures in place to stop this attack. So we’re going to see how McAfee picks up on it and again, how RC picks up on it as well. And the same with Google Drive and O365. I have a local copy of my G Drive open. I have to synchronize that into the cloud, and that is exactly where RC is monitoring. So I’ll swap and show you the device as we run the attack.

Now, here’s my Google Drive open in the background, same attack software. Before I launch, there’s our McAfee tells you everything is fine, I look good. And before we do anything, we’ll take a look over here and open up a couple just to show you again, I really do have data in here. And again, it doesn’t matter what extension I am opening up. So we’re going to go ahead and choose WannaCry as our attack, initiate that attack. As soon as I do, we’ll begin to see encryption on the left-hand side. If you look at my Google Drive now, you can see my files are now being encrypted, given that WannaCry extension from the top all the way down to the bottom. And as I was mentioning, same as O365, it has to synchronize into the cloud. So if I click on the little icon in systrate, you can see those files are already making their way into the cloud.

And remember, I’ve already delivered the attack. The local hard drive is being encrypted. It’s spreading, it’s making its way into the cloud. So if I bring up McAfee again, everything still looks pretty good. So let’s go ahead and take a look at that Google Drive and see what we have going on in the slide there. So again, we have another CryptoInfo. Open that, that’s that ransomware note that’s been left behind. So we’re picking up on the attacks. You’re going to see a ransom note that’s going to be left in each and every one of your file folders out there. Go ahead and close that and see if we can go ahead and open up one of our WannaCrys. Usually, you can open up the application easily. Now I’m trying to open it up, and you can see nothing but garbletext. Not fast enough. RC has already picked this attack up and is shutting that PC down. I swap back to our view. Our dashboard’s lit up, and the PC is going down at the same exact time.

The breakdown that we’re getting on this attack from RC is it’s picked up on a mismatch on heuristics with the WannaCry attack. I’m also picking up on some known bad extensions, such as the WannaCry, and known bad artifacts that are coming in at the same time. I can see the Google Drive account that was used to initiate the attack. Again, the files targeted that triggered the alert and the commands RC executed to isolate that user and that device. And like I said, within a minute or two, if you go into recovery, that report is available. We just use the breakdown here to fill out that summary and ship it out. But more importantly, we’re going to tell you exactly what account or what files that user has encrypted as well.

So I’m going to reset the dashboard one more time. And the last attack is always just a little bit more fun because we do it a little bit differently. I’m going to run the attack differently. I’m also going to run the isolation differently. So I’m not going to use that same attack software. I’m just going to use our iPhone charging cable. It looks like your standard iPhone charging cable. Pretty much it is. It just has ransomware attached so nobody will use it. But there is a chip at the end of this cable, and the criminals have the ability to program that chip. They do a lot of different things, but nowadays it’s become very popular for them to put ransomware on here, and they use delay switches. And all that means to you and me is when you plug it in, it won’t deliver the payload immediately. It’s going to wait until after hours. Maybe you’ve gone home for the day, might be the weekend or even the holidays, when you usually have fewer eyes watching your environment. Believe it or not, these cables are making their way out there in several different ways, too. Criminals are just leaving them left behind. People see an abandoned cable, they take it home with them. The criminals are also going to the trade shows where the vendors have the booth set up with all the free giveaways on the tables. They’re walking by, dropping a bunch of these, so don’t pick them up. And then finally, they are reselling phones on the Internet, and the criminals are shrink-wrapping these and sending them out. Customers have no idea they’ve got a ransomware cable.

A lot of customers will tell us that they’re protected because they don’t allow external storage devices. In most cases, they’d be correct. However, that is not picked up as an external storage device. It’s a human interface device, like a keyboard or a mouse, so it will allow it to connect. I can plug it into the wall adapter, charges my phone perfectly fine. I can plug it into this PC and into my phone, and I can see my photos without any issues whatsoever. But it will deliver that payload at the same exact time. So I’m going to run the attack a little bit differently. I’m also going to run the isolation differently as well. So remember the two-way RESTful API I mentioned earlier? We integrated RC with SentinelOne. And what that means is instead of me doing PowerShell scripts to shut it down like I did the other devices, RC will send a command to the SentinelOne console manager letting them know the device is under attack and it’s time for SentinelOne to quarantine that device. Most endpoint solutions will not shut a PC down. They’ll disconnect it from the network resources. That way, the user can’t do anything and connect anything anymore. And if they try to reboot that device and bring it back up, that SentinelOne agent still has them disconnected from those network resources. And if they try to go log in somewhere else, don’t forget, we disable their AD account as well. They’re not going to get back on. They’re going to speak to somebody at the help desk. I’m going to swap and show you that device. SentinelOne is a NextGen AV solution. It’s a pretty good one. We use it ourselves here at BullWall. But this attack method just shows you the challenges that any of the NextGen AV solutions are facing in the wild today.

I do have SentinelOne running, not because of my background. If I bring it up, it tells you my overall status is secure. It does show you that I’m online just to show you it is a valid copy of SentinelOne. I do have my license and key everything in here, and I am connected to another on-prem file share. I’m going to open it just to show you I have access. I can get to my file share and navigate around, and that will become important in just a moment. I’m going to swap back to this view. Take our cable. I’m just going to plug it into this device. As soon as I do, a little command prompt jumps up on that PC. And then in the background. There we go. Then in the background, RC is already starting to pick this attack up as it’s coming in, and it’s starting to build us a little bit of a breakdown of exactly what it’s seeing. Now, you may have noticed I didn’t have to click on anything. I didn’t have to hit any keystrokes. Simply plugging that cable in the attack took off. And with the breakdown of RC, we are picking up on some known bad artifacts at the moment as they’re coming in. I can also see my user that initiated the attack as my Jake versus the John I used for the first demo. I can see the on-prem file share server he’s connected to. I can see the files that got targeted, that triggered my alert to 100%, and the commands RC is executing behind the scenes. And one last time, within a couple of minutes, if I go into recovery, what is available, we just use the breakdown here to fill out the summary. Then that report is available to be sent out.

Most companies have like 72 hours to ship that report out. With RC, you can be done in less than ten minutes. But more importantly, with 100% accuracy. We are going to identify exactly what files that user has encrypted so you can easily recover those from your backup solution. Now, an integration with the endpoint solution, we’re at the mercy of that endpoint on how fast they will perform the isolation. I’ve seen with SentinelOne, and especially in my lab environment, it’s a little bit slower. It takes anywhere between, it takes 60 seconds or a little bit longer before it isolates that device. I’ve seen others—CrowdStrike, Sophos, Defender ATP, and a few more—they usually perform that isolation within 20 to 30 seconds. It just depends on the endpoint solution itself. That’s why usually when we do integrations, we recommend doing PowerShell as well as the integration with the endpoint. That way, one way or another, RC is going to capture it, and we are going to shut it down.

So I’ll get ready to swap over to our device as we wait for that command to come through so I can tell my lab is running just a little bit slower this morning. We are waiting for our SentinelOne console manager to send us the command identifying that this device has now been isolated and it has been disconnected from the network. Another thing on this, when it comes to doing this attack on this device is not only am I actually running the attack and RC is picking it up, SentinelOne has not detected this attack at all. So it was RC telling SentinelOne to isolate it versus SentinelOne picking up the ransomware, isolating it itself.

Now you can see the command finally came through. It tells you I’m no longer secure, that I have now been disconnected from the network. And remember the on-prem file share? I go ahead and click on that one now. I no longer have access to it. I just have a spinning cursor on my device itself. So as I mentioned earlier, this user can reboot this device if they want to and bring it up. That SentinelOne agent will still have them disconnected so they won’t be able to access any resources, and we disable that account so they can’t log in anywhere else.

I’ve finished up my demos. I do appreciate your time. I’m going to turn it back over to Steve and the team, but I will be around to help answer any questions that you may have as well. Thank you.

Steve Hahn:
Yeah, just one point to note there, as you looked at that isolation through SentinelOne, we can send both PowerShell script and a command, a two-way RESTful API command to the endpoint security agent to take those isolation orders. And typically, our recommendation would be both. The reason being is threat actors often disable the EDR solution or come at it from a non-EDR enabled product. We’ve seen that with servers that they’re coming in on and hitting and deploying the payload from there. So it’s actually good to potentially use both.

One other thing, we’ve picked up a lot of customers in the last couple of years. Over 1,000 in the last couple of years. Hundreds of those have been hit successfully with ransomware. We have stopped every single one of those attacks. When our solution is up and running and in kill switch mode, we did have a customer that was just deploying it. We weren’t in containment mode yet. We did alert on it and save most of their infrastructure as well. But when our solution is up and running, fully deployed, we’ve contained literally hundreds of attacks and have yet to be circumvented. As Mark said, there’s no 100% solution there, and we’re not claiming that, but pretty proud of our efforts to contain those events.

With that, I’ll see if there are any questions. That’s Mark or Caitlin that can let us know.

Caitlin:
Yeah, I’d be happy to kind of shepherd that process. I have a quick question for you. Speaking of fully deployed, what does the implementation process look like from a BullWall perspective?

Steve Hahn:
Yeah, typically it’s going to be different for every environment. Mark has a pretty complex environment. The larger companies will have lots of different shares, but really the RC server can be deployed on as many devices as you want. We don’t charge a license fee per RC console, if you will. So you deploy those consoles, you begin mapping the drives, the shared drives, and we begin monitoring. There could be some other things we do with you guys like setting up honeypots and things like that to protect some of your other critical infrastructure. But from there, our system runs in machine learning mode. And as it begins to kind of develop a baseline for what is good encryption and normal, what your normal environment looks like, the number of alerts that we get goes down, and eventually, the number of containment level alerts goes to zero. And then we have our baseline, and then we can go into kill switch mode, which means now our solution is fully deployed, we can now send isolation commands to contain those events. That process typically goes about six weeks is the average for running that machine learning. It really depends on how much interaction we’re getting from the various teams and how much whitelisting and things like that we need to do. But it’s pretty simple and pretty straightforward compared to a lot of other technologies to deploy.

Caitlin:
Thanks for that, Steve.

Steve Hahn:
Sure.

Caitlin:
Yeah. And Steve mentioned if there’s anybody out there that would care to ask a question, you can either put that in the chat or go off mute and ask it personally if you’d like.

Steve Hahn:
I’ll hit a really common one. Like I said, every time I sort of get the question of, well, why isn’t everyone else doing this? Or who else does this? This is a true statement. No one else is doing this. You can call Gartner. They’ll tell you the same thing. We’ve shown it to Gartner privately. Gartner said that it was one of the best demos they’d seen in about four years. They’ll tell you that there’s no one else doing this. There are some other ransomware-focused solutions that aren’t focused so much on the endpoint, but they’re not doing this kind of containment thing. There’s one that says, well, they’ll get the decryption key, and they say they do that by putting an agent on every single endpoint. And if the event began from there, they ingest the key, and they can provide you that key later. I have no idea how effective it is. It sounds like a neat solution. I just say the difference there is we don’t have an agent on the endpoint. We don’t care about the endpoints. Neither really do you. At the end of the day, what you care about is protecting your file shares. If they’ve already encrypted everything and you get the decryption key, to me, that’s a lot of extra effort. Your infrastructure is down and now you’re trying to use the decryption key the same as if you paid the ransom. You have that key, so you’ll save some money. But your infrastructure did get encrypted at that point, and you’re going to have to begin the recovery process. So there are some pros and cons to both approaches, I’m sure, but no one else is doing this kind of containment approach.

If there are any other questions, I’ll just say what you saw today is you’re looking at it. It’s in our lab environment. And Mark, I’ll come to you for any final comments here in a second. If you want to see this in your own environment, and you think, well, yeah, that’s great, but, you know, I have better security than you probably have in your lab. I challenge folks to reach out to us and we’ll do an assessment. We’ll bring essentially six ransomware packages in. We’ll throw them at your endpoint, of course, in a controlled environment. We’ll map it to some dummy file shares. So we’re encrypting dummy data and that kind of thing. But you can, and I’ve seen it, people put their entire SOC team in there and they’re watching everything that’s happening and saying, all right, Bob, do you see what’s happening? Or did you know the endpoints every time are going to be encrypted by zero-day events? And then it does every time in every customer’s assessment end up encrypting the file shares. We’ll show you, even in that scenario, how our solution comes into place and how quickly we can contain that event, but certainly love to do those sorts of assessment tests.

And last thing I’ll say before I reach over to Mark is Mark brought up insurance earlier. We hit on that one for a minute. We talked about the payouts. One other thing we’ve done here is we actually surveyed our customers, and about 30% of the respondents—like I said, we have a lot of customers—about 30% of the respondents said that they were either able to stave off a price increase with their cyber insurer, they were able to get a discount, or they were able to get insurance when they couldn’t before. So no price increases for about 30%. The other 70%, we don’t necessarily know if they even tried. But what I would say is, again, no guarantees there, but I would encourage folks, once you’ve deployed our solution, to go back and negotiate with the insurer and say, pen test us. Let’s see. Ransomware is the most expensive event you can pay out on. Let’s see if you can get past us. No one has gotten past us so far. Customers have even brought on their own pen testers to try to see if they can break our containment. And to date, that hasn’t happened, whether it’s an insurer or some of the best pen testing companies out there that a lot of our enterprise customers employ to say, all right, yeah, cool. You’re stopping the ransomware you bring. But these guys have some really nasty ransomware. Let’s see if you can stop it. At the end of the day, all ransomware does the same thing. It encrypts the file shares. So when we see that, we contain it. So, Mark, any closing comments from you?

Mark Campbell:
Oh, you’re on mute.

Steve Hahn:
Oh, you’re on mute, Mark.

Mark Campbell:
Sorry, that was a test there. So I was itching my eyebrow earlier. I wasn’t really raising my hand. But in closing, this is one of those things where I’m not easy to get on, basically, Mike, to provide support for a solution provider. But for those that do what they say they’re going to do and have proven that they can save an environment and it works, I don’t mind doing that. And this is one of the situations where teaming up with Zivaro and BullWall, it’s a no-brainer. When I saw I did, I can’t say that when I sold this to my executive team, including my CEO, it was the quickest pitch I ever had to do in my career—seven minutes. And they said it was a no-brainer. They all voted done. So it brings significant value to your environment.

Steve Hahn:
And Mark, if we remember correctly, I think you said, or your team said, we’re going to give you about 15 minutes here. We don’t have a lot of time, and we’ll probably end this call in about 15 minutes. I think that call, the first one, lasted about an hour and a half. You guys ended up canceling several other meetings after seeing it.

Mark Campbell:
Yes, again, if you’ve got the ability to bring on a solution like this to further strengthen your cyber program, don’t hesitate. Do it because it can be that lifesaving measure that you put in place that will help you out in the future.

Steve Hahn:
Well, with that, everyone, thank you so much for attending. We’re exactly on the hour. Appreciate everyone’s time. Please reach out to your Zivaro folks for additional questions or comments. And have a great day. Thank you all.