Just to let you know guys, I have not named the company or I have not disclosed any major details here. I usually find the most interesting vulnerabilities when I stop looking at individual endpoints and start looking at how the application behaves as a system.
During an authorized security assessment of an organization that I will refer to as Company X, I was initially looking at its externally exposed web application and API infrastructure. My aim was simply to identify vulnerabilities that could allow an external attacker to cross the application's intended security boundaries.
So, what started as a relatively simple API assessment actually turned into a much more interesting attack chain. I was able to move from external reconnaissance to an authentication weakness, obtain access to an application context, identify an internal service that should not have been reachable from that context, abuse a server-side trust relationship, and ultimately show access to critical internal resources.
I deliberately stopped short of destructive actions. The objective was to prove the attack path and its business impact, not to damage the environment. For the purposes of this write-up, the company name, domains, IP addresses, usernames, tokens, internal hostnames and sensitive data have been removed or modified.
The attack chain looked approximately like this:
External Reconnaissance
|
v
Public API Discovery
|
v
Authorization Weakness
|
v
Authenticated Application Context
|
v
Application / Host Enumeration
|
v
Internal Service Discovery
|
v
Server-Side Request Abuse
|
v
Internal Resource Access
|
v
Credential / Token Exposure
|
v
Privileged Internal Access
|
v
Controlled Proof of Impact
From a MITRE ATT&CK perspective, the interesting part was that the compromise did not depend on a single spectacular vulnerability.It was the combination of several vulnerabilities that created the meaningful attack path.
So, I started the assessment from an external attacker's perspective. I did not assume that I had an employee account, VPN access, internal network access or any privileged credentials. The very first thing I wanted to understand was what Company X was exposing to the Internet. I identified several externally accessible components:
company.example
api.example
portal.example
auth.example
cdn.example
The API immediately became interesting because the application was not simply serving static content. It exposed multiple JSON-based endpoints used by the web application. Then I mapped the API structure and identified functionality related to:
/users
/profile
/accounts
/documents
/reports
/admin
/internal
Obviously, finding an endpoint does not mean that it is vulnerable. My next step was understanding the authorization model. And I created separate test accounts and compared the requests generated by each account. And the first interesting behavior appeared.
The application correctly required authentication for most sensitive API operations. However, authentication and authorization were not being enforced in exactly the same way.I noticed that some API requests contained an object identifier supplied by the client. So, the request looked like:
GET /api/v1/accounts/18421/documents HTTP/1.1
Host: api.example
Authorization: Bearer [REDACTED]
The identifier was not derived exclusively from the authenticated session.I changed the identifier to another test object's identifier.The application returned a response instead of rejecting the request. That was the first important finding. The problem was not that the API accepted arbitrary input. APIs are supposed to accept input. The problem was that the server failed to establish whether the authenticated principal was actually authorized to access the object identified by that input.
In other words:
Authentication
|
v
Valid session
|
X
Authorization check missing
|
v
Object returned
This is the classic pattern associated with Broken Object Level Authorization, commonly classified as CWE-639. From an ATT&CK perspective, this was part of the initial access path rather than merely an isolated application defect. At this point, I had access to objects belonging to another application context. I did not immediately start enumerating everything.
Instead, I wanted to understand what information the API was returning.The response contained metadata that was not visible through the normal user interface. Among the returned fields were references to backend resources.
A simple example looked like:
{
"id": 18421,
"status": "active",
"storage_reference": "internal-storage-03",
"processing_service": "report-worker",
"document_path": "[REDACTED]"
}
That changed my understanding of the environment. The application was exposing information about its backend architecture. I now had evidence that the public application communicated with internal services. The next question was whether those internal services were actually isolated.
So, I started looking at how the application communicated with backend components. The architecture appeared to resemble:
Internet
|
v
Reverse Proxy
|
v
Web Application
/ \
/ \
v v
API Service Report Service
|
v
Internal Network
/ | \
v v v
Storage Database Admin API
The web application was effectively acting as a bridge between the external user and several internal services. That is not inherently insecure. The problem occurs when the backend assumes:
Requests originating from the application server are trusted.That assumption becomes dangerous when an attacker can influence requests made by the application server. I therefore started testing whether any server-side request functionality existed.
So, one of the application's report-generation features accepted a remote resource reference. The legitimate application flow was approximately:
User
|
v
Web Application
|
v
Report Service
|
v
Fetch Resource
|
v
Generate Report
I wanted to find whether the resource-fetching component validated its destination properly. To do this I supplied a controlled test endpoint that I owned. The request reached my endpoint. And that proved that the server was performing the outbound request. The next question was whether it could reach resources that were not accessible directly from the Internet. I tested this only against authorized internal resources. The response behavior indicated that the server could communicate with an internal service that was not externally exposed. This was the second major stage of the attack.
So, the initial exploitation of the externally exposed application maps to:
The important point here is that I was not exploiting an operating-system vulnerability. The initial entry point was application-layer behavior exposed through an Internet-facing service. The ATT&CK technique therefore describes the adversary behavior:
Internet
|
v
Public Application
|
v
Application Weakness
|
v
Unauthorized Access
The application vulnerability provided the initial foothold into the attack path. Once I established that the server could reach internal resources, I switched from trying to access data to understanding the internal attack surface.The application exposed enough behavioral information to identify several internal service classes.I found references corresponding to:
10.10.x.x Report Service
10.10.x.x Storage Service
10.10.x.x Internal API
10.10.x.x Database Service
The actual addresses are intentionally omitted.The important observation was that these services were not directly reachable from the Internet. The application server had network access that the external attacker did not.That meant the application had effectively become a pivot point. I believe the architecture itself became part of the vulnerability here.
A server-side request vulnerability is often described too simply, The server can make requests on behalf of the attacker.That description misses the real security consequence. The important question is: Where can the server make those requests?
In this case:
External Attacker
|
v
Public Web Application
|
v
Server-Side Request
|
v
Internal Network
|
+----> Internal API
|
+----> Metadata / Service Endpoint
|
+----> Administrative Service
The security boundary was therefore:
Internet
|
X
Internal Network
But the vulnerable application provided a path around that boundary. From an attacker perspective, I did not need direct network access to the internal service. I only needed the vulnerable server to communicate with it on my behalf.
The internal service did not expose the same authentication mechanism as the public application. Instead, it relied on a combination of network location and application-level authentication. This was another important discovery. The internal API assumed that requests arriving from the application tier were trusted. That created the following trust relationship:
Public User
|
v
Web Application
|
| trusted internal request
v
Internal API
The problem was that the first component was attacker-influenced. The trust relationship therefore became:
Attacker
|
v
Public Application
|
v
Trusted Internal Request
|
v
Internal API
This is a classic example of why network location should not be treated as an authorization boundary by itself. While examining the application's configuration behavior, I found a service configuration reference containing an authentication token. The token itself is obviously omitted here. The important detail was where it was stored and how it was being used.
Conceptually:
Application
|
v
Configuration
|
v
Service Credential
|
v
Internal API
The credential was intended for machine-to-machine authentication. Because the application context was already compromised, the credential became accessible to the attacker. This converted an application compromise into an identity compromise. The attack path was now:
Application Vulnerability
|
v
Application Access
|
v
Configuration Exposure
|
v
Service Credential
|
v
Internal Authentication
Now, the credential exposure can be associated with the Credential Access tactic in MITRE ATT&CK.The exact ATT&CK sub-technique depends on the actual mechanism through which the credential was obtained. I would not classify every credential discovery as T1003 or Credential Dumping. That would be technically incorrect.
In this case, the credential was obtained from an application configuration context rather than through operating-system credential dumping. MITRE ATT&CK is most useful when the mapping describes the actual behavior that occurred rather than being used as a collection of impressive-looking technique numbers. So, I then validated whether the exposed service credential could actually authenticate to the internal API.
The request flow became:
Attacker
|
v
Recovered Service Credential
|
v
Internal API
|
v
Authenticated Session
The authentication succeeded. This was significant because the credential was not limited to the vulnerable application's original functionality. It provided access to another security boundary. I therefore treated the credential as a separate finding rather than simply considering it part of the original vulnerability.
Now, with authenticated access to the internal API, I began enumerating the functionality available to that identity. The internal API exposed several administrative operations.
The important ones included:
/users
/services
/jobs
/configuration
/audit
/reports
Again, I did not attempt destructive operations. I focused on identifying what the compromised identity could legitimately perform.The internal service returned metadata showing additional infrastructure. At this stage, the attack chain had moved beyond the original web application.
The internal service used role information associated with the service identity. The identity was intended to perform background processing. However, the same identity could invoke functionality associated with administrative operations.
The application was effectively treating:
service identity = trusted identity
rather than:
service identity = minimum required privileges
This violated the principle of least privilege.
The resulting privilege boundary looked like:
Low-Privilege Application
|
v
Service Credential
|
v
Internal API
|
X
Insufficient authorization
|
v
Administrative Functionality
This was the point at which the severity of the original attack path increased substantially. I then validated whether the compromised internal identity could reach another authorized system. The objective was not to compromise the entire environment. I wanted to answer one question:
Could the attacker use the compromised application as a stepping stone into another security zone?
The answer was yes.The internal service had network connectivity to an additional backend system.The resulting attack path was:
Internet
|
v
Web Application
|
v
Internal API
|
v
Backend Service
This shows a lateral-movement opportunity.Depending on the actual protocol used, the appropriate MITRE ATT&CK mapping would be selected from the relevant Remote Services or Valid Accounts techniques. Again, the exact sub-technique should correspond to what was actually observed.
The final validation involved accessing a sensitive but non-destructive resource. My aim was to show impact without extracting unnecessary production information. I retrieved only enough information to prove that the compromised identity could cross the intended security boundary.
The evidence established:
External Access
|
v
Application Compromise
|
v
Internal Network Access
|
v
Authenticated Internal Service
|
v
Privileged Functionality
|
v
Sensitive Resource
At this stage, the attack chain was proven. There was no need to modify production records, delete files, deploy ransomware, establish persistence, or perform any destructive action. The ability to reach the critical resource was sufficient to prove the security impact.
The operation can be represented as a behavioral attack chain:
| Phase | MITRE ATT&CK | What I Actually Demonstrated |
|---|---|---|
| Reconnaissance | T1595 | External attack-surface discovery and service enumeration |
| Initial Access | T1190 | Exploitation of the Internet-facing application |
| Discovery | T1046 / applicable discovery technique | Identification of reachable services |
| Credential Access | Applicable credential-access technique | Recovery of an exposed service credential |
| Valid Accounts | T1078, where applicable | Authentication using the recovered service identity |
| Discovery | Applicable discovery techniques | Enumeration of internal resources |
| Lateral Movement | Applicable T1021 sub-technique, where applicable | Movement through an authorized internal service path |
| Collection | Applicable collection technique | Controlled access to sensitive information |
I intentionally would not claim techniques such as persistence, command-and-control or impact techniques unless they were actually demonstrated. That is one of the biggest differences between a technically credible ATT&CK report and a report that simply adds ATT&CK numbers to every phase of an attack.
#. What Actually Made This Vulnerability Dangerous
If I had reported only the original authorization vulnerability, the organization would have been looking at one application security problem. But the real issue was the chain.
Individually:
Broken Authorization
+
SSRF
+
Exposed Service Credential
+
Overprivileged Internal Identity
+
Weak Internal Authorization
might appear to be several unrelated security issues.
Together they created:
External Attacker
|
v
Application
|
v
Internal Network
|
v
Trusted Identity
|
v
Administrative Functionality
|
v
Sensitive Resource
That is the difference between vulnerability discovery and attack-path analysis. An attacker does not necessarily care whether each weakness has a different CVSS score.They care whether weakness A can be chained with weakness B to reach something that was never supposed to be accessible. Looking at the attack from the defender's perspective, there were multiple opportunities to detect it.
The initial application exploitation could potentially have generated:
Unusual API request patterns
Abnormal object-access sequences
Repeated authorization failures
Unexpected parameter manipulation
The server-side request activity could have generated:
Unexpected outbound connections
Requests from the application server to internal address ranges
Access to services normally unused by the application
Unusual DNS resolution patterns
The credential usage could have generated:
Service-account authentication from an unusual source
Unexpected API operations
Authentication outside the normal application workflow
The internal movement could have generated:
East-west connections
Unusual service-to-service communication
Access to administrative endpoints
Unexpected access to sensitive resources
The important lesson is that preventing the first vulnerability is only one defensive layer. Detection should also exist for the behavior that follows a successful compromise.
The findings described in this article were responsibly disclosed to the affected organization. All identifying information has been removed, and the technical details have been generalized where necessary to avoid exposing sensitive infrastructure or enabling unauthorized access.