Greetings, HackingBlogs community! Greetings from Day 3 of our 10-day Bug Bounty Bootcamp! I am Dipanshu Kumar, your guide, and I am really excited to accompany you on this tour.
On this third day, we are diving deeply into developing and applying several bug bounty searching methods. We will discuss the fundamental GitHub and cloud operations as well as the conventional recon procedures used by bug bounty hunters. We will also explore the capabilities of Google Dorks in our recon process, discover how credentials are leaked, and talk about typical exploits, misconfigurations, CMS, OWASP, and brute force workflows.
Prepare to expand your bug bounty skill set by using these useful and fundamental methods! Come on, let us start!
“Without a plan, you’re just wandering in the dark. A well-structured workflow lights the way and connects the dots of your process.”
The last thing you want to do is randomly perform tasks and make no progress. Instead, you need to create a clear map or workflow for your attack process. This will give you a broader perspective and help you understand how each part of your process interconnects.
Starting With Recon Workflow
Traditional Workflow
For Domain
Basically What is means here is , Select a business that offers a bug bounty programme first. Next, locate every domain associated with that business. After obtaining the root domains, determine each one’s subdomains. Next, obtain the A, NS, MX, and CNAME entries for every target by performing DNS resolution. In the end, include every A record in a list of the company’s intellectual property.
Well, i hope that goes right above the brains for those who are starting it first but do not worry i’ll be explaining each and every element
Breaking Down Element
- Root Domains – The top level of a website’s domain name is called a root domain, and it usually looks like
example.com. The primary domain that contains the website is this one. Numerous subdomains (such as sub.example.com) may exist under the root domain. - Subdomains – The root domain expands via subdomains. Examples of subdomains of example.com are
blog.example.comandshop.example.com. These subdomains frequently stand for various services or website areas. - DNS Resolution – The process of converting a human-readable domain name, such as example.com, into an IP address that computers can use to find and connect to a server is known as DNS resolution. It is a crucial component of the internet’s operation since it enables users to access websites by entering memorable domain names rather than IP addresses.
- A Record (Address Record) – An IP address and a domain are mapped by an A record. This enables users to utilise the domain name to reach the website.
Example Of An A Record:example.com. IN A 192.0.2.1. (This indicates that 192.0.2.1 is the IP address that example.com links to.) - NS Record (Name Server Record) – An NS record identifies the name servers in charge of the domain. The DNS records for the domain are kept on these servers. Example Of NS Record
example.com. IN NS ns1.nameserver.com | example.com. IN NS ns2.nameserver.com(This indicates that ns1.nameserver.com and ns2.nameserver.com are the authoritative name servers for example.com.) - MX Record (Mail Exchange Record) – The mail servers that manage email for the domain are listed in an MX record.
Example :example.com. IN MX 10 mailserver1.example.com|example.com. IN MX 20 mailserver2.example.com.(It means that emails sent to example.com will attempt to reach mailserver1.example.com first, and then mailserver2.example.com if it is not available. Priority is indicated by the numbers 10 and 20, where lower numbers denote more priority.) - CNAME Record (Canonical Name Record): One domain name is mapped to another by a CNAME record. Subdomains that point to the primary domain are frequently utilised in this way. Example:
www.example.com. IN CNAME example.com.(This indicates that both domains point to the same website because www.example.com is an alias for example.com.)
For CIDR and IP
Smaller businesses typically rent servers from outside providers like AWS or Rackspace, therefore they will not have a CIDR range. In contrast, larger businesses frequently have their own CIDR range, which is a block of IP addresses.
CIDR example: 192.168.0.0/24. This is a representation of all 256 IP addresses, ranging from 192.168.0.0 to 192.168.0.255.
The “/24″ indicates that the first 24 bits of the block are fixed, whereas the following bits correspond to various IP addresses.
Once the IP list has been collected, run a port scan on each. To determine which protocols and services are exposed, this is crucial. If you do not properly scan, you can overlook vulnerabilities. Passive scans can be performed with third-party scanners, but occasionally manual scanning is required, particularly for certain ports that third-party programs might not support.
To find out where the IP is situated and whose company owns it, it is also critical to verify the Autonomous System Number (ASN) and geolocation. An example ASN is AS15169, which is Google’s. This indicates that ASN 15169 is used to identify all IP addresses under Google’s control. You can use websites like IPinfo.io or tools like WHOIS to find an IP’s ASN.
Using the list of IP addresses and subdomains hosting a web application, fingerprinting and content detection are the last steps in the recon process. This involves identifying which technologies—such as web servers, CMSs, and programming languages—are being utilised on each endpoint.
Tools to help with this: Identifying Technologies
- WhatWeb: identifies the technologies that a website uses, such as the JavaScript framework, CMS, and web server.
- Wappalyzer: An online tool or browser extension that can identify technologies such as CMS, web frameworks, analytics tools, and more.
- Nikto: A web server scanner that finds common web server vulnerabilities and conducts security checks.
- Nmap: In addition to port scanning, Nmap may be used to identify the technologies and services that are operating on a server.
Applying knowledge is the only way to make it useful. Install these tools now, then follow the steps and begin testing. Do not only read about it; actually do it! To demonstrate your progress, tag me on LinkedIn after you have finished. By putting this knowledge to use, you will improve your abilities and inspire me to continue helping. Recall that knowledge without action is merely data that is just waiting to be put to use.
Tomorrow, we will go into the crucial workflows that we still need to discuss. The power of Google Dorks in our recon process, how passwords are leaked, and common attacks, misconfigurations, CMS, OWASP, and brute force workflows will all be covered tomorrow. Watch this space for some interesting information.
