Ransomware Awareness for SQL Server

As I am seeing Ransomware attacks increase around the globe, I have been engaged with multiple customers whose SQL Server infrastructure has been infected.  I do not know the variant these customers were affected with, however, these variants were able to take SQL Server services offline and encrypt the MDF/LDF of each database.  In one scenario, they were also able to encrypt non-native SQL backups. 

Ransomware can quickly bring down organizations.  To protect against Ransomware, follow the security best practices for minimal privileged access.  Remove vector of access to backups.

  • Offline and external backups.  SQL Server backups should have detached storage, that can be recovered if main backup sources become encrypted.
  • Updated anti-virus and malware protection software.  SQL Server instances should have these installed with the following best practices for database exclusions.
  • Patching SQL Server or Operating System security patches when released.  Microsoft recommends applying Critical and Important security patches within a week of release.
  • Watch out for email attachments or links.  Follow the organization’s best practices for detecting and protecting against email threats.  Minimize downloading or executing any sensitive content using privileged credentials.

Vectors of Attack

  • Fake emails with infected attachments (Locky, CryptoLocker)
  • Exploit a security vulnerability in Windows (WannaCry)
  • Drive-By Attacks Insecure Websites (Bad Rabbit)
  • Trojan – Disable Recovery Functions (Ryuk)
  • Spam Email (Shade/Troldesh)
  • Job Application via Infected Dropbox Link (Petya, GoldenEye)
  • Attack via .rontok Linux Files (B0r0nt0k)
  • Installed by Hackers Manually via already compromised systems (Dharma Brrr)

Infection Possibilities

  • Files, Documents, etc. these can target over 100 different file types.
  • The infections will disable all recovery options and delete shadow copies to prevent recovery.
  • The infections can also encrypt master boot record (MBR) preventing access to the disk storage.
  • Compromise privileged account, change password, and walk-through network for infection.

Protecting Your SQL Server Infrastructure

  • SQL Server Service Accounts
    • Leverage Group Managed or Managed Service accounts (gMSA/MSA).
    • Create a dedicated service account for services and servers.
    • Do not grant local administrator permissions.
    • If non-gMSA is required due to the version of SQL Server, change the password at regular intervals.  Microsoft recommends at least every 6-months.  If you need an automation tool to accomplish this please reference my solution (https://github.com/sqlcan/SQLSvcAcctDBMgmt & https://github.com/sqlcan/SQLSvcAcctMgmt).
  • Leverage SQL Server Proxy Accounts
    • When executing jobs on SQL Server for PowerShell, Replication, SSIS, implement SQL Server Proxy account for the workload and/or application.  Minimize the utilization of SQL Server agent account for the run as property.
  • Review privileged access
    • Review individuals or teams with SYSADMIN and LOCAL ADMIN access.  Evaluate if they need SYSADMIN, can you leverage custom Server Roles to grant them a subset of permissions.
    • Leverage SQL Server policies to make sure non-admin accounts do not have privileged access.
  • Review SQL Logins
    • Any SQL server login with privileged access should be reviewed.
    • SA account should be disabled with a strong password.
  • Patching
    • Keep up-to-date on patching monitoring Microsoft Security Bulletin.  Apply any important or critical security patches for Windows or SQL Server, within a week.
  • Review access to MDF/LDF files
    • By default, only Local Admin and SQL Engine accounts should have access to each server.  Make sure non-admin accounts have not been granted access.
  • Do not store or execute any job using a privileged account that can access the internet.
    • This includes scheduled tasks, SSMS, remote desktop manager, etc.
  • Protect SQL Server backups
  • Service Interruption Monitoring
    • Monitor for unexpected SQL Server restarts and shutdown. If services are shutdown or restarted and it can’t be explained, consider assessing risks with data compromised.

References

Ransomware in News

Warning & Notice

Please note do not try these exploits, pen-testing tools on production environments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.