Deep Dive: Squashing an MSSQL Attack

Robert Galvan
Huntress
Published in
6 min readJul 17, 2017

During the previous MSP Moment, we walked our readers through an incident where our partner, NTConnections, used Huntress to discover a previously undetected breach. In this Deep Drive, we’ll examine the tradecraft used by the attackers to gain access through the database, kill/disable antivirus, download malicious files, and establish a persistent foothold within the network.

When it comes to a breach, one of the first questions typically asked is “how did the attackers get in?”. Unfortunately, this isn’t always an easy question to answer. Thankfully, the actors behind this attack were quite noisy and the server had several months of backups available for forensic inspection. Within minutes of investigating the Windows Event Logs, we discovered signs of the initial access vector — 1000s of failed login attempts to the MSSQL database.

Bruteforcing Weak Database Credentials

MSSQL provides remote access through an Open Database Connectivity (ODBC) interface that typically listens on port 1433. After establishing a connection to this interface, users are prompted for a database username and password. Similar to Windows’ predictable “Administrator” account, MSSQL has an “sa” account which provides system administrator access. The hackers used this knowledge to their advantage and launched a brute force attack with commonly used passwords.

Event Viewer detailing the brute force attack logged in the Application Event Log

In addition to the “sa” account, the attacker tried 20 additional user names:

After 37,000+ attempts, they successfully authenticated with the MSSQL database.

Executing Shell Commands From MSSQL

With this access, the attackers now needed to successfully transition from database privileges to native command execution. Within MSSQL, the xp_cmdshell feature is ideal for this. However, it’s disabled by default so the attackers had to reconfigure the database with the following commands:

On a vanilla Windows installation, this is all that is needed to execute shell commands. For hardened systems like kiosks and mission critical systems, Group Policy can be locked down to prevent users from tinkering within the Command Prompt. Rather than take any chances, the attacker chose to modify and delete several registry keys to ensure their commands would run as expected.

With these hurdles out of their way, the attackers were free to perform more nefarious actions such as killing antivirus processes:

Killing Antivirus w/Image File Execution Options

In addition to using taskkill.exe, the attackers took other precautionary steps to disable many common antivirus applications from running. One of these techniques leveraged the Image File Execution Options (IFEO) feature within the registry. The attacker specifically abused IFEO’s Debugger value which caused taskkill.exe to execute instead of the named processes.

Abusing IFEO’s Debugger value to prevent notepad.exe from opening

For unfamiliar readers, the IFEO key is a centralized location for adjusting how images (processes) are executed. As demonstrated in the above GIF, you can modify the way named processes are executed by creating a key with the targeted process’ name (for example, notepad.exe). Under this key, there are several values you can create to adjust the ASLR implementation (MitigationOptions) or automatically attach a specified debugger to troubleshoot a process (Debugger).

When a process gains execution, one of the earliest actions performed by explorer.exe is to check the IFEO key. If the executed process has a correlating subkey (shares the same name), Windows will check for a Debugger value. If the Debugger value exists, the OS will execute the data within the value and pass the original process and process arguments to the specified debugger.

For instance, if you were the developer of myApp.exe, you could add the following to the registry to automatically attach the Windows Debugger (windbg.exe) when your process is executed:

If the command line syntax for this program was myApp.exe, the OS would effectively run windbg.exe myApp.exe (thus never actually running myApp.exe directly). If attackers created a Debugger value set to “taskkill.exe /F /IM ” for within the myApp.exe subkey, Windows would actually run “taskkill.exe /F /IM myApp.exe” as demonstrated in this ProcMon screenshot:

Taskkill.exe is automatically called to terminate the targeted process

This technique is an ideal way to prevent some antivirus products from running. To see exactly what processes these attackers were targeting, check out the full list of their IFEO related registry modifications here.

Downloading Malware w/FTP Answer Files

Once the attackers disabled antivirus, they immediately started downloading malware. To do this, they first attempted to disable the Windows Firewall by stopping the dependent SharedAccess service. Next, the attacker used the “echo” command to create FTP answer files:

Building the contents of an FTP answer file via “echo”

These answer files act as unattended scripts which instruct “ftp.exe” what actions to execute. Once the answer file was created, the command “ftp -s:NameOfScript.txt” was run. In the example below, we connect to the attacker’s FTP server and download a file from their server into our directory.

FTP Answer Files in action!

During this incident, we discovered the attackers downloaded all sorts of nastiness including crimeware, remote access tools, and cryptocurrency miners. Our detailed technical write ups on the samples we reverse engineered can be found below:

Maintaining Persistent Access to the Victim

Our product Huntress complements preventive security products (like antivirus), by auditing the footholds attackers use to ensure long term access. During this breach, we discovered several malicious Run Keys and Services that automatically launched malware when a user logged in or after the system rebooted.

Shady Run Key
Immediately after the MSSQL database was compromised, the attackers used the previously discussed xp_cmdshell technique to create several registry based footholds:

REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v Aut2 /t REG_SZ /d c:\windows\system32\cmd.exe /c net stop sharedaccess… /F

Although cmd.exe was a legitimate Microsoft executable, the use of a registry value named “Aut2” with these nested commands was anomalous. As a result, Huntress classified the activity as malicious.

Suspicious Service
Huntress also discovered a service named “Wsqhwr zajttrgb” that was created by one of the malicious files downloaded through the FTP Answer Files. This service automatically launched a UPX packed binary from C:\Program Files\Microsoft Otvkec\Cgowgmi.exe at startup. After further inspection, we learned the malware was capable of self-installing its own persistence mechanism and frequently reached out to fyunf.f3322[.]net (42.51.33.115).

Service settings within the Registry

SHA256:420bdfbd9df7773185c39a771d24b6ffa7a38c3983ce08448b55182bbe77d004

Parting Thoughts on this Breach

Although the hackers behind this compromise used many different techniques, all of them were well known and documented within the cybersecurity community. Despite this, these attackers were able to gain access, disable the preventive security in place, establish a foothold, and significantly disrupt an SMB’s productivity.

Just like the Fortune 500, small and medium sized businesses need security expertise beyond configuring firewalls and antivirus. Our Managed Detection and Response Service makes this an easy and profitable solution for Managed Service Providers.

Ready to find hackers in your network? Sign up for our 21-day Free Trial

At Huntress Labs, we believe the best defense is a good offense. We’ve spent our careers circumventing preventive security products to stay a step ahead of malicious actors. This mentality enables our products and analysts to tackle threats head-on. As a result, we force hackers to earn every inch of their access within the networks we protect and monitor.

Indicators of Compromise

SHA256 Hashes

  • a603f7ceb5f80069674b31879acbfd3aeb7786e43a910194270740602b939406
  • e62d433e662bff743e8d0fc554c2308db6c72fa500e64091d76e127445f337e1
  • 420bdfbd9df7773185c39a771d24b6ffa7a38c3983ce08448b55182bbe77d004
  • ed756c1cd9167690ad6a054c5b25a246289c93adb48e94f864b47d847bfd176e
  • 477d7ad7fc262f168df18f61334ea2e0499de71ffd04f2fe23513f3d441e83e2
  • 42a0e84845714ee18f63f80e37b26fe7c29f52cd76305db6c10d51c0534e6a53
  • 748e5d31dfd30eeb2e34423f8b7c173b1c0585a98aecd57ef955bbfdb01b74ec
  • 085ba2ddcae15e2dd996b8152d6512c53958e7e6ae0bd87a5f2f7c7e4352428e
  • 4187894e15916bb51bb7c7f9297e15a6ddec9839ead55148c7e62821d42a5bab

Malicious IP Addresses

  • 14.152.95.39
  • 23.238.133.194
  • 42.51.33.115
  • 49.4.135.126
  • 49.4.135.223
  • 49.4.142.49
  • 49.4.142.141
  • 49.4.142.187
  • 49.4.142.195
  • 49.4.143.176
  • 58.221.72.196
  • 58.253.66.22
  • 59.33.252.251
  • 59.63.189.106
  • 103.228.131.193
  • 103.230.108.85
  • 107.179.126.94
  • 114.80.253.90
  • 117.21.191.79
  • 118.192.151.7
  • 118.193.231.203
  • 118.254.32.82
  • 123.249.27.61
  • 123.249.27.92
  • 123.249.79.241
  • 157.52.163.121
  • 162.109.168.17
  • 173.254.203.28
  • 175.19.209.140
  • 180.97.215.61
  • 180.97.215.155
  • 180.97.239.21
  • 180.97.239.22
  • 183.47.48.214
  • 190.216.240.209
  • 198.55.114.203
  • 219.223.8.218
  • 220.189.255.9
  • 221.194.44.221
  • 222.173.103.229
  • 222.186.10.245
  • 222.186.190.123

--

--