# gwen001/pentest-tools: one file per check, four languages, one cleanup in 2022

> A flat directory of small security scripts for one-off needs, with no framework and no plugin system, installed by cloning and installing a dozen loosely pinned libraries. The most useful line in its README is the note about the 2022 cleanup that moved ten tools out to their own repositories.

**gwen001/pentest-tools** — A collection of custom security tools for quick needs.

- Repository: https://github.com/gwen001/pentest-tools
- Stars: 3,335 · Forks: 778
- Language: Python
- License: not declared
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/gwen001-pentest-tools

## A flat directory of single purpose scripts

There is no framework here and nothing to install as a library. The repository is a directory of files, each of which does one small job, and you use them by running them.

They are written in four languages. Most are shell scripts, there is a set of Python tools, a group written in PHP, and a couple in JavaScript. That mixture is not a design decision so much as the result of writing a script in whichever language suited the task at the time.

The practical consequence is that there is no shared abstraction. There is no configuration object, no plugin registry and no common argument parser. Two scripts that do the same thing are usually separate implementations, and the README says so explicitly in at least one case, pointing from one file to another as an alternative rather than a wrapper.

So the mental model is a shelf, not a framework. If a script is the wrong shape for your environment you read it, take the idea, and write your own, which is exactly the use its author described in the one-line description.

## The 2022 cleanup is the most important note in the README

Before anything else, the README carries a section headed important note, and it is about the collection's own history.

A large cleanup happened in November 2022. Some scripts described as useless or not working were archived, and some others were moved into their own repositories so they would get more visibility, and ten of them are linked.

The list is more informative than it looks, because it tells you what the author judged worth its own repository. There is an Android package analyser, a tool for finding origin addresses behind a CDN, a content security policy analyser, something that looks up known vulnerabilities, an endpoint extractor, a trick using a site icon hash, a Google search helper, a GraphQL introspection analyser, a known weak key testing script, and a related domain finder.

Two things follow. First, what remains in this repository is the residue that did not justify promotion, which is a useful filter and also a hint about quality. Second, a reader arriving through a search result for endpoint extraction or weak key testing should follow those links rather than search this repository.

## The requirements file is a developer convenience list

The install step is three lines, and the interesting part is what it pulls in.

```
git clone https://github.com/gwen001/pentest-tools
cd pentest-tools
pip3 install -r requirements.txt
```

The requirements file lists twelve libraries, none of them pinned to a version. Among the recognisable ones are an HTTP client, a Shodan client, a library for extracting public suffixes, a whois client and an IP range helper.

Two details deserve a second look. The standard library argument parser is on the list, which is not a dependency and should never be installed over your distribution's copy. And a murmur hash library sits beside a Cloudflare address checker and two Cloudflare address data files, which is exactly the pairing you would expect for a check that looks up an address by hash.

The rest look like one developer's convenience installs over a few years. For a collection of small scripts that may never all run on one machine, that is defensible. It also means installing the file gives you a dozen unpinned packages you may not need.

## Half the collection is names and addresses

The largest group of scripts deals with names, addresses and what is listening, and the repetition is the story.

There are four subdomain brute force scripts that differ by method: one through a wordlist, one through numeric variation, and two reverse lookup variants, one taking a range and one reading a file. There is a zone transfer test and a mass zone transfer test across a list of domains, a script requesting every DNS record type for a name, and a script pulling subdomains from a public certificate transparency search.

Then live host discovery, implemented three times over with three different tools, because shell history suggests each was faster for a different situation. Port scanning with netcat, and a script that checks whether the two remote desktop ports are open on a range.

The rest of that group is address arithmetic: converting a reverse lookup name to a conventional one, converting an address between formats, generating every address in a range with a netmask, resolving a list of hosts to see which are alive, and generating a random private address and port for use in a server side request forgery test.

## One file per web vulnerability class

The web checks are a list of single-class testers, and the naming convention tells you there is no shared engine behind them.

There are separate scripts for cross-origin configuration, header injection, open redirect, remote code execution, local file inclusion, cross-site scripting and request smuggling, each described as testing a given list of hosts. The cross-site scripting one runs a headless browser engine the project bundles a wrapper for, and there is a JavaScript file that the README describes as an alternative to it.

There is a script that classifies and displays URLs by vulnerability type, which suggests a use where you have a list of URLs and want them sorted rather than tested.

And the duplication is explicit: two implementations of a path tester, one in PHP and one in Python, described as the same thing. That pattern, a pair of files doing one job in two languages, recurs across the collection, which is consistent with a repository that grows by adding rather than by unifying.

One script deserves naming because of what it is not: a generator that produces search queries for a domain and explicitly does not perform the searches. It is a preparation tool, not a scanning one.

## Two scripts wrap other people's tools, and several guess usernames

This is the group to look at before you run anything, and it is worth being precise about what is here.

One script tests for a known arbitrary command execution flaw in a remote plugin executor, and it does so by invoking a well known exploitation framework. That is a check for a specific published vulnerability on a host you name, and the implementation is somebody else's tool.

Two scripts test whether server mailbox user enumeration is possible across a list of addresses, again wrapping a third party script. The pair is the interesting part: one is described as performing the enumeration and the other as only testing whether enumeration is possible. Both exist, and the difference is one line of shell that somebody cared enough to split out.

Two more guess at usernames rather than passwords. One tries server logins using a timing difference, and one brute forces a web storage protocol using another third party script.

Then the scope point, which the documentation does not make. Every one of these takes a list of hosts or an address range as input. There is no scope file, no allow list, no rate limit, no host ownership check and no warning about authorisation anywhere in the README. The repository assumes you already have permission, and nothing in it helps you prove it.

## One release, after the cleanup, and no licence

Two small facts close the picture.

The repository has a single release tag, version 2.0.0, published in December 2022, which is weeks after the cleanup described at the top. That ordering makes sense: the cleanup changed what the project was, and the major version records it. A version file in the tree carries the number for anything that wants it.

And there is no licence file. The repository metadata does not resolve a licence identifier either, and the readme has no licence section.

For a collection of small scripts that is an unusual omission, because the scripts are the kind of thing people copy into their own tooling. Reuse here is not clearly permitted and not clearly forbidden, which means the only safe reading is that you should ask. The one thing the documentation does invite is an issue, for a problem with a script, which is a narrower request than a licence question and the wrong place to raise it.

Commits continue after the release, so the scripts are still being touched even though nothing has been published since.

## Conclusion

Read this repository as a reference shelf rather than adopt it as a toolkit. Its value is that each file does one small thing and you can read the whole thing in a minute, which makes it useful when you need exactly one check and want to see how somebody else implemented it. Do not point its enumeration and brute force scripts at hosts you are not authorised to test, and note that the repository includes no scope statement, no rate limiting and no authorisation warning anywhere in its documentation, so the responsibility for every target list is entirely yours. Before you copy anything out of it, remember that several scripts are thin wrappers around other people's tools, that the requirements file is a developer's convenience list rather than a curated one, and that there is no licence file, so reusing code from here means asking the author.

## FAQ

### What is gwen001/pentest-tools?

A flat collection of small, single purpose security scripts for quick one-off needs, with no framework, no plugin system and no package to import. You clone it and install a small requirements file, then run individual scripts against hosts you choose.

### Which languages does pentest-tools use?

Four: shell, Python, PHP and JavaScript, all in one directory with no build step. The primary language detected for the repository is Python, but most of the files are shell scripts.

### What happened to the tools that were removed from pentest-tools?

The README records a large cleanup in November 2022: some scripts were archived as useless or not working and others moved to their own repositories for visibility, and ten are linked, including an endpoint extractor, a related domain finder, a content security policy analyser and a GraphQL introspection analyser.

### What is in the pentest-tools requirements file?

Twelve libraries with no version pins, including an HTTP client, a Shodan client, a public suffix extractor, a whois client, an IP range helper and a murmur hash library that sits beside the CDN address checker. The standard library argument parser is also listed, which is not a dependency.

### Does pentest-tools have a licence?

No licence file appears in the repository and the metadata resolves no licence identifier, so reuse terms are unstated. There is a single release, version 2.0.0 from December 2022, published weeks after the cleanup the README describes.

## Sources

- [gwen001/pentest-tools on GitHub](https://github.com/gwen001/pentest-tools)
- [Issues](https://github.com/gwen001/pentest-tools/issues)
- [README](https://github.com/gwen001/pentest-tools/blob/master/README.md)
- [Releases](https://github.com/gwen001/pentest-tools/releases)

---

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