Exposed Hacker Server Reveals Toolkit Used in Viva Aerobus-Linked Intrusion

A publicly exposed attacker staging server has provided a rare, detailed view of a Microsoft SQL Server-focused intrusion linked to a Viva Aerobus-side environment.

The server, hosted at 151.243.232.123, functioned as both a tool-delivery point and a repository for stolen material.

It was left accessible without authentication, allowing unrelated internet hosts to enumerate its directories and retrieve offensive tooling shortly after a victim-side Microsoft SQL Server downloaded a payload from the same infrastructure.

ThreatMon identified the activity during routine threat-hunting operations and reconstructed a workflow centered on MSSQL command execution, credential access, data staging, and preparation for credential reuse across additional SQL and SMB targets.

The intrusion appears to have used Microsoft SQL Server as an execution platform through xp_cmdshell.

This extended stored procedure can launch operating-system commands from an SQL Server session when enabled.

At 16:20 on September 25, a victim-side MSSQL server retrieved a payload from the attacker-controlled host.

Recovered scripts indicate the attackers used xp_cmdshell to execute Windows commands and Base64-encoded PowerShell payloads, likely under the SQL Server service account.

This approach can be especially dangerous in environments where database servers hold privileged credentials, contain connection strings, or have access to internal file shares.

It also reduces the attacker’s need to deploy a conventional malware implant or create a separate command-and-control channel.

Recovered tooling could read files, split them into Base64-encoded chunks, and return the content through MSSQL query output.

That method enables data transfer through an existing SQL execution path rather than requiring a new outbound network connection.

Organizations should treat unusual xp_cmdshell activity, particularly executions of cmd.exe or powershell.exe, as a high-priority detection and incident-response trigger.

The exposed server contained 17 named post-exploitation tools and related artifacts.

Files included chrome_dump.ps1, cred_dump.ps1, and cred_enum.ps1, which were designed to extract credentials from browser stores, Windows credential stores, and other locally available sources.

Other recovered tools, including sqlspray.ps1 and mssqltest.ps1, were intended to test credentials against SQL Server targets.

Scripts named exfil.py and upload.py supported file transfers, while vault.cmd and vtest.ps1 were likely associated with Windows Credential Manager or Vault access.

The infrastructure also exposed loot/ and loot2/ directories, along with artifacts such as cred_dec.txt, mdump.txt, and httpd.log.

ThreatMon researchers discovered that, the unauthenticated server on September 25, 2026, exposing post-exploitation tools, credential-dumping output, SQL Server Management Studio (SSMS) artifacts, and files apparently collected during the operation.

Viva Aerobus Intrusion

ThreatMon published SHA-256 indicators for exfil.py, upload.py, and sqlspray.ps1, enabling defenders to hunt for direct file matches rather than relying only on potentially changed filenames.

Credential-access activity relied on Mimikatz, PowerShell, browser credential theft, Windows Credential Manager targeting, and attempts to recover Data Protection API-protected material.

The collection of SSMS user settings was particularly significant because it may reveal historical SQL Server connections, database usernames, and protected saved-password data.

Such artifacts can provide attackers with a practical map of internal databases and privileged accounts for later credential-reuse attempts.

ThreatMon withheld victim-specific hostnames, usernames, and DPAPI-protected content from public reporting.

Researchers also found evidence that the threat actor collected source code and configuration material containing references to SQL, OAuth, email, SFTP, payment, and reporting integrations.

While ThreatMon did not publish any sensitive values, the activity indicates an effort to identify embedded secrets, service credentials, and integration paths that could support expanded access.

Recovered scripts also tested SQL credentials, enumerated effective login identities and SQL Server role membership, and probed SMB administrative-share access.

ThreatMon assessed that SSMS metadata and configuration files likely informed at least part of the attacker’s follow-on targeting.

However, the available evidence does not confirm successful lateral movement, access to additional systems, or exfiltration of sensitive passenger, payment, or equivalent business data.

The activity supports credential harvesting and lateral-movement preparation, not confirmed downstream compromise.

The incident also demonstrates how attacker operational-security failures can create a second compromise event.

At 16:21, within minutes of the victim-side payload retrieval, an unrelated external host began enumerating the exposed staging server and its loot directories.

Additional external hosts accessed tooling and loot artifacts between 18:04 and 18:05.

ThreatMon mapped the observed behavior to PowerShell execution, Windows command-shell use, OS credential dumping, password-store theft, unsecured credentials in files, remote-services preparation, data staging, and exfiltration over an existing command channel.

The case highlights a critical defensive lesson: exposed attacker infrastructure may contain tools, credentials, collected files, and victim-derived intelligence that should be considered compromised by multiple parties.

Security teams should investigate suspicious MSSQL activity, turn off xp_cmdshell where it is not required, rotate potentially exposed database credentials, and review SQL Server service-account privileges and outbound connections.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC