Search for a command to run...
Table of Contents
Table of Contents
Share
Share this article
In this non-technical post, I talk about why red teaming doesn't have to turn you into the villain, discussed various non-technical aspects of responsible red teaming.
Marcus Aurelius once wrote: "The impediment to action advances action. What stands in the way becomes the way."
I think about this quote a lot when hunting bugs or conducting simulations for clients. Sometimes the universe just aligns. A file upload feature here, a missing validation there, a configuration file in an unusual location. Each weakness, unremarkable on its own. Together? Sometimes forms potential infrastructure takeover.
A few months ago (September '25), my collaborator Swapnil and I were working on a bug bounty program for a cloud hosting provider. They offered VPS services and other usual services that cloud hosting providers offer.
For context: I'm a red team operator and security researcher who goes by "kr1shna4garwal" (Krishna Agarwal). I spend my days (and nights, let's be honest) trying to break things that shouldn't break and acting like a state-sponsored threat actor sometimes.
This program was particularly dominated by my friend Swapnil (shoutout to this great mysterious man!). He'd been working on it for a long time, reporting a bunch of access control and cross-site scripting issues, so one day he invited me to hunt on this together.
We worked together on this for a few months and together reported a few more issues back in time, like oVirt panel credential exposure due to issue in async request processing, that's a story for another day.
One day (on 29th September), scrolling through the customer panel, I noticed something new. They had added a support ticket system. customers could now raise support requests directly from the dashboard. Behind the scenes, they were using Jira, though.
So the support ticket system takes a Summary, Description, and a "revolutionary" attachment feature. Fair enough. I lorem ipsum'd both fields and attached a beautiful, non-harmful image.
Here is the redacted POST request:
POST /[Somefile].php HTTP/2
Host: customer.REDACTED.com
Cookie: [...My Cookies...]
Content-Length: 682
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept: application/json, text/javascript, */*; q=0.01
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary0nA5NXTKKKAAOBGT
Origin: https://customer.REDACTED.com
Accept-Encoding: gzip, deflate, br
------WebKitFormBoundary0nA5NXTKKKAAOBGT
Content-Disposition: form-data; name="action"
open_a_ticket
------WebKitFormBoundary0nA5NXTKKKAAOBGT
Content-Disposition: form-data; name="token"
[...MY Access Token...]
------WebKitFormBoundary0nA5NXTKKKAAOBGT
Content-Disposition: form-data; name="summary"
Quo usque tandem, patientia nostra?
------WebKitFormBoundary0nA5NXTKKKAAOBGT
Content-Disposition: form-data; name="message"
Nec dubitamus multa iter quae et nos invenerat.
------WebKitFormBoundary0nA5NXTKKKAAOBGT
Content-Disposition: form-data; name="file[]"; filename="fox.jpeg"
Content-Type: image/jpeg
[...JPEG...]
------WebKitFormBoundary0nA5NXTKKKAAOBGT--The file went through, and I refreshed the page. I found a hyperlink in my support request that, when clicked, initiated a separate POST request to download my file. Interesting!
The request was:
POST /[Somefile].php HTTP/2
Host: customer.REDACTED.com
Cookie: [...My Cookies...]
Content-Length: 107
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept: */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: https://customer.REDACTED.com
Accept-Encoding: gzip, deflate, br
action=download_file&token=[...MY Access Token...]&download_url=https://support.REDACTED.com/_servicedesk/customers/secure/attachment/[...Some Kind of Integer id...]/fox.jpeg?fromIssue=[...My Issue Number...]There it was. That beautiful, terrible parameter that got my attention immediately: download_url.
For those unfamiliar, seeing a parameter like download_url, which by design seems to take input as a URL, is a red flag for Server-Side Request Forgery (SSRF)!
I replaced the value of the download_url parameter with my out-of-band server, and sure enough, I received the HTTP request, confirming Server-Side Request Forgery. Next up, I could scan for internal services here. But destiny had other plans.
In this materialistic world, HTTP and HTTPS aren't the only URL protocols. Some are more dangerous than others. The file:// protocol, for instance, allows access to the local filesystem.
Most HTTP libraries support multiple protocols. PHP's file_get_contents(), cURL, and similar functions will happily process file:// URLs unless explicitly filtered.
I modified my POST request again:
download_url=file:///etc/passwdAnd surprisingly, the response came back with:
root:x:0:0:root:/root:/bin/ash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
[...SNIP...]
guest:x:405:100:guest:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
api:x:100:65533:Linux User,,,:/opt/app:/sbin/nologin
The server's /etc/passwd content returned!
Now, this is where the so-called philosopher inside me appreciated the elegance of the universe. A Server-Side Request Forgery that accepts the file:// protocol is essentially a Local File Inclusion (LFI) vulnerability in disguise. Imagine if I had just stopped and reported this. Surely this was a high-severity finding, certainly. But my goal was critical.
Let me show you what's happening behind the scenes, based on my understanding, here is pseudo-code I imagined
function download_req($action, $token, $download_url) {
$user = validate_user_token($token)
$foo = curl_init()
curl_setopt($foo, CURLOPT_URL, $download_url);
curl_setopt($foo, CURLOPT_RETURNTRANSFER, true);
$result = curl_exec($foo); // curl_exec foo!
curl_close($foo);
if (!$user) {
return error_resp("Invalid Token");
} // If token is invalid, no further processing
if ($action === 'download_file') {
$file_content = $result;
return $file_content; // return response
}
}
?>The application was essentially acting as a proxy, It takes a URL, fetches its content and return it to the user in response.
PHP has a feature called stream wrappers that can chain filters together. In recent years, many researchers have discovered ways to use these chains to achieve arbitrary code execution through file read. But here, the application wasn't processing PHP filters. Afterwards, I tried several other techniques such as gopher:// and other potentially dangerous protocols, log poisoning, SSH keys, etc. But all attempts failed miserably.
Someone said it right: when one path closes, examine or carve another. We couldn't get code execution through conventional means, unfortunately. But we had arbitrary file read, and the next most valuable thing to read is configuration files.
Modern web applications are essentially configured secrets wrapped in code. credentials, API keys, encryption keys. All stored somewhere, in some form, on the server.
I started fuzzing for the usual suspects like .env, database.php, config.php in usual paths like /, /var/www/html, /usr/share/nginx/html, and so on.
All returned empty responses. Unfortunately.
From past whitebox based assessments, I learned that developers sometimes deploy applications in various ways. Docker containers often mount application code to /app or /opt/app, sometimes developers find /opt/ convenient for organization, and many other such non-standard patterns exist.
From here, I guessed many, but got hit at:
download_url=file:///opt/app/config.php
And here we go! It returned about 300 lines of response containing the disaster.
I got everything, including (but not limited to) configuration values, credentials, secrets, API keys, tokens. Everything in plaintext. This single file contained everything.
Just for clarity, here are the items we got: LiveChat credentials, Kayako credentials, Jira Service credentials, cPanel credentials, Plesk credentials, ISPManager credentials, Foreman infrastructure credentials (spanning 13 regions: RU, NL, DE, IS, US, UK, FR, TR, ES, IT, CH, PL, FI), database credentials, RabbitMQ credentials, PayPal/BitPay/Stripe/Coinbase credentials, email credentials, GitHub credentials, PowerDNS keys, encryption keys, and more.
Do I even need to write the impact in a fancy manner here? This is complete potential infrastructure takeover. We stopped right after getting the credentials and reported it right away. Using these credentials and the Local File Inclusion issue, I could have gained control over all their mentioned financial platforms, databases, repositories, panels, and application PHP source codes, respectively.
I calculated severity of this vulnerability as Critical (9.9) and CVSS:3.1 vector string was CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Here is the breakdown:
We documented everything and reported the vulnerability to their Chief Technology Officer. He responded promptly and immediately took action.
Timeline:
Disclaimer: All details have been anonymized or changed to protect the affected organization. No actual credentials or identifying information are included.