A database is normally viewed as a place where organisations store and manage information.

But when attackers gain sufficient access to a database server, its legitimate administrative capabilities can potentially become tools for further intrusion.

A recent investigation by cybersecurity researchers at ThreatMon highlights this risk after identifying malicious activity linked to a Viva Aerobus-side environment in September 2026.

According to the investigation, attackers abused Microsoft SQL Server functionality to execute Windows commands, collect credentials and handle files through the database environment.

Importantly, the available evidence does not establish how the attackers initially gained access, nor does it confirm that passenger or payment information was successfully stolen.

The incident nevertheless demonstrates an important cybersecurity principle:

A trusted system can become an attack platform when its legitimate capabilities are abused.

How SQL Server Became Part of the Attack

The investigation identified the use of Microsoft's xp_cmdshell functionality.

xp_cmdshell allows SQL Server to execute operating-system commands. While it can have legitimate administrative uses, Microsoft recommends that it remain disabled when it is not required.

In this incident, ThreatMon reported that attackers used the functionality to execute commands on the underlying Windows system.

This potentially gives an attacker capabilities beyond simply reading or modifying database records.

Instead, the database server can become a gateway to the operating system itself.

Using SQL Server to Handle Files

ThreatMon also reported the discovery of tooling capable of reading files, splitting their contents into smaller portions and converting the information into Base64-encoded text.

The encoded information could then be returned through SQL query output.

Base64 itself is not encryption. It is simply a way of representing data as text.

From an attacker's perspective, however, using an existing database communication mechanism can provide another way of moving information through an environment.

This demonstrates why security teams should not monitor only traditional malware or obviously suspicious network connections.

Legitimate applications and services can also be abused.

Credential Collection Was Part of the Activity

The investigation also identified tools and scripts associated with credential discovery.

Reported artifacts included components associated with:

• Windows credential collection
• Browser credential collection
• SQL Server credentials
• Mimikatz-related functionality
• SQL Server connection information

Credentials are particularly valuable to attackers because they may provide access to additional systems.

However, finding credential-harvesting tools does not automatically prove that every credential was successfully obtained or subsequently used.

This distinction is important when analysing cybersecurity incidents.

Security researchers often discover evidence of what attackers attempted to do, but attempted activity and confirmed successful activity are not necessarily the same thing.

Preparing for Possible Lateral Movement

ThreatMon also identified tools capable of testing SQL credentials against other systems and checking Windows SMB administrative shares.

These capabilities can be associated with attempts to discover or access additional systems inside a network.

This is commonly known as lateral movement.

However, the presence of these tools does not by itself prove that attackers successfully compromised additional systems.

It demonstrates why defenders should pay attention to unusual authentication attempts and connections originating from database servers.

The Attackers' Infrastructure Was Also Exposed

One of the more unusual findings from the investigation involved infrastructure reportedly used by the attackers.

ThreatMon found that a server associated with the activity was accessible from the public internet.

Other unrelated internet hosts subsequently accessed material stored on that infrastructure.

This illustrates another cybersecurity lesson:

Attackers can make security mistakes too.

Infrastructure used to support an attack can itself become exposed, potentially allowing researchers or unrelated parties to discover tools, files or other evidence.

Why xp_cmdshell Deserves Attention

The incident highlights why organisations should carefully review powerful administrative features.

Microsoft SQL Server's xp_cmdshell is not malware.

It is a legitimate SQL Server capability.

The security risk comes from what happens when an attacker obtains sufficient privileges to abuse it.

Microsoft documents that xp_cmdshell is disabled by default on new installations and recommends avoiding its use in newly developed applications. Organisations that require it for legitimate legacy processes should carefully control and monitor its use.

This reflects a broader cybersecurity problem.

Attackers do not always need to install something obviously malicious.

Sometimes they can abuse tools that are already present on the system.

Legitimate Tools Can Become Attack Tools

This pattern appears across cybersecurity.

PowerShell is a legitimate Windows administration tool.

Command Prompt is legitimate.

SQL Server is legitimate.

Remote administration tools are legitimate.

Cloud services are legitimate.

The security question is therefore not simply:

"Is this tool malicious?"

Instead, organisations need to ask:

"Is this tool being used in a way that is unusual for this system?"

For example, a database server normally performing database operations may be expected.

A database server suddenly launching PowerShell, executing Windows commands and making unusual external connections deserves investigation.

What Security Teams Can Learn

Organisations running SQL Server can use incidents like this to review their own security controls.

Review unnecessary functionality

Determine whether features such as xp_cmdshell are actually required.

If they are not required, disabling them can reduce the potential attack surface.

Apply least privilege

Database accounts and service accounts should have only the permissions necessary to perform their functions.

Excessive privileges can increase the impact of a compromised account.

Monitor unusual process activity

Security teams should investigate unexpected relationships between SQL Server and operating-system processes such as:

• cmd.exe
• PowerShell
• Script interpreters
• Unknown executables

Monitor database server network traffic

A database server making unusual outbound connections may warrant investigation, particularly when combined with suspicious process activity.

Protect credentials

Organisations should avoid unnecessary credential storage and password reuse.

Compromised database credentials can potentially provide attackers with opportunities to explore other systems.

Maintain detailed logging

Logs can help security teams reconstruct what happened after suspicious activity is discovered.

Without sufficient logging, determining whether an attacker merely attempted an action or successfully completed it can become much more difficult.

What We Know — and What We Don't

Based on the publicly reported investigation, researchers identified activity involving:

• Microsoft SQL Server
• xp_cmdshell
• Windows command execution
• PowerShell-related activity
• Credential-discovery tooling
• File handling and Base64 encoding
• SQL credential testing
• SMB-related discovery
• Exposed attacker infrastructure

However, several important questions remain unanswered.

The public investigation does not establish the initial access method.

It also does not establish that attackers successfully compromised additional systems or stole passenger or payment information.

These limitations matter.

Good cybersecurity reporting should distinguish between:

Observed activity

Suspected attacker objectives

and

Confirmed impact.

Making that distinction helps organisations understand what actually happened instead of turning an investigation into speculation.

The Bigger Cybersecurity Lesson

The incident is a reminder that database security is not only about protecting the data stored inside a database.

The database server is also a computer.

If attackers gain sufficient privileges, they may attempt to use its legitimate capabilities to execute commands, discover credentials, interact with other systems or move information.

That means organisations should think beyond:

"Is our database protected?"

They should also ask:

"What could an attacker do with our database server if they gained access?"

That question changes the focus from simply preventing intrusion to also limiting the damage after a compromise.

Security Is About Limiting What Attackers Can Do

No security system can guarantee that an attacker will never gain access.

A stronger security strategy assumes that some security controls may eventually fail.

The goal then becomes limiting the attacker's options.

Disable unnecessary features.

Reduce privileges.

Protect credentials.

Monitor unusual behaviour.

Segment critical systems.

Record sufficient logs.

And investigate unexpected activity quickly.

The recent SQL Server investigation provides a useful reminder of why these principles matter.

A database may be designed to store information.

But in the wrong hands, its legitimate capabilities can become part of an attacker's toolkit.

The question is not only whether attackers can get into your systems.

It is what they can do after they get there.