Fundamentals of Bug Bounty Recon

probably the most talked about subject in the bug bounty space is recon and i kind of encourage that here as well i covered i mean my first video was f it's it's typically considered a fuzzing slash recon tool um a lot of the tools that i've written are recon focused the challenge i'm trying to bring to the table today is that we talk about this a little bit too generically myself included and i'm trying to change the habit and the way we do that now that i'd like to challenge is we talk about recon as one big bucket which there's a lot of things that we intuitively know as hunters as we get more experienced but a beginner comes in all they hear is recon and you can see this manifesting uh particularly over twitter the number of people that build recon scripts uh without considering the various elements i'm going to cover today and the number of people that are like hey i enumerated this program and i found this thing with nuclei or i found this thing with this exploit um the diamonds and the rough those findings they're not how you make sustainable bug bounty income and i want to try and break that apart and help you to understand where value lies and how to think about recon a little bit more deeper by covering the fundamentals that i think many hunters know but we don't often put labels on [Music] so the first um active and passive this is one that's obvious we used to talk about a lot and we've kind of pulled back from it as tooling breaks terms and services more openly i guess if we go back three to four years ago it was very common to write tooling that adhered to terms of services it was very deliberate um when i spent i was first doing subfinder we took a very deliberate approach to follow all terms and services we made it a purely passive recon tool um over time tooling and services have kind of pushed that bar and they don't respect it as much which i'm not saying that's necessarily a bad thing but along that journey we've lost the discussion of active and passive as a byproduct of everything just being thrown at the wall see what sticks which tends to be the mentality of recon in general these days um so active and passive what that means is passive is when you're using a third-party api that touches a service for you so you could query the security trails api and you're querying their database for details relating to an asset you're not actually hitting that asset directly versus dns brute forcing where you're actively touching the asset or you know directory brute forcing you're actively touching an asset and the difference there can be down to conditions of a service or maybe you want to limit the traffic that you're putting through maybe you're a pen tester and you want to go for a lighter touch on a red team engagement but it's important to understand what services are doing what what are your active services and your active tests versus what are your passive services and passive tests and the typical rule is that if you touch the asset you're doing an active test if you're going via a third party or a third-party data set such as rapid seven you'll passively identifying information and that can also include uh passive identification through aussie such as scraping social media for acquisition information and things like that now another element that i've always referred to as breadth and depth and i heard this described much more elegantly by shubs at crikeycon in his 2021 talk where he called it narrow and wide i think that's a far superior way of describing this and i'm going to use that from now on but uh narrow and wide recon is basically the difference between identifying a company's target space and enumerating the targets so wide recon is your first pass what assets belong to the company that you're looking over what two top level domains do they own what sub-level sub-domains are under that what acquisitions have they made um and then taking that the next step further you've now got the targets it's time to dig into the targets and perform recon there with narrow recon so that could be things like directory brute forcing mapping out the api mapping out the application level functionality and doing things that helps you to understand the makeup of each target in the asset space and this delineation is important because today a lot of recon scripts a lot of recon tools tend to put both into the same tool or the same workflow and that's not ideal because you want to do wide recon more regularly than you do narrow recon because narrow recon has a computational cost to it both in time and it's a good there's a higher chance of getting kicked off a program or kicked off a platform because you can break rate limits and terms and conditions on a brief much much easier if you're over enumerating on narrow recon likewise you need to understand when to go deep with narrow recon and when to go subtle and what i mean by that is you might want to do a first pass so you might do your wide recon you've mapped all of the domains and you want to see is there any easy identify items in there that are going to make you go deeper and to do that you might have a word list of only 50 items that you're going to spray wide you don't want to spray a 100 000 or even a 10 000 word word list over all of those targets if you're going for a quick pass it's just not a productive use of time and a well-tailored shorter list is gonna have a much greater impact for you and essentially accomplish the same result without the high overhead of time and effort in and that brings us to our third point which is the difference in recon styles and the one that's truly making money and the people that are making money off recon are not the people who are doing point in time recon point in time recon is when you re you map an asset space for the first time you go okay i'm going to understand i'm going to run all the tools and go as deep as possible and i'm going to run nuclei i'm going to submit all the things you're very very lucky if you get findings that way and it's not unlikely it happens but you're not going to make consistent return that way you would have to regularly change programs regularly hunt around the people that are having success in bug bounties and the people that are making regular returns are doing recon over time not point of time recon they're mapping asset space today and then next time they return to the program they're mapping again and they're learning what the program changes and what they care about where are they currently changing their asset space where are they deploying new assets what is the difference here and this isn't very well understood still today everyone seems to have and i say everyone as a as a collective not everyone directly and literally but as a collective the emphasis in tooling is all built on scripts and point of time recon everyone's going recon sh let's map everything and there's this emphasis of trying to get more and more and more into that script the unfortunate reality is i can accomplish as much in that script as i can in security trials surface browser if i want to and you're better investing better off investing your time in identifying how to track differences in programs and how to understand programs so you do that through the combination of good notes and good tooling today public tooling in terms of mapping identification of change in assets isn't very popular i contributed my own here recently for mapping the difference in dns in the form of doot tom nom nom for a few years now has had a really good tool called anew that'll show you when new assets pop up and a mass has functionality to show you when your assets arrive as well what we're missing and what we need to do better is to track points of change and you can do this loosely with tools like httpx you can track similar state changes as you would to do but there isn't in the public space at least a great way of going okay this at this page changed on this date and this always changes on a friday which indicates this team's using scrum and they deploy changes on a friday i should focus my time there at this point and the people i've seen having a lot of success have nailed this they know when to look for change and where to look for change and that's where you're typically going to have the most value if you choose to focus directly on specific programs now obviously there's exceptions to every rule there are phenomenal hunters i see that pick up run and they find things and there are programs that support that very well the wider a program's target space the more it's going to support point of time recon but the more competitive this space becomes the less that's going to work the other side of this coin too is there are people that are purely focused on doing sub-domain takeovers and various other discoveries the reality is none of those people are doing the subdomain takeovers that you know about because they're typically doing ones that aren't in the public space the most valuable takeovers don't render up in public tooling and as a frustrating thing as that is to hear for many it should be encouraging from the lens of you should dive deeper into identifying unique elements if you want to run tools and have them make money instead of learning how to hack more legitimately and going deeper into an application you need to learn how to identify custom events so you need to know how to make your own nuclei templates and you need to know how to identify what is a subdomain takeover that may not be picked up by a subject or tko subs or something of the like you will still find you will still make money if you follow the standard approach but there are so many people doing it now you won't make a regular return and you will cap out pretty quick in how much you can make and it's hard to hear and it's frustrating to hear but the reason i raise it is because i don't think it's talked about enough a lot of twitter a lot of our emphasis is on hey i made bug by this template or by doing this and it renders a very false expectation of bounties because the people that are making regular returns in other ways aren't talking about it so in closing uh what have we covered we've covered active and passive recon so active is whenever you touch a target and passive is when you're going via a third party such as an api we've covered narrow and wide recon so wide is when you understand the target space that makes up a company and narrows when you understand the elements that make up a target specifically we've also covered the difference between point of time recon when you recon an asset space for the first time and recon over time when you re-recon a target or you monitor targets to see points of change and work out what a company cares about and what they're doing and there's a whole world to explore in that there is everything from monitoring for new acquisitions monitoring social media to monitoring the you know hashed response of a page or the levenshtein difference of a page response and you know there's a lot of competition still to be found here i think the element of subdomain takeovers and easy templates is extremely competitive now i think that's moving to be a product space competition the average lifespan for a lot of those bugs at the moment tends to be within the 30 minute range and so i think the next big iteration for everyone is how do you find what a company is pushing code and how do you compete in that area most directly because there's a handful of key players that i think are going to retain and dominate the other side of this equation a lot more directly those secrets aren't easily won and you can see that a lot um once you understand the kind of vulnerability classes that people are making a lot of money off and you compare it to what's known publicly there's a pretty big divide there and you know that's up to you that's not to say that you couldn't compete purely focusing on recon based findings but i think you're setting yourself up short if you do and i think the best way to find success as a hunter and i will always emphasize this is to understand how to hack and to learn how to hack and then learn how to weaponize that directly if you shortcut yourself and you purely focus on letting people who have written other tools do it for you they'll have already run those tools themselves with private templates or ahead of going public and they've already cleaned up a lot of the space what you want to focus on is how do you make those tools better or how do you make your own tools or how do you use the tools to point your knowledge and your skill set in the direction that you're going to make the most return i truly believe that's the best way to be successful instead of looking for short-term wins but to make something that's more sustainable and longer term for yourself and you're providing maximum value at that point as well and that's going to lead to additional opportunities but all in all i hope this was insightful and interesting i'm very open to discussion on this i know it's one of those subjects that uh people see very differently uh perspective i manage a triage team and i've been quite successful as a hunter that's where i'm speaking from here um i'm open to varying opinions and i'm certainly not suggesting that i know everything here i think i have exposure that's valuable to talk about this subject but if you have a difference of opinion let's chat about it i'm very interested and i'd love to dig into it deeper as well as see how we can shape the narrative around

Channel: codingo

Views: 25,922

Keywords: hackerone, bugcrowd, intigriti, synack, yeswehack, cobalt, bug bounty, bug bounties, hacking, hacker, burp suite, burpsuite, osint, recon, rapid7, securitytrails

Id: DABPWQ40yb0

Length: 12min 39sec (759 seconds)

Published: Thu Apr 15 2021