Author: Blogger

I am the one who publishes all the blogs for ENCIPHERS :-)
22 Jun 2018

Doing RECON the correct way

Hey guys, today we will discuss Information gathering aka Recon which is the foundation of every bug bounties or penetration tests which you will ever do. Many security researchers have found many CRITICAL and HIGH priority bugs just by doing proper information gathering which is the initial phase of a penetration test.

If I get 6 hours to chop a wood, I would spend the first 4 hours sharpening my ax.

This is exactly the case in this phase. Most of the researchers just start looking for vulnerabilities like XSS, CSRF, IDOR as soon as they get the target but with proper information gathering at the start people can know what the target is and the different technologies on which it is built and several other things. For now, we will keep this post general and simple and with time we will make sure to update it or write the 2nd part of it. So let’s get started on what you should do in the initial phase of knowing your target.

  1. Subdomain Enumeration:

    We have already published a post on Subdomain Enumeration in which we discussed several tools and techniques by which you could do subdomain enumeration. You can find the post here. In the time we last wrote that post, we came across some other cool tools which are much faster and bring better results when you have a target like * and you need to enumerate all the subdomains.


    One of these tools is Subfinder. You can get the tool from here. It is faster than Subbrute or Sublist3r. It has been written in Go language so you will need to follow the instructions to install Go and setup this tool on your machine. Also, you will need to set up private API keys for some of the services like Virustotal to get results from them also. It has been mentioned in brief on that Github page. After installing the tool, there are several options which you can use. One of our favorites is:

    ./subdinder -d

    This will make sure to get subdomains from 22 passive data sources. But if you have a text file like this all.txt and you want to brute force the subdomains, then you can use the option below

    ./subfinder -d -b -w all.txt

    Subfinder is one of the fastest and mostly used subdomain enumeration tools out there recently. Make sure to use it to get juicy subdomains to gain more chances of getting a bug there.


    Amass is the second new tool which is there and we wanted to let you know in case you haven’t used it yet. It has also been written in Go and is super fast. Installation instructions and everything else which you will need can be found here.

    After installation, you can simply run the command:

    amass -d

    to get different subdomains for that target. There are many other different flags mentioned there which can help you in finding a quality number of good subdomains. Now if you are thinking, why we are talking about subdomain enumeration tool once again, and Subbrute or Sublist3r would suffice this purpose. Then we would like to add something, as of now Sublist3r has really become depreciated as a tool and you will find a great difference when you compare the results from Subfinder and Subbrute or Sublist3r. Make sure to try these 2 tools to have better chances of finding a different domain and ultimately getting a valid bug on that.

  2. Censys:

    Now, this is one tool which many researchers have been focussing on in recent years. And this is one of the coolest tools for information gathering. Censys actually scan the IP addresses and gathers information from a set of different ports. Creativity is a way while doing Censys search. A simple search like this, “” internal might lead to unexpected results. There are many tutorials online available on how to get more than the normal information usually shown and you should really check that out. You can access the tool from here. Just enter any website’s name in the Search Box and you will get a whole lot of results and many times subdomains data from there. Do take a look at it while doing information gathering.

  3. Shodan:

    Shodan is more or less the same as Censys except that it scans every IP addresses and generate a lot of data. The process is also almost the same and is really popular among bug bounty hunters. You can access the tool from here. There are many books like this and online tutorial plus videos which goes into a deep study on different shodan techniques to get better results. Again creativity is the key here, so do gather some information on Shodan before gathering info on the target application. So do check this one out.

  4. Github:

    Github is the world’s largest software development platform. It is one of the best places to look for various issues and knowledge about the technology stack the company is making it’s products on.
    While doing a Github Recon for a particular target, you could look for many things like:

      • Looking for secret keys labeled as API_key and AWS_Secret
      • Some internal credentials such as username, the password for Database or admin portals.
      • You could also get some different API endpoints and look for different domain patterns.
      • Not only this, there are many environments like dev, stage, and prod and you may find some interesting details or any interesting subdomain based on this.
      • Let’s suppose the testing application is, then you could just make a search as
        “” “dev” or “” “prod” to look for the above details.
        For searching secrets like API_key, you can just make a search as “” API_key and it might give you some unexpected results in many cases.
        Similarly, if you want to refine your searches for passwords, you should make a search for “” password


    There are many tools available for Github Recon like gitrob, git-all-secrets etc, but the best way will be to do it manually so you don’t miss anything important.

  5. Amazon Web Services(AWS):

    AWS s3 buckets are being used by a lot of companies to host their content nowadays. But many times unsecured methods leave them misconfigured which could then be an asset to a malicious hacker. In a CRITICAL scenario, this misconfigured s3 bucket may allow an attacker to read and write files on a bucket belonging to the company. Just as for finding any ‘juicy’ information on Github, it is also possible to get a good amount of information while doing AWS recon.

    Some of the ways can be like to use a Google Dork. Let’s say the target is then a google search like +
    may provide you with some interesting results.
    It is also possible to get s3 buckets on Github, so in this case, you may provide a search query in Github such as:
    “” + “s3”

So this is all for this first post on Information Gathering. There are many other methods like dig command and which can be also helpful for getting various types of information. Information gathering is just what the name says. Gathering information from anywhere. Even though if you don’t find any sensitive file during Recon, knowing the technology stack, subdomains will definitely give you an upper hand in the latter half of pentesting. In the upcoming months, we will make sure to make a part 2 for Information Gathering where we will talk about some of these topics in depth or add new updated tools and methodologies to help you in your penetration testing career.

Until then, keep practicing and Happy hacking. !!

21 Jun 2018

A User can change the personal details of any other user

Hi everyone. Welcome to this new post from ENCIPHERS. So recently, our team at ENCIPHERS conducted a penetration test for a certain company. The company is a very reputed one in the field of Money Investment and Real State business and it has a lot of day to day users. The client asked us for a penetration test on a limited scope of only i.e the main application of the client without interfering with any other subdomains.

As it stood, the application was more or less quite secured to find vulnerabilities like XSS and CSRF. The next thing, that will come to any penetration tester at that time is to check for any broken access control related issues, and the same happened to us. So it was then that we started testing rigorously to find any critical bugs and yes we did find some of them.

Here are the different steps. Let’s see them one by one.

As we have already told you in lots of our posts earlier, you always need to make 2 accounts to test for cross-testing. So we started with that and logged into both the accounts in 2 different browsers.

Next, we started looking in the application URL and also in the Requests tab in Burpsuite, for anything where there will be something like a Identifier or a random number that could be used to differentiate between 2 different profiles.

We told you before that it was a Real estate business company. So in there, was an option to see the different profiles created by the user. These profiles contained different confidential information about the user like the Contact Information, the Ownership Type, and Legal Title. The Request looked like this:

And the Response to this particular request showed various details of the user.

Now what we simply did was to change the profile id with that of the other user account, to see if it shows Access Denied. But no, it doesn’t. Instead, it gave us the full details of that profile of the other user.
The JSON request part looked something like this:

As you can see, the profile_id was changed.

Not only Read but we also got Write Access to change the profile name of the other user’s account.
Actually, the link to edit the details of a profile, looked like this:

So we just changed the id with the second one and the link became this:

And to our utter surprise, the option to Edit the Info was still working and we successfully changed the profile name of the other user and saved it.

Not only this, a user can also see the various Investment details of any other user plus the Earnings of that user also. Here is how.
The Request to see the Investment details of a certain profile of a user looked something like this:

As you can see, the profile_id is in the JSON request and as a penetration tester, you won’t be missing to check what happens if you put any valid id of any other user there.
So we simply replaced the id with our other account’s id. And yes, it was ‘200 OK’ with the other account details there.

The Earnings tab was similarly vulnerable to Access Control issues where it was possible to get the whole details of any other user by giving that id.

The Request, in this case, looked like this:

As you can guess, what happens after this. We simply replaced the id and yes, that was it.
Now for certain curious readers, who must be thinking that how will someone guess the profile id of any other user because it seems to be a long random number. So for you, the sole purpose of a penetration test is to look for vulnerabilities present in any condition. The companies should always take the first step to make their site secure by taking the proper measures against access control issues instead of thinking that a hacker will not be able to guess such a long random number. If there was proper access control, then when we sent the request by replacing the id, it would have directly shown me Forbidden or Access Denied. Not only this, the profile id’s are also getting saved in the browser’s history and what if someone gets their hands on it. So proper access control measures should be applied in the first place so that even if someone finds a way or an algorithm to guess the number, it won’t help them with accessing the other user’s account.

So this was all for this post. See it is very simple and easy to find such kinds of bugs. The issue in the last post was also easy. You just have to be on the lookout for an identifier and then cross-test among them to find these issues. Hope you must have learned some new things from this post too. See you guys in the next post. So go apply these techniques now and Happy Hacking.!!!!

19 Jun 2018

Knoxss vs Burpsuite(A practical Demonstration)

Hello guys. So this is going to be an interesting blog as we are going to watch a practical demonstration of two awesome tools in the penetration testing industry.

One is Burpsuite. If you are here, then we probably assume that you know what Burpsuite is and how it works. This post will give you some better insights into it. Also you can enrol yourself in a course on Udemy on ‘Web Application Penetration Testing Using Burp Suite‘, a full fledged course on being Zero to One in web application penetration testing using Burp Suite.

The other is Knoxss. If you don’t know then just know that Brute Logic develops it and if you know XSS, then we guess you must have used the Brutelogic Website at least once.

Burpsuite is a hacker’s toolbox as it contains tools for every purpose. Whereas Knoxss is only for finding XSS vulnerabilities so here we will only try to find XSS bugs in the application and compare both the results.
Now the thing is we will be comparing the Burpsuite Pro version against the Knoxss Pro version and give our conclusions so you will know more about them and how will they be useful.

Practical Demonstration

The first thing that you need to do is get Webgoat up and running.

Webgoat is an intentionally vulnerable web application and is basically used for training new security researchers. You can see the different steps involved to get it running from here.

If all is good, then upon opening the URL http://localhost:8080/WebGoat/, it will look like this:

Scanning with Burpsuite Active Scanner

Let’s start with Burpsuite first and then we will again check it with Knoxss.
One thing which you will need to do is to change your Burpsuite proxy listener to any value except 8080 because Webgoat is running on that. We have changed it to 8000 in our case to avoid problems. See the screenshot below.

Similarly, you need to change the browser’s proxy to 8000 also so that Burpsuite could act as the proxy.
See the screenshot.

If you are facing problems with this setting, watch this video on setting Burpsuite.

So all set and done, let’s start finding XSS with Burpsuite.

Stored XSS
So go to Cross Site Scripting -> Stored XSS challenge in Webgoat and write anything in the input boxes. Make sure the Intercept is on in Burpsuite. Capture the request and do an active scan on it. Remember, Active Scan is only available for Pro versions. Active scan sends multiple requests to see if a vulnerability is present, so in this case, we will look out for XSS vulnerabilities.

This is what we got by doing an active request in Burpsuite Pro for this request.

Though it was able to find some other vulnerabilities, it couldn’t find out that the input fields in this page are vulnerable to XSS. Burpsuite results can be false positives also sometimes.

Reflected XSS
Let’s see for Reflected XSS challenge now.
You can see that it worked in this case correctly.

It correctly found Reflected XSS vulnerability in that page for certain. So Burpsuite passes in this case.

Testing with Knoxss Pro Extension for Firefox

Let’s get back to Knoxss for this two cases.

As of this moment,  we are using Firefox Quantum and the Knoxss extension is not working for this latest version of Firefox. The deadline for this issue is still unsure so it will be wise to use the Firefox-ESR instead of an outdated Firefox version and install the extension there. We will make sure to update this post as soon as we get the new extension which will support Firefox Quantum.

For the extension to work, go to the page where you want to check for XSS, and then press the ‘K’ button which must be there if you installed the extension correctly. Then the extension will get ‘ON’ and you can then see if it found any XSS on the page or not.

Stored XSS
So let’s check for Stored XSS first. Go to the stored XSS challenge page and start the extension.
See the screenshot below.

If you see in the top-right corner, it says Knoxss wasn’t able to find any vulnerability in the form. The same as with Burpsuite. But we know that the page is vulnerable to stored XSS, so both of them couldn’t find it.

Reflected XSS:
Turn the extension off by clicking and once again start it after visiting this page and stay there for 10-30 seconds.

Knoxss wasn’t able to find the XSS vulnerability in this case also.

Final Conclusion:

Please don’t get us wrong. While you will see many posts on successful working of tools, this post was to show that even such popular scanners can fail.  This post tells that you can’t always rely on the findings of an automated tool. Sometimes the results can be false positives but many a time it’s possible that they won’t even catch the vulnerability. We knew about both cases that they are vulnerable but the scanners couldn’t get it. But if we had inserted a simple payload, checking for XSS it might have worked.

We would like to mention that these two have worked magnificently for many other users while live testing. This post was just for demonstration purpose. Where Burpsuite Pro requires 349$ per year license, a year license for Knoxss Pro is 107$. So, try out with the free versions and if you think you should buy the pro version go for it. As for us, we are trying both of them now and we will be updating this post again if we find something interesting to share with you all. So stay tuned for that.

Until then keep trying and if you get stuck, please comment and someone from ENCIPHERS will surely help you out.

18 Jun 2018

How can Expired URL’s lead to an all new kind of vulnerability?

Hey guys. Actually, this is the 2nd part of the vulnerability which we discussed in the earlier post. You can read that post from here. Now if you read the post, you will get to know that we have discussed the IDOR which we got in the e-commerce application.

What is this 2nd part all about?

So let us explain it in an easy to understand manner. What are the normal steps when you try to change your password on Facebook?

  • You chose the option of ‘Forgot Password’.
  • A link is sent to your mail id.
  • You reset your password using that link.

Now did you ever try, again revisiting that link? Do you think that again revisiting that link will help you to reset your password?

Then the simple answer to this NO. It won’t help you to reset the password because the link gets expired after one use. The reason for that is if someone gets access to your emails anyhow, he/she can change the password if the link doesn’t get expired. That is why there is always a token in the links and if you check it, you will find that the token gets changed with each “Forgot Password” request.

But the vulnerability in our case was slightly different than that.

The way the application was working that it will send an email to the user for notifications when he subscribed anything.

The link in the mail would look something like this:

Now when we unchecked all the subscriptions and again visited this link, it said that the link has expired or the URL contained an error which was the perfect way the application should work.

When we again subscribe any item, we got an email with a link something like this:

As you can notice, the identifier got changed i.e the tokens we were talking about earlier.

Here lies the vulnerability. As we used the previously expired link again now, we can see the different subscriptions and that even the new ones. It was not that the link was showing us the cached page. We were able to see the latest subscription for the user and we can again uncheck some of his subscriptions and play around with it. This was quite an unusual bug for our team but it was a well-found bug.

The major and the most CRITICAL problem of this bug is if an attacker can guess an identifier for once, then the user is doomed. He can just save this identifier and whenever he tries to use this and finds the link is expired, it will mean that the user hasn’t subscribed to anything for now. But as soon as the user subscribes anything, the attacker will again be able to see the user’s subscription and has full WRITE access to it.

Final Points

So the IDOR mentioned in the previous post along with this case of the link not expiring even after another link is issued was a HIGH priority vulnerability for the e-commerce company.
If the application has been properly tested and verified, problems like this shouldn’t have existed in the start i.e. the issue of non-expiration of links for quite a number of days.

This was all for this two-part post which was quite related to each other. As we have already mentioned before, issues like this are very easy to find and just needs a keen sense of open eyes. So this was all for this time. Hope you all learned something out of this and learned to always check the link in the emails cautiously because that can open a whole new door of possibilities for vulnerability finding. Until then, Keep Learning and happy Hacking..!!!!

13 Jun 2018

Bypassing Cloudflare WAF to get more vulnerabilities

Hey guys,

If you have been doing penetration testing or bug bounties for some time now, then you must have come across applications which uses Cloudflare as their Content Delivery Network(CDN). As a new bug bounty hunter or penetration tester, you must be feeling kind of frustrated when any XSS Payload you provide leads to a security page or you get blocked by Cloudflare’s Web Application Firewall in place there.

What exactly is Cloudflare and how can you detect which web application uses it?

CloudFlare is a useful tool to enhance site performance, accelerate the access speed and improve the visitors’ experience. It is a CDN, DNS, Security(Web Firewall), Optimer, Analytics etc. all in one package. In a simple way, you can say that Cloudflare makes the application loading time faster and saves it from attacks such as SQLi and XSS to save your users from being hacked. If you are unsure about how to check if a web application is using Cloudflare, you can simply use an extension such as Wappaylzer which shows the different technologies, Frameworks, CDN’s the application is using. You can download it from here if you don’t have this or any other extension like it.  Its usage is pretty simple. This is how it will look like when you browse an application which uses Cloudflare as CDN.

This is how it will look when you see the Extension for a particular app using Cloudflare. There are other ways too and we will get to that eventually. Now if you try to use your normal XSS payload, you are either going to get the Captcha Security Box every time or on doing it constantly you will be blocked from further interaction with the app on that IP. Not only this, scanning and spam messages or emails will also lead to problematic issues for as a penetration tester.

What’s actually happening behind the scenes?

When a company uses Cloudflare, what happens is that Cloudflare sits in between you and the web application original server. So any malicious payloads or files which you try to execute on the main app goes through Cloudflare and as a result it blocks you. Not only this, even if you get the IP address and try to access the app using this IP, it will show that “Direct Access is not allowed”. Below is the image of a target which uses Cloudflare. Use the below command to get the IP being used


This is where Cloudflare is hosting your application. Any time you insert your payload, it goes here. Now just try to directly access the app using this IP and you will get the following error:

So is there any way out of it?

Yes, of course, there is. Think of what will happen if you could just access the Origin Server directly without going through Cloudflare’s protection? Then the app will have no protection via Cloudflare’s firewall and we can now test for various vulnerabilities like XSS and SQLI.

Let’s see some of the tools and methods which can help us to access the Origin Server directly.


You can access the application here. This applications work is solely based to determine the Directly Accessible server for that application i.e the origin server. They have maintained a database and a zip file containing the name of all the services which use Cloudflare and who is sitting behind this Cloudflare’s service. You will be able to see a search box at the bottom of the page. Once you enter the website’s name and Crimeflare comes up with a Direct Connection IP, then you can be almost sure that it’s the Origin Server. We are using “almost” here because many times the results produced are that of the target’s subdomain instead of the main domain, so you have to further verify from the other methods we are going to talk about. On the other hand, if you didn’t get any information on the Origin Server from here move to the other methods.

A sample demonstration for which uses Cloudflare and how you can get the Origin Server.


The website itself says that it’s a tool to find and analyze every reachable server on the internet. This tool comes in very handy during the Recon process of a penetration test or Bug Bounties as we can get different types of information from here about the target. But this is also helpful in this case where we have to find the Origin Server for an application using Cloudflare.

If you just enter the target’s name in the search box, it will come up with the IP’s of that target and mostly the origin server is in those. Let’s say for example Bugcrowd here.

This is what the URL looks like and it’s giving a lot of results because the application might be using multiple hosts so you need to work a little harder.

3.Security Trails:

It is actually a repository of historical DNS data and you can get the origin server’s IP by looking at this data. Just like before, enter the application name in the search box and it will give you a whole lot of information. On the left side, you will find 4 rows. Go to Historical Data in there and see the ‘A’ field which will reveal all the IP’s related to the target.


This website contains the history of hosting records for different websites. It can also be used if the other previous methods are not working. There is an extension for Netcraft which you can install to keep a look at the target’s different info which you can get from here.

What to do after we got the Origin Server?

Now there are 3 things which you can do now.

  1. Directly access the app through the real IP.
  2. Add the entry in the /etc/hosts file. In Windows, you can access this file from c:\windows\system32\drivers\etc\ hosts. Add the entry in it. In Linux, you can just do cd /etc to go to the /etc directory and then do nano hosts or vi hosts, whichever you like and add the entry like this.

    The OriginServer one was our new entry. You can use the same format on both Linux and Windows. Now when you do this, if you now try to go to the target application, it won’t go through the Cloudflare’s servers and directly access the application.

  3. Instead of option 2, you can also choose to override the DNS resolver for this project if you are using Burpsuite while Testing. It will do the same thing but it’s probably better because you just want to do it for this pentesting project and not for every time.To do this, go to the Project Options -> Hostname Resolution. Add the entry there. Just see the below screenshot in which I have added the Hostname and the IP address and this will override our computer’s DNS resolution which always takes us to the Cloudflare’s server.

When to think of bypass?

These methods are not 100% full proof and there are many more methods to bypass Cloudflare’s protection. dig and ping are especially useful in this cases. But when should you start looking for a bypass. Don’t just start looking for a bypass just after seeing that the application is using a Cloudflare’s CDN. First know, if the firewall is blocking your payloads. Cloudflare won’t possibly block you for every testing. Like it won’t if you check for Access Control and IDOR’s. It is up to the applications internal code how it handles that. Cloudflare will mostly block you for XSS, SQli injections, DoS, and DDoS attacks primarily, spamming etc. And many times even if you find the real IP and you go there it may behave in a weird manner or they may have taken extra measures in advance, so don’t lose hope. But from the next time you find an application using Cloudflare, you can definitely follow the methods mentioned in the post and you can also find some other ways if you search the internet. Try this and let us know your success stories.

HAPPY HACKING until then. !!!

30 Apr 2018

IDOR to change the email notifications of user

Hey guys. Welcome to this new post from ENCIPHERS. Recently we have been writing a lot about bypass of different access controls and in the recent pentest conducted by our team, we again got some medium priority vulnerabilities regarding horizontal access bypass. And we will be discussing what was the vulnerability and how we proceeded to get that.

So what was the vulnerability?

As you can see in the title itself, the vulnerability was that any user can unsubscribe any other random user from the email notifications. Now on the first look, you will think that it’s not a very cool type of vulnerability but let’s say, there is going to be a sale of Redmi Note 6 Pro on Amazon from today. The item is already OUT OF STOCK, so Amazon says that you will get an email notification when the sale resumes again. We believe that you must be getting where we are going with this. So now, what if the user was unsubscribed from his/her email services and wasn’t getting email notifications for the above item when it was out? He/she won’t know when the item is again in stock. This will lead to the decline of the business of the company which is a great problem in itself. Now the site we pen-tested had the similar kind of vulnerability present.

How we proceeded to get the vulnerability?

The application was a European e-commerce website.

  • We simply logged in to our user account.
  • For every item present there, there was an option to get email notifications for any upcoming information on that item.
  • If we turned on this notification, each time a mail will be sent to us.The link in the mail looked something like this:
  • As you can see, there is an identifier and we have already discussed in our IDOR posts earlier, how to check when there are simple identifiers like this one, no alphabets or special characters included.
    So we created another account and tried to open this same link in that user account.

Result of doing this?

We could see the items to which the user has subscribed to. Not only this, the user’s email id was also in open there with an option to check and uncheck the different subscriptions.
Now, we simply unchecked the different subscriptions and then when we checked it from the first account, there were no subscriptions present in the Subscription tab.

So this was a simple horizontal access bypass in which if we could somehow guess the identifier or we could see the person’s mail and which can definitely help for a larger attack. Now the most dangerous thing in this case, can be using the Burp INTRUDER. In cases like this, the one thing which you need is to see that what part of the identifier is varying and put your payload in that style.
It can give you a whole list of valid user id’s which can then be used for phishing or different high-level attacks apart from the IDOR we have seen here.

Main Points to take out from here:

We have written many posts on this kind of issues and the motivation to write this is access control measures not taken like putting a filter at a place. It needs to be executed for each request and for each action. There were no identifiers present in the application itself. But the identifier was present in the mail which led to getting this medium priority vulnerability. So keep a look for any place be it URL or mail for any kind of id. For any kind of reference on IDOR, you can always read this post of ours. Hope you will get to know another technique if you get something similar to this while testing or bug hunting. Happy hacking..!!!!

30 Apr 2018

Doing Subdomain Enumeration the right way

Hey guys. Welcome to this new post from ENCIPHERS. For the last few months, we have been continuously writing about different Findings and the approach our team took to find those. But there was one thing, which we wanted to share and that was the very first step itself. Be it bug bounties or Penetration tests, one thing that is commonly important is the subdomain enumeration of the targets.

We think we have talked about one or two subdomain enumeration tools in the post of subdomain takeover. But in this post, we will be discussing a whole lot more while providing you the required resources and how to use these tools accordingly. Not only this, but we will also tell you how our team was able to find a CRITICAL vulnerability during a client’s penetration test. So let’s start.

So what really is Subdomain Enumeration?

This is something which you will simply get to know from a simple Google search in much details. In a simple sense, it is the process of finding valid (resolvable) subdomains for a domain. Now, what does it mean practically?
Suppose you have to do a penetration test for a client, and the target in-scope is * Here, the main domain is but due to that “*”, all the subdomains are also in scope. In this case, the subdomains can be,, and many more. It becomes all the more important in bug bounties to find as many subdomains as possible to find vulnerabilities in areas where no one else has started testing.

Let’s see the practical side and tools which will help you in Subdomain enumeration:

There are a whole lot of tools present today for subdomain enumeration. Many security researchers maintain their own scripts to find manually valid subdomains so that they don’t need to deal with many false-positives. But if you are starting new, it will be the best to use the most popular tools for this purpose which have got good support from a large number of users. Some of these are:

  • Sublist3r:It is one of the most popular open source subdomain enumeration tools. This is the Github link from where you can see how to install and start using Sublist3r.
    Sublist3r enumerates subdomains using many search engines such as Google, Yahoo, Bing, Baidu, and Ask. Sublist3r also enumerates subdomains using Netcraft, Virustotal, ThreatCrowd, DNSdumpster, and ReverseDNS. So you get a lot of subdomains from a simple scan using Sublist3r. The problem sometimes is that Sublist3r relies mainly on passive data and so it doesn’t validate if the subdomains do exist in reality or not. So after a simple scan, you will need to check one by one for the valid subdomains.
    Example: If Sublist3r has been installed correctly and the target is, then,python -d

    will give you all the subdomains of Google. See the below screenshot.

  • Subbrute:Coming back, this was our first and favorite subdomain enumeration tool for a little while earlier. You can download and install Subbrute from here. Moreover, Sublist3r has also been integrated with Subbrute just for the purpose of finding more accurate subdomains using brute force with an improved word list.Example:

  • Google Dorks:Now this one is the most famous and the best tool for subdomain enumeration. Actually, it is not a tool, it is just the way of using Google in an advanced way which can unlock many hidden doors. We have already written a post on Google Dorks here. One of the easiest ways to get different valid subdomains is by using a simple technique mentioned in the example.Example:
    In the search box just type
    It will start with www subdomain and then all the subdomains after that. Suppose, the page only contains with different paths. Now what you will do, is -www -cloud

    This search query will remove both the www and cloud subdomains of google from the results. The results will get less and less and you can add each unique result to your subdomain list. It is a manual task, but this gives the valid subdomains in all cases, and many times you may find a page or application just open to hacking into. There are many more applicable cases in this. Read the link we provided earlier to get more of it.

There are other tools like Knock and Masscan. Read more and download Knock from here. You can download Masscan from here.
I will be doing a separate writeup or will add them here in the near future after properly using them. Still the abovee 3 will work fine for you.

How Subdomain Enumeration helped our ENCIPHERS team to get a critical bug which could lead to the total hijacking of the application?

If you have read H1 reports for some time, then you must have seen many Subdomain Takeover reports which were found just by doing Subdomain Enumeration and then taking over that subdomain by hosting some simple content there. But in the last penetration test, our team found one of the easiest and most Critical bugs that could be found there. Let’s suppose the application to be tested was

A simple subdomain enumeration scan through Subbrute gave our team member Rahul the following subdomains:


Now it was time to manually validate each subdomain and of course, there were many more subdomains we got but we didn’t add them here. The thing which he did by mistake was to only search for the exact subdomain without testing for the https:// one. What it means is:

When he searched for, it showed him nothing on the page and he just left it there that this subdomain is invalid or so. But then the other team member Abhinav told me to look for
and to my utter surprise this page could authorize us to there Jenkins server account and after that, even a newbie hacker will know what to do.:) So this was his personal experience, where he came to know across one fact that always check subdomains for both HTTP and HTTPS and then make sure if they are valid or not.

Important Advice:

One thing you will learn in the white-hat hacking community is that to always abide by the scope of the target and not to test on out of scope items. But from our personal view, always do a complete subdomain enumeration of the target at hand and see if there are any vulnerable to subdomain takeover or if things like Jenkins or important private git files are just in the open for the public. The companies won’t mention it implicitly but you can always send these reports and if it is a bug bounty, then stay ready for being rewarded. But do not manually test on the subdomains if they are not in scope. Just test for subdomain takeovers and private files in open and that’s it.

So this was all for this post. If you already knew about Subdomain enumeration tools and if you have one of your favorite please write about them in the comment section and we will make sure that we update this post to add yours. Meanwhile, if you are not yet aware go read about different tools which we mentioned and play with them and see which one works best for you. Happy hacking till then.:)

14 Mar 2018

Bypassing Access Control to see the private videos of an user

Hello security professionals. In the last post, we talked about the XSS finding in the recent penetration test conducted by our company ENCIPHERS. Here is a link to that post. In the same penetration test, we found another vulnerability which was really an interesting one.
But first thing’s first, if you are not sure about access control issues, we have already posted a tutorial for it. Go to this link to read the post.

Now, let’s see what we did and go through step by step. If you know, to test any access control issues, the best way is to create two accounts. You can make 2 accounts which have the same access level or if you can, you should always create 2 accounts 1 with normal features and other with the more features of a Paid account. This is the first thing which we did. Created 2 accounts, one of a Free User and the other of a Pro user and started cross-testing them.

We logged in with both of these accounts in different browsers. Then we opened the account with Pro features. As we already told you in the previous post, there was an option to create self-videos and edit the different details as necessary.

So we created a video and opened the Edit options which led me to a new page. The link to that looked something like this:

The identifier here was not random i.e it wouldn’t change if we made any edits in the video. So this was a plus point and a hint to test for access control because the identifier won’t be unique every time.

The request in Burpsuite looked something like this:

And the response was the one giving out all the details of that video and stuffs inside it like text.

So we went back to our free account and in that browser opened the above link by pasting it there. It worked.We could see the whole video and even play it with what else has been written or added as animation or text. There were no access control measures in place until this point. To see this in Burpsuite, we just needed to change that identifier fwyFsxFfB8Z to the one from the other account to see all the details.
But right after this point, the system prevented me to Edit or Save the file but we had full read control over the video.This vulnerability was critical in its own sense. Because of:

  1. All the URL’s were getting saved in the browser’s history. It means anyone gaining an access can then open the link or share it with him to check the video in make.
  2. The most important issue was the attacker will always see the updated thing. That means if the user has made any changes in the video or animation by adding any text or scenes, the attacker will see the same thing as that user.
  3. The issue was for both private and public videos.
  4. This could lead to important information disclosure because the attacker could see the same video. Just think for a second, if it is a reputed company or so, preparing their videos or any stuff and it is in a draft state and if the attacker by any chance get the link, he will see that stuff himself/herself and meanwhile can find any other way to download that thing before the video gets public.

So this was a simple case of access control. You will think that Write access was not granted but gaining access to things which you are not meant to have is what is access control. We had full READ access to that video which is pretty much a problem in itself.

We will be back again with lots of cool stuff which ENCIPHERS findings pentests or Bug Bounties. Hope you will like it and learn a lot from these practical cases. Happy hacking until then.:)

14 Mar 2018

How self XSS got turned into an stored XSS ?

Hey everyone. Our company ENCIPHERS recently conducted a penetration test for a certain client XYZ and in this post, we will be sharing my XSS finding which was among the most critical vulnerabilities we found in the application.
The client here was a very reputed company which works in the field of video creation and animation. We can’t release the name of the client because the bug hasn’t been fixed yet as the test was done recently.

So our team started testing the application The first thing we did was to create 2 accounts one with the more features of a Paid account and the other was a Free Account and started cross-testing it for certain issues. But we soon found out, that there was an option to create our own videos and save it for future use. You can edit the videos or the text plus Export them or Upload to your google drive and several other features.

Now, what we did was to log in to our free account and created a video for ourselves. We saved the video with the payload

as name. But we got no popup and even checking in my videos list there was no success to be found because the name wasn’t getting reflected anywhere on the page.
Right beside it was an option for Collaboration. That means that we could share a copy of my video with other people who can work on them and can then again share it with us. As soon as we clicked the option for Collaboration, we got the popup as it was saying the video with “Video name” will be shared with these peoples and as a result, the name of the video was getting reflecting back. But the main thing was that till now, it was just a Self-XSS and it was not a high priority bug that could be used to attack others.

But there were two options which struck in our mind. The first was there was no X-Frame-Header or Click-jacking Protection present which could turn this into a Stored XSS. And the other method is what we actually did to turn it into a Stored XSS.

We went to the Collaboration option and gave our Paid account’s email id. We logged in to our Paid account and accepted the invitation to collaborate. As we think you must have guessed now, it had the same exact options as with the original one. So now if this user again goes to the Collaborate option to start sharing with some other person, the name gets reflected without any HTML sanitization and the user gets the popup. This was a simple method to get Stored XSS and in this case, it was a high priority issue because a user with an account for FREE features can get the session id and cookies of a PRO user and hijack the session. This is the POC screenshot.

Moreover, since it was STORED it can have as many victims as the attacker wants. Clickjacking in the whole application issue made the issue more CRITICAL because an attacker could use it to make the user accept the invitation for Collaboration.

This was all we did to get the above-stored XSS. The main thing to take out from this is there are always ways to convert any self-XSS to a General one. You just need to be on the lookout for that opportunity. Abusing Self-XSS using CSRF and Clickjacking are two of the well-known cases where any Self-XSS can be turned into a general one if the site is already vulnerable to attacks like CSRF and Clickjacking.

Meanwhile, keep hacking and we at ENCIPHERS will make sure to keep updating our blogs and tutorials so that you can learn different techniques with each post. Until then, Happy Hacking.:)

03 Mar 2018

Some quick checks to do in the password reset implementation during a pentest

Hello and welcome everyone to this new post from ENCIPHERS. Passwords are the first line of defense against any security attack. You must have already been told to use a hard and long password containing different kinds of characters. Password policies are also implemented so that the user is bound to follow these rules. But most of the times, the developers, and the testers miss one important thing to test thoroughly, and that is the Password Reset or Forgot Password functionality.

Yes, and in some of the recent pentests our team found a whole lot of vulnerabilities in the Password reset implementation of a web application. I will be discussing some of them in this post and the different steps and tools we used to find those issues. So let’s start then.

  • Broken Authentication in Reset password

    This was one of the most critical issues and was given a P1 priority. Through this vulnerability, an attacker could change any other user’s password without his/her knowledge through the Password Reset functionality. The attacker could use the “/passwordreset” API endpoint and change the password of any account with just the knowledge of email address.


    1. First, we raised a password reset request for our account say from forgot password link
    2. Capture this request in Burpsuite and just change the email to another valid email say
    3. Hit the Go button and see the Response. The password of the other account was changed to your previous password successfully.

    This was the Request.

    POST /passwordreset HTTP/1.1
    User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
    Accept: application/json, text/javascript, */*; q=0.01
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/json
    X-Requested-With: true
    Content-Length: 63
    Cookie: session_guid=s%3As9hwB7YRvUuu0ZrtShtc1K994uINRPHW.mWdj5EBB5y%2BF8hZGQK52g5BrOkbuM0QujoT4HVlns8M
    Connection: close


    This was the original Request. We just changed the email value to other valid email and we got the below Response. So we change the email in the above request to and send the request. You are able to change the password of xyz user as shown in the Response below.

    HTTP/1.1 200 OK
    Server: nginx/1.11.8
    Date: Wed, 24 Jan 2018 21:27:52 GMT
    Content-Type: application/json; charset=utf-8
    Content-Length: 32
    Connection: close
    X-DNS-Prefetch-Control: off
    X-Frame-Options: DENY
    Strict-Transport-Security: max-age=7776000000; includeSubDomains
    X-Download-Options: noopen
    X-Content-Type-Options: nosniff
    X-XSS-Protection: 1; mode=block
    Vary: X-HTTP-Method-Override, Accept-Encoding
    ETag: W/"20-ji/kkxAvLqkafQZ/AmvRSPoi2nc"


  • Reset password list can be intruded to get a list of registered users

    This was a P3 priority issue but this issue along with the first issue could be used as a full fledged attack which will compromise the user account totally.
    The Forgot password url did not impose any restriction in number of requests being sent from a user. A hacker could make use of this and test for numerous email address which will result in sending reset password email to registered users.

    The Forgot password redirected to recover page if user was registered otherwise it redirected to login page with not registered message which can be used to guess which emails are registered.

    Sample Request and Response for a registered Email id:

    GET /passwordreset/request?email=risabh%2enandwani@gmail%2ecom&g-recaptcha-response=03AA7ASh3zEWVCZjJiMIWFSs1zrSA-eiPoARwlgVFWGjZ0QgJMRVAZvV8ipx2q_lGnPN76E1jN6CzIa1pM05SQVc2zVXS21b_kqS0u4XhJW0grAWoujxQ7pArCXyaRbbapKNUD57dod793eKVcM1MRliiCMg16m3Rf8Hrc4q9G_bST5ynYQdjfLZdZs-oVhdA7WrPlmVJl8HTXSsAvjt4mQ5wR7brYch0i1U802ECRnDDpYC8Rcs1Hqfg3DZJ9cDv2BNRqRZ1gQMezvhhDhrBCx5r9SgD9NFCbZHWShKYygugGh76aiWWsZ1tSegFFmY0hP2ITV-t4hKmOUxo7GvXyMENaR-JFbsd22hz-UyHSauT5a5zETqy5e1-ZgG7QVETsDcnT6Nw7Pa8RVKOkSU8AQ90Ujg_Kv7cdIg&action= HTTP/1.1
    User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Connection: close
    Upgrade-Insecure-Requests: 1


    HTTP/1.1 302 Found
    Server: nginx/1.11.8
    Date: Mon, 22 Jan 2018 09:32:30 GMT
    Content-Type: text/html; charset=utf-8
    Content-Length: 62
    Connection: close
    X-DNS-Prefetch-Control: off
    X-Frame-Options: DENY
    Strict-Transport-Security: max-age=7776000000; includeSubDomains
    X-Download-Options: noopen
    X-Content-Type-Options: nosniff
    X-XSS-Protection: 1; mode=block
    Location: /?recover
    Vary: Accept, Accept-Encoding

    Found. Redirecting to /?recover


    Now just think for a moment. If the application isn’t using any restrictions on the number of attempts here, a hacker can simply use the Intruder in Burpsuite and do a brute force attack to know which users have registered email addresses. Now, this attack can then be further used for the attack we discussed in the first example to change the password of that account which will then totally compromise that account whether it be a user or an admin.

  • Denial of Service

    Now, this was kind of a vulnerability which will definitely create problems for the registered users.
    What it means is that if a password reset request is raised for any account, that account holder cannot login to his old account unless he resets his/her password through that link.
    It can be used to temporarily revoke the access of a user.

      1. Just raised a password reset request for another email id obtained through the Example 2.
      2. The reset link will be sent to the user but if the user doesn’t check the mail, he/she won’t be able to login to the application through previous details.
      3. If the user resets his password, the attacker can again send a password reset request and keep on sending them which will then totally deny access to the user.

    This was the Request and Response for a valid user.


    POST /auth/local HTTP/1.1
    User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/json
    X-Requested-With: true
    Content-Length: 55
    Cookie: session_guid=s%3Ag7MHq7gbCo-DYEcINT0ph5A7ZkDvbvFF.VV24NQNxr7Jls0qJQH91lH%2BHq25BTY5xE7JezupoeIQ
    Connection: close



    HTTP/1.1 200 OK
    Server: nginx/1.11.8
    Date: Tue, 23 Jan 2018 11:04:40 GMT
    Content-Type: application/json; charset=utf-8
    Content-Length: 36
    Connection: close
    X-DNS-Prefetch-Control: off
    X-Frame-Options: DENY
    Strict-Transport-Security: max-age=7776000000; includeSubDomains
    X-Download-Options: noopen
    X-Content-Type-Options: nosniff
    X-XSS-Protection: 1; mode=block
    Vary: X-HTTP-Method-Override, Accept-Encoding
    ETag: W/"24-9CvwFGpkVCOkoBhIf3mK/SyHVEk"


    See, after the password reset request was raised, the response we got was account not verified. And it will be like this unless we reset the password through that link.

    This was a P3 vulnerability but I think you can understand the relation between the 3 examples and how one can lead to getting the other.

  • Token used in Password Reset link

    Password reset test should be tested thoroughly else even one mistake may allow an attacker to take over the whole user account by changing his/her password.


    1. Let’s say the target is Send a password reset request for a normal user at
    2. Check your mail. In our case, the token was written in the link simply. Something like this:
    3. Now the things we need to check here, first of all, is the token expiration.
      Just suppose that this link doesn’t get expired after one use, then if the person could somehow get access to the user’s mail, he/she can then reset the password through this link again and take over the account.
    4. Many times, it may happen that the token used maybe is just an integer. In that case, you will need to send several different requests to check how the algorithm works and if the token is random all the times.

    So testing of tokens is an integral part of the testing for password reset functionality.

This was all we wanted to discuss in this post. This post will help you understand these things practically which will then allow you to use these methods for password reset testing. We hope you understood most of the things in this post. In any case, if you are a seasoned bug bounty hunter or penetration tester and you have other different methods to test for password reset testing, please comment below or write to us. We will make sure to add them in this post for our readers. Thanks and happy hacking everyone.:)