Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
87 changes: 86 additions & 1 deletion src/AI/Web-Black-Box-AI-Pentester-Bots.md
Original file line number Diff line number Diff line change
Expand Up @@ -81,7 +81,91 @@ When you turn the workflow into reusable skills/prompts, explicitly bias the age
- **Source-map mining**: grep `sourcesContent` for mock paths, hidden assets, API route names, service filenames, feature flags, and committed tokens; use the findings to drive the next fuzzing/validation loop.
- **dApp signing hooks**: if XSS lands on a wallet-connected origin, immediately inspect whether the page can tamper with `signTransaction`, `signAndSendTransaction`, or similar signing methods to change the transaction after the UI intent is established.

## 8. Good agent outputs
## 8. Exploitability-first target pruning

A good autonomous agent should rank **exploitable population**, not just **vulnerable versions**. For internet-wide hunting, first compare:

- deployment count / reachable population
- public PoC maturity
- affected-version overlap when chaining multiple bugs
- **target-side prerequisites** such as public endpoints, auth state, upload fields, feature flags, or insecure defaults

Practical workflow:

1. enumerate a large candidate set from FOFA/Shodan/Censys/MCP-backed search
2. fingerprint versions with **lightweight** requests first (`curl`, headers, HTML titles, exposed metadata)
3. read the PoC and extract the **real preconditions**
4. discard hosts that only match the version but not the configuration
5. only then spend tokens/time on exploitation

This matters for chained exploits:

- **Langflow-style cases**: a vulnerable version may still need `auto_login` or a public flow/workflow identifier before the exploit reaches code execution.
- **n8n-style cases**: if the chain needs both an arbitrary file read and a sandbox bypass, compare both patch boundaries and then confirm the required **unauthenticated file-upload form** exists. If the form requires auth, the unauthenticated chain is dead even when the version is old enough.

A useful pattern is to persist a `prerequisites` object per target, for example:

```json
{
"product": "n8n",
"version": "1.117.3",
"vuln_chain": ["file-read", "sandbox-bypass"],
"public_form": true,
"file_upload": true,
"auth_required": false,
"exploitable": true
}
```

## 9. Autonomous recon-to-exploitation loops

A practical offensive loop is:

1. receive a goal
2. translate it into asset-search queries
3. fingerprint products/versions
4. search public PoCs / advisories
5. download or generate scanners
6. validate exploit prerequisites
7. attempt exploitation
8. classify failure and **pivot automatically**

MCP-connected tooling makes this cheaper because the agent can call internet-search backends, scanner generators, and custom scripts in one loop. The important engineering detail is not the LLM alone, but the **closed loop** between search, versioning, exploit acquisition, validation, and retargeting.

For thin targets, sample aggressively before full scanning. If a search engine returns tens of thousands of candidates, probe a small subset, measure reachable/vulnerable/prereq-satisfied ratios, and expand only when the hit rate stays high.

## 10. Permission profiles are part of the exploit chain

Autonomy depends heavily on the client-side execution policy. Settings such as `dangerously-skip-permissions: true`, `approvalMode: "yolo"`, `network_access = "enabled"`, or trusted writable workspaces remove the human from the loop and let the agent:

- run shell commands
- modify PoCs and scanners
- fetch exploits and advisories
- spawn subagents
- exfiltrate collected data

From an offensive perspective this enables fast iteration. From a defensive perspective these settings are part of the **attack surface**: prompt injection, repo-local config poisoning, or malicious MCP metadata become much more dangerous when the client no longer asks for approval before file, shell, or network actions.

## 11. Agent opsec failures leak the whole workspace

Do not forget that autonomous tooling also makes attacker mistakes cheaper. A classic example is:

```bash
cd /home/worker
python3 -m http.server 8888
```

`python3 -m http.server` serves the **current directory and descendants**. If the agent starts it from a home directory, repository root, or shared workspace, it can publish:

- API keys and config files
- shell history
- target lists
- downloaded PoCs
- agent logs and transcripts

For operators, use an empty staging directory and low-privilege account before exposing any file server. For defenders, hunt for unexpected `python3 -m http.server` processes, port `8888` listeners, and public directory indexes exposing dotfiles or agent artifacts.

## 12. Good agent outputs

The best output of an autonomous hacking agent is usually **not** a polished report. It is a queue of:

Expand All @@ -93,5 +177,6 @@ The best output of an autonomous hacking agent is usually **not** a polished rep
## References

- [Joseph Thacker & xssdoctor - The Bug Bounty Singularity: Our Hackbot](https://josephthacker.com/hacking/2026/07/01/we-built-a-hackbot.html)
- [Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks](https://unit42.paloaltonetworks.com/autonomous-ai-cyber-attack-campaign/)

{{#include ../banners/hacktricks-training.md}}