BeginnersQuest(part-1)-What to do after recon?

Hello Everyone,

I am going to start a new blog series for beginners or an overview of what I should have done when I started . This series will have 3 parts where I will try to elaborate common functionalities in web app’s and try to explain you how to exploit them after the recon process . So, this is the first one...enjoy !!

This blog series will solve below questions in your mind:

• I don’t know what to do next after i did some recon on example.com
• Where i can start to fuzz once i collect data like sub-domains, Software details and after running Spider on the site & soooo on..... Hence, I'll share my own approach to new targets and testing methodology I use for hunting.
• So…Personally, I would suggest you guys do some basic recon like collecting alive subdomains, JavaScript etc. as much as possible, it includes directory search also, I would suggest to use DirSearch as it comes with the best built-in wordlist. Checkout, basic features provided by the domain/organization like what they do , how they communicate , which software versions they are currently using and all also try to recon some admin functions like what admin can do as it will help you while finding IDOR(Insecure-Direct Object reference). The best way to do this is visit their site, read the documentations(must) or watch and try to understand each request using a proxy such as burp suite/ZAP.

So we’ve done all of these things, now what?

• The first thing i would like to do when i start with a new target is to make two testing accounts (1st as attack@mail.com and 2nd as victim@mail.com, Be sure to use portal domain like username@wearehackerone.com.)This helps me in testing for vulnerabilities without tampering legit users data, Next thing, i would suggest you to first start testing with this 3 features of the company since you can get many unusual things here.

1.Login pages.

2.Registration page.

3.Password reset/Forgot password page.

1. Login page

The first thing you can test after creating an account is to test for Session Expiration, Improper Session Validation. If you are hunting on a Well-known platform like H1, BugCrowd or intigriti then its almost impossible to find this low hanging fruits but if you are like me and hunt on a External programs hosted by a company/organization itself then try google dorking to find this kind of programs eg. “intext:responsible disclosure bounty” ,i’ll suggest you to try this type of program before jumping on H1 cuz it’s already crowded and has too much competition ;) you can still hit some of these bugs leveraging in the wild.

The second thing which i jump onto is checking if they provide any kind of OAuth method to login the user like some companies provides “Login with Google,Facebook,Github,GitLab and soo on” the good thing about this login method is that many new bug hunters neglects it and searches for other low hanging fruits. So what can we test here ?

I. OAuth bypass.

II. OAuth Token Stealing.

III. Authentication bypass etc.

IV. Privilege escalation.

V. SQLi.

Here are some reads you can use to learn how this vulnerability can be exploited if you don’t know

1. https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc

2. https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html

3. https://xpoc.pro/oauth-authentication-bypass-on-airbnb-acquisition-using-weird-1-char-open-redirect

• This is not that tough to exploit or to test against, but first you must have a bit of knowledge about what OAuth2.0 is and how it works for authentication (Google is your best friend).
• Privilege escalation is a vast topic to cover in single blog but basically its like comparing the request from two account(verified & unverified) then try making the changes to escalate the privilege of verified account to do the things which are not permitted(DM me if you want me to write about it in my future blogs).
• Here’s the last but not least which i test for its SQLi , SQLi is one of the toughest/tricky vulnerabilities to exploit cuz it differs in each scenario and targets, Maybe you can find SQL Injection but you must already know about WAF. But it sure definitely worth trying for it cuz we all know the pay-outs for SQLi ;)

2. Registration page:-

Registration pages have many functionality that we can test for , few common things that you’ll notice in registration page is email verification , mobile number verification , file upload ( profile pic,document etc.).So we can use this feature as a test subject one by one and test for this kind of vulnerabilities listed below

• XMLi and XSSi using SVG file upload.
• Not-supported File Type upload. (like some sites limits the file type to upload so if we can bypass it, it’ll sure be worth to dig more into it)
• RCE via file upload (this type of vuln gives high pay-outs ,here’s a nice (reference https://anotherhackerblog.com/exploiting-file-uploads-pt-2/)
• You can also try to bypass email or mobile verification using different tricks and techniques ( dm me on twitter or do research by yourself about this)
• Next thing you can try is to brute force OTP sent for verification (NOTE: not all programs allows brute forcing, read their scope carefully)
• XSSHow can we forget this, and you know how to exploit it with the technique “find reflecting parameter->Insert payload -> check if its executed->if not try for bypass/another payload”

3. Password reset/Forgot password page.

Password reset functionality is one of the critical points to test for cuz it does matters a lot.As you may/may not know that most of the sites generates a password reset token when a user attempts to reset his password so things we can test in password reset functionality is:

1. Password reset poisoning(Impact high):- Pretty much similar to how we exploit host header injection , but it is a really serious issue mainly ranked as Critical/P1 or P2. If you want to learn how to exploit and fuzz for this check the references or google it :

Reference :

https://www.acunetix.com/blog/articles/password-reset-poisoning/

2. Reset Token/link not expiring (you can report this kind of bugs too and they will will pay)

3. Password token leak on third party site through referer header(impact — medium):- here to exploit this check on the password reset page, is there any third party link or not ?( like facebook,twitter,insta ,github,some other site links in bottom or in the page) The vulnerability is caused because all the site stores the log of referer header when we are redirected to them. so basically the token should not be sent via referrer if they are redirecting us to any third party site they can have our password reset token even if we have not used it yet.

So, This is the end of part one and i’ll try to write the next part asap . I’m not saying that only this type of bugs can be found on those pages but this are the easy ones and deserves to be checked on each program and for a beginner it’ll be easy to test for it. Just keep trying and don’t give up cuz everything is vulnerable so you just need to have knowledge and patience.

Thanks for reading , this was my first blog so please do share your thoughts with me on twitter @Debian_Hunter or in my discord server https://discord.gg/QvzUMMd.