Bug bounty programs are a hot topic these days. More and more companies are realizing the benefits of running a program, and researchers are jumping at the opportunity to grab some swag and make some extra cash from the bugs they find. Reporting security issues has never been as easy, open, and risk-free as it is right now. Everybody wins!

Though that doesn't mean we should stop there. As researchers, we spend a lot of time doing the same menial tasks for each program: monitoring for new targets, checking for common issues, remembering just which flags you needed to pass to that tool (or even which tool is best for that job). We build new tools, hack together shell scripts, and generally make small incremental changes to our process. But surely there's a better approach?

Are you sick of repeating the same tedious tasks over and over? Wouldn't it be nice to have your own bug hunting machine? One that -

Is always watching
Reacts as soon as a new target becomes available
Takes care of those tedious repetitive steps for you
Makes life easy when you want to integrate a new tool/workflow
Doesn't cost the world to run, and trivially scales
Leverages lessons and technologies battle tested in the dev world to improve your offensive capacity, capability and productivity
Monitors your own infrastructure and reacts before hackers can (while saving you the cost of those Bug Bounty payouts in the meantime)
We call this approach Bug Bounty Hunting on Steroids. We will discuss our research and approach to building such a machine, sharing some of the lessons we learned along the way. x