Part 3: Dorking using automated tool 

Dorking with automated tool graphic

Part 3: Dorking using automated tool 

In the previous post, we discussed how any information that is committed to a version control platform can be searched through to find information. The process was performed manually by using the platforms search function; however, in this final post, we will be using a tool to discover the same information.  

First, we need to create the repository (see previous dorking post on how to do this). I have created the same repository; however, I have made a few commits which are just modifying the username and password for this example. 

This screenshot shows the initial commit adding the username and password into the file:

Dorking initial commit


Now, we’ll be using a tool to search through this repository. The tool chosen is TruffleHog. So, what is TruffleHog?

The following definition is taken from its GitHub page: 

“Searches through git repositories for secrets, digging deep into commit history and branches. This is effective at finding secrets accidentally committed.” 

Following the installation by cloning the repository and using the requirements file to install the prerequisites, we’ll run TruffleHog with command stated on its Github page. This is as follows “python3 –regex –entropy=False repo”. However, before running the tool, we need to use a rules file. The default rules file contains an entry to search for any RSA private keys; however, for us, this will not work. 

We’ll need to create another JSON file which contains what we want to search. Here is the JSON file that we’ll be using:

Dorking - JSON file


Now we have the rules file, we can now run the tool using the –rules flag to use the custom rules file:

Dorking - Rules file


As you can see, the tool has found commits based on the regex that was used and has showed the results to us. From here, we have enough information to look at this commits manually and verify the information is correct. 

 So, what is the risk of this happening now and even the future? Well, only recently (last month) a researcher was able to find a configuration file containing credentials as well as other information for a well-known organisation:

Dorking -


So, you could say the risk is quite high as it’s still being discovered in 2020 and it will be most likely in the future. It only takes for one developer to accidentally commit their credentials or some other credentials that they use, for the same to occur. 

There are a few ways in which this could be remediated – making sure that everything that gets committed doesn’t contain any information of value. One way of doing this and safeguarding credentials, for example, is the use of environment variables within the system. These environment variables can be referenced inside the code. If this code was then committed to a public repository, the credentials wouldn’t be sent along with it, only the referenced variables names.

Another would be to encrypt the credentials with a key. This key needs to be stored separately and not included in the commit.