Exploiting the Shadows: How I Uncovered a Command Injection via OOB and Bagged $800

Welcome back to my writeup once again!!! This day, I will share with you how I discovered a Command Injection via OOB! This wasn’t just any find — it was a vulnerability that allowed me to execute system commands remotely, proving just how critical this issue was. With patience, creativity, and some sneaky out-of-band (OOB) exploitation, I managed to turn a simple test into a serious security flaw. Let me walk you through the entire process, from identifying the injection point to getting a sweet $800 bounty reward!

Let’s start!

First, of course, I started with some enumeration. After running a subdirectory brute-force scan, I discovered an interesting subdirectory that caught my attention! APIs are often vulnerable because they serve as direct communication channels between clients and servers, potentially exposing critical functionalities to external users. That’s why let’s give this subdirectory a shot!

As I explored this subdirectory, I came across this.

At this point, I immediately recognized a potential weakness. The API structure indicated that it required an action parameter, suggesting a design that leaned more towards an RPC-style (Remote Procedure Call) rather than a RESTful approach. The presence of this parameter hinted that the backend dynamically executed different commands based on the provided parameter value. This type of architecture is often found in older or custom-built APIs, particularly in PHP-based systems, legacy applications, or internal admin panels, where all requests are funneled through a single entry point like like this. Such implementations can sometimes introduce security risks if user input is not properly validated or sanitized.

Next, I proceeded to fuzz the action parameter to identify possible valid values!

After lots of enumeration, I fired up Burp Suite to intercept and analyze requests — this was the moment where things started getting interesting!

The server started acting strangely when I changed the cloud_type parameter from an integer to a character. Instead of rejecting the input gracefully, it threw a syntax error. This immediately caught my attention because it suggested improper input validation or direct injection into a command or query. Such behavior often indicates that user-controlled data is being processed unsafely, potentially leading to injection vulnerabilities. Seeing this response, I knew I had found something interesting, and it was time to dig deeper to see how far I could push the system.

After trying out numerous payloads, I spent a significant amount of time testing various injection techniques, hoping to find one that would successfully execute. It was a tedious and time-consuming process, requiring patience and persistence. The frustration started creeping in as nothing seemed to work initially. However, I knew that in bug hunting, persistence is key — sometimes, the right payload is just one step away from discovery. So, instead of giving up, I kept refining my approach, adjusting my payloads, and analyzing every response carefully.

Here’s my new approach

I set up an Interactsh server to perform an Out-of-Band (OOB) test, aiming to see if I could make the target server interact with my external server. My goal was to determine if I could achieve Remote Code Execution (RCE) by forcing the application to send a request outward. To accomplish this, I crafted a payload utilizing cURL, which was designed to exfiltrate the contents of /etc/passwd to my Interactsh server. If successful, this would confirm that the target was vulnerable to command injection and capable of executing arbitrary commands remotely.

And……..

It worked!!!

At this moment, I knew I had struck gold. The server successfully executed my injected command, proving without a doubt that it was vulnerable to Command Injection. Seeing the contents of passwd and ssh configuration land on my Interactsh server was all the confirmation I needed. This wasn't just a simple bug—it was a critical flaw that could allow an attacker to execute arbitrary commands on the system. The feeling of finally getting a successful hit after all the testing and failed attempts was exhilarating!

Now let me explain the Out-of-Band (OOB) for you, its a technique used in security testing where the attacker forces a vulnerable system to send a request to an external server they control. This method is particularly useful for detecting blind vulnerabilities — ones that don’t immediately return output in the response. Some vulnerabilities, like Blind Command Injection, Blind SSRF, or Blind XXE, don’t provide a direct response in the HTTP response body. Instead, they execute in the background without showing visible signs of exploitation. In such cases, OOB techniques help confirm whether the exploit worked by making the target system interact with an external server controlled by the attacker.

This was, without a doubt, one of the most thrilling and rewarding bounty hunts I’ve ever tackled! From the very start, I knew this was going to be a challenge, but I was ready to push through every obstacle in my way. Countless hours were spent analyzing responses, crafting payloads, and experimenting with different injection techniques — each failed attempt fueling my determination even more. There were moments of frustration, where nothing seemed to work, but I refused to back down.

Then, after relentless testing, the breakthrough finally came — the server reached out to my interactsh listener, confirming that I had successfully exploited a Command Injection! The rush of excitement in that moment was unreal. It was the culmination of persistence, problem-solving, and an unshakable belief that there had to be a way in. Seeing my report get validated and securing the bounty made every second of effort completely worth it.

This hunt reinforced an important lesson: real hackers don’t quit when things get tough — they adapt, learn, and keep pushing forward until they win. And that’s exactly what I did.