SQL Injection to RCE: When Containment Is Not Remediation

A database server is not supposed to run shell commands.

When one does, something upstream has already gone badly wrong.

This is an account from our incident response desk of a case where a single web form field ended with an attacker running operating system commands on a production database host.

The customer and every identifier are generalised, and some details are deliberately left out.

The chain, the mistakes, and the hunting are the point, and those travel to any environment running the same pattern.

The one line worth carrying out of it: the host was contained, the containment was lifted while the hole was still open, and the attacker walked back in the same day through the identical path.

The short version

What happened.

An external attacker found a SQL injection flaw in a public web service.

The service connected to its database as a full administrator login, so the injected SQL inherited sysadmin rights.

From there it switched on a database facility that runs operating system commands, and used it to execute on the database host.

A web application firewall sat in front of the service, and it did not stop the injection.

Why it reached that far.

Two defects, and either one fixed alone would have stopped it.

The query was built by concatenating user input instead of using parameters.

The service connected as a sysadmin login instead of a least privilege account.

The turning point.

The host was network contained within a couple of hours of the first command execution, an action taken on the customer side.

Containment was lifted later that day while the application flaw was still unpatched.

The attacker returned within hours and escalated from reconnaissance to harvesting credentials and mapping the wider database estate.

What we could and could not say.

We confirmed the compromise end to end from web, database, and endpoint telemetry.

We could not clear data exposure, because database read auditing was off and some of the estate had no sensor.

We said so plainly, rather than letting a quiet console read as an all clear.

What we did not do.

We did not change a single setting.

The whole investigation was read only, under the managed detection engagement.

Containment, release, and remediation were all customer actions.

How a web field became a shell

The flaw lived in a legacy web service on the public tier.

It took input from the request and built a database call by pasting that input straight into the SQL text, rather than passing it as a parameter.

That is the whole of SQL injection in one sentence: input that was meant to be data is run as code.

On its own, a SQL injection against a well scoped database account is serious but bounded.

The attacker can read and write what that account can reach, and no more.

This account was not well scoped.

The web service connected to the database as the server's full administrator login.

So the injected SQL did not run as a limited application user.

It ran as the database server itself.

With that level of access, the attacker enabled a built in database facility that runs operating system commands, a facility that had been left on for legitimate automation, and began issuing commands on the host.

The database process spawned a command shell.

That single parent to child relationship, a database engine launching a command interpreter, is the cleanest signal in the whole case, and we come back to it in the hunting section.

The uncomfortable part is how ordinary each ingredient is.

A legacy service nobody had revisited.

A connection string that used the administrator login because it was convenient years ago.

A database feature switched on for a real reason and never switched back off.

None of them is remarkable alone, and together they are remote code execution.

When a WAF is not enough

The obvious question at this point is where the web application firewall was.

It was right there.

A WAF sat in front of the service, and the injection reached the application anyway.

That surprises people, and it should not.

A WAF inspects requests and blocks the ones that match what it knows to look for.

It is a filter at the edge, and a good one narrows the attack surface.

It is not the same thing as code that cannot be injected.

An injection gets past a WAF for ordinary reasons.

The vulnerable method sits on a path or a parameter the policy was not inspecting closely.

An exclusion was added once to stop a false positive and quietly widened the gap.

Or the payload was shaped to read as legitimate input and slipped through on its merits.

Running down which of those happened here is part of closing the case, and the answer does not change the lesson.

A WAF in front of an injectable application buys you time and noise reduction.

It does not make the application safe, and treating a deployed WAF as proof that the app is protected is how an injectable endpoint stays injectable for years.

The only thing that closes SQL injection is the code behind the WAF.

Two phases, one open door

The intrusion ran in two acts, and the gap between them is the lesson.

Phase one, that morning.

The attacker swept the web service with injection probes, confirmed command execution, created an output table in the database to capture results, and ran a round of host reconnaissance.

Who am I, what account is this, what is the network around me.

The command execution was detected quickly and the host was network contained within roughly two hours.

Worth sitting with: the injection sweep had been running against the web tier for the better part of an hour before anything fired.

The first alert came from the last link in the chain, the database spawning a shell, not from the injection that started it.

Our first read, stated at the time, was reconnaissance only, impact limited to the one host.

Phase two, that evening.

Containment was lifted while the application flaw was still open.

Within hours the attacker returned through the same web service, because nothing about the way in had changed.

This time they escalated.

They read the vulnerable service's own source code, so they now understand the flaw better than most of its maintainers.

They searched configuration files for connection strings and passwords, queried the operating system credential store, and hunted for certificates and private keys.

They mapped the internal network and enumerated the wider database estate, then opened outbound connections on the database port to a long list of internal and external hosts to test what they could reach.

Our morning assessment did not survive the evening.

That is why the headline of this post is not about SQL injection.

It is about what containment is and is not.

Containment buys you time. It does not fix anything.

A contained host is a paused problem, not a solved one.

The only thing that closes a SQL injection to RCE path is correcting the code and reducing the database account, and until that is done the host must stay isolated.

Lifting containment before the fix is live is reopening the door and hoping nobody is still outside.

Someone was.

What we could not see, and said so

The investigation was read only.

We reviewed web server logs, database trace and cached queries, and endpoint process, network, and logon records.

We changed nothing, and every query we ran was recorded with its provenance for the case file.

That discipline includes being honest about the edges of what the evidence can prove.

A record only tells you what it was able to record.

Three blind spots shaped this case, and all three went into the report as limitations rather than being quietly ignored.

Database read auditing was off.

We found no evidence of bulk data extraction in the telemetry we had, and we found no references to sensitive customer data in the cached queries that survived.

That is not a clearance.

Successful read auditing was disabled, the query cache is incomplete and ages out, and the contents of the attacker's own output table were not readable without database access we did not have.

So the honest finding is that data exposure could not be excluded, not that it did not happen.

Part of the estate had no sensor.

The attacker probed other database hosts, and several of them carried no endpoint sensor.

No alert from a host that cannot raise one is not evidence of safety.

We listed those hosts as unexamined, because absence of evidence from a blind host is not evidence of absence.

Endpoint history had a horizon.

The endpoint record covered roughly a month.

Anything before that window simply was not in view, and we said so rather than treating the edge of the data as the edge of the activity.

The most dangerous sentence in an incident report is "no evidence of X" when it is written where it should say "we could not see X."

The first sounds like safety.

The second is the truth, and it is the one that gets the audit logging turned on.

Two defects, two fixes, and why both matter

The root cause is not one bug.

It is two, and defence in depth means either one alone would have held.

Fix the injection.

The data access code must pass user input as parameters, never concatenate it into the query text.

This is the actual vulnerability, and it is the one the attacker now knows intimately because they read the source.

Reduce the database account.

A web service should connect with a login scoped to exactly the tables and operations it needs, and nothing else.

Had this service used a least privilege account, the same injection would have been contained to the data layer.

No sysadmin rights, no operating system command facility, no shell.

There is a third layer worth switching off, with one caveat that matters.

The database facility that runs operating system commands, along with other extensibility features a typical application never needs, should be disabled unless a specific documented job requires it.

But be clear about what that buys you.

When the service connects as a sysadmin login, turning the feature off is hygiene, not a boundary, because an injection running with sysadmin rights can turn it back on.

The only thing that actually bounds the injection is the privilege of the login it runs as.

That is why moving the service to a least privilege account, which is a connection string change rather than a code change, is the fastest control that genuinely contains this, and it was available the entire time the host sat contained.

Hunting for this in CrowdStrike NextGen SIEM

If you run a database tier, you can hunt for this pattern now, before an alert ever fires.

The queries below are generic DFIR hunts in CrowdStrike Query Language, drawn from our own NextGen SIEM pack.

One honest caveat first, the same one our engineers work under.

The tool surface is stable, but NextGen SIEM field names and event names vary by environment and schema version, so treat every query below as a starting shape and confirm the field names against your own data before you rely on a result.

Run a census of the event types your own tenant emits first, because a field the schema does not recognise silently becomes free text and returns nothing.

A query that has never returned a hit has proven nothing by returning nothing.

These are read only hunts.

They find behaviour, they do not make a verdict, and a hit is the start of an investigation, not the end of one.

1. The database engine spawned a shell.

This is the signal that would have caught both phases of this case on the first command.

A database process has almost no legitimate reason to launch a command interpreter.

#event_simpleName=ProcessRollup2 event_platform=Win
| ParentBaseFileName=/^sqlservr\.exe$/i
| ImageFileName=/\\(cmd|powershell|pwsh|wscript|cscript|bitsadmin|certutil)\.exe$/i
| table([ComputerName, UserName, ParentBaseFileName, ImageFileName, CommandLine])

2. The web worker process spawned an interpreter.

A web server worker launching a shell is the classic tell of a web exploit or a web shell, one tier upstream of the database.

Expect this one to come back empty for an injection that executes down in the database tier, and that is the lesson rather than a disappointment.

An empty web tier is not a clean web tier, which is exactly why you also run query one against the database tier.

#event_simpleName=ProcessRollup2 event_platform=Win
| ParentBaseFileName=/^w3wp\.exe$/i
| ImageFileName=/\\(cmd|powershell|pwsh|mshta|rundll32)\.exe$/i
| table([ComputerName, UserName, ImageFileName, CommandLine])

3. Attribute the outbound database port fan out to a process.

In phase two the attacker opened outbound connections on the database port to many hosts to test reach.

This join ties each outbound connection back to the process that made it, so a database host suddenly calling many others stands out.

(#event_simpleName=NetworkConnectIP4 OR #event_simpleName=NetworkConnectIP6)
| RemotePort=1433
| join({ #event_simpleName=ProcessRollup2 | table([aid, TargetProcessId, ImageFileName, CommandLine]) },
       field=[aid, ContextProcessId], key=[aid, TargetProcessId], include=[ImageFileName, CommandLine])
| groupBy([aid, ComputerName, ImageFileName], function=count(RemoteAddressIP4, distinct=true, as=distinct_targets))
| distinct_targets >= 5
| sort(distinct_targets, order=desc, limit=50)

4. Credential access on the host.

Phase two went after secrets.

This surfaces the common credential dumping tradecraft so you can see it against the same host and window.

#event_simpleName=ProcessRollup2 event_platform=Win
| CommandLine=/comsvcs\.dll.*MiniDump|procdump(64)?.*lsass|reg(\.exe)?\s+save\s+.*\\(sam|security|system)|\bmimikatz\b|sekurlsa|lsadump/i
| table([ComputerName, UserName, ParentBaseFileName, ImageFileName, CommandLine])

5. Establish visibility before you trust a negative.

Run this first, not last.

It gives you each host's first and last telemetry in the window, so when you say a host shows nothing, you know whether that is because nothing happened or because the sensor was not watching.

#event_simpleName=*
| groupBy([aid, ComputerName, event_platform], function=[min(ContextTimeStamp, as=firstSeen), max(ContextTimeStamp, as=lastSeen), count(as=events)])
| sort(lastSeen, order=asc, limit=1000)

The order matters.

Query five is what separates "this host is clean" from "this host is dark," and that distinction is the whole difference between an honest finding and a comforting one.

A note on the findings beside the findings

An engagement almost always turns up exposures that had nothing to do with the intrusion.

A stale privileged account here, an over powerful remote access tool there.

They were not the way in this time, and they are the way in next time for someone.

The discipline is to report them separately, label them clearly as unrelated to the attack, and resist the urge to weave them into the story, because an incident narrative that absorbs every loose end stops being evidence and starts being a morality tale.

What to take from this

1. Contain, then fix, then release, in that order. A contained host with an unpatched flaw is a countdown, not a resolution.
2. No web service should hold sysadmin on its database. Least privilege turns a breach into a bounded one.
3. A WAF is a filter, not a fix. It narrows exposure, and the injection still landed. Verify coverage and exclusions, and never read a deployed WAF as a secure application.
4. Turn off the features nobody uses. The operating system command facility in a database is a gift to an attacker and a convenience to almost no one.
5. Write down what you could not see. Disabled auditing, unmonitored hosts, and aged out logs are findings, not footnotes.
6. Hunt the behaviour, not just the signature. A database engine spawning a shell is true across every variant of this attack, and you can look for it today.

What we still do not know

An honest case closes some questions and names the ones it cannot.

Whether regulated data was read.

With database read auditing off and the attacker's own output table unread without credentials we did not hold, exposure can be neither confirmed nor excluded.

Whether any of the outbound database connections authenticated.

We saw the connection attempts.

We did not see a successful login at the other end.

Whether anything was left behind in the database.

The object change records we could read showed no attacker procedures, functions, triggers or views, but the scheduled job state and the live in database state were not ours to read on a read only engagement.

None of these is a loose end we forgot.

Each is a question that needs access or auditing we did not have, and saying so is the difference between an investigation and a reassurance.

When you need an incident handled this way

At QMasters, we run digital forensics and incident response as part of StrongHold MCSS, read only by default, with provenance on every step and a report that states what it could not prove as clearly as what it could.

For help reviewing the application and privilege controls behind an incident, explore expert consulting.

If you are mid incident, start with our incident response first 24 hours playbook.

If you want the detections in place before you need them, talk to a security expert and we will walk your database tier against the hunts above.

---

Author · QMasters DFIR

Last updated · 2026-10-03

Reading time · 12 min