A 1998 feature doing 2026 damage
xp_cmdshell is an extended stored procedure that has shipped with Microsoft SQL Server since the late 1990s, letting a database session execute arbitrary operating system commands and PowerShell scripts directly from within a SQL query. It exists for legitimate administrative convenience, and most security guidance has recommended disabling it in production environments for years precisely because of what it enables when it falls into the wrong hands.
Attackers who had already obtained database access used xp_cmdshell to run commands and PowerShell scripts on the underlying server, turning a feature meant for administrative convenience into a full remote command execution channel. The technique has been understood conceptually for years, and its continued effectiveness against production systems in 2026 is a reminder that a feature's age does nothing to reduce the danger it poses once it remains enabled and reachable by an attacker who has already found a way in.
Exfiltration without a command server
The more distinctive part of this attack is how data left the network. Rather than standing up a separate command-and-control infrastructure, which is the kind of network traffic many security tools are specifically tuned to detect, the attackers converted stolen file contents to Base64 encoding and returned that encoded data through ordinary SQL query output, the same channel a legitimate database query would use to return results to an application.
That approach means the exfiltration traffic looks, at a network level, like a database doing exactly what databases are supposed to do: answering queries and returning data. Security monitoring tuned to flag connections to unusual external command servers has nothing to catch here, because there is no separate server; the database connection the organization already trusts and expects to see constant traffic on is the exfiltration channel itself.
How it came to light
ThreatMon researchers did not discover this through analyzing a victim's compromised network directly. They found it during routine threat hunting, when they located a publicly accessible staging server belonging to the attackers themselves, left exposed and containing a collection of seventeen tools along with stolen materials connected to a separate intrusion linked to Viva Aerobus. That kind of operational security failure on the attacker's side is often how researchers piece together techniques that would otherwise go entirely undetected on the victim's end.
The investigation notably could not establish how the attackers first gained entry to the environment, and no named malware family was identified behind the activity. That gap matters: it means organizations cannot simply patch a specific vulnerability and consider the exposure closed, because the actual initial access vector behind this specific technique remains unknown and could recur through an entirely different entry point next time.
Why this evades conventional monitoring
Most enterprise security monitoring programs are built around detecting anomalous network connections, unusual outbound traffic to unfamiliar destinations, and known malware signatures. This technique defeats all three by design: the commands run through a legitimate, expected database feature, the data leaves through a connection the monitoring stack already treats as routine and trusted, and there is no malware binary to fingerprint because the entire operation runs through native database functionality rather than a custom tool.
That combination is precisely why detection has to shift toward behavioral monitoring of what a database account is actually doing, rather than relying on signature or destination-based detection alone. An xp_cmdshell call from an application service account that has never needed to invoke it before is the kind of anomaly that behavioral monitoring can catch even when every other layer of detection sees nothing unusual at all.
What database administrators should do now
The immediate, concrete steps are specific and achievable without a major infrastructure overhaul. Disable xp_cmdshell in any environment where it is not actively required for a documented administrative purpose, and where it must remain enabled, restrict and closely monitor exactly which accounts can invoke it. Watch specifically for encoded PowerShell execution patterns running under a SQL service account, since that combination is a strong indicator of exactly this kind of abuse rather than routine administrative activity.
Beyond the immediate technical fix, this incident is a prompt to review how database connection credentials and configuration details are stored and protected across the environment, treating them with the same sensitivity as any other high-value secret. Any credentials that may have touched an exposed staging server anywhere in the environment's history should be treated as compromised and rotated immediately, rather than assumed safe simply because no direct evidence of misuse has surfaced yet.
