Automation and Pentesting: Use AI and Open-Source Tools

This article aims to combine automation and pentesting methodologies in a practical way, using artificial intelligence and multiple open-source tools. More than just a list of commands, it’s about sharing a replicable, flexible, and accessible methodology.

The approach we want to showcase is how, with the publicly available tools today and the help of AI models, it’s possible to improve automated processes—reducing the need for manual effort and allowing more time to focus on exploitation and, why not, the more fun parts.

Ideally, in this first phase, you should think like an attacker. Let’s start from a typical scenario: we have a company domain, for example evilcorp.com, and from there, we begin to expand our attack surface:

• Subdomain reconnaissance
  
• Port scanning
  
• Service analysis
  
• Vulnerability discovery
  
• Reporting of findings
  

The order is not random. First, the attack surface is expanded, then more active techniques are introduced, and finally, specific vulnerabilities that can be exploited are identified.

Let’s continue with the previous example (using our fictional company, evilcorp), and understand that we shouldn’t limit ourselves to just evilcorp.com. We need to consider the entire attack surface—subdomains, services, IP addresses, and DNS records. The goal is to expand the attack surface as much as possible before moving on to more active phases.

There are countless tools we can use, such as bbot, subfinder, and sublist3r, which are ideal for blackbox projects (where we have limited knowledge of the target). For instance, bbot has the unique feature of being self-reinforcing: it finds subdomains, then IPs, and continues expanding the available information automatically.

In this demo, we’ll focus on assetfinder and use the e --subs-only parameter, which quickly yields a long list of subdomains. Here’s where we can make our first key observation:

While we do find new subdomains, we notice that there are several duplicates or records that don’t resolve correctly. That’s why it’s crucial to filter and keep only the entries that are truly useful.

Once the subdomains have been identified, the next step is to analyze which services are exposed through them. As we saw earlier, there are several tools we can use:

• masscan
• naabu
• nmap

In our case, we’ll use Nmap with the following parameters:

• --top-ports 100 (only the 100 most common ports)
• -Pn ((to skip ICMP/ping checks)
• -iL [hosts.txt] ((where we pass a list of hosts separated by line breaks)
• open ( (to see only results with open ports)

Again, as we see in the video, there are some errors that highlight areas for improvement:

• Several domains did not resolve.
• It might be better to use IPs instead of subdomains.

A useful step, at least at this stage, is to limit the number of false positives when trying to analyze a web application, where we can use, for example, httpx to validate if the URL we have responds on a web port (80/443). This will verify that the applications are real, and if we want to analyze them, we will know in advance that the service is running without issues.

We could also consider a scenario where our port scanner receives input of IP addresses directly, since in some cases it fails to resolve or analyze the associated domains. For that, we can use a one-liner like the one shown below, where from a txt file of subdomains, we can resolve the IP addresses they resolve to (to later be passed, for example, to nmap).

Having a refined list of IPs, validated and confirmed domains and subdomains, we can move on to the vulnerability analysis stage, where again, many open-source tools can help us:

• OpenVAS (more focused on infrastructure)
• nuclei
• nikto (more focused on web)

In our case, we will focus on nuclei due to its versatility, as it allows running many (and varied) tests in a short time, using templates that detect everything from incorrect security configurations to specific vulnerabilities such as exposed panels, outdated software versions, or endpoints with interesting responses (for example, exposed backups).

Now, the problem arises when the scan generates hundreds of findings. How do we prioritize? How do we turn that into something useful for the security team or management? This is where artificial intelligence starts to play a key role. Using models like GPT – either through services like OpenAI or running local models such as those offered by Ollama – we can analyze those results, group them by severity, generate readable explanations for non-technical people, and even propose possible solutions.

This is not theory: today automatic reports are already being generated that convert 200 technical findings into a two-page summary, with prioritized risks, estimated impact, and language understandable for business areas. It’s even possible to produce two versions of the same report: a technical one for the infrastructure team, and an executive one for the CISO or the board.

The real power lies in automating the entire workflow: from the input with a list of domains, through IP resolution, scanning with Nuclei, AI analysis of results, to the automatic generation of the final report. All of this can be integrated with Bash or Python scripts, scheduled tasks with cron, pipelines that run when a new target list is received or after an alert in the SIEM. What matters is not only that it’s automatic, but that it’s designed to scale without losing context.

And like any good automation, there’s always room for manual review. Because AI can suggest, but the analyst decides. The valuable part is not just the code or tools, but how we design the flow, how we choose what to automate, and where we keep applying human judgment.

Automating is not about replacing the analyst, it’s about enabling them to focus on what really matters. What part of your workflow could you automate tomorrow?

Watch the full talk here

Gabriel Franco, is the person who leads the security services area at Faraday explains that their background comes from the technical world, specifically from development. Their first approach to pentesting was precisely from that angle: creating scripts and automations to run analysis tools and save time, with a focus on obtaining results faster and more effectively.

Over time, they took on more management roles but remain involved in technical tasks, especially when they find something that can be improved or automated. They explain that within the team, they are always attentive to patterns that repeat across different projects. When they detect recurring tasks, they seek to automate them in order to focus on what truly adds value.

Trainings, red teaming services, or continuous scanning? We’ve got you covered. 🚀⚡ 

Reach out for more information.