# CaA: a Burp Suite extension that mines HTTP traffic into fuzzing dictionaries

> CaA is a Burp Suite extension that collects parameters, cookie names, paths and file names from the HTTP traffic you browse, counts how often they appear, and turns that into a practical fuzzing dictionary, and it can also generate request payloads for Intruder. It suits a security tester who wants a wordlist built from the target's own vocabulary rather than a generic one.

**overspace-labs/CaA** — CaA - Collector and Analyzer, Insight into information, exploring with intelligence in a thousand ways. 信息洞察，智探千方！

- Repository: https://github.com/overspace-labs/CaA
- Stars: 1,526 · Forks: 83
- Language: Java
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/overspace-labs-caa

## The dictionary comes from the target, not from a list

CaA stands for Collector and Analyzer, and the description positions it as an auxiliary project in the cybersecurity field, specifically vulnerability research, primarily used for analyzing and dissecting HTTP protocol packets. What it extracts from those packets is the useful part: parameters, paths, files and parameter values, and then it counts their frequency of occurrence. The stated purpose is helping users build practical and operationally valuable fuzzing dictionaries, and the design concept is described as originating in web fuzzing technology, aimed at uncovering hidden vulnerability surfaces through collecting, analysing and organising information, which the project calls data mining.

That framing is the whole appeal and also the main caveat. A generic fuzzing dictionary contains thousands of paths that a particular application probably does not have, and the noise ratio in a large dictionary makes a scan slow and its results hard to read. A dictionary built from the traffic of the target contains the parameter names that target actually uses, the path segments it actually serves, the cookie names it actually sets, and the file names it actually references. That vocabulary is the same vocabulary an attacker would find by reading the application, which is why it is worth mining rather than guessing.

The project is a Java Burp Suite extension, Apache-2.0 licensed, with a Gradle build in the repository root, build.gradle and settings.gradle, and the source under src/. The authors are listed in the readme, with the first author credited as EvilChen and two others from the Mystery Security Team, and the readme is bilingual with English and Simplified Chinese versions. It was selected for the 2024 KCon Arsenal, which is a security conference tool track.

## What gets collected and what gets generated

The readme lists the types of collected information precisely, and the list is what defines the tool's reach. GET and POST normal form parameters and their values. Cookie names and values. POST parameters and their values for the JSON, Multipart and XML body formats. And layered paths, file names and full URLs. So the collector is not limited to query strings, which is the usual limitation of similar tooling, and it treats the three structured body formats separately because a parameter named id in a JSON body and a parameter named id in a form body are different things even when the name matches.

The generated payload list mirrors that coverage. It produces GET requests, POST requests, POST with JSON requests, POST with XML requests, POST with Multipart requests, and requests for layered directory traversal. That last one is the most interesting of the six, because directory traversal payloads only work if the generator knows the path structure of the target, which is precisely what the collection phase learns.

The four interfaces follow the workflow. Databoard is the data collection view, Config handles configuration management, Generator is the payload generation module, and CollectInfo is the data display view where the collected entries are shown. The naming of the first one is a typo carried by the project, and the readme keeps it, which is a small reminder that this is a tool with a personality rather than a corporate product.

## Installing the extension and where it stores its state

Installation follows the standard Burp Suite extension path, through the Extender menu, then Extensions, then Add, then selecting the file and clicking Next. That is a jar file loaded into Burp, not a separate application.

There is a version constraint that matters, and it is stated in the readme notes. Starting with CaA version 1.0, development is done using the Montoya API, and to use the new version of CaA you need to upgrade your Burp Suite to 2023.12.1 or later. The Montoya API is the modern extension interface that replaced the older Burp extension API, and a tool built on it cannot run on an older Burp at all, so this is a hard floor rather than a recommendation.

On first load, CaA automatically creates a configuration file named Config.json and a database file named CaA.db. The location depends on the platform, at ~/.config/CaA/ for Linux and Mac users and %USERPROFILE%/.config/CaA/ for Windows users. There is also an option to place the configuration files in the /.config/CaA/ directory under the same folder as the CaA jar package, which the readme describes as being for easier offline portability. That matters for a security testing setup, where a machine may be isolated and moving the whole tool on a single directory is convenient.

## Feeding the generator into Burp Intruder

The practical tip the readme gives for the Burp workflow is worth following exactly, because the detail about URL encoding is where this usually goes wrong. You generate a payload in the Generator module, then use it in the Intruder module by selecting the Extension-generated option and then CaA Payload Generator, and then you have to disable URL encoding.

The URL encoding point is not a formality. Intruder encodes the payload before it sends the request, which is correct for a payload that is meant to be a literal string, and wrong for a payload that is a whole request or a payload with structure you have already encoded. Leaving encoding on will silently transform what you generated, and the request that reaches the server will not be the one you built.

The other tip is about the CollectInfo panel, where you can right-click on parameter values of RAW, JSON or XML type to copy them, which makes them easy to reuse in request testing. That is a small ergonomic feature with a real effect on throughput. Fuzzing work involves moving a value from a collection view into a request and back again constantly, and a right-click copy for the three body formats removes a step from the loop. The scripts under the hood that make this work are not described in the readme, so the details of the collection heuristics are not documented.

## Where CaA is the wrong tool

Three cases argue against it. The first is a team without Burp Suite. CaA is a Burp extension, so it inherits Burp's licensing and its setup, and it cannot be run against traffic that is not flowing through Burp. A team that captures traffic with a proxy, a browser extension or a headless crawler has no use for it as written, and the collection logic would have to be reimplemented to move the vocabulary building outside Burp. The second is a scan that needs coverage rather than relevance. If you are looking for endpoints that the application has never mentioned, in a section of the site that no user flow touches, then a dictionary mined from observed traffic will not contain them, because those requests were never made. Mining works when the traffic you observed is representative, and it fails silently otherwise, which is the dangerous property of a tool that produces a list that looks like a finished artifact.

The third is a workflow where the collected data must be reviewable and owned. CaA stores its collection in a CaA.db file and presents it in a panel, and the readme documents the copy-out behaviour rather than an export or version control story, so the dictionary is something you build inside the tool and copy out. A team that wants a curated, reviewed, versioned wordlist in a repository has to add that process themselves on top.

On the operational side, the frequency counting is the part that needs judgement. A parameter name that appears in every request is common, and a parameter name that appears once is either a rare feature or a mistake, and the tool counts occurrences without deciding which. The README describes the collection and the generation, and it does not document a scoring or ranking scheme beyond the frequency counts, so the curation step is the user's. The release history shows a steady line of versions, with 3.0 and 3.1 in May 2026 and 2.2 in February 2026, and the last push was on 2026-05-25, so the project is being worked on even though it publishes no GitHub releases in the repository listing.

## Conclusion

CaA suits a security tester who already works in Burp Suite and wants a fuzzing dictionary derived from the application's own vocabulary, or who wants to generate Intruder payloads without writing them by hand. It does not suit someone without Burp Suite, since it is an extension rather than a standalone tool, and it does not suit a team that wants coverage without a manual curation step, because the raw collection is unranked input that still has to be judged. Before you deploy it, confirm your Burp Suite is 2023.12.1 or newer, since CaA 1.0 onward is built on the Montoya API, and note that the last push was on 2026-05-25 with the newest release at 3.1 from 2026-05-22.

## FAQ

### How do I install CaA in Burp Suite?

Load the jar through Extender, then Extensions, then Add, then select the file and click Next. You need Burp Suite 2023.12.1 or later, because CaA from version 1.0 onward is developed with the Montoya API.

### What information does CaA collect from HTTP traffic?

GET and POST normal form parameters and their values, cookie names and values, POST parameters and values in JSON, Multipart and XML formats, and layered paths, file names and full URLs. It also counts how often each appears.

### How do I use CaA payloads with Burp Intruder?

Generate a payload in the Generator module, select Extension-generated and then CaA Payload Generator in the Intruder module, and disable URL encoding, which the readme calls out as a step not to forget.

### Where does CaA store its configuration and data?

On first load it creates Config.json and CaA.db in ~/.config/CaA/ on Linux and Mac, and in %USERPROFILE%/.config/CaA/ on Windows. You can also place the files in a .config/CaA/ directory next to the CaA jar for offline portability.

## Sources

- [Issues](https://github.com/overspace-labs/CaA/issues)
- [License: Apache-2.0](https://github.com/overspace-labs/CaA/blob/main/LICENSE)
- [overspace-labs/CaA on GitHub](https://github.com/overspace-labs/CaA)
- [README](https://github.com/overspace-labs/CaA/blob/main/README.md)
- [Releases](https://github.com/overspace-labs/CaA/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/overspace-labs-caa