September 7, 2026

One Web Vulnerability. One Pivot. The Entire Domain.

The initial foothold wasn’t the interesting part. It was what the server could see from the inside.

By Suyash

6 min read

The initial foothold wasn't the interesting part. It was what the server could see from the inside.

During a controlled security assessment, I came across a command injection vulnerability in an internet-facing web application.

The vulnerability itself wasn't particularly complicated.

The application was passing user-controlled input into an operating-system command without properly handling it.

A few requests later, I had command execution on the underlying Linux server.

At this point, I had a shell.

But getting a shell is one thing. Figuring out what that shell actually gives you is another.

So before going deeper into the application, I started with a much simpler question:

Where am I?

And then the more interesting one:

What can this machine reach that I can't?

Note:_ All organization names, hostnames, IP addresses, usernames, passwords, endpoints, and other sensitive details have been changed or sanitized for this write-up._

The First Foothold

The compromised server looked like a fairly normal production web server.

Nothing immediately stood out.

So I started doing the usual post-compromise enumeration — hostname, network interfaces, routes, running services, and the application environment.

That's when I noticed something I wasn't expecting.

The server had connectivity into a separate internal network segment.

From my attacking machine, that network wasn't directly reachable.

From the compromised web server, it was.

That changed the situation.

I didn't just have a compromised web server anymore.

I had a machine sitting on the other side of a network boundary.

Attacker
   |
   ▼
Web Application
   |
   ▼
 WEB01
   |
   ▼
Internal Network

The command injection had given me code execution.

The network configuration had potentially given me a way further into the environment.

Turning the Web Server Into a Pivot

At this point, I could have continued enumerating WEB01.

But I already had something more interesting to work with.

I established a controlled tunnel through the compromised host and started looking at the internal network from there.

Before the tunnel:

Attacker ─────────X────────> Internal Network

After the tunnel:

Attacker
   |
   | Tunnel
   ▼
 WEB01
   |
   ▼
Internal Network

And this is where the assessment started changing.

Systems that weren't reachable from the outside were now reachable through WEB01.

Services that I couldn't interact with directly could now be investigated from the server's network position.

This is one of those things that's easy to overlook when looking at a web vulnerability in isolation.

The question isn't only:

"Can I execute commands on this server?"

It's also:

"What network boundary did this server just give me access to?"

What Was Actually Inside?

The internal environment wasn't huge.

There were a mix of Linux and Windows systems — development systems, file resources, application infrastructure, databases, and eventually Active Directory.

I wasn't trying to compromise every host I could find.

That wasn't really the point.

I wanted to understand the environment first.

Which systems were there?

Which ports were exposed?

Why could WEB01 communicate with them?

Which services depended on each other?

And where were the useful credentials and identities?

The first rough map looked something like this:

WEB01
                   |
                   ▼
           Internal Network
            /      |       \
           /       |        \
        DEV01    FILE01    APP01
           \       |        /
            \      |       /
             \     ▼      /
          Windows Environment
                   |
                   ▼
            Active Directory

The interesting part wasn't really the number of machines.

It was why they were connected.

That was what I wanted to understand.

Following the Breadcrumbs

This part of the assessment wasn't particularly exciting.

It was mostly enumeration.

Look at one system.

Find something useful.

Follow it.

Sometimes it leads somewhere.

Sometimes it doesn't.

That's normal during a pentest.

In this case, information from the compromised environment started pointing toward internal systems that weren't visible from the outside.

A hostname here.

A configuration detail there.

A credential associated with an internal service.

An account that had access somewhere else.

Nothing looked catastrophic on its own.

But after following a few of these leads, the picture started to make more sense.

WEB01
  ↓
Internal Network
  ↓
Internal System
  ↓
Credential / Access
  ↓
Windows Environment

And this was probably the first point where I realized the original web vulnerability wasn't really the main story anymore.

The command injection had done its job.

I was inside the network.

Now I wanted to know how far that access could actually go.

From Machines to Identities

Once I had enough visibility into the Windows environment, my focus shifted.

Machines were useful.

Identities were more interesting.

I started looking at users, groups, service accounts, permissions, and the relationships between them.

The question had changed.

At the beginning, it was:

"What can I exploit?"

Now it was:

"What does my current access allow me to become?"

This is where Active Directory environments get interesting.

You don't necessarily need to find another vulnerability every time you want to move forward.

Sometimes the next step is already there.

It might be a group membership.

A delegated permission.

A service account.

An exposed credential.

Or a trust relationship that gives an account more access than it actually needs.

The difficult part is figuring out which of those relationships actually matter.

Finding the Privilege Path

Eventually, I found one.

An account had access that it didn't really need for its intended purpose.

That access opened another part of the environment.

From there, further enumeration revealed another privilege relationship.

And then the path started becoming clear.

It wasn't one of those situations where you find a single exploit and suddenly you're Domain Admin.

It was a chain of smaller steps.

Initial Access
      ↓
WEB01
      ↓
Internal Network
      ↓
Internal System
      ↓
Identity / Credential Discovery
      ↓
Privilege Relationship
      ↓
Higher-Privilege Access
      ↓
Domain-Level Access
      ↓
DC01

This was the part I found most interesting.

Each individual step looked relatively small.

But each one gave me enough access to make the next step possible.

And eventually, the distance between the original web server and the domain controller wasn't as large as it initially looked.

The Domain Controller Wasn't the Vulnerability

This was probably the biggest takeaway from the assessment.

The domain controller itself didn't need to be vulnerable.

I didn't need to find some critical RCE on the DC.

The environment around it had already created a path toward it.

The attack path was essentially:

Web Vulnerability
       ↓
Compromised Server
       ↓
Internal Network Access
       ↓
Pivot
       ↓
Internal Enumeration
       ↓
Credential / Identity Discovery
       ↓
Privilege Escalation
       ↓
Domain-Level Access
       ↓
DC01

The domain controller was simply the final destination.

The actual security problem was everything connecting the first compromised machine to it.

Looking Back at the Attack Path

When I stepped back and looked at the whole thing, there wasn't one massive failure.

There were several smaller ones.

1. The application allowed command injection

This was the entry point.

User-controlled input should never have been allowed to reach an operating-system command in the first place.

2. WEB01 had too much network access

Once the web server was compromised, it provided a route toward internal systems that shouldn't have been reachable from an internet-facing application server.

This is where segmentation becomes important.

3. Internal systems trusted each other too much

The relationships between internal systems made sense from a business perspective.

The problem was what those relationships looked like after one of the systems had been compromised.

4. Credentials created additional access

Credentials and service relationships that were useful for normal operations also became useful to an attacker once I was operating from inside the network.

This is one of the reasons credential exposure and service-account permissions matter so much in an internal compromise.

5. Active Directory contained an exploitable privilege path

The Windows environment contained a relationship that allowed access to move from a relatively low-privileged position toward significantly higher privileges.

None of these findings alone screamed:

"The domain is going down."

The problem was that they weren't isolated.

They connected.

The Real Lesson

The command injection was the vulnerability.

It wasn't the breach.

The breach was the chain.

COMMAND INJECTION
                     │
                     ▼
                  WEB01
                     │
                     ▼
            INTERNAL NETWORK
                     │
                     ▼
           INTERNAL SYSTEMS
                     │
                     ▼
        CREDENTIAL / IDENTITY ACCESS
                     │
                     ▼
            PRIVILEGE ESCALATION
                     │
                     ▼
             DOMAIN COMPROMISE
                     │
                     ▼
                    DC01

This is why I think looking at vulnerabilities individually can sometimes give a false sense of security.

You can patch the web application.

You can patch the domain controller.

You can run vulnerability scans across the environment.

And still have an attack path sitting between them.

The important question isn't only:

"Can an attacker compromise this server?"

It's also:

"If they compromise it, what does that give them?"

And then:

"Where can they go from there?"

That is the part that matters.

What Would Have Stopped Me?

The first fix is obvious:

Eliminate the command injection.

But that alone wouldn't have addressed the entire attack path.

The web server shouldn't have had unnecessary access to sensitive internal networks.

Internal services should only be reachable where there is a genuine business requirement.

Service accounts should have the minimum permissions they actually need.

Credentials shouldn't unnecessarily provide access across multiple systems.

And Active Directory permissions should be regularly reviewed for unexpected privilege paths.

Most importantly, organizations should test what happens after an internet-facing server is compromised.

Because asking:

"Can someone compromise our web server?"

is only half the question.

The more important one is:

"If they do, how far can they go?"

In this assessment, the answer was much further than it should have been.

And that's what turned a relatively ordinary web vulnerability into a domain-level compromise.