How I Built Recon to Scale with Serverless Architecture

In the current cybersecurity scene, there is many different ways to perform recon. You can log into your server and run commands or write scripts until the sun goes down. Or you could use one of the existing recon frameworks either locally or on your server of choice. But at some point whether you are an industry professional, independent researcher/consultant, or a bug bounty hunter performing reconnaissance, you will need to manage infrastructure to scale. Currently, this normally means managing handfuls of tools and servers spread out across the internet. Scaling this kind of infrastructure can be confusing, costly, and more importantly TIME CONSUMING. But this can all end now. Using a group of AWS serverless options, we can create a recon framework that brings a heap of benefits. This recon framework can up split up into microservices, making updates and changes a breeze. It can also be scaled up and down at will. Since your resources will scale with your workload, this also will reduce the cost of running recon, so that you only have to pay for the resources you are actually using.

In my talk, I will go over my architecture for the framework that I have built thus far. To begin, I will go over AWS step functions, and how I used them to easily set up exactly the workflow that I wanted. I will go over how to set them up, how to embed step functions inside step functions, as well as how I automatically fire off my workflows using an AWS EventBridge rule that triggers every time a new “job” is put in an AWS SQS queue! Inside the step functions I have a variety of AWS tools I use to actually make the workflows. I use AWS lambda functions in parallel to handle computational workloads, DynamoDB to store and handle data, S3 to handle program onboarding and upkeep, and other services as well.

My framework that I present is used for recon from a bug bounty perspective, but can really be applied to any aspect of offensive security. The framework will passively and actively collect subdomains of a root domain, clean the domains to only those that resolve AND are not wildcard domains, use the existing domains to discover outliers and permutations that resolve to even more domains, port scan the domains for interesting ports, and perform fingerprinting as well as content discovery on the domains found to host web servers.

As time goes on, thorough recon is becoming more and more important. And especially against larger targets, having automation in place to gather as much information as possible in real time gives hackers a leg up! I currently don’t use this framework for actual exploitation, but I will touch on how easy it would be to expand something like this into the actual exploitation phase.

I think the serverless and cloud-managed route is the future of automation for offensive security experts everywhere. At the end of the day, the most ideal solution is something that both works extremely well, and can be spun up or changed easily/quickly. And that is exactly what this type of setup provides.

I am SO excited about all the work I have done to make this a working reality, and I really hope that you will let me share it with the amazing recon village community at DEFCON! If you have any further questions please feel free to reach out!