How 100% Manual Hacking (Without Even Kali And Burp) Led To 2 Medium Vulnerabilities On YesWeHack

Hello Folks, and welcome back! I’m Manan Sanghvi. I’m excited to share another Write-Up with you today.

If you’re a beginner, this Write-Up is perfect for you. You’ll learn something new about how to perform good reconnaissance through Google Dorking .

Before that, if you haven’t read my previous write-ups, I highly recommend checking them out. You’ll find valuable insights and experiences that can help you on your journey.

For those who haven’t seen it yet, my first write-up is titled: “In under age (<18), How I Hacked Multi- Billion-Dollar-Corp and got first 4 fig. $2600 Bounty!” Make sure to give it a read — it’s an exciting story that marked the beginning of my journey in hacking.

So, back to the topic. I was hacking a very large target with numerous subdomains and services in scope for hacking on YesWeHack. Although this is a public program, I won’t be disclosing the name of the program.

I started by looking for subdomains for *.target.com using Google Dorking. My approach is a bit unique compared to what most people do. Typically, people might search like this: site:*.target.com or site:*.*.*.target.com (especially for larger scopes). These mathods are also good but I combine everything and try a different type of dorks:

site:*<*.target.*

site:*<-*.target.*

site:*>*.target.*

site:*->*.target.*

site:*<->*.target.*

In Normal approach you can see that

And in my approach:

You can clearly see some small differences in those dorks. To find juicy subdomains, I used a specific dorks on that target, which looked something like this:

site:*<*.target.com intext:"login" | intitle:"login" | inurl:"login" | intext:"username" | intitle:"username" | inurl:"username" | intext:"password" | intitle:"password" | inurl:"password"

You will able see the some different subdomains which has login panels. Now, In that target I found 2 juicy subdomains which has search bar on home page.

Now, everyone asks me where and how I start looking for XSS vulnerabilities, so here’s my process: I first combine various tags and special characters (abc ' " } < > ; // # -) into a single search to understand how the web application responds to each one. For example, I might input something like this:

abc’ “ ><>#; — —

This is always my first step when testing for XSS. The goal is to see how the website handles different characters and whether it uses any Web Application Firewall (WAF) or encoding that might interfere with the injection. In this case, I put my payload in search bar on both subdomains and I found that there was nothing in place that could block my attempts. This is output I got In one subdomain:

And in second subdomain:

You can see that there is not output encoding. So I think I should spend some more time on this and I created custom payload

abc’”><><img src=1 onerror=alert(document.cookie)>

This is my all-time favorite payload for testing XSS. I’ve found numerous vulnerabilities using just this one line of code.

Here is a Pop Up I Got:

Then I reported to YesWeHack and It was Accepted:

I hope you enjoyed this write-up! If you found it helpful, feel free to connect with me on LinkedIn or Twitter.

Follow Me On Linked in (Most Active):

https://www.linkedin.com/in/manan-sanghvi-799863176/

Follow Me On Twitter:

https://twitter.com/An____Anonymous

Thank You.