[rahatichlukumus]

Here you will learn how to improve your level in OSINT, examples and ready search queries will be given.

(You can complement me if I forgot something in the comments).

What is it and what does it serve for?
Github Dorking is an extremely important part of a site scouting or BugBounty program.

If you're familiar with Google Dorking, they are very similar and serve the same purpose - keyword searches on the system.


What can be found using Github Dorking?
1. Sensitive authorization data:

• Access tokens (OAuth, JWT, etc.).
  
• API keys (Google, AWS, Azure, Twitter, Stripe, etc.).
  
• Logins and passwords in code or configuration files.
  
• SSH keys (especially private keys).
  
• .env files containing secrets.
  

2. Confidential Files:

• Application configuration files (config.php, .env, web.config).
  
• Error or deployment logs (error.log, debug.log).
  
• Database files (database.sql, .sqlite).
  

3. server information:

• IP addresses of servers or internal nodes.
  
• Deployment secrets (e.g. Ansible Vault or Kubernetes Secrets).
  
• Logins/passwords for servers or databases.
  

4. Sensitive company data:

• Internal documents or memos.
  
• Names of internal projects.
  
• Internal infrastructure data (e.g., domain names, subdomains).
  

5. Error or vulnerability codes:

• Stationary tokens or test accounts.
  
• Hard-coded encryption keys.
  
• Vulnerable code or outdated libraries.
  

6. Personal information:

• Employee e-mail addresses.
  
• Personal information files (user_data.json, credentials.txt).
  
• Photos or documents (e.g., accidentally uploaded scans).
  

How to use Github Dorking step by step.
1. The first thing to do is to find your “target” in github, for which you can use several approaches:
1.1 by company/site name .
The basic and easiest way is to type in the company or site name and find their repository (target - replace with any site): https://github.com/search?q=target&type=repositories.
The bigger and better known the company is, the more noise there will be in search and similar repositories

Let's take Google as an example:


Looks daunting - 965K repositories, doesn't it?

But look closely at the filters on the left; you'll see that there are fewer users, allowing you to find your main company faster. (Companies often create a separate user (organizational account) on the platform to store their data and development).

1.2 Searching by source code or code from a website
Here it's individual, you need to open your target:target.com and try to find the source code using fuzz and finding directories (example target.com/login/FUZZ Here we try to find the .js file which is responsible for authorization) or unique lines of code/key on the site. After finding them, we type in Code and replace them with the found code/key https://github.com/search?q=Code&type=code.
As for the keys, they will do, as they are most often unique.

2 Searching within a repository/company (Github Dorking)


Open a company organizational account:
https://github.com/google
You can use the github search bar to search the organizational account:



Or use the Google search bar and replace TEST in it with what you are looking for (other examples will be shown in this form) https://github.com/search?q=org%3Agoogle...&type=code.

How to search for hidden data in git? Github Dorking to the rescue!
Start by searching GitHub for the name of your target organization combined with potentially sensitive types of information such as “api key”, “api keys”, “apikey”, “authorization: Bearer”, “access_token”, “secret”, or “token”. (For a more complete list of Github Dorking, see below at the end of the article).

Then explore the various tabs of the GitHub repository to discover API endpoints and potential weaknesses. Analyze the source code on the Code tab, find bugs on the Issues tab, and review proposed changes on the Pull Requests tab.


On the “Code” tab, you can view the code in its current form or use ctrl-F to search for terms of interest (such as API, key, and secret). You can also view historical changes to the code using the “history” button located in the upper right corner in the image above. If you encounter an issue or comment that leads you to believe that vulnerabilities were once associated with the code, you can view historical commits to see if those vulnerabilities are available for review.

When viewing a commit, use the Split button to view a side-by-side comparison of file versions and find the exact location where a change was made to the code.

The “Split” button (top right in the image above) allows you to split the previous code (left) and the updated code (right).

On the “issuse” tab, developers can track bugs, tasks, and feature requests. If an issue is open, there's a good chance that the vulnerability is still present in the code.

The Pull requests tab is a place for developers to collaboratively make changes to the code. If you review the suggested changes, sometimes you may get lucky and find a problem.

Pay attention to the programming languages used, information about API endpoints, and usage documentation, all of which will come in handy in the future.

I thought it would be inconvenient to post a large number of Github Doking examples, so you can use the link to the examples on a separate site: https://book.hacktricks.wiki/en/generic-...king#dorks.
There are automated tools there as well.