On September 25, 2026, an attacker-controlled staging server used to host tools and stolen material was left exposed to the public internet with no authentication.
At 16:20, a victim-side Microsoft SQL Server retrieved a payload from the infrastructure. Within minutes, an unrelated external host began enumerating the same server and its exposed directories. By early evening, additional hosts had accessed the toolkit and loot.
ThreatMon’s Threat Intelligence Team identified the infrastructure during routine threat-hunting activity. What followed offered an unusually clear view into an MSSQL-focused post-exploitation workflow and showed how quickly an attacker’s own infrastructure failure can create a second exposure event.
ThreatMon identified an exposed, unauthenticated attacker staging and loot server at 151.243.232.123, linked to activity involving a Viva Aerobus-side environment between September 25–29, 2026.
A victim-side Microsoft SQL Server was used as an execution point through xp_cmdshell, supporting Windows commands and Base64-encoded PowerShell.
The exposed infrastructure contained 17 named post-exploitation tools, including credential-dumping scripts, Mimikatz output, SQL credential-testing utilities, and file-transfer tooling.
Files could be broken into Base64 chunks and returned through MSSQL query output, allowing data transfer without establishing a conventional C2 channel.
Recovered artifacts included SSMS connection history and DPAPI-protected saved-password material, which could be used to build target lists for subsequent SQL and SMB credential-reuse attempts.
Unrelated internet hosts accessed the exposed infrastructure shortly after the first confirmed victim-side activity, creating a secondary exposure risk for both the attacker’s tools and previously collected material.
ThreatMon found no evidence confirming successful lateral movement or the exfiltration of sensitive passenger, payment, or equivalent business data.
Much of the visibility into this intrusion came not from the victim environment, but from the attacker’s own infrastructure.
ThreatMon researchers identified an HTTP staging server being used to host tools, receive collected files, and support post-exploitation activity. The server had no authentication or effective access control separating its working directories from the public internet.
That exposure provided visibility into several stages of the operation.
Recovered HTTP activity, tooling, credential-access output, and SSMS artifacts allowed ThreatMon to reconstruct a workflow moving from MSSQL-based command execution to credential harvesting, configuration and source-code exposure, SSMS metadata collection, and preparation for credential reuse against additional systems.
The available evidence supports these stages through credential harvesting and lateral-movement preparation. It does not confirm successful access to additional systems.
The exposed server contained more than a single payload or isolated script. It held a compact post-exploitation toolkit built around an MSSQL-centric environment.
Among the recovered files were:
chrome_dump.ps1 and cred_dump.ps1 for extracting credentials from browser and Windows credential stores.
cred_enum.ps1 for enumerating available credentials.
sqlspray.ps1 and mssqltest.ps1 for testing SQL credentials against target systems.
exfil.py and upload.py for transferring files.
vault.cmd and vtest.ps1, likely associated with Windows Credential Manager or Vault access.
Two directories loot/ and loot2/ were also present alongside artifacts including cred_dec.txt, mdump.txt, and httpd.log.
Three recovered tools exfil.py, upload.py, and sqlspray.ps1 are included in the public IOC set with SHA256 hashes, allowing defenders to search for direct matches without relying solely on filenames.
Credential-access activity relied heavily on Mimikatz and PowerShell tooling targeting Windows Credential Manager, DPAPI, and browser credential stores.
One artifact was particularly useful for understanding what the attacker may have intended to do next: recovered SQL Server Management Studio user-settings data.
The material contained previously used server references, database usernames, and DPAPI-protected saved-password data. In the hands of an attacker, saved administrative connections can effectively become a map of potential follow-on targets.
ThreatMon withheld victim-specific hostnames, usernames, and DPAPI material from the public release.
The attacker’s workflow relied heavily on xp_cmdshell, an extended SQL Server stored procedure capable of executing operating-system commands when enabled.
Recovered tooling was designed specifically to use an MSSQL session to submit commands and execute Base64-encoded PowerShell through this mechanism.
The same access path was also used for file transfer.
Instead of establishing a separate outbound channel, recovered tooling could read a file, divide it into chunks, Base64-encode the content, and return those chunks through MSSQL query output.
This matters because the attacker did not necessarily need to establish a new communication path for data transfer. The existing SQL execution channel could also carry information back out.
For defenders, unusual xp_cmdshell activity particularly the execution of cmd.exe or powershell.exe under a SQL Server service account should therefore be treated as a high-priority investigation point.
Two additional activities followed the initial credential-access stage.
First, the attacker collected source code and configuration material containing references to SQL, OAuth, mail, SFTP, and payment or reporting integrations.
Sensitive values from those files have not been included in the public report, but the collection activity indicates an effort to identify credentials, secrets, or integrations that could potentially support further access.
Second, recovered tooling was designed to test username and password combinations against additional SQL targets and determine the effective login identity and server-role membership when authentication succeeded.
Companion tooling also tested SMB administrative-share access.
ThreatMon assessed that at least part of the targeting information used during this stage came from previously collected SSMS metadata and configuration files.
The recovered evidence demonstrates credential-reuse attempts and lateral-movement preparation, but does not establish that those attempts resulted in successful access to additional systems.
Secondary Exposure Risk: Sensitive material stored on an unauthenticated attacker staging server should be treated as potentially compromised by additional parties, even when downstream use cannot be confirmed.
In this case, the HTTP logs show that this risk materialized quickly.
The staging server’s HTTP activity provided a relatively precise sequence of events:
16:20 — A payload was requested locally from the staging server and subsequently retrieved by the victim-side MSSQL environment.
16:21–16:23 — An unrelated external host enumerated the staging server and exposed loot directories.
16:30 — Self-test-style requests were observed from the staging host.
18:04–18:05 — Additional external hosts retrieved post-exploitation tooling and loot artifacts.
The sequence illustrates two simultaneous security failures.
The infrastructure was functioning as intended from the attacker’s perspective, delivering tooling into the victim environment. At nearly the same time, its lack of authentication allowed unrelated systems on the internet to discover and access the same material.
The result was a secondary exposure event layered on top of the original intrusion.
ThreatMon mapped the observed activity to eight MITRE ATT&CK techniques spanning execution, credential access, staging, lateral-movement preparation, and exfiltration.
| Technique | Category | Observed Behavior |
|---|---|---|
| T1059.001 | Command and Scripting Interpreter: PowerShell | Encoded PowerShell executed through xp_cmdshell |
| T1059.003 | Command and Scripting Interpreter: Windows Command Shell | OS commands executed through xp_cmdshell |
| T1003 | OS Credential Dumping | Mimikatz execution artifacts |
| T1555 | Credentials from Password Stores | Credential Manager, Vault, and browser credential stores targeted |
| T1552.001 | Unsecured Credentials: Credentials in Files | Credential and secret discovery in source code and configuration files |
| T1021 | Remote Services | Lateral-movement preparation through MSSQL and SMB |
| T1074 | Data Staged | Collected files retained in staging and loot directories |
| T1041 | Exfiltration Over C2 Channel | Base64-chunk transfer through MSSQL output |
The public IOC set is deliberately limited to attacker-side infrastructure and artifacts:
IPv4151.243.232.123
Exposed attacker staging/loot server
SHA256 — exfil.pyc38f49ba68b891bb476510704cddf080798f3c70075e2a517e98e04e833f64fa
SHA256 — upload.py33aeaaa3d57b7785ef2be5b8ccd39d534b8af50e0cd32a5036fdb64601a52fc9
SHA256 — sqlspray.ps18b6c53e3d57b4c3049f3d0765a44d9a52feb6af78f1eaa5aff19daf1b9665998
Windows PathC:\Windows\Temp\artex
Victim IP addresses, internal server names, SQL instance names, usernames, credential dumps, DPAPI blobs, OAuth identifiers, mail/SFTP/SQL credentials, partner-specific configuration, and victim-side source-code material have been excluded from the public release.
The exposed infrastructure provides several concrete detection opportunities for defenders.
Organizations should review historical network telemetry for connections involving 151.243.232.123 and search endpoints for the published file hashes and the working directory C:\Windows\Temp\artex.
SQL Server environments deserve particular attention.
Unexpected activation or use of xp_cmdshell, especially when followed by cmd.exe, PowerShell, encoded commands, or unusual file operations under a SQL Server service account, should be investigated immediately.
SSMS metadata should also be treated as sensitive credential-adjacent information. Saved connections, connection history, usernames, and DPAPI-protected password material can provide attackers with a structured map for credential reuse and lateral-movement attempts.
Finally, credentials or secrets known to have reached exposed staging infrastructure should be considered compromised regardless of whether subsequent abuse has been observed. Once attacker-controlled infrastructure becomes publicly accessible, there is no reliable way to assume that the original operator remained the only party with access.
This incident demonstrates both sides of exposed attacker infrastructure: it can provide defenders with rare visibility into post-exploitation workflows, while simultaneously increasing the exposure of material already taken from a victim.
More posts
Share this article
Found it interesting? Don’t hesitate to share it to wow your friends or colleagues
Subscribe to our blog newsletter to follow the latest posts
