 Hello, everyone, and welcome to my talk at DEF CON 29. So in this talk, we are going to see the bug hunters record methodology. So before starting, let me introduce myself. So my name is Tussar Verma, and I am working as an application security engineer. I'm also a part of Cinec Red Team and a full-time bug bounty hunter. I'm also an InfoSec trainer and speaker. So let's see the agenda for this talk. So the first thing which we'll be seeing will be the scope review for any bug bounty program. Then we'll be moving forward to before record and after record, like when we are starting, then what kind of information we will be getting from the company which we are testing. And then after record, what kind of information we will be getting. Then we will be moving forward to scope-based record methodology, and we'll be seeing the plus point, the benefit of that methodology. Then we'll be seeing the basic methodology. In this basic methodology, basically, my aim is to just give you an insight like, OK, if we are doing a record. And the main thing is you need to use every single information which you are getting from it and use it to make your record more and more useful for it. You can get more endpoints, more information for it. You can get new variety, and then you can get paid for it. And after that, at last, we'll be seeing the tools and automation frameworks, basically, because nowadays we can automate everything. So we'll be seeing how we can automate these things. And there are many automation frameworks also available in open source. We can use that also. So the first thing is scope review for in-program. So before record also, you need to first do some scope review for the program which you want to start with. So this is a very not-so-easy task for everyone. So you need to first see the assets. So what is the asset for the in-scope and the out-scope items present for any program? Basically, if you've got more in-scope items on your program, then, of course, you can start with it because you have more things to test. You have more endpoints, more in-scope items. So you can start with that. So if the asset is not at you, so you can't, like, you know that in bugman program, everyone is testing on the same program. You have a lot of completion. So for that, you need to be getting assets. Like, if you have more number of assets, the in-scope items are more, then you can go with that program. The second thing you need to say is the number of reports with all. So, of course, like, if anyone is reporting to any bugman program and the number of reports is all is more, means the company is also very active and it is like they are taking action against every report they are getting. And they are patching everything. So, of course, the company is active. So the chances, like, you will be getting a reply from that company is more. So you can go for that company, like, that program also. The third thing, and I think this is the most important thing is the payout, because I think in bug1D, everyone is just, like, hunting for bounty only, like they just want reward, money, huge, like, they are getting everything in bug1D. So this is a very important thing. You need to set the payout, like, OK, for, like, a particular kind of vulnerability, how much they are paying to compare with two, three programs, and the program which you see, OK, this is the best payout in all these three to four programs, and you can go for it. See, it's a personal choice. It depends upon you. Another time to try, then time to bounty. This is a very important thing, like, OK, after your bounty, like, your bug has been accepted, you need to see, like, after how many, like, days you will be getting bounty, how many days it will take to just pay you and all. So you need to see these four things, then only you can just, like, come to a, like, like you can say, we can just make up a mind, like, OK, this program is best for me. OK, we can say that. So then you can start forward and start doing Rekon on that program. So now, for Rekon. So when I just, like, for example, I was, like, let's put in Buckrow or in Hagrid one, we have everything given, like, OK, the, about the company assets, the number of deport is all the payout, and the time to try, then time to bounty. In Buckrow, we have only, like, OK, after these money, they will be giving you a response. OK, so they give everything, like, clearly, it's mentioned everywhere. So you cannot say it from these two. Now, after that, when you will be jumping into that program, you will see some basic information which is available for every program. The first thing is company name, of course, let's put it in the scale of company name X, Y, Z, and you will be having the available scope also. So, like, all the in-scope items, out-of-scope, this thing will be given. They will be also giving you some overview of the company business. And the fourth thing will be, like, they will give you some out-of-scope identity, like, they don't want these bugs to be reported. And they will also give you some focus area, like, OK, focus on these bugs, these endpoints, because they want that endpoints or that one to be tested on their application. So these are things which is given to you before Rekon, like, you're getting before Rekon only. Now, after doing Rekon, what things you are getting? So, after Rekon, we are getting, the first thing is the service info. The second is the backend technology use. The third is the interesting endpoints. The fourth is the juicy links, which may be vulnerable. And then we are getting more and more things, like, after you're doing Rekon. So, of course, you're getting more and more. So these are things, like, before Rekon and after Rekon, you're getting. So now, the main thing is, like, how to start doing Rekon. So the scope-based Rekon methodology by Harfotra is the best one. Why? Because the first thing is, like, it will be saving you a lot of time, because you know, like, OK, for that particular scope, you need to test that things only, like a limited number of things only. You won't be, like, mixing up everything. OK, the first thing. The second advantage is, like, the chances for getting duplicate or autoscope bug will be very less, because you know about your scope, right? So if you know about your scope, then, of course, it's a very good thing. And the chances of getting a bug, which is not, like, accepted by company, will be very less, so it's a very good thing. Also, you can automate your Rekon workflow, because you know about, like, OK, the scope is, like, small or medium or large. So, of course, you can automate that workflow also. And then you can just get all the information in just one automation. And it will also, like, you know, basically, the thing is, like, just blindly doing Rekon is not a very, like, not give you anything, OK? So you need to understand the workflow first. So for that, scope-based Rekon is the best thing. So, if scope-based Rekon, basically, we have three types of scope available, the small scope, the medium scope, and the large scope. So the small scope, if you are getting, then you'll only get a single URL, like the domain or the subdomain, OK? So if you get any, like, for example, evu.com or info.evu.com, then, of course, it's a small scope target. We'll be, like, moving forward with a small scope Rekon. The second one is the medium scope target. So in that, we'll be getting a wildcard domain, that is star evu.com. This is a, like, you can just see, and, OK, if there's a wildcard domain present, then, of course, you can go for the medium scope Rekon. Then comes the large scope one. So anything, like, if you are testing a company, so anything about the company, which is related to that company, we will be in scope, so you can do a large scope Rekon on that company. Now comes the basic methodology. So, like, why, like, just, for example, if we are starting the Rekon field, OK? And we need to, like, we are getting a target, let's evu.com, it's just, like, medium scope one. So we need to start a Rekon here. Now the main thing is what happens in Rekon, basically, we just go on blindly doing Rekon and we don't use every single information which we are getting from it. So I will be giving you a basic, like, like workflow, like, what we can follow, and then you can automate also with some tools. So for example, if we get our target, let's evu.com, it's a wildcard domain. So we can first start doing the, like, we can run a subfinder, MRs, and we can get all the subdomains. And we can save it in a folder, let's say the, any name we can give it. Now we have got all the, like, after getting everything from that, then we can just move it to the HTTPX or HTTP Pro, and we can fit out the active endpoints from them. Now after getting the active one, we will be making one more folder for it. Now we got two. Now let's support that we need to get more and more information from these two only. So we'll be carrying out the active TXT file, and we will be, like, moving, just making it a scan from the, like, we need to get some more endpoints, some URLs from it. So we'll be using Wayback URL and Go, and we can get all the, like, endpoints which can be, like, we can just go on for testing also and any input which related to that particular domain we'll be getting from that. So now we got three files saved. Now after that, we can, now we got the first file which is having only subdomains. So now what we can do, we can just use the pub tool and we can just, like, get some more endpoints. We can put four of them, and if we are getting any, like, response for, like, four access, we can try to bypass that. So now after that, we'll be getting one more file, we can just save that file also. Now we got four files, just keep in mind that. Now after that, we can do a NMAPS and all the active TXT file. And in that, and, like, after doing that, we'll be seeing all the open ports and everything available. So we can now save it as a, let's say, we can save it one new file now again. So we got around, like, the first file which is having only the subdomains. The second file is having only the active subdomains. The third file is having the data which we got after using first. Like, we are, then the fourth one will be, like, having all the endpoints which we got from Gov and Wayback URL. And the fifth one will be, we are getting all the open ports from NMAPS. Now the main task is to get some endpoint which we can start testing for the SQL or let's say, XSS or any other vulnerabilities. So for that, we can use GF or GF pattern. And then we can start, like, just, like for example, if you want to test for XSS, we can just use GF pattern and get all the endpoints which can be, like, can be vulnerable to this, this particular bug, OK, like, or XSS or SQLI or LFA or anything else. So we'll be getting that. We can save it in a file. Now if we want to grab some JS file also, we can do that also from that. So these are some things. Now after collecting every file, now we can just use an automated scanner also and we can pass all these files and we can get, like, some variety from them also. Like, we can just get some more endpoints. We can get some variety. We can get some more information on what target also. So this is a flow, like, we are using every single information which we are getting from Rekon, we're not wasting it, OK. So now this is a very long work, like, of course, I'm not telling, also, now I am, sometimes I'm mixing many things. So it's a very long, like, process and it will take time doing manually. So you need to, like, automate everything. So nowadays, in open source, we are, like, we have got various, like, tools and frameworks which are available. So the best one, like, which I am also using, the first one is the Rekon FTW. Rekon FTW is, like, it has everything, like, automated. Everything, like, every single thing which you want to do in Rekon is, like, put it in this tool and it's a free open source tool. So you can use this to automate your Rekon workflow. The second one is the Project Beam by Hertz Botra and this is a, like, it is working on the method of scope-based Rekon. So if you're following a scope-based Rekon methodology, then you can use this tool. The third one is the Osmedius. It's an old one, but now also if you are, like, if you want to just do a Rekon scan and all, then you can use this tool because it is also giving you a proper result of that. Of course, it is, like, because these three tools are doing a lot of Rekon work, so it will take time, of course. So if you don't have, like, a higher internet connection, then it will be very, it will take time. And of course, like, because the tools are doing many videos, same. So you can do one thing. You can just, like, use this tool in background and do things manually also. So manual plus automation, if you're doing in Rekon, then, of course, it will be very, like, it will be giving you an advantage also. And the main thing is, because you know, like, what you're doing, because if you don't understand the workflow about these tools and all, then, of course, it is very, like, hard for anyone to, because you're just, like, for example, you're getting every information, but you don't know how to use that information further on for your testing. Then it's a waste of time for you. And, like, if you're running a tool, you're getting many various information, but you don't know how to use that. So, of course, it's a waste of time. So don't do that. Always first understand what you want to do, what you want from the target, what kind of information you need, and then only start your Rekon. That's all. I hope you, like, enjoyed my talk. If you have any theory, then you can contact me on these handles. Thank you.