- Host: Steve Stedman / Shannon Lindsay
- Topic: Ransomware
- Recording Date: May 16, 2025
- Listen on Spotify!
Stedman SQL Podcast Season 2 Episode 17 Ransomware
In this episode of the SQL Server Podcast by Stedman Solutions, we take a close look at ransomware—a dangerous form of malware that encrypts your data and demands payment for its release. We explain how ransomware works, why it’s a growing threat to SQL Server environments, and what the real consequences are for businesses that aren’t properly protected.
We’ll walk through real-world examples of ransomware attacks, explore why SQL Servers are often prime targets, and reveal the hidden costs that come with recovery—even if the ransom is paid. You’ll learn why standard backups are often not enough, and how a poorly tested backup plan can actually leave you worse off.
We also cover proven strategies to prevent ransomware from compromising your systems, from strengthening your backups to implementing proactive monitoring and alerting. You’ll learn how Database Health Monitor can help detect early warning signs, and how our SQL Server Managed Services provide expert, around-the-clock protection from threats like ransomware.
Whether you’re a DBA, an IT manager, or a business owner responsible for data, this episode will give you a clear roadmap for defending your SQL Server environment from one of today’s most serious cybersecurity threats.
Watch Episode 17 Here
Podcast Transcript
Steve Stedman 00:16
Hey everyone, and welcome to this week’s podcast episode on the Stedman SQL Podcast. I’m Steve Stedman, and Shannon Lindsay is with me today as my co host. Hi, Shannon. This is season two, Episode 17, or our 30th episode so far in last two years. Welcome to the show.
Shannon Lindsay 00:37
Yeah. Welcome everyone.
Steve Stedman 00:41
Quick overview of what we’re going to cover today. We’re going to talk about ransomware threats for SQL Server. And this is one of those things that is a real serious, serious thing you need to plan for. There’s some pretty real world impacts on ransomware, and unfortunately, there’s a lot of money being made by these ransomware people, so they keep doing it. We’ve got quite a bit of experience preventing being putting people in a position where they can be ready if they’re hit with ransomware, but we’ve also got a lot of experience where people have contacted us after the fact that they’ve been hit with ransomware, and that’s usually a really tough spot to deal with at that point. So let’s jump into it first. Let’s talk about understanding ransomware and how it impacts SQL Server. So first, what is ransomware? And what it is it’s your old style virus, like the computer viruses have been around since we’ve had computers, I think, but it gets into your system and it goes through and finds everything that you need, and it encrypts it, and it will make it so your entire SQL Server, all your backups, all your data files and things are encrypted, putting you in a position where you can’t get them back unless you pay the ransom. What I hate to see when anybody ever has to pay a ransom to ransomware, so we do what we can to help prepare and prep so that nobody’s ever in that position. Part of what a lot of people say, Well, I’m good. I’ve got backups. I’ll just go use my backups. Well, oftentimes what the ransomware will do is they’ll get on that server, it’ll be there for a while before you know about it, and it will go and encrypt all of the backups first, and then the very last thing it does is it’ll shut down your SQL Server and encrypt your data and log files. There’s been a lot of different exploits out there that have over the last few years, and I’ve seen some pretty, pretty scary situations.
Shannon Lindsay 02:44
yeah, especially some real world examples. Not only are you talking data loss and the cost of downtime, but the financial costs also the ransoms that go anywhere from 50,000 to 350,000.
Steve Stedman 03:04
Or even more. I mean, that’s one of those that a lot of the time, the ransomware was being paid with Bitcoin. And when Bitcoin was going up rapidly, one Bitcoin or 10 Bitcoins, or whatever the ransom was, sometimes ended up being a lot more money than what they originally intended. An example of this, we got a call a couple years ago from a regional hospital, and they had lost all of their patient data due to ransomware. They had been hit hard. They had a lot of people involved in trying to rebuild all their desktop computers and their servers and everything to get it going. And they came to us and said, Well, what can you do to help us? And I spent a couple of hours taking a look at it. And unfortunately, the outcome we had there was, there was nothing we could do to help them. They had 100,000 plus patients, probably in their system that they lost all record of every visit that those patients had ever had to that hospital? Imagine if you have a surgery scheduled for tomorrow, and you go in and they say, Hi, what’s your name and tell us why you’re here. And you would probably expect, if you’ve got a surgery scheduled, that they would know about it, but everything was lost from appointments to bookings to your history to everything like that, and they were at a point where they just had to go get the INSTALL disk for the software they were using to track their patient information, install it from scratch with an empty database, and just start filling it in over time. It was a really, really bad scenario for that regional hospital.
Shannon Lindsay 04:43
Why would SQL Servers be a prime target for ransomware?
Steve Stedman 04:47
Well, a big part of it is that that’s your critical data. I think that, I mean, there’s a lot of different servers in different environments that if you lose you. Maybe you can rebuild them. Maybe you rebuild your mail server and you get it back and you lose some mail, and it might not be the end of the world, but with SQL Server being that location that’s going to hold that critical data, yeah, it’s prime target, you can rebuild your other servers easier, but you can’t get that data back very well unless you’ve got some backup that has not been caught, not been hit with the ransomware.
Shannon Lindsay 05:25
What would you say are some key strategies that you can do to protect your SQL Server?
Steve Stedman 05:30
First off, you want to assume that you will be hit with ransomware at some point, and no matter how good of a DBA you are or system administrator, everything you do to protect that server, there’s going to be some other server in your environment that somebody didn’t know about that gets hit with ransomware and opens the door to let something into your SQL Server. So just start by assuming that you are going to be hit, and that worst case scenario is when you are hit, how are you going to fix things? How are you going to get things back and running again. The way to do that is really with regularly tested backups and having off site or immutable storage. I really like off site, like Azure Blob Storage or Amazon storage or, I mean, working with one client a couple years ago, they had a weekly backup that they would put on a removable USB drive and take just throw one of the guys would throw it in their backpack and take it home with them. Every day. Worked with other clients, where once a week, they would take a full backup and put it in a safe deposit box, because their office was right next to the bank where they had the safe deposit box available. But with this, the key is having backups that you that the bad guys can’t get at and can’t destroy. And if you say, Oh, well, I’ve got my backups copied to the network drive, well, if your SQL Server has the ability to write to that network drive, the bad guys probably will end up having that same ability to write to that network drive and destroy those backups before you have a chance to even know that they’re on your system.
Shannon Lindsay 07:04
How would you secure your environment? You know, using things like TD and stuff?
Steve Stedman 07:11
Well, first I would start with keeping up to date on SQL Server and operating system patches and vulnerability patching with that most of the time we’ve seen ransomware has been that some system on or some system in their network wasn’t being patched appropriately. So number one, get it secure to do what you can to prevent things out. Follow the best practices for securing your SQL Server, where you set up limited access and restrict the permissions, make sure you’ve got the right file permissions and that like website users that systems are using don’t have full system administrator access, for instance. And then another one is using transparent data encryption for the data in log files and the backups as well. Now TDE, we’re going to talk about that in next week’s episode. TDE is not going to prevent or help you recover your data, but what it will do is it will make it so that if the ransomware people try and steal that data as part of their exploit that you know that they won’t be able to get that data and run it in their environment if all of those are encrypted backups to begin with. So the other thing is doing proactive monitoring using tools like our database health monitor, or our daily monitoring that we do for our managed services clients, where we will detect unusual activity, looking at things like different size backups, setting up alerts for failed backups or unauthorized access attempts, basically being able to know The status and health of that server, so that when you’re at the point that something is impacting your system, you know about it before it takes your system down. The other side of this, I think, is really important, is just having a ransomware aware culture. A lot of companies now are required. We do this where we have security training regularly for our team, our employees, and with that, it just goes over some of those basic social engineering things and training people so that they’re more aware of what could be happening that they could be doing to let some bad guy, bad person into the system. So basically, just be aware that there’s always someone out there trying to get you, and that training that you may be forced to do by your employer is a good thing for everyone, not just for you, but for everyone in the company. So they everyone’s doing what they can to reduce it, but from the SQL Server. The side of things, just assume you will be hit with ransomware at some point, and have a plan that if your entire SQL Server is compromised or destroyed, how are you going to get that back?
Shannon Lindsay 10:08
So I guess when it comes down to making that plan, what would you say are some of the first steps that you could do?
Steve Stedman 10:16
Well, the first step I’ve seen a lot of people do, and I’ve kind of joked about this a little bit, but it’s not, it’s not it’s kind of a sad joke. Is their hit and they go to Google and how do I and search on, how do I recover from my day, from how do I restore my backups? Then they find out their backups don’t work. But the key here is really practice, practice, practice, and documenting it and building what we often call a playbook. The playbook is like a script that outlines this is what you’re going to do. It may not be scripted down to the exact word, but it’ll cover things like go to your safe deposit box and grab last week’s full backup, or go to your Azure Blob Storage and grab those last immutable full backups, bring them down and do things like restoring them, documenting the whole process and testing it as you go, so that you’re never in a position where you’re having to just kind of figure it out for the first time, practice recovery drills to ensure minimum downtime. One client we worked with few years ago, we had, once a week, we would have a tabletop disaster recovery scenario where it was during a meeting. We take about 15 minutes of that meeting time, and I would present here’s a scenario, and everything from ransomware to failed drives to other things like that. And then the whole team would verbally work through it. Nobody would actually be online doing the restores, but they would verbally work through it so that it was fresh in their mind that if that disaster hit, you’d be ready to recover from it. So practice it with, actually, real restores. But also practice it on, like, tabletop discussion, yeah.
Shannon Lindsay 11:53
So, like, when you’re in elementary school and you do the practice fire drills or the earthquake drills,
Steve Stedman 12:00
Oh, yeah. And, you know, I guess I’m, I’m fortunate that I never had to, I never experienced a real fire or a real or a real earthquake and when I was going to school. But yeah, we, we practice those, we practice those things. And we every, we knew everyone was ready for it. So yeah, just like that. So our approach to our to ransomware recovery is that if you’ve been hit with ransomware and you’re not prepared, it’s probably too late. You’re in a world of hurt at that point. So it’s all about being proactive, ahead of time, before you’re hit with ransomware, assess the backup integrity and make sure that you’ve got things so that if you are hit, you’re gonna be able to recover practice restoring the databases without paying the ransom when possible. One scenario that I’ve seen more than once with people who’ve contacted me after they’ve been hit with ransomware is they’re giant data files. I mean, if you’ve got a data file that’s like a terabyte or several terabytes in size, apparently these ransomware developers did not do the best job doing testing and QA on them, and they have a lot of problems decrypting those really big files. So even if you pay the ransom, oftentimes you will not get your bigger database files back. We had one example of this where we had worked with a client I’d really pushed for off Site Backups. They got hit with ransomware. It was a small manufacturing company, and it took them about an hour. They called me as soon as they got hit. We got on the phone, worked it together, and we were able to pull in their off site backup, and within about an hour, get them back up and running with their business continuity plan. So basically, you want to collaborate and have people available so that when you do get hit, that you’ve got the right team in place in order to deal with it in order to get things running again. What’s one way that you could test a backup? Well, I think the best way for testing it is to restore it. There’s the one of my backup classes. I talk about Schroedinger as backup, where it’s from a physics example of children’s cat, where it’s theorized that there’s a whole big thing around it, that the cat is neither is either alive or dead in a box, obviously kind of brutal there. But the deal is, your backup is could be bad, could be good. You have no idea until you’ve actually tested it and proved that it works. And if you run backups and you don’t regularly test those, you can be in a position where doing that restore might something might not be working the way you think it is. I’ve had some people contact me and said, Well, we thought we had backups running, but it looks like some somebody disabled the job 18 months ago and there hasn’t been a backup. Since then. So being able the only way to know for sure that you’ve got good backups is to actually go and test those once in a while.
Shannon Lindsay 15:08
What if those backups are encrypted?
Steve Stedman 15:12
Okay, that’s an interesting question, because two angles on that if those backups are encrypted, as in, encrypted by ransomware, where they’re already been hit, well, you’re out of luck. You might get them back if you pay the ransom. You might not, but if they’re encrypted with something like TDE or transparent data encryption, well you just need to make sure you have the right certificates and pieces in place in order to be able to get those back, get them restored. And that’s where testing will make sure that you’ve got everything in place with that. I think that we’ve got some resources available for this that I want to share. We have a free ransomware awareness course. This is something I built four or five years ago, and after working with a few clients that had been hit with ransomware, the ransomware people just made me so angry that I wanted to do everything I could to get the word out there on how to prepare for that. That’s why we’re doing this podcast episode. And we’ve got this free ransomware class available at Https://stedman.us/ransomware and that’s that’ll redirect you to our teachable courses, where we normally sell classes there, but the ransomware one, we give it away totally free, because I think it’s so important to get the word out. We also have a backup and recovery class. It’s a pay class. It’s not an awful lot of money, but it will help you prepare for ransomware as well. That’s available at stedman.us/backup and that’s one of those things that the backup class focuses more on the recovery side than the straight backup. Because I think everyone with can probably figure out how to run a backup, but being able to figure out, how does that, how did that back? Did the backup work correctly? And how am I going to restore it? How am I going to get it back in place when we do get hit? That’s the important part. And then we also have an IT managers white paper available that’s available on Stedman solutions.com in our white paper section, and it’s the IT managers white paper, and part of the section of that talks about preparing for ransomware as well.
Shannon Lindsay 17:18
So what would you say are some of the key takeaways?
Steve Stedman 17:23
I think the key thing here is to treat your data as though it is as critical as it is, and prioritize your backups. Prioritize the testing of those backups, make sure that you have your servers secured and fully patched, and plan for how you’re going to do a recovery when you do get hit. And that may be going and spinning up a new virtual machine in the cloud, or on your on your network somewhere, and then just going and doing a restore there the I mean, we’ve worked on servers after they’ve been hit with ransomware, and the only way you really know that they’re clean and there’s no more ransomware infecting that system. Is to build a new machine from scratch. I would never trust a server that’s had ransomware on it in the past, so prioritize getting a server built out securing it and planning of how you’re going to recover there.
Shannon Lindsay 18:16
And practice… All right. Well, I think that kind of wraps it up. But next week, we have Derek joining, and the topic is going to be transparent data encryption, or TD, and we’re excited for him to be another guest appearance.
Steve Stedman 18:38
Yeah. It’s interesting. Some of the more popular podcast episodes that we’ve done have been the ones with Derek on it. So yeah, check that out. We’re going to talk about everything you need to know to get going with transparent data encryption. Next week, I’d like to invite everyone to consider subscribing to the podcast on Spotify or YouTube. You can go to stedman.us/podcastYouTube, or stedman.us/podcastSpotify. Or you can go to the Stedman solutions and click on the podcast link and get access to all of it there. If you’re watching this on YouTube or Spotify, please click the like and click the bell icon if you’re on YouTube, so you get notified of updates as we post more future episodes. If you need any help with preparing for ransomware, you can contact Stedman Solutions. We have a free 30 minute consultation, and you can get that at Stedmansolutions.com Also consider downloading Database Health Monitor as our monitoring tool that we can use for proactive monitoring at databasehealth.com I think that wraps up this week’s episode. Thanks for CO hosting with me, Shannon. And have a great day everyone. Thanks for watching our video. I’m Steve, and I hope you’ve enjoyed this. Please click the thumbs up if you liked it. And if you want more information, more videos like this, click the subscribe button and hit the bell icon so that you can get notified of future videos that we create.