How to Protect Microsoft SQL Server Databases from FARGO Ransomware

The news about the FARGO ransomware discovery has been all over the Internet, and it’s a major cause for concern for organizations relying on their Microsoft SQL Server databases to power critical systems. The AhnLab Security Emergency Response Center (ASEC) discovered a recent wave of ransomware attacks that target unsecured Microsoft SQL Server databases.

 
This ransomware attack, called FARGO, also known as Mallox and TargetCompany, starts off by using brute force and dictionary attacks to gain access to the system. From there, it loads malware that leads to the data being encrypted by the attacker and held for ransom.

Whether your SQL systems are on-premises, fully in the cloud, or in a hybrid environment, the threat of ransomware attacks is very real and very concerning.

Verizon’s Data Breach Investigation Report 2022 found that ransomware accounts for 25% of cyber threats facing organizations in 2022. FARGO may be the latest wave, but many others have wreaked havoc on unsecured databases. Use the following tips to improve the security posture of your Microsoft SQL Server databases and associated systems.

Make Sure You Can Recover Your Data

For a ransomware attack to be effective, the hacker needs to cut off the victim from their data. By ensuring that your systems are recoverable, you remove the hacker’s leverage and can restore your systems without paying them.

Start with your backup strategy. We’ll cover both Azure and Amazon Web Services examples, but you can use similar methods with other environments.

First, we need to think of methods to protect these backups from the on-premises systems. There are a few ways to back up your SQL databases to an encrypted and inaccessible location that would not be compromised during the attack. A typical method is by backing up using a URL.

AWS S3 Database Backups

In this first example, we use scripting to use SQLCMD and the aws command-line utility. SQLCMD allows you to interact with SQL Server from the command line. It’s part of the SQL Server installation package. The aws utility allows you to interact with AWS. Configuration takes place through AWS configure.

This method uses Amazon S3, and you’ll need to configure the encryption and access keys in advance. All keys that you’re using for this backup must have write access to that S3 bucket. The following is a simple script that backs up a SQL Server database to AWS S3.

The code example comes from https://dba.stackexchange.com/questions/294539/backup-to-url-s3

set day=%date:~7,2%

aws s3 cp W:\temp\%backup_name%.bak s3://my-backet-name/%backup_name%.bak

For the first three lines that use parts of today’s date to create the file name, please note that the numbers’ positions are dictated by the regional settings of your %date% system variable.

Azure Database Backups

The code examples for this method come from this Microsoft Learn article, and you can find additional details on setting up the secure location and the credentials required for this method: https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/sql-server-backup-to-url?view=sql-server-ver16

Here are the backup commands recommended by Microsoft:

Create a Full SQL Server Database Backup To URL in Azure Blog Storage

These examples execute a full backup of the AdventureWorks2016 database, and send that backup to Azure Blog Storage.

If you want to use Shared Access Signature when backing up the database to URL, use this:

BACKUP DATABASE AdventureWorks2016
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2016.bak';
GO

If you want to use storage account identity and access key, use this:

BACKUP DATABASE AdventureWorks2016
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2016.bak'
WITH CREDENTIAL = '<mycredentialname>'
,COMPRESSION
,STATS = 5;
GO

Restoring Your SQL Server Database Backup From URL

To restore the AdventureWorks2016 database to a point-in-time using STOPAT, use the following code example to restore from URL using Shared Access Signature:

RESTORE DATABASE AdventureWorks2016 FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2016_2015_05_18_16_00_00.bak'
WITH MOVE 'AdventureWorks2016_data' to 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2016.mdf'
,MOVE 'AdventureWorks2016_log' to 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2016.ldf'
,NORECOVERY
,REPLACE
,STATS = 5;
GO

RESTORE LOG AdventureWorks2016 FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2016_2015_05_18_18_00_00.trn'
WITH
RECOVERY
,STOPAT = 'May 18, 2015 5:35 PM'
GO

Database Backups When You’re Already in the Cloud

This next set of examples covers what to do if your databases are in the cloud already. While these examples cover AWS specifically, many of the concepts and details are relevant elsewhere.

AWS offers a variety of options for backing up and restoring your systems, including AWS Backup and CloudEndure Disaster Recovery. When you’re protecting your organization from ransomware, keep in mind that you want a more robust option than simply creating a snapshot of an Amazon EC2 instance.

One particularly powerful function of the AWS Backup service involves creating a backup vault and setting a different customer master key (CMK) in AWS Key Management Service. You can set a key policy for the CMK that allows AWS operators to use that key for backup encryption, but decrypting it can be limited to a different principal. A user who is authorized by the AWS Identity and Access Management principal access policy, but uses the incorrect CMK for decryption, will not be able to access that data.

You can also create a dedicated AWS account for backups, as AWS Backup natively supports cross-account capabilities. A hacker would have an even harder time of getting at the backup data during a ransomware attack. The AWS Backup Developer Guide goes into detail on how to implement this functionality.

If you’d like to read more about ransomware remediation, or to see the architectural diagrams of using multiple customer master keys, one of my favorite articles on the topic can be found here: https://aws.amazon.com/blogs/security/ransomware-mitigation-top-5-protections-and-recovery-preparation-actions/

When you set up your SQL Server database backups, make sure that you include all the data and systems that you need to protect from ransomware. Consider your business recovery time objective (RTO) and recovery point objective (RPO) when creating your backup schedule.

Encrypting Your Data

Ransomware attacks sometimes involve double extortion schemes, where your data gets encrypted by the hacker and they threaten to release it if your organization doesn’t pay. By encrypting data and strictly controlling the systems and user accounts capable of decrypting data, it’s harder for hackers to pull this off.

However, you must maintain the right balance between encryption and performance. Encrypting your data has the potential to reduce performance, as it’s a resource-intensive process.

Stay on Top of SQL Server Patches

An unpatched database, especially one running on an end-of-life version of SQL Server, is a prime target for ransomware and other types of attacks. Microsoft releases patches on a routine basis to address security problems, performance issues, and other problems. Your organization needs to have a robust strategy to keep your databases, operating systems, and other software up to date. It can make all the difference in the world when you’re being targeted.

Implement Security Best Practices

Putting security standards in place to mitigate your organization’s risks of ransomware is another essential step in protection. The Principle of Least Privilege means that interactions should be limited to only what’s needed for a particular operational goal. If you’re using services on a public cloud, then these services should only be able to interact with your on-premises systems when it’s required for an operation.

The Zero Trust principle is another robust security standard. Any new resources added to an environment should not be able to interact with anything until they are authenticated and authorized to ensure that they are legitimate.

For example, when your organization follows Zero Trust, you would not allow new local servers to join infrastructure until after the vetting process. I had seen many times a buttoned-down environment, with good security, have a hole introduced when the new server was stood up inside the environment without the same precautions placed on it that were enforced in the production environment.

The FARGO ransomware attacks and other threats to SQL Server databases are concerning, but when you make your environment recoverable and well-protected against these types of attacks, you put your organization in a strong position.

Does your in-house IT team already have enough on their plates, or lack a deep understanding of where security vulnerabilities get introduced into a Microsoft SQL Server environment? At Datavail, we specialize in database management, applications, and analytics, and have partnerships with Microsoft, AWS, and many other leading technologies.

Whether you just want a database assessment to determine if you’re doing everything you can to strengthen your systems, or you’d like a helping hand with 24×7 operational DBA support, we’re here with 1,000 data specialists. Contact us to talk to our SQL Server experts and learn more.