A SQL Server attack linked to a Viva Aerobus environment turned database sessions into channels for command execution and data exfiltration. Observed from 25 to 29 September 2026, the activity also exposed attack tools and collected material through a publicly accessible server.
ThreatMon disclosed the findings publicly on 2 October 2026. The available evidence confirms post-exploitation activity against a Microsoft SQL Server system, but does not establish how the intruders initially entered the environment.
How the SQL Server attack was uncovered
ThreatMon identified an unauthenticated, attacker-controlled server used to stage tools and store loot. Its contents and associated HTTP activity revealed a collection of scripts, logs and stolen artefacts oriented towards post-exploitation in Microsoft SQL Server environments.
The server was reportedly open to the internet without authentication. This meant unrelated users could browse or download exposed directories containing both attacker tooling and material collected during the intrusion.
ThreatMon linked the activity to a victim-side Microsoft SQL Server in an environment associated with Viva Aerobus. However, no public statement from Viva Aerobus confirming or denying the incident had been identified when the findings were published.
The activity began on 25 September 2026 and continued until 29 September 2026. The first timestamped public coverage appeared on 2 October 2026, with further summaries published on the same day. No later authoritative update from the affected organisation or Microsoft was available.
What remains unknown
The investigation did not identify the initial access method. There is no confirmed vulnerable internet-facing application, compromised account, phishing route or exploited CVE associated with the entry point.
No named malware family was identified either. The recovered material was characterised as a toolkit made up of scripts and utilities rather than a single, persistent malware implant. ThreatMon labelled the report in connection with Blackhatsect0r and DXQRTXX, but no broader attribution has been established publicly.
SQL Server attack abused xp_cmdshell
The central technique was the abuse of xp_cmdshell, an extended stored procedure that allows Microsoft SQL Server to run operating-system commands. Microsoft documents xp_cmdshell as disabled by default, although administrators can enable it for workloads that require command-line interaction.
In this incident, the attackers used SQL sessions to issue Windows commands through xp_cmdshell. They also executed Base64-encoded PowerShell, allowing post-exploitation instructions to be passed through the database connection instead of relying on an obvious standalone command-and-control channel.
This matters because a database connection can become much more than a route for querying records. If an attacker has sufficient SQL Server privileges and can enable or invoke xp_cmdshell, the session can provide access to the underlying Windows operating system under the permissions available to the SQL Server service or configured proxy account.
The exact Microsoft SQL Server version was not disclosed. The reporting therefore does not identify a specific affected release or indicate that a newly discovered product vulnerability was exploited. The confirmed issue is abuse of powerful SQL Server functionality after access had already been obtained.
Files exfiltrated through query results
Secondary reporting described an unusual exfiltration method within the SQL Server attack. Files were divided into chunks, Base64-encoded and returned as text through SQL query results.
This approach kept data movement inside the existing SQL session. Rather than creating a separate outbound connection that might trigger network controls, the intruders could retrieve file contents through traffic that appeared to be part of normal database communication.
Base64 does not encrypt information, but it converts binary content into text that can be transferred more easily through query responses. Reassembling and decoding the chunks on the attacker side would restore the original files.
Credentials, DPAPI data and source code targeted
The recovered activity indicated several post-exploitation objectives. The attackers harvested credentials and collected Windows Data Protection API, or DPAPI, material that could potentially help decrypt secrets protected for particular users or systems.
SQL Server Management Studio connection artefacts were also collected. These can reveal server names, account details and connection history, giving attackers information about other databases that administrators access from a compromised host.
The operation gathered source code, configuration data and other files. Recovered evidence also showed preparation to reuse credentials against additional SQL and Server Message Block targets, although it did not prove that those attempts produced successful access.
Reported contents of the exposed attacker server included:
- Directories named loot and loot2.
- Files named cred_dec.txt, mdump.txt and httpd.log.
- Credential tools such as cred_dump.ps1, cred_enum.ps1 and chrome_dump.ps1.
- SQL scripts including sqlspray.ps1 and mssqltest.ps1.
- Data movement utilities including exfil.py and upload.py.
- Additional files named vault.cmd and vtest.ps1.
Secondary reports also mentioned recovered Mimikatz output and identified 151.243.232.123 as the alleged staging and loot server. These indicators were reported indirectly and should be validated before being used for blocking or incident attribution. ThreatMon withheld victim-specific addresses and other sensitive information from its public account.
Current exploitation status and organisational risk
This was confirmed in-the-wild post-exploitation, not a proof of concept for a single vulnerability. ThreatMon documented victim-side SQL command execution, credential collection and preparation for lateral movement during the September activity window.
The SQL Server attack demonstrates how a database service can be repurposed after compromise. For organisations running self-hosted SQL Server on Windows, particularly those with legacy configurations, database monitoring should account for operating-system commands and data encoded inside query results.
Because the initial access route remains unknown, the incident does not support claims that all SQL Server installations are directly exploitable. Exposure depends on existing access, account privileges, configuration and whether controls can detect xp_cmdshell being enabled or used.
Actions for Microsoft SQL Server defenders
Organisations should first establish whether xp_cmdshell is enabled on any SQL Server instance and document the operational reason. Where it is unnecessary, it should remain disabled. Changes to its configuration should generate an investigation rather than being treated as routine administration.
Defenders should review activity from 25 to 29 September 2026 where relevant and examine:
- Execution of xp_cmdshell, including attempts to enable it.
- SQL queries containing Base64 data, encoded PowerShell or unusually large text results.
- SQL Server processes launching command shells, PowerShell or credential tools.
- Access to DPAPI material and SQL Server Management Studio connection artefacts.
- Connections from database hosts to unexpected SQL, SMB or internet destinations.
- Matches for the indirectly reported filenames and staging server address.
Any identified credential collection should prompt scoping beyond the database host. Potentially exposed passwords, service accounts and saved database connections may provide routes to other SQL or SMB systems, even though successful lateral movement was not confirmed in this case.
Originally reported by cybersecuritynews.com.
