The data we collect here includes DNS and Web Server data of public bug bounty programs.

Our aim with this project is to:

• Monitor over 800 companies for new assets
• help bug bounty hunters get up and running on new programs as quickly as possible.
• give security teams better visibility into their assets.
• reduce the load and noise that some programs face from automated tools (we run them on schedule, and give the results to everyone)

The setup consists of two workflows

• Inventory 3.0 - Targets
• Inventory 3.0

This workflow streamlines the consolidation of bug bounty program data from various sources, ensuring a comprehensive and organized view. Let's break it down:

1. Data collection: The workflow fetches data from two important sources:

   • Bounty Targets Data: This repository contains a wealth of bug bounty program information.
   • Chaos Public Bug Bounty Programs: It provides additional valuable bug bounty program data.

2. Data transformation: The collected data undergoes transformation using Python scripts. The scripts convert the data into a specific format, ensuring consistency and ease of analysis. You can find the detailed data format in the targets.json file.

3. Program merging: To avoid duplication, the workflow merges programs with the same URL together. This consolidation eliminates redundancies and presents a unified view of bug bounty programs.

4. Community program inclusion: The workflow incorporates an additional set of programs from the community.json file. These programs are merged with the existing dataset, enhancing its coverage and diversity.

5. Final output: The workflow generates a final consolidated JSON file, targets.json, which encompasses all the merged bug bounty program data. This file serves as a valuable resource for bug bounty researchers, providing a centralized and comprehensive view of programs.

Note: The screenshot above provides a visual representation of the workflow.

1. Gathering the tagets: Get the list of domains from targets.json, and extract program names.

2. Making workflow run in parallel: Extracted program names are connected file-splitter node to make the whole workflow distributed per program

3. Passive Enumeration:
   • Use subfinder, vita, findomain to get passive enumeration data.
   • Use mksub to create a custom list of potential subdomains
   • Resolve with puredns and trickest resolvers
   • Generate custom-wordlists from passive results with custom bash script

4. Active Enumeration
   • Use passive enumeration data and create a new bruteforce wordlist
   • Use dsieve to get environments per subdomain level
   • Generate new potential subdomains with mksub and custom wordlist, with additional level2.txt wordlist
   • Resolve again with puredns

5. Permutations
   • Merge active and passive results from previous steps
   • Extract environments per subdomain level again
   • Use alterx to generate permutations and resolve with puredns

6. Collecting previous results
   • Use python script that will get all of the previous hostnames.txt per program
   • Use anew to get the new hostnames found
   • zip active, passive, permutations per program to be pushed to repository

7. Reporting
   • Use dnsx to resolve found hostnames and python script for dns-report.csv; mark newly found domains coming from anew with [x]
   • Use httpx to gather web servers and python script for `server-report.csv
   • Push to the repository

Note: As described, almost everything in this repository is generated automatically. We carefully designed the workflows (and continue to develop them) to ensure the results are as accurate as possible.

All contributions/ideas/suggestions are welcome! If you want to add/edit a target/workflow, feel free to send us a PR with new targets through community.json, tweet at us @trick3st, or join the conversation on Discord.

We believe in the value of tinkering. Sign up for a demo on trickest.com to customize this workflow to your use case, get access to many more workflows, or build your own from scratch!