An SQL injection vulnerability in a web application became the doorway for a threat actor to plant persistent tooling on an IIS web server, according to a June 26 incident investigated by the Huntress SOC. The attacker never touched the Microsoft SQL Server (sqlservr.exe) directly. Instead, they found a web page where user input wasn't properly validated, and that flaw let them run commands on the endpoint. (Source: Huntress)

What makes this incident worth your attention isn't data theft—it's what came after. Once inside, the actor didn't grab files and leave. They reshaped the box to keep long-term access and quietly monetize it.

The tooling they installed tells the story of that intent:

• BadIIS modules (HttpFastCgiModule.dll and HttpCgiModule.dll), a family of malicious IIS modules that Cisco Talos has tracked across multiple campaigns for SEO fraud, traffic redirection, and content hijacking
• XMRig, the open-source cryptocurrency miner, delivered as xmr-1.zip
• nssm.exe, the "non-sucking service manager," used to turn the miner into a resilient Windows service that restarts on its own
• Multiple PowerShell scripts and batch files, including qdcjoke1.2.ps1 and qd_tjoke.bat

The combination matters because it separates a smash-and-grab from a foothold. When an attacker installs IIS modules and registers a service, the malicious code loads with your web server and survives reboots—it becomes part of how the machine runs, not a file sitting on disk waiting to be scanned.

For the tech-sector organization involved, that meant an internet-facing IIS server was quietly serving fraud traffic and burning compute cycles on mining while the attacker held admin-level access. Any organization running IIS alongside a web application that doesn't validate user input faces the same path: a single injection flaw becomes server-level persistence rather than a one-time breach.

Attack Chain: From SQL Injection to Cryptomining and Backdoor Installation

The attack unfolded as a linear chain, each step building on the code execution won at the start. It began when the threat actor located a web page served by the endpoint's IIS installation where user input wasn't validated. Exploiting that SQL injection flaw gave them command execution on the host without ever authenticating to the Microsoft SQL Server directly (MITRE ATT&CK T1190 – Exploit Public-Facing Application).

With that foothold, the actor pivoted to native tooling. They used appcmd.exe, the built-in IIS management binary, to register malicious modules into the web server's request-processing pipeline (T1505.004 – Server Software Component: IIS Components). This is the part of the chain that deserves your attention.

Injecting a rogue module into IIS is different from dropping a file on disk and hoping it runs. The module loads into the IIS worker process every time the service starts, which means it persists through IIS restarts and even system reboots without any scheduled task or run key to give it away. Because it lives inside a legitimate, signed Microsoft service, it blends into normal web server activity and is difficult to spot with routine file scanning.

For a business, that translates to a backdoor that can survive routine remediation. Wiping malware from disk or resetting a compromised account does nothing if the IIS module is still loaded and quietly serving the attacker's purposes.

From there, the actor moved to monetization and layered defense evasion. They pulled down the XMRig cryptocurrency miner and added a protective wrapper to help the miner run without drawing attention. Cryptomining consumes CPU and power on the compromised host, which shows up as degraded application performance and higher infrastructure costs before anyone identifies the cause.

PowerShell and batch scripts carried out the post-exploitation work throughout the chain (T1059.001 – PowerShell; T1059.003 – Windows Command Shell). The staging pattern is worth mapping:

• The SQL server process spawned cmd.exe to download an initial PowerShell script to the shared user profile directory at C:\users\public\.
• That first-stage script pulled down additional payloads, chaining one download into the next.
• A later PowerShell command launched a batch file from C:\ProgramData\tjoke\qd_tjoke.bat with -WindowStyle Hidden and -ExecutionPolicy Bypass, so the batch files ran with no visible window, prompt, or policy restriction (T1562.001 – Impair Defenses).

Using C:\users\public\ and C:\ProgramData\ as staging locations is deliberate: both are world-writable and rarely inspected, so payloads sit there without tripping permission errors or attracting review.

To keep the miner alive across reboots, the actor turned to nssm.exe, the non-sucking service manager. This freely available utility wraps a standalone executable as a resilient Windows service (T1543.003 – Create or Modify System Service). Registering the miner as a service means Windows itself restarts it after a crash or reboot, giving the actor persistence that outlasts a simple process kill.

The attack surface here is straightforward to define: any IIS server running a web application that fails to validate user input is exposed to the same entry point. The SQL injection provides code execution, and once an attacker reaches that point on an IIS host, native module injection, script-based staging, and service persistence follow the same pattern documented in this June 26 incident.

The threat actor never touched the SQL Server instance directly — a single unvalidated web input was enough to run commands, plant a persistent IIS module, and stand up a cryptominer as a Windows service.

Each stage reinforces the next, so cutting off only the miner or only the new account leaves the IIS module and the underlying injection flaw in place. That is why the full chain, not any single artifact, defines the scope of this compromise.

Business and Operational Impact on Tech Sector Organizations

The most immediate cost of this incident is one you can measure on your electricity bill and your monitoring dashboards. XMRig, the cryptocurrency miner the threat actor dropped onto the compromised endpoint, consumes processor and memory resources to mine Monero. On a production server also running IIS and Microsoft SQL Server, that stolen compute directly competes with the workloads your customers depend on.

For a tech-sector organization, degraded server performance shows up as slower application response times, timeouts, and missed service-level agreements. If you host applications for your own clients, their experience suffers because a hidden process is burning cycles you are paying for.

The persistence is what turns a single intrusion into an ongoing problem. Because the attacker registered malicious IIS modules and stood up a resilient Windows service for the miner, the compromise survives reboots and routine cleanup. Removing the miner alone does not close the door.

The attacker also created a new administrator account and enabled Remote Desktop Services, then disabled Windows Defender. That combination means someone can log back in with legitimate-looking credentials whenever they choose. Until every piece is found and removed, you are not recovering from a breach — you are sharing your server.

Had the original means of access, via an SQL injection vulnerability within a web page, gone unchecked, even if all of the remnants of the threat actor activity had been removed, they could return unfettered.

That return path matters for what comes next. An attacker holding administrator access and a foothold in your web server pipeline can pivot from cryptomining to data exfiltration or move to other systems on your network. The miner may be the noisiest activity, but it is not necessarily the most damaging outcome available to whoever controls the box.

Then there is the compliance exposure. The entry point here was SQL injection against a web application that connects to a Microsoft SQL Server — the exact scenario that puts customer records within reach. If the database behind that vulnerable page held personal data, you may face breach-notification obligations under regimes such as GDPR and CCPA, along with the potential liability that follows.

The practical consequences of that exposure include:

• Notification timelines and legal review that begin the moment you can no longer rule out data access, not when you confirm it.
• Forensic investigation costs to determine the full scope — which the source stresses is essential, because you must establish root cause before you can confirm the attacker's access is cut off.
• Customer trust erosion, which for a tech company selling reliability and security is a direct hit to the value you offer.

Reputational damage is harder to price than a power bill, but it follows the same logic. Clients who learn their data sat on a server running an attacker-controlled service and a disabled antivirus will question whether to keep their business with you. Some will move it.

The incident response bill itself compounds these costs. Investigating a host where an attacker made a wide range of modifications takes longer than cleaning up a smash-and-grab. Every account, service, module, and hidden file has to be accounted for, and the server may need to stay offline or heavily restricted while that work happens — downtime you absorb on top of the recovery effort.

The reason this incident stood out to the investigating analysts was the sheer breadth of changes made to one endpoint. For you, that breadth translates into a longer, costlier cleanup and a wider window during which the attacker held access. The bill is not a single line item; it is compute theft, investigation hours, potential regulatory penalties, and lost customer confidence stacked together.

Detection and Forensic Indicators for BadIIS and Related Artifacts

The clearest place to start hunting is the IIS module directory. The malicious modules in this incident, HttpFastCgiModule.dll and HttpCgiModule.dll, were registered into the web server's request pipeline using the built-in appcmd.exe binary. Inspect %windir%\System32\inetsrv\ for DLLs with these or similar names, and compare their file timestamps and digital signatures against a known-good baseline.

Legitimate IIS modules ship signed by Microsoft. A module DLL with no signature, a mismatched signature, or a creation date that lines up with your incident window is a strong indicator of a BadIIS implant. You can also enumerate registered modules directly with appcmd.exe list modules and flag any entry that doesn't map to a documented Microsoft or vendor module.

For your business, an unauthorized module in the pipeline means every request hitting the web server can be inspected, redirected, or modified by the attacker without touching application code — which is why the file-level and signature checks matter more than trusting the module list at face value.

Windows event logs give you a second angle. Watch for these patterns:

• Application pool crashes or recycling events tied to w3wp.exe, the IIS worker process, which can accompany a bad module load
• Module load failures in the IIS or application event logs following a configuration change
• sqlservr.exe spawning cmd.exe or powershell.exe — a database engine launching command shells is rarely legitimate and matches the initial execution seen here

On the process side, the XMRig miner is one of the more visible artifacts. Look for a process consuming sustained high CPU, running from an unexpected path, and holding outbound network connections. In this case the miner files were staged as edge.exe and Taskgmr.ps1 under C:\Program Files (x86)\Microsoft\EdgeUpdate\ — names chosen to blend in with legitimate Microsoft Edge update components.

Because the attacker used attrib.exe to set these files to system, hidden, archive, and read-only, a standard directory listing won't show them. Enumerate that path with hidden and system files included, and treat any executable masquerading as an Edge update component as suspect.

Service persistence is another checkpoint. The miner was installed as a resilient Windows service using nssm.exe. Review service creation events and look for services whose binary path points to nssm.exe or to a wrapped standalone executable rather than a signed vendor binary. That service is what restarts the miner after a reboot, so removing the files without removing the service leaves the door open.

For PowerShell and script artifacts, search across the file system and temp directories for the named payloads:

• qdcjoke1.2.ps1 and c_joke1.2.ps1, staged in the shared profile directory C:\users\public\
• qd_tjoke.bat, run from C:\ProgramData\tjoke\
• PowerShell invocations using -ExecutionPolicy Bypass, -WindowStyle Hidden, -NoProfile, and -NonInteractive together, which is the exact combination used to run the batch file silently

Enable PowerShell script block logging if it isn't already on, then query for base64-encoded command strings and Invoke-WebRequest calls posting local command output to external hosts. That behavior is how the attacker exfiltrated reconnaissance data in this incident.

Network telemetry ties the artifacts together. Monitor outbound connections for two categories: traffic to cryptomining pools generated by the miner, and callbacks to attacker-controlled infrastructure. The reconnaissance output in this case was posted to a subdomain of oastify.com, a Burp Collaborator domain often used to confirm out-of-band command execution, and additional payloads were pulled from an r2.dev Cloudflare storage endpoint.

An unsigned or unexpectedly timestamped DLL in %windir%\System32\inetsrv\ is the single most reliable on-disk indicator that a BadIIS module has been registered on your web server.

Finally, check for the account and access artifacts that outlast the malware. Query for the adminweb2$ account, its membership in the local Administrators group, and any account whose name ends in $ to mimic a machine account. Review whether Remote Desktop Services was recently enabled, and correlate that with logon events from unfamiliar sources. These persistence markers let an attacker return even after the miner and scripts are cleaned up.

Immediate Remediation and Long-Term Hardening

The most urgent action is to close the door the attacker walked through: the SQL injection flaw in your web application. Until that unvalidated input is fixed, removing every payload on the server still leaves the way back in open. Start with a code review of the affected page, convert database queries to parameterized statements (prepared queries that treat user input as data, not executable SQL), and stage a Web Application Firewall rule to filter injection patterns while your developers work on the permanent fix.

Following the NIST Cybersecurity Framework, here is how to sequence the rest of the response.

Identify. Pull the IIS request logs for the affected endpoint and trace the injection attempts back to their earliest timestamp. That first malicious request is your dwell-time anchor. Review which database tables and stored procedures the injected queries touched, so you know whether the actor read or altered data beyond planting tooling.

Protect. Contain the host before you clean it, then remove the attacker's footholds in order:

• Stop and disable the affected IIS application pool so the malicious request-processing path stops serving traffic.
• Kill the running miner and its supporting processes, then remove the resilient Windows service the actor registered to relaunch it after reboot.
• Delete the hidden and system-attributed files staged under the Edge update directory, and clear the attrib flags on anything before removal so nothing is missed.
• Delete the unauthorized local administrator account and any scheduled tasks tied to it, then re-enable the endpoint protection the actor turned off.
• Reset credentials for every account that could have been exposed during the intrusion, including service accounts the MSSQL instance runs under.

In environments Capstone manages, SentinelOne flags and blocks the endpoint-protection tampering described in earlier sections, catching the moment antivirus is disabled rather than after a miner is already running.

Detect. Turn on full IIS logging if it isn't already, and forward those logs to a central SIEM so injection attempts against any application are visible in one place. Add process-monitoring rules for cryptomining behavior and for hidden-window PowerShell execution with execution-policy bypass, which is how the batch payloads in this incident ran without prompts. Baseline your registered IIS modules and alert on any new DLL added to the request pipeline.

Respond. Treat this as more than a single-host cleanup. Over the following week, run a forensic scan for lateral movement and secondary persistence—the actor who gets one administrator account often plants a second, quieter foothold in case the first is found. Confirm no other web servers share the vulnerable code, and check whether the same account was reused elsewhere.

Had the SQL injection flaw gone unaddressed, even a fully cleaned endpoint would have let the actor return unfettered and act in ways that take longer to detect.

Recover. If you hold clean backups from before the earliest exploitation timestamp, restoring the endpoint is faster and more certain than manual cleanup, because it removes footholds you may not have found. Rebuild from a known-good image where the intrusion scope is unclear, then reapply the input validation and WAF rules before the server returns to production.

For the long term, bake the root cause back into your engineering practice: mandatory parameterized queries, security code review of all internet-facing applications, and IIS module integrity monitoring so an unsigned DLL in the pipeline raises an alert the same day it appears. An accurate inventory of your applications and their versions is what makes each of these controls enforceable rather than aspirational.

Key Takeaway: SQL Injection Remains a Critical IIS Attack Vector

The core lesson from this June 26 incident is that an unvalidated web input field gave the attacker everything they needed—not because SQL injection is exotic, but because it sat unnoticed on a server also running IIS and a database. The web application was the weak point, and the database engine simply became the launchpad for command execution.

What you should take from this is the sequence, not any single tool. A single injection flaw let the actor turn a public-facing web page into a persistent foothold, then embed themselves into the web server's own request-processing pipeline through malicious IIS modules and a hidden Windows service. That combination is harder to find and harder to fully remove than a typical defaced page or stolen record, because the malicious code runs as part of trusted server infrastructure.

The single most important action is to audit every IIS-hosted web application you run for SQL injection weaknesses and fix them at the code level. An injection flaw that stays open means that clearing the miner, the rogue account, and the malicious modules still leaves the original way back in intact.

Treat SQL injection remediation and ongoing integrity checking of your registered IIS modules as standing controls rather than one-time cleanup tasks. A breach that reaches into the web server's request pipeline demands forensic rigor: you have to trace the root cause, confirm exactly what the actor changed, and verify that every persistence point is gone before you call the endpoint clean.