Speaker 1: Imagine getting paid to find like the digital version of
Speaker 1: an unlocked door, not to break in, but just to
Speaker 1: point it out so the owner can fix it.
Speaker 2: Yeah, that's pretty much the gist of ethical hacking and
Speaker 2: bug bounties.
Speaker 1: It's this really fascinating world where you can sharpen your
Speaker 1: cybersecurity skills and well maybe even earn some serious rewards.
Speaker 2: Absolutely, and it's a field that's constantly changing, always needing
Speaker 2: shirt people to spot those weaknesses that crop up with
Speaker 2: new tech companies. See the value in.
Speaker 1: It definitely, and that's exactly what we're diving into today.
Speaker 1: On the deep Dive. We got some great source material
Speaker 1: from a listener, excerpts from bug Bounty from Scratch by
Speaker 1: Francisco Javier Santiago Vasquez.
Speaker 2: Oh yeah, that sounds useful.
Speaker 1: It really looks like it seems perfect for anyone curious
Speaker 1: about this or you know, maybe already in it but
Speaker 1: wanted to sharpen their game.
Speaker 2: Right and looking at the author, Francisco Oscrez, he's got
Speaker 2: real hands on experience red teaming pen testing across different industries.
Speaker 2: That counts for a lot.
Speaker 1: It does. Plus, the book's got endorsements from people like
Speaker 1: Muhammad Hadji, big name in bug bounties, and doctor Shifah Cyklwala,
Speaker 1: another cybersecurity leader, add some weight, doesn't it?
Speaker 2: Yeah, definitely suggests it's a credible resource.
Speaker 1: So our mission today is basically to pull out the
Speaker 1: essential stuff about bug bounties from this book. What they are,
Speaker 1: how they actually work, the kind of skills and tools
Speaker 1: you need, and.
Speaker 2: Some of the core techniques bug hunters use.
Speaker 1: Right exactly. Think of this is like your shortcut to
Speaker 1: understanding the basics without getting totally bogged down in detail.
Speaker 2: Sounds good, Let's get into it, Okay.
Speaker 1: So let's kick things off. What is a bug bounty
Speaker 1: in simple terms?
Speaker 2: Okay? Essentially, it's when a company puts out an open invitation.
Speaker 2: They're basically saying, hey, find security flaws in our systems,
Speaker 2: tell us about them, responsibly.
Speaker 1: Follow our rules, and we'll reward you exactly.
Speaker 2: And that reward it can be cash, sometimes small, sometimes
Speaker 2: pretty substantial, depending on how critical the bug is, or
Speaker 2: it might be public recognition like getting your on a
Speaker 2: hall of fame.
Speaker 1: Okay, but how do these companies actually connect with the hackers,
Speaker 1: the researchers looking for these bugs. It's not like the
Speaker 1: post job ads, is it No?
Speaker 2: Not? Usually that's where bug bounty platforms come in. Think
Speaker 2: of them as middlemen, like brokers sort of platforms like
Speaker 2: hacker one, bug Craft, they're big ones. They connect the
Speaker 2: companies running these programs with the security researchers. So researchers
Speaker 2: sign up, find programs that fit their skills and get
Speaker 2: hunting right.
Speaker 1: So a company lists their program on hacker one, for instance,
Speaker 1: how does it actually work? Then? What are the steps?
Speaker 2: Well, the company first sets out the rules, the terms
Speaker 2: of engagement. This includes what kinds of vulnerabilities they care about,
Speaker 2: which systems are in scope that's crucial, what you're allowed.
Speaker 1: To test, and what you're not allowed to touch precisely.
Speaker 2: And they'll also list the rewards for different bug severities.
Speaker 2: Then the researchers get to work. If they find something
Speaker 2: valid and it's within that defined scope, they write up
Speaker 2: a report yes submitted to the platform. The company's security
Speaker 2: team reviews it. If they agree it's a real in
Speaker 2: scope vulnerability, the researcher gets the reward.
Speaker 1: Okay, are all these programs pretty much the same or
Speaker 1: do they vary? Oh?
Speaker 2: They vary quite a bit. Some are really specific, like
Speaker 2: focusing only on their mobile app, maybe an Android or
Speaker 2: iOS app, or just one specific API, while others are
Speaker 2: broader exactly, some might cover a much wider range of
Speaker 2: their digital assets. And then there's a difference between public
Speaker 2: and private programs.
Speaker 1: Ah okay, what's that.
Speaker 2: Public programs are open to basically anyone registered on the platform.
Speaker 2: Private ones, though, are invitation only. Usually you get invited
Speaker 2: based on your track record, your reputation on the platform.
Speaker 1: So proving yourself in public programs can lead to private.
Speaker 2: Invites potentially, Yes. And one more type, Vulnerability disclosure programs
Speaker 2: or vdps. They're similar. They want you to report vulnerabilities,
Speaker 2: but they typically offer recognition, maybe some swag, but not
Speaker 2: usually cash rewards.
Speaker 1: Got it? So? Okay, someone's listening, Maybe they have some
Speaker 1: tech background and they're thinking, hmm, this sounds interesting. What
Speaker 1: kind of foundational knowledge is really needed to even start
Speaker 1: thinking about this?
Speaker 2: Yeah, the book really stresses having a basic grasp of
Speaker 2: core computer science concepts, things like networking fundamentals, how systems
Speaker 2: generally work.
Speaker 1: You don't need to be an expert pen tester.
Speaker 2: From day one, no, not at all, but having that
Speaker 2: solid base helps you understand how things are built, which
Speaker 2: then helps you figure out where they might be weak.
Speaker 1: You know, right, makes sense. So you've got that foundation.
Speaker 1: You go onto one of these platforms and there are
Speaker 1: maybe hundreds of programs. How do you even pick where
Speaker 1: to start?
Speaker 2: That's a really good question. It's strategic. The book suggests
Speaker 2: looking at a few things. First, does the program focus
Speaker 2: align with your skills? If you know web apps, well,
Speaker 2: maybe start there.
Speaker 1: Play to your strengths exactly.
Speaker 2: Second, and this is super important, you have to understand
Speaker 2: the program's scope, what domains What apps are okay to test,
Speaker 2: what's exc implicitly forbidden.
Speaker 1: The book mentioned some examples right from hacker own, Snapchat,
Speaker 1: and Visa.
Speaker 2: Yeah, those are good examples because they show the contrast.
Speaker 2: Snapchat apparently gives a really detailed list of what's in scope.
Speaker 2: Visa's example in the book is more about illustrating the
Speaker 2: reward structure. You know, how much they might pay for
Speaker 2: different types of flaws.
Speaker 1: And getting that scope wrong is bad news, very bad news.
Speaker 2: Testing things that are explicitly out of scope can land
Speaker 2: you in serious legal trouble. It's not worth the risk.
Speaker 1: Definitely not so scope skills what else? Rewards must play
Speaker 1: a part?
Speaker 2: Oh for sure? I mean learning is great, the challenge
Speaker 2: is fun, but let's be honest, the potential payout is
Speaker 2: a big motivator for many people. Looking at the reward
Speaker 2: tiers can help you decide where to invest your time.
Speaker 2: Makes sense, But beyond the practical stuff, the book really
Speaker 2: hammers home the ethical side. The whole idea is think
Speaker 2: like a bad guy, but don't be one. Right to
Speaker 2: the rules, Absolutely, follow the program rules, strictly, test ethically.
Speaker 2: Don't cause disruption, that's non negotiable.
Speaker 1: Yeah, you're helping them, not hurting them. Okay. The book
Speaker 1: also mentioned identifying critical systems. Why is that important for
Speaker 1: a bug hunter?
Speaker 2: Well, think about it. If you understand what a company
Speaker 2: considers its crown jewels, maybe their main customer database, or
Speaker 2: the payment system, or how users log in the really
Speaker 2: sensitive stuff exactly, focusing your efforts there means finding a
Speaker 2: vulnerability could have a much bigger impact, And the book
Speaker 2: points out breaches in those areas cause huge reputational damage,
Speaker 2: maybe lose customers, cost a lot of money.
Speaker 1: So finding bugs and critical systems is generally more valuable.
Speaker 2: Usually, yes, and often those findings carry higher rewards too.
Speaker 1: Okay, this is great, We've covered the basics, how programs work,
Speaker 1: prep ethics. Now that really hands on part. What tools
Speaker 1: and techniques do bug hunters actually use? This is where
Speaker 1: it gets exciting for someone wanting to try this.
Speaker 2: Right the practical side, The book breaks down the tools
Speaker 2: quite nicely. First up, information gathering, This is key.
Speaker 1: What kind of tools.
Speaker 2: Tools like sublister a mass, DNA s dumpster, subfinder, aquatone.
Speaker 2: These are mainly for finding subdomains, discovering all the different
Speaker 2: web addresses associated with a company.
Speaker 1: Like finding hidden doors and windows.
Speaker 2: Kind of Yeah, it increases the potential area you can test.
Speaker 2: Then you have standard stuff like who's lookups for domain
Speaker 2: ownership info and DNS tools like en slok up or
Speaker 2: dig okay.
Speaker 1: So mapping out the territory first, what about testing web applications?
Speaker 2: Specifically for web stuff. Burps suite is pretty much the standard.
Speaker 2: It's mentioned repeatedly as essential. It lets you like intercept
Speaker 2: web traffic, mess with it, analyze requests, automate tests. It's powerful,
Speaker 2: the go to tool for web hunters largely yes. The
Speaker 2: book also mentions wp scan, which is specifically for WordPress sites,
Speaker 2: finding known vulnerabilities there, and der search which helps find
Speaker 2: hidden folders and files on a web server.
Speaker 1: What if you need to look deeper at the network.
Speaker 2: Level, then NMP is your friend. Often called the King
Speaker 2: of Network scan. It finds live computers, checks for open ports,
Speaker 2: tries to identify what services are running on those ports,
Speaker 2: even guesses the operating system sometimes.
Speaker 1: So NMAP maps the network itself. And if you think
Speaker 1: you found something a potential vulnerability.
Speaker 2: That's where something like exploit dB comes in handy. It's
Speaker 2: a big public database of known vulnerabilities and crucially exploit
Speaker 2: code or proof of concepts showing how they can be triggered.
Speaker 1: Ah, so you can see how a theoretical vulnerability actually
Speaker 1: works in practice exactly.
Speaker 2: Understanding the exploit helps you confirm and report the issue effectively.
Speaker 2: The book also touches on ossent open source intelligence.
Speaker 1: Using publicly available info.
Speaker 2: Right tools like multago or showdand can help gather that
Speaker 2: and even simple things like clever Google searches Google dorks.
Speaker 2: The book gives examples like searching and title index of
Speaker 2: password dot txt.
Speaker 1: Wow, finding password files just.
Speaker 2: With Google sometimes or intex dot username, intex dot password.
Speaker 2: It's surprising what gets left exposed sometimes due to simple mistakes.
Speaker 1: That really highlights how basic errors can create openings. Okay,
Speaker 1: so those are some tools. What about the actual techniques
Speaker 1: for finding bugs?
Speaker 2: Well, reconnaissance is the foundation, Like we said, gathering info,
Speaker 2: identifying services, running, maybe doing initial automated scans to see
Speaker 2: if any low hanging fruit pops up.
Speaker 1: You can lay the land definitely.
Speaker 2: Then the book talks about exploring human errors.
Speaker 1: This can be really effective Tawso like.
Speaker 2: Checking the robots dot txt file on a website. It
Speaker 2: tells search engines what not to index, but sometimes it
Speaker 2: points directly to admin pages or sensitive areas developers didn't
Speaker 2: want public.
Speaker 1: Huh, telling people where the hidden stuff is.
Speaker 2: Ironically yeah. Also, using the Wayback Machine the Internet archive,
Speaker 2: you can look at old versions of websites. The book
Speaker 2: mentions an example where someone found deleted resources on packed
Speaker 2: Pubs site. This way old info might still be relevant
Speaker 2: or expose something.
Speaker 1: It's clever using web history for security.
Speaker 2: It can be also just looking for general information leaks,
Speaker 2: maybe databases left open, credentials and so code comments.
Speaker 1: Right. What other techniques?
Speaker 2: Subdomain takeover is another interesting one. Sometimes a company stops
Speaker 2: using a subdomain, but the DNS record still points to
Speaker 2: a third party service if that service allows you to
Speaker 2: claim unused names. You might be able to take over the.
Speaker 1: Subdomain and then potentially misuse it.
Speaker 2: Potentially, yes, which is why it's a vulnerability. Also, checking
Speaker 2: GitHub repositories is common now, looking for apikeys, passwords, or
Speaker 2: just badly configured code accidentally pushed.
Speaker 1: Publicly developers leaving secrets in the code happens all the time.
Speaker 2: I bet more often than you'd think. Local file inclusion
Speaker 2: or LFI is another classic web vulnerability, basically tricking the
Speaker 2: server into letting you read files It shouldn't like configuration files.
Speaker 1: It sounds like a mix of technical skill and being
Speaker 1: really observant looking for those small mistakes.
Speaker 2: That's a huge part of it. The book also mentions
Speaker 2: things like deeper enumeration, trying to find lists of directories, files,
Speaker 2: even usernames, and analyzing.
Speaker 1: Jobascript file that was a script. Why is that important?
Speaker 2: Because they often get overlooked, but they can contain hints
Speaker 2: about atis, internal URLs, other interesting bits of information. Sometimes
Speaker 2: the code is obfuscated made hard to read, but tools
Speaker 2: like beautifier or defogs can help decode it.
Speaker 1: Ah, so hidden clues within the script itself interesting.
Speaker 2: Definitely worth digging into and Finally, file upload vulnerabilities. Can
Speaker 2: someone upload malicious file like a webshow or maybe just
Speaker 2: a huge file to crash the server? That's another area
Speaker 2: to test. The book even circles back to Google dorking,
Speaker 2: like finding WordPress login pages, which could then be a
Speaker 2: target for trying to guess passwords like brute forcing. Exactly
Speaker 2: that could be the next step.
Speaker 1: Okay, wow, lots of tools, lots of techniques. So let's
Speaker 1: say you use these, you follow the rules, and you
Speaker 1: find something. Okay, real vulnerability. What's next? You can't just
Speaker 1: like post it on Twitter? Right?
Speaker 2: Absolutely not. Responsible disclosure is key. The book really emphasizes
Speaker 2: submitting a high quality report back through the platform.
Speaker 1: What makes a report high quality.
Speaker 2: Clarity is crucial. You need to explain what you found,
Speaker 2: why it's a security risk, the potential impact. You need
Speaker 2: to provide a clear proof of concept or.
Speaker 1: PC like step by step instructions.
Speaker 2: Exactly show them exactly how to reproduce the vulnerability you found,
Speaker 2: and ideally maybe suggest how they could fix it.
Speaker 1: And do this ethically. Right, don't grab more data than
Speaker 1: you need to prove the point.
Speaker 2: Absolutely, stay within the program's rules. Respect privacy, only access
Speaker 2: what's necessary. To demonstrate the flaw.
Speaker 1: And then if all goes well, comes the reward.
Speaker 2: Hopefully, Yes, The rewards vary a lot, Like we said,
Speaker 2: depends on the company, the platform, and especially the severity
Speaker 2: and impact of the bug you found. Critical flaws usually
Speaker 2: pay the most.
Speaker 1: It feels like this whole area must be changing constantly,
Speaker 1: new bugs found, new defenses built, new attack techniques. How
Speaker 1: do people keep up?
Speaker 2: Yeah, continuous learning is just essential. You can't learn this
Speaker 2: once and be done. The booklists a bunch of resources
Speaker 2: like what Well. Getting securities certifications can help structure your learning.
Speaker 2: Improve skills. Things like cech oscp gpamos do are mentioned.
Speaker 2: Keeping an eye on exploit databases like exploitdb tells you
Speaker 2: about the latest discovered vulnerabilities.
Speaker 1: So staying current on threats right.
Speaker 2: And actively using the tools we talked about experimenting Using
Speaker 2: security focused operating systems like Collie Linux or Parrot Security
Speaker 2: OS helps with that they come pre loaded with lots
Speaker 2: of tools.
Speaker 1: Sands on practice definitely.
Speaker 2: The book also suggests following good security blogs. Sam Curry's
Speaker 2: blog gets a mention. Using online training platforms is huge too.
Speaker 2: Hack the box, try hack me, Portswigger's web security Academy.
Speaker 2: They offer challenges and labs learning by doing exactly, and
Speaker 2: even YouTube channels hacker on TV, Live Overflow Ports, Swigger's channel.
Speaker 2: They often have great practical content.
Speaker 1: So it really is a commitment to ongoing learning. It's
Speaker 1: not static, not at all.
Speaker 2: The landscape shifts constantly.
Speaker 1: Okay, let's try and wrap this up then, Based on
Speaker 1: our deep dive into bug bound from scratch, what are
Speaker 1: the main takeaways for someone listening?
Speaker 2: Well? I think first, bug bounties are a really dynamic
Speaker 2: way to learn cybersecurity hands on. You test real systems, sharpen.
Speaker 1: Skills, you potentially get paid for it right.
Speaker 2: Second, ethics are paramount. It's ethical hacking, follow the rules,
Speaker 2: report responsibly. Third, preparation is key. Understand your skills, understand
Speaker 2: the program, scope, identify critical systems, don't just.
Speaker 1: Jump in blindly.
Speaker 2: Yeah. Fourth, you need the right tools and techniques reconnaissance,
Speaker 2: web testing, network scanning, knowing where to look for common flaws.
Speaker 2: And finally, communication matters, write clear, detailed reports.
Speaker 1: It definitely sounds challenging, but also yeah, potentially very rewarding.
Speaker 1: You're helping make things more secure exactly.
Speaker 2: It's a way to contribute positively while building your own expertise.
Speaker 2: Hopefully this chat gave you the listener a good overview
Speaker 2: without being too overwhelming. Maybe sparks some ideas.
Speaker 1: Yeah, absolutely so. If this did peak your interest, maybe
Speaker 1: how's the time to explore further, check out one of
Speaker 1: those platforms, Perhaps try a tool like endmap or burp
Speaker 1: suite on a test system, or read up on a
Speaker 1: technique like LFI.
Speaker 2: And maybe a final thought to leave you with. In
Speaker 2: a world that's so reliant on digital systems and where
Speaker 2: threats are everywhere, is this kind of ethical hacking, this
Speaker 2: bug bounty approach actually becoming one of the most crucial
Speaker 2: ways we defend ourselves collectively.
Speaker 1: That a really interesting question to ponder. Is it becoming
Speaker 1: essential food for thought? Okay, thanks for joining us on
Speaker 1: this deep dive. We'll catch you on the next one.