One Minute to a Second Visitor: The Viva Aerobus-Linked Loot Server and the SQL Logins It Was Mapping

At 16:20 on 25 September, a Microsoft SQL Server on the victim side of a Viva Aerobus-linked environment reached out and pulled a payload from 151.243.232.123. At 16:21, a completely unrelated host on the internet started enumerating that same server.

One minute. That's how long the attacker kept their staging box to themselves.

ThreatMon's threat intelligence team found the server during routine hunting and published two write-ups this week. The box had no authentication at all. It served the operator's working directories over plain HTTP: 17 named post-exploitation tools, two loot folders called loot/ and loot2/, decrypted credential output and the server's own access log. GBHackers and Cyber Security News both covered the findings, and the facts below line up across ThreatMon's reports and that coverage.

Scope first, because it matters. ThreatMon says it found no evidence of successful lateral movement and no confirmed exfiltration of passenger, payment or equivalent business data. This isn't a "millions of records" story. It's something I find more useful as an intel analyst: a rare look at an intrusion caught mid-thought, with the operator's plan sitting in a public folder.

Reading the directory listing

When I review leaked attacker infrastructure, I read the filenames first. Names are cheap for the operator and honest for the analyst. Nobody calls a script sqlspray.ps1 by accident.

Here's what ThreatMon recovered, grouped by purpose:

Stage	Files	What it tells you
Execution	xp_cmdshell, encoded PowerShell	The database was the shell
Local credential theft	chrome_dump.ps1, cred_dump.ps1, cred_enum.ps1, mdump.txt	Browser stores, Windows credential stores
Stored-secret access	vault.cmd, vtest.ps1	Windows Credential Manager, per GBHackers' reading
Credential reuse	sqlspray.ps1, mssqltest.ps1	Testing logins against other SQL servers and SMB shares
File movement	exfil.py, upload.py	Pulling loot back out
Output	cred_dec.txt, httpd.log, SSMS metadata	Decrypted secrets and a log of who came to look

Read top to bottom, that's a workflow. Get execution through SQL. Collect every credential the box already holds. Then test those credentials against anything else that speaks the same protocols. The two loot folders, per GBHackers, also held configuration referencing OAuth, SFTP, mail and payment integrations, though ThreatMon withheld the values.

ThreatMon ties the activity to two handles, Blackhatsect0r and DXQRTXX. I haven't seen independent attribution for either, so treat those as ThreatMon's labels, not a confirmed group.

One more thing the filenames give away: there is no persistence tooling in the recovered set, no custom implant, nothing that screams nation-state tradecraft. This reads like credential-focused crime. The goal wasn't to live on the box forever. It was to grab what logged in from there and move on to the next database before anyone noticed. That matters for defenders because it tells you what to protect: not the server's uptime, but the credentials that pass through it.

The database was the quiet channel

The execution method is old, and that's why it keeps working. xp_cmdshell is a SQL Server feature that runs an operating-system command and hands the output back as rows. It ships disabled. On this victim, somebody had enabled it, or an account with enough rights did so during the intrusion.

The detail worth sitting with is how data came back out. Per ThreatMon, files were "broken into Base64 chunks and returned through MSSQL query output."

Think about what that does to network monitoring. There's no beacon to a strange domain, no new outbound port. The data rides back inside the same SQL session on 1433, looking like a query that returned a lot of text. If your entire detection plan for a database server is "alert on unusual egress," this traffic blends into normal application noise. That's the lesson for defenders, not a recipe: a database host needs query-level and authentication-level telemetry, not just a firewall watching the edge.

Why a boring database host keeps ending up first

Step back from this one server and the pattern is familiar. Unit 42's 2026 Global Incident Response Report put identity weaknesses at the center of 89% of the investigations it ran, with identity-based techniques behind 65% of initial access. A SQL Server with command execution and a pile of cached logins is identity risk wearing a database costume. The foothold is technical; everything valuable that comes after is a credential.

What makes database hosts a soft first target is less glamorous than a zero-day. They tend to run with powerful service accounts. They're trusted deep inside the network, so lateral traffic from them looks ordinary. DBAs connect to them from admin workstations that cache logins for convenience. And they're monitored for performance far more than for authentication anomalies. Put those together and you get a host that is simultaneously high value, widely trusted and lightly watched. That's the profile an intruder wants under their first set of stolen credentials.

The Viva Aerobus-linked case is a clean illustration rather than an outlier. The operator didn't need novel tooling. They needed one database to say yes, and then a place to stand while they read everything that database could tell them about its neighbors.

The SSMS settings file is a map, not just a password

Here's the finding that should change how DBAs set up their own workstations and jump boxes.

ThreatMon recovered SQL Server Management Studio user settings containing "previously used server references, database usernames, and DPAPI-protected saved-password data." Its own phrase for what that handed the attacker: "a map of potential follow-on targets."

That phrasing is exact, and the second half of it is the part most teams underrate.

If you've ever ticked "Remember password" in the SSMS connect dialog, three things got saved to a per-user settings file: the server name, the login, and an encrypted copy of the password. The password is wrapped with DPAPI, which binds it to that Windows user, so defenders tend to stop at "it's encrypted, we're fine."

The encryption is the least interesting part. The server list is the prize. Even with every password still sealed, that file tells an intruder the exact hostnames and usernames of every other database this operator touches. It turns a single compromised box into a directory of the rest of the estate. Where to go next stops being a guessing game.

So the practical guidance isn't "trust DPAPI." It's: don't let SSMS cache credentials on shared or internet-reachable hosts, prefer Windows or Entra authentication over saved SQL logins, and treat the SSMS settings file on any admin machine as sensitive inventory in its own right. The map is dangerous even when the keys on it still work.

Where deception changes this specific shape of attack

I spend most of my time tracking campaigns, not selling tools, so take this as analysis. The Viva Aerobus-linked intrusion has a feature that makes it a near-perfect case for deception: every stage after the first foothold depends on reusing credentials the attacker believes are real.

sqlspray.ps1 and mssqltest.ps1 exist to answer one question over and over: does this login work on that server? That is a question a defender gets to answer with a lie.

Seed the SSMS histories, the credential stores and the config files on a database host with a fake SQL login that points at a decoy server, and you've planted a tripwire exactly where this workflow reaches next. The first sqlspray attempt against the decoy fires an alert. Nobody legitimate ever authenticates with that login, because nobody legitimate knows it exists, so there's nothing to tune and no false positive to dismiss. That's the whole argument behind honeytokens as a trap for credential reuse: the signal is the use itself.

The decoy server side matters just as much. A MineField decoy service listening where no production system should be gets touched only by something scanning or spraying. Pair that with the earlier point about SQL being a quiet execution channel and you get a useful split: you may not catch the first query, but you can make the second, third and fourth steps, the credential reuse, light up loudly. We walked through the same logic for Active Directory in our breakdown of Kerberoasting and decoy accounts, and the shape is identical here. Deception doesn't care how the intruder got the first set of credentials. It cares that they try to use the next one.

The part nobody planned: the open door swung both ways

One last thread, because it's the detail I can't stop thinking about.

Within a minute of the victim box pulling its payload, an unrelated external host was already enumerating the staging server. By 18:04 to 18:05, more outside hosts were reading the toolkit and the loot folders. The operator ran an unauthenticated HTTP server holding decrypted credentials, and the internet noticed in roughly sixty seconds.

So the stolen credentials in those loot folders may have been copied by people the original attacker never intended to share with. Victim data exposed once by an intrusion, then exposed again by the intruder's own sloppiness. For the organization on the receiving end, "assume the credentials are burned" is the only safe reading. Rotate everything that lived on that SQL host, and anything an admin ever typed into SSMS from it, as if it's already public. It may well be.

That's also why the count ThreatMon could not confirm, the number of records actually taken, is the wrong thing to anchor on. The right question is how many credentials sat on that box, because each one is a door into somewhere else, and for about a minute, and then again that evening, the doors were open to anyone.

If you run SQL Server anywhere an attacker could reach a service account, the move worth making this week is to map where your own logins are cached and drop a few decoy credentials among the real ones. Start a Mine2 deception pilot and watch which fake login gets sprayed first. In an intrusion built on credential reuse, the lie you plant is the alarm you've been missing.