SQLToolsPS.exe (Windows LOLBin)

What this LOLBin is doing under the hood

SQLToolsPS.exe is not dangerous because it is obscure, it is dangerous because it sits inside an administrative workflow that defenders may already trust. As a Microsoft SQL Server PowerShell-related executable, it can be used as intended for database administration, but it can also be abused to launch code through a signed, familiar component and blend into legitimate operations.

The security problem is not the presence of a management binary by itself. The problem is that attacker activity can inherit the credibility of ordinary DBA tooling, which makes execution review harder than it would be for a clearly hostile dropper or script host.

Why it is attractive for abuse

Living off the land works when the attacker can borrow normality. A trusted executable can bypass crude allowlists, inherit execution context from approved administrative paths, and create noise that looks like routine support work. That makes SQLToolsPS.exe useful in post-compromise tradecraft when an adversary wants to reduce suspicion while executing code on a Windows host.

Living off the Land Guide explains how dual-use Windows utilities, proxy execution, and command-line abuse are commonly chained, which is the same abuse pattern defenders should consider here. In practice, the more closely an execution resembles normal admin activity, the more likely it is to evade casual review.

How defenders should evaluate exposure

Exposure starts with knowing where the binary exists, where it is permitted to run, and which teams actually use it. If SQL administration tooling appears on endpoints that do not support database work, or launches from user workstations rather than managed admin systems, the likelihood of abuse rises sharply.

Review command-line patterns, parent-child process relationships, and whether executions occur during real maintenance windows. A launch is more suspicious when it is not tied to a change ticket, database task, or approved remote administration path. That context matters because the same binary can be benign in one environment and highly suspicious in another.

Use the vendor's own documentation and Microsoft security guidance to confirm normal behavior and legitimate administrative use, rather than trying to infer allowlist decisions from the filename alone.

Detection and response priorities

Detection should focus on abnormal launches, unusual arguments, and executions that do not line up with known SQL administration work. Process creation telemetry, PowerShell logging, and command-line auditing are especially useful when they show the binary being invoked from unexpected paths or by unusual parent processes.

MITRE ATT&CK Enterprise Matrix is the right reference point for mapping this behavior to proxy execution, command interpretation, and adjacent post-compromise activity. That mapping helps defenders decide whether they are seeing a one-off misuse of admin tooling or part of a wider intrusion chain.

If abuse is confirmed, review what the process touched, what child processes were spawned, and whether the host shows signs of lateral movement or credential abuse. For a LOLBin, the executable is often only the carrier, not the end goal.

Practitioner Guidance

What to watch for: Treat this binary as a monitored administrative utility, not as a ban-by-name candidate. The strongest signal is not that it exists, but that it runs outside normal DBA context, from unexpected parents, or with arguments that do not match routine database maintenance.

Governance implication: Define who may use SQL administration tooling, from where, and under what change-control conditions. That makes it easier to separate legitimate work from adversary use without blocking valid operations.

Related resources from NHI Mgmt Group

• Atbroker.exe (Windows LOLBin)
• Bginfo.exe (Windows LOLBin)
• CertReq.exe (Windows LOLBin)
• Cmdkey.exe (Windows LOLBin)