Hi everyone in the HackingBlogs community! Welcome to the 10-Day Bug Bounty Bootcamp’s fourth day! As your guide, I am Dipanshu Kumar, and I am excited for our journey together deeper.
We will continue where we left off yesterday, diving further into Workflows, which are a crucial component of bug bounty searching. I do not plan on rushing through it because it is a wide topic. We will discuss cloud workflows, GitHub workflows, Google Dorking, leaked credentials, brute force methods.
Hackers, let us get started! Make sure you are putting all I say into practice, and never forget to go deeper. That is what sets a real hacker apart from the others.
“You must learn to walk before you start running“
Github Workflows : Starting Bug Bounty Day-4
I am really happy that you were interested in reading this post. Let us now discuss GitHub workflows, which essentially deal with locating sensitive information on GitHub. It is really simple to carry out, and if done correctly, it may produce some very important results. Since almost all developers keep their code on GitHub, there is a wealth of useful content to search through.
Because developers frequently mistakenly upload configuration files containing sensitive information and hard-coded credentials for public viewing, the chance of discovering important data is quite high.
Although this is in the recon phase, some would argue that it should be in the exploit phase since it becomes a vulnerability as soon as working credentials are discovered.
Phase Of Searching
My first step in researching a target is usually to search for their GitHub organisation. If Google does not state that it is open source, for instance, a fast search for “goggle” will direct me to their GitHub org page.
I look over the repos when I get there. I search for ones that are original (not forks) by either adding &type=source to the URL or selecting “Sources” from the “Type” selection.
Take note of the programming languages used in their projects
Look for specific vulnerability-related keywords, such as “hmac,” in the organization’s repositories by using the search field. This will assist you in identifying possible security vulnerabilities.
An open-source security program called Trufflehog was created to look for possible security threats in code repositories like GitHub. It analyses high-entropy strings in a Git repository’s version history to find sensitive data, such as API keys and passwords. This program offers a simple yet efficient method for improving codebase security.
Cloud Workflow
A penetration testing technique called Cloud Recon enables you to examine a target using a single interface across several cloud platforms.VPS, database, storage, and everything else can be hosted in the cloud. Penetration testers can increase their abilities and testing methods by becoming proficient in Cloud Recon. Among the most popular cloud platforms are:
- Web Services by Amazon (AWS)
- Ocean Digital
- Cloud by Google
- Azure by Microsoft
- Cloud by Oracle
People have been gaining unauthorised access to AWS S3 buckets for some time now. In basic terms, an S3 bucket is a cloud place of storage for files. Occasionally, businesses mistakenly allow anyone to access these buckets, allowing sensitive data to be downloaded. This problem is not exclusive to AWS; it affects the majority of cloud providers.
Finding S3 Buckets
Our process will be to search cloud storage for sensitive data. In simple terms, we will target sites that use cloud storage, and then use Google Dorking or brute force the buckets to locate them.
Google Dorking To Find Buckets
By looking for particular terms or patterns associated with S3 URLs, Google Dorking can be used to locate accessible S3 buckets. This method assists in identifying buckets that are open to the public and may hold sensitive information.
site:.s3.amazonaws.com "company"
Brute Forcing : Tools (Cloud_enum.py)
Common keywords that your target might use as a bucket name can also be bruteforced. You can enumerate AWS S3 buckets with the aid of automated tools like cloud_enum and S3enum.
Googl Dorking : I Have Nothing To Say
I have already published two excellent pieces on the subject, so I do not have much more to say about it. They are totally free, so I strongly suggest checking them out to learn more! Just Click On The Images To Reach The Articles
Here is a small case study for you to check the real use of Google Dorks and the power they hold.
We went into great detail about Google Dorking, cloud workflows, and recon in today’s session. We will start conducting our own reconnaissance tomorrow, and believe me, it is one of the most exciting and practical aspects of bug bounty hunting! I kindly ask that anyone who wishes to learn but may be restricted share this free information. Also, setup Kali or any Linux computer for the session tomorrow. I will see you all then!
