Module Search and Static Inventory

Why this chapter matters

In a rich framework, the first danger is not missing tools. It is the opposite:

• observation modules, low risk;
• validation modules, more precise;
• intrusive modules, reserved for isolated test environment or explicit mandate;
• duplicates, which risk producing noise;
• broken, incomplete, or out-of-context modules.

Mental model: the catalog as a library

Imagine KittySploit as a technical library. sync updates the catalog. search helps you find books by subject. inventory inspects the shelves: overcrowded families, under-covered areas, duplicates, damaged cards. This image avoids a trap: believing search is only a command.

When you search for wordpress, you do not want just a list. You want to answer questions:

• Am I trying to identify WordPress or test a specific plugin?
• Do I have a version, URL, authentication, perimeter?
• Do I want a non-intrusive scanner or stronger validation?
• Do several modules do the same thing?
• What clean proof will I expect at the end?

Indexing: understanding sync

sync
sync now
sync status

sync indexes modules so search does not depend on a slow, fragile filesystem walk. After git pull, marketplace extension install, or local module addition, sync now should become a reflex.

Search by intent

Naive search starts with a word. Professional search starts with an intent. Here are the most common intents:

search wordpress --type scanner --protocol http
search --cve CVE-2026-24849
search --tag authenticated --reliability high
search --platform linux --type exploits
search sql injection --type auxiliary --protocol http

These commands are not recipes. They are questions posed to the catalog. After each output, force yourself to formulate a sentence:

This search tells me that... so my next decision is...

Guided example: preparing a WordPress audit

Step 1: open the topic

search wordpress --type scanner --limit 50

Do not read the output as a shopping list. Mentally classify results:

• WordPress core fingerprint;
• plugin/theme enumeration;
• user detection;
• plugin CVE verification;
• modules that seem too intrusive for this mandate.

Step 2: reduce noise

If fifteen modules mention plugins, you will not run them all. You look for those that maximize signal and minimize risk. A good first pack can contain:

• a general WordPress detector;
• an unauthenticated plugin scanner;
• a header check;
• sensitive file detection;
• a version or exposed readme module, if available.

Step 3: formulate the plan

Before execution, write the plan in plain language:

I will first confirm the target is WordPress, then look for exposed plugins. I will not use authentication or bruteforce modules. I will keep as evidence public paths, exposed versions, and HTTP headers.

This plan matters more than the command: it shows you control the framework.

inventory: view the catalog without executing it

inventory analyzes .py sources without importing or executing them. It is a framework audit tool. It serves pentesters and maintainers alike.

inventory
inventory --only duplicates
inventory --only broken
inventory --only gaps
inventory --type scanner --protocol http --verbose
inventory --export /tmp/kitty_inventory.json

Building a detection pack

A detection_pack is an intentional selection. It must have a theme, a risk level, and execution order logic. For example, a non-intrusive WordPress pack can be organized as follows:

1. confirm the technology;
2. list public indicators;
3. check sensitive files;
4. detect known plugins;
5. produce configuration findings;
6. stop before any authenticated action or brute force.

detection_pack list
detection_pack show <name>

A pack's value does not come from module count. It comes from being readable by a human: why these modules, in this order, for this mandate.

attack catalog: linking technical and tactical

attack catalog
attack catalog --declared-only
attack show scanner/http/security_headers_detect

inventory shows technical coverage. attack catalog helps you link that coverage to a MITRE ATT&CK reading or attack/defense narrative. This cross-check is useful when you must explain a campaign to a non-developer audience.

Workshop: from search to mission plan

Objective: prepare a mini-mission without running an intrusive module.

1. Choose a theme: WordPress, S3, LDAP, Next.js, or FTP.
2. Run a broad search with search.
3. Classify results in three columns: observe, validate, intrusive.
4. Run inventory with relevant filters.
5. Note duplicates and coverage gaps.
6. Select at most five modules for a first pack.
7. Write the plan in plain language before any execution.