# tactical-exploitation: an exploit-less penetration testing toolkit > tactical-exploitation collects the small scripts a penetration tester reaches for when the goal is to abuse process weaknesses rather than a published CVE: SMB brute force, information leakage checks, HTTP method scanning, search engine recon and Meterpreter stagers. The README marks every tool as a proof of concept that may be buggy or incomplete. **0xdea/tactical-exploitation** — Modern tactical exploitation toolkit. - Repository: https://github.com/0xdea/tactical-exploitation - Website: https://0xdeadbeef.info - Stars: 867 · Forks: 122 - Language: Python - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/0xdea-tactical-exploitation ## Tactical exploitation as a working method The repository name carries an argument, and the README states it plainly. The author describes himself as a long time proponent of a tactical approach to penetration testing that does not focus on exploiting known software vulnerabilities but instead relies on old school techniques such as information gathering and brute force. The stated advantage is reliability. Rather than hunting for an unpatched service, a tester looks at what is actually running: which accounts exist, which HTTP methods a server accepts, which hosts in a range are indexed by a search engine. The author frames this as exploiting process vulnerabilities, and claims it minimises detection and other unwanted side effects compared with a noisy exploit. The README carries a warning, and it is the most important line in the document for anyone considering deployment. The tools are proofs of concept. They are functional, the README says, but may be buggy or incomplete, and they are to be used at your own risk. That caveat sets the tone for everything else here. This is a working notebook of engagement utilities, published in the open by a researcher who also writes about the method in long form. The linked articles on tactical exploitation, the PowerShell discovery story and the Meterpreter stager written in Go explain the reasoning behind the scripts in more depth than the README does. ## The inventory: eight scripts and one Go binary The repository root is flat, which tells you how these tools are meant to be used. There is no package, no install target and no configuration layer. Each script stands alone. For information gathering there are four Python scripts. Botshot captures screenshots of websites from the command line, which the README says is useful to automate mapping the web attack surface of large networks. Verbal is an HTTP request method security scanner that tries a series of interesting methods against a list of website paths to determine which methods are available and accessible. Netdork uses the Google Custom Search Engine API to collect information on public networks and map the available attack surface, with two attack types supported: a network search sweep based on target CIDRs and subdomain discovery via the search engine. Seitan uses the Shodan.io API for open source intelligence on targets, with ipaddr to view everything available for an IP address and domain to search services related to a domain or host name. For active work there are Easywin, a Python script that attacks Windows and Active Directory environments through information gathering and brute force against the SMB protocol, and Poriluk, a helper for information leakage vulnerabilities covering dictionary based user enumeration via SMTP VRFY, EXPN and RCPT, plus HTTP Apache mod_userdir. And for post-exploitation there are three implementations of Metasploit staging: Letmein in PowerShell, a Python alternative, and Letme.go in Go. ## Reconnaissance first: Botshot, Verbal, Netdork and Seitan Four of the scripts do no exploitation at all, and they are the ones with the widest appeal. Verbal is the most self contained. It sends a series of HTTP methods against a list of paths and reports which ones are available and accessible. The README lists the methods currently supported as GET, OPTIONS, TRACE, DEBUG and PUT. That list is interesting because it is not a set of methods a normal client uses; TRACE and DEBUG are frequently disabled or misconfigured, and PUT may be enabled on an upload endpoint that nobody remembered to lock down. A script that reports which methods a server honours gives you a quick read on that. Netdork and Seitan both outsource the discovery to somebody else's index. Netdork queries the Google Custom Search Engine API to sweep target CIDRs and to find subdomains, and Seitan queries the Shodan.io API for information about a host or for services related to a domain. The README describes Netdork as mapping the attack surface stealthily, and both scripts depend on API credentials, so they need configuration the README does not describe. Botshot is the odd one out. Taking screenshots of a list of sites from the command line is not an attack, it is documentation. The README positions it as a way to automate mapping the web attack surface of large networks, and for a large engagement that means producing a visual record of what an internal user would see when they browse those hosts. ## Easywin and Poriluk: attacking accounts and services directly Easywin is the script that gives the repository its offensive edge. The README describes it as a toolkit for exploit-less attacks aimed at Windows and Active Directory environments, leveraging information gathering and brute force capabilities against the SMB protocol. That is deliberately unglamorous work. Rather than exploiting a service, you authenticate against it with guessed credentials until something succeeds. The technique is old, it works because organisations leave test accounts and default passwords in place, and it produces very little in the way of the telemetry that exploit based tooling generates. Whether it succeeds is entirely a question of the target's password hygiene. Poriluk is a smaller helper with a specific scope. The README says it provides a comfortable interface to exploit common information leakage vulnerabilities, and names the ones supported at the moment: dictionary based user enumeration over SMTP with the VRFY, EXPN and RCPT commands, and HTTP Apache mod_userdir. The SMTP side is the interesting half, since the three commands are still widely enabled and reveal whether a given account name exists, which turns a wordlist into a targeted credential list rather than a spray. The mod_userdir path covers a specific Apache misconfiguration. Both are narrow, both are old, and both are the kind of finding that still shows up on internal networks where the mail server and the web server were configured years ago and never revisited. ## Staging with Letmein and Letme.go The last group is the post-exploitation side, and it is the one with the clearest workflow in the README. Letmein is a pure PowerShell implementation of the staging protocols used by the Metasploit Framework. The described sequence is: start an exploit/multi/handler instance on the attack box, configured to handle one of the supported Meterpreter payloads, run letmein.ps1 on the compromised Windows box, ideally as Administrator, and wait for the session. The README says the technique is quite effective at bypassing antivirus and obtaining a Meterpreter shell on Windows, and notes that an alternative Python implementation is provided for educational purposes but is not recommended in the field. Letme.go is the same idea in Go, described as a minimalistic implementation of the main staging protocols. The workflow is identical: a handler on the attack box, letme.exe on the target, and a session when they meet. The README links to backdoor-rs for a Rust variant, and an article about learning Rust for fun with a backdoor implementation. The design reason for a separate stager is that the staging protocol is what turns a one shot delivery into a working session, and implementing it yourself avoids shipping a large payload. The reason to prefer the Go version is size and portability. The reason the Python one is marked as not recommended in the field is that it is the least discreet of the three, and a Python interpreter on a target is itself a signal. ## Where this toolkit sits against its alternatives The alternative to this approach is exploit-led testing, and the author is explicit about the trade rather than pretending both are equally good. A published vulnerability gives you a repeatable path to code execution on an unpatched host. An exploit-less approach gives you a path that depends on the target's own hygiene, which is slower and less certain but does not depend on a patch state you do not control. A second alternative is writing your own tooling for the same job. Almost every script here is small enough that a competent tester could reproduce it: Verbal is a loop over methods, Easywin is authentication attempts against SMB, Seitan is a wrapper over Shodan API calls. What the repository gives you is the accumulated set, already written, with the rough edges of the author's own engagements still in them. That last point is where the warning applies. These are proofs of concept. The README says the tools are functional but may be buggy or incomplete, and there are no GitHub releases to pin against, so there is no version history to consult when behaviour changes. In an engagement you own the scripts, which means you own the debugging too. ## Licence, maintenance and the practical red lines The repository is MIT licensed, which is a permissive licence that allows use, modification and redistribution with attribution and no warranty. Whether it suits your organisation is a question for your own legal review. On maintenance, the facts are modest. The last push was on 2026-08-02, and the repository has no GitHub releases at all. There is no changelog, no tagged version to pin and no issue release cadence to rely on. What you get is a snapshot of scripts whose last edit was in 2026, which is recent enough to run against current systems and old enough that nobody is committing to their long term upkeep. Two constraints deserve emphasis. The first is authorisation. Easywin brute forces SMB against Windows and Active Directory hosts, and Netdork and Seitan will map the public and search indexed surface of a target range. Running any of these against infrastructure you are not contracted to test is not a grey area, and the scripts make no attempt to prevent misuse, because they are proofs of concept rather than guarded tooling. The second is the proof of concept warning itself. The README says plainly that the tools may be buggy or incomplete and are to be used at your own risk. In a live engagement, that means testing each script in isolation before you rely on it, and having a fallback that does not depend on this repository working exactly as documented. ## Conclusion tactical-exploitation suits testers who work under a written scope and want the unglamorous path of enumeration and default credentials before they consider a memory corruption bug, and its separate scripts make it easy to lift exactly one tool into an engagement. It is the wrong choice for engagements that require an exploit chain, for production pipelines that need supported tooling with an SLA, and for anyone without explicit authorisation on the target network, since Easywin brute forces SMB and Netdork sweeps search engines for your CIDR ranges. Verify first that the scripts still run against the versions in your environment, since the README warns they may be buggy or incomplete, and confirm the scope of any CIDR or domain list before you point Netdork or Seitan at it. ## FAQ ### What is tactical-exploitation and who is it for? It is a toolkit of standalone scripts for penetration testers who prefer information gathering and brute force over exploiting published vulnerabilities, covering Windows, Active Directory, web and network reconnaissance tasks. ### How do I install the tools in the tactical-exploitation repository? The README documents no installation or dependency steps. The repository ships standalone scripts such as easywin.py, botshot.py and verbal.py at its root, so you copy the ones you need and provide their own credentials where required. ### How does letmein.ps1 work with Metasploit? You start an exploit/multi/handler on your attack box configured for one of the supported Meterpreter payloads, run letmein.ps1 on the compromised Windows host, ideally as Administrator, and wait for the session. ### What HTTP methods does verbal.py test? The README lists GET, OPTIONS, TRACE, DEBUG and PUT as the methods currently supported, tried against a list of paths to see which are available and accessible. ## Sources - [0xdea/tactical-exploitation on GitHub](https://github.com/0xdea/tactical-exploitation) - [Issues](https://github.com/0xdea/tactical-exploitation/issues) - [License: MIT](https://github.com/0xdea/tactical-exploitation/blob/master/LICENSE) - [Project website](https://0xdeadbeef.info) - [README](https://github.com/0xdea/tactical-exploitation/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/0xdea-tactical-exploitation