The poor man’s bug bounty monitoring setup
Published: 2018-07-30 10:48:44

---
title: The poor man’s bug bounty monitoring setup
published: true
tags: 
canonical_url: 
---

![](https://www.oldbookillustrations.com/wp-content/uploads/2017/07/fishing-station.png)

_Fishing station on the shores of the Black Sea_ by Jules Laurens

I must confess, I have been holding on to a small trick that could allow anybody — even those of you that are not into developing and maintaining software — to set up a monitoring system in mere minutes. The reason why I call it the poor man’s monitoring setup is simply to indicate that this setup is not extremely sophisticated, but it does its job beautifully.

When bug bounty hunters monitor targets, they want to receive indications that something new has appeared or that there is a new instance. This is done so that one can immediately jump onto interesting targets and components, which is particularly useful on competitive bug bounty programmes.

The main part of this setup relies on [Git](https://git-scm.com/). We want to be able to store results from our reconnaissance tools — such as subdomain-bruteforcing scripts — and be able to quickly see changes. We also need a place to store the output remotely. For this particular example, I will be using private GitHub repositories. Students can get free private repositories on GitHub if you apply here: https://education.github.com/pack. Please keep in mind, that there are plenty of alternatives out there, I am just sticking to GitHub for this write-up.

Once you have your private repository set up, make sure to store all output from your tools that you want to monitor inside of the local Git folder. When done running your tools, your monitoring script should attempt to `git commit` the output. The clever thing here is that Git will not commit unmodified files, meaning you will only be able to `git commit` files that include newly discovered endpoints. `git push` your files to the private GitHub and include a nice commit message, because this will become useful later.

![](https://user-images.githubusercontent.com/18099289/42733457-f67a872c-8831-11e8-9dce-fd3f1295f324.png)

Now that everything is being pushed to GitHub, we want to have a way to be notified about new commits. It turns out, GitHub has a nifty little feature which allows you to send emails to an address whenever there is a new commit on the master branch.

1) Navigate to https://github.com/YOUR\_USERNAME/REPO/settings/installations;

2) Under the “Add service” dropdown, look for “email”;

![](https://user-images.githubusercontent.com/18099289/42733459-f6af8daa-8831-11e8-9462-846496e0f804.png)

3) Add your email address in the “Address” field.

![](https://user-images.githubusercontent.com/18099289/42733471-1daf4896-8832-11e8-9aa0-173bb798012a.png)

Finally, run the your tools with the Git commit process as a cron job. I wrote the whole thing in a few lines of Bash.

```
$ crontab -l
# Edit this file to introduce tasks to be run by cron.
...

0 * * * * /usr/local/bin/scan example.com

```

You are now ready to go. Sit back and relax. GitHub will now notify you whenever any changes were made via email with a nice diff of the files. So you can be sat in a Caffè somewhere and know straight away when a new endpoint was discovered on your favourite bug bounty target.

On a side note, I just want to add, please do not perform over-the-top type of scanning when monitoring. Keep things light-weight and prioritise targets.