Bug Bounties

Using Automated Scanning in Bug Bounties Without Getting Banned

Every serious bounty hunter uses automation. Most will not admit how much. There is an unspoken tension in the community: platforms say they value manual testing, programs say they want quality over quantity, but the hunters pulling consistent payouts are the ones who built pipelines that do the boring work for them so they can focus on the interesting parts.

I am not going to pretend automation is optional. It is not. But using it poorly will get you banned, blacklisted, or both. I have watched hunters get kicked from programs for hammering staging servers with Burp Scanner on full throttle at 2 AM. I have also watched hunters find $10,000 bugs because a custom Nuclei template flagged a misconfiguration that manual testing would have missed entirely.

The difference is not whether you automate. It is how.

What program policies actually say

Read the policy. I mean actually read it, not skim it. Most bounty program policies on HackerOne, Bugcrowd, and Intigriti include a section about automated testing. The language varies, but the common patterns are:

Some programs explicitly ban all automated scanning. Respect that. Others are more nuanced. Shopify, for example, allows automated testing but asks hunters to keep request rates reasonable. Google’s VRP permits automated tools but will suspend your account if you degrade service availability.

The key phrase to look for is “safe harbor.” Programs with safe harbor language protect you legally as long as you follow their rules. If the rules say no scanners, that protection evaporates the moment you fire up Nuclei.

If you are still picking a program to target, choosing your first bug bounty program covers how to evaluate policies and scope before committing time.

Configuring scanners to not get you banned

The default configuration of every scanner is wrong for bounty hunting. Defaults assume you own the target or have explicit permission to test at full speed. In a bounty context, you need to throttle everything.

Rate limiting

This is the single most important setting. A good baseline:

In Nuclei, rate limiting looks like this:

nuclei -u https://target.example.com -rate-limit 5 -bulk-size 1 -concurrency 1

The -rate-limit flag caps requests per second. But -bulk-size and -concurrency matter too. A rate limit of 5 with a concurrency of 25 means 25 templates running simultaneously, each at 5 requests per second. That is 125 requests per second. Not what you want.

For Burp Scanner, go to Project options > Connections and set:

Scope enforcement

Your scanner must know the boundaries. In Nuclei, define scope with an explicit target list:

# Only scan these specific URLs
nuclei -l in-scope-urls.txt -rate-limit 3

Never pass a root domain and let the scanner crawl. That is how you end up scanning customer subdomains, third-party services, or assets belonging to a completely different organization that shares the CDN.

In Burp, use the Target Scope tab. Add the in-scope domains and enable “Use advanced scope control.” Then in the scanner settings, select “Scan only in-scope items.” Verify this is working before you walk away. I have seen Burp follow OAuth redirects to Google, GitHub, and dozens of other third-party domains because the redirect chain started in scope.

Time of day

Scan during business hours in the target’s timezone. If something breaks, their on-call team is awake and at a desk, not getting paged at 3 AM. This sounds like a small thing. It is not. The fastest way to get banned is to cause an incident that wakes up a VP of Engineering.

Nuclei templates: community and custom

Nuclei’s power comes from its templates. The community template repository has over 9,000 templates covering CVEs, misconfigurations, exposures, and default credentials. But running all of them against a target is wasteful and loud.

Selecting the right templates

Be selective. If you have done proper recon and fingerprinted the target’s technology stack, you know what to look for.

# Target runs WordPress - only run WordPress templates
nuclei -u https://target.example.com -tags wordpress -rate-limit 3

# Check for exposed sensitive files and misconfigurations
nuclei -u https://target.example.com -tags exposure,misconfig -rate-limit 3

# Run only critical and high severity templates
nuclei -u https://target.example.com -severity critical,high -rate-limit 3

I typically start with exposure and misconfig tags. These are low-noise checks for things like exposed .git directories, debug endpoints, backup files, and default credentials. They send few requests and often find things other hunters skipped.

Writing custom templates

This is where the real value is. Community templates catch known issues. Custom templates catch the things you notice during manual testing and want to check at scale across many targets.

Here is a real-world example. I noticed that a particular SaaS platform leaked internal API keys through a predictable endpoint pattern. I wrote a template to check for it:

id: custom-api-key-exposure

info:
  name: Internal API key exposure via debug endpoint
  author: your-handle
  severity: high
  description: Checks for exposed API keys on common debug paths

http:
  - method: GET
    path:
      - "{{BaseURL}}/debug/config"
      - "{{BaseURL}}/_internal/settings"
      - "{{BaseURL}}/api/debug/keys"

    matchers-condition: and
    matchers:
      - type: word
        words:
          - "api_key"
          - "secret_key"
          - "access_token"
        condition: or

      - type: status
        status:
          - 200

    extractors:
      - type: regex
        regex:
          - '"api_key"\s*:\s*"([^"]+)"'
          - '"secret_key"\s*:\s*"([^"]+)"'

Another common pattern: checking for CORS misconfigurations across many subdomains.

id: custom-cors-wildcard-check

info:
  name: Permissive CORS with credentials
  author: your-handle
  severity: medium

http:
  - method: GET
    path:
      - "{{BaseURL}}"
    headers:
      Origin: "https://evil.example.com"

    matchers-condition: and
    matchers:
      - type: word
        part: header
        words:
          - "evil.example.com"

      - type: word
        part: header
        words:
          - "Access-Control-Allow-Credentials: true"

The template checks whether the server reflects an arbitrary origin in the Access-Control-Allow-Origin header while also allowing credentials. If both match, you have a reportable CORS misconfiguration.

Store your custom templates in a separate directory and version control them. They compound over time. After a year of bounty hunting, your private template collection becomes one of your biggest competitive advantages.

nuclei -u https://target.example.com -t ~/custom-nuclei-templates/ -rate-limit 3

AI-assisted hunting: where it stands now

Automation in bug bounties is not just scanners anymore. AI is changing the field in ways that are hard to ignore.

At DEF CON 33, DARPA’s AIxCC put autonomous systems against real software, competing to find and patch vulnerabilities without human intervention. The systems found real bugs in real code. This was not a theoretical exercise.

On the platform side, HackerOne has disclosed that over 560 valid vulnerability reports were submitted with the assistance of AI agents in a single year. That number is growing fast. Some of those are trivial findings that AI stumbled onto. Others are legitimate, complex vulnerabilities that AI-assisted workflows surfaced faster than a human could have alone.

What AI tools can actually do today

LLMs are surprisingly good at a few specific bounty tasks:

Code review. Give an LLM a JavaScript file and ask it to identify injection points, authentication bypasses, or insecure deserialization. It will not catch everything, but it catches things fast. I use this when reviewing open-source dependencies of a target or analyzing client-side JavaScript for hardcoded secrets and API endpoints.

Fuzzing payload generation. Instead of pulling from a static wordlist, you can ask an LLM to generate context-aware payloads. “Generate 50 XSS payloads that would bypass a WAF that strips <script> tags and onerror attributes” gives you better results than a generic payload list.

Report writing. This is the least controversial use. Drafting clear, well-structured reports from your notes saves time without any ethical concerns.

Recon analysis. Feed an LLM the output of your recon tools, a list of subdomains, open ports, technology fingerprints, and ask it to identify the most interesting targets. It can spot patterns across large datasets faster than you can scan a terminal.

What AI cannot do yet

AI is bad at multi-step exploitation chains that require understanding application business logic. It cannot reason about what a specific feature is supposed to do versus what it actually does. It does not understand that the “transfer money” endpoint should not let you send negative amounts, because that is a business logic flaw that requires domain knowledge.

AI also generates false positives constantly. Every AI-generated finding needs manual verification. Submitting unverified AI output to a bounty program is a fast track to losing reputation.

The ethical line

Here is my take. Using AI to assist your workflow is no different from using Burp Suite or Nuclei. You are using a tool to augment your skills. The output still requires human judgment, verification, and context.

What crosses the line: running a fully autonomous agent that sprays AI-generated reports across 50 programs with no human review. This is happening, and platforms are cracking down on it. HackerOne and Bugcrowd have both started flagging reports that appear to be unreviewed AI output. Low-quality submissions hurt your reputation score, and platforms are building detection for mass-submitted AI-generated reports.

The hunters who will benefit most from AI are the ones who already know how to find bugs manually. AI amplifies skill. It does not replace it. If you want to explore AI-specific testing, AI and LLM security testing for bug bounties covers the vulnerability classes you should be looking for.

The line between automation and manual work

Here is how I think about splitting my time.

Automate: subdomain enumeration, port scanning, technology fingerprinting, known CVE checks, misconfiguration checks, screenshot collection, content discovery with wordlists. These are mechanical tasks with deterministic outputs. A human doing them manually is just a slow computer.

Do manually: authentication testing, authorization testing, business logic flaws, payment flow manipulation, multi-step attack chains, anything that requires understanding what the application is supposed to do. These require judgment, creativity, and an attacker mindset that no tool replicates well.

The hybrid zone: Some tasks benefit from automation that surfaces candidates for manual review. CORS checks, SSRF testing via parameter injection, and open redirect detection all work well as semi-automated workflows. The scanner flags potential issues, you verify and exploit them manually.

If you are building your toolkit, start with the automation layer for recon and known-issue checks. Then spend your manual effort on the things scanners cannot see.

A practical workflow

This is roughly how I approach a new target:

  1. Passive recon: subfinder, waybackurls, CT log queries. Fully automated, no interaction with the target.
  2. Active recon: httpx to probe live hosts, naabu for port scanning. Throttled, in-scope only.
  3. Automated scanning: Nuclei with targeted templates based on the tech stack I identified. Rate limited, scoped tightly.
  4. Manual testing: Log into the application. Use it like a real user. Understand the features. Test auth, authz, and business logic by hand.
  5. Targeted automation: Write custom Nuclei templates or Burp extensions for patterns I notice during manual testing, then scale them across the target’s subdomains.

Steps 1-3 take maybe an hour. Step 4 is where I spend 80% of my time. Step 5 is what separates a one-off find from a pipeline that keeps producing results.

Staying on the right side

A few final rules I follow:

Log everything. Keep records of what you scanned, when, at what rate. If a program contacts you about unusual traffic, you want to show exactly what happened.

Start slow, increase gradually. Begin at 1 request per second. If the target handles it fine, increase. If you see 429 (Too Many Requests) or 503 responses, back off immediately.

Never scan shared infrastructure aggressively. If the target uses a shared hosting provider, a CDN, or a cloud WAF, your traffic affects other customers too. This is how automation becomes a denial-of-service issue even when you are not trying.

Read the response headers. Many servers include X-RateLimit-Remaining or similar headers. Respect them. If the server tells you how fast it wants you to go, listen.

Do not automate report submission. I should not have to say this, but: write every report yourself. Verify every finding yourself. Automated report submission is the fastest way to get permanently banned from every platform simultaneously.

Automation is a multiplier. It multiplies skill and it multiplies recklessness in equal measure. Use it to extend your reach, not to replace your thinking.