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.
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.
In addition to the “sa” account, the attacker tried 20 additional user names:
After 37,000+ attempts, they successfully authenticated with the MSSQL database.
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:
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.
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:
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.
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:
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.
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:
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).
SHA256:420bdfbd9df7773185c39a771d24b6ffa7a38c3983ce08448b55182bbe77d004
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.
SHA256 Hashes
Malicious IP Addresses
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
