Social-Engineer Toolkit (SET): A Consent-First Framework for Authorized Phishing Tests

What SET Tests and Who It Is For

The Social-Engineer Toolkit is an open-source penetration testing framework for authorized social-engineering assessments. It is maintained by TrustedSec and written by David Kennedy (ReL1K). The README's first sentence frames the intended use: guided attack vectors for security teams that need to test user awareness, validate controls, and run consent-based red-team exercises.

The target users are professional penetration testers and internal red teams who hold explicit written authorization to test the organization they are assessing. The README makes this requirement explicit: SET is only for authorized testing where permission and scope have been established. A security team at a financial institution simulating a spear-phishing campaign against its own employees, or a consulting firm running a credentialed engagement, fits the intended use. Anyone running SET without prior consent does not.

SET version 8.1.3 targets Python 3.11 through Python 3.13, as stated in the pyproject.toml. The supported platforms are Linux (primary), macOS (experimental), and Windows through WSL2 or another supported Linux environment. Native Windows without WSL is not a documented configuration.

The Interactive Console and What It Wraps

SET's primary interface is an interactive console launched from the command line. The framework organizes attack vectors as numbered menu options. A tester navigates menus to select an attack type, configure it, and launch it against a target defined within the engagement scope.

The pyproject.toml lists SET's runtime dependencies: pexpect for subprocess interaction, pycryptodome for cryptographic operations, requests for HTTP, pyOpenSSL for TLS handling, pefile for Windows executable analysis, impacket for Windows networking protocols, qrcode and pillow for visual output generation, and pymssql (pinned below version 3.0, as the project has been discontinued) for MSSQL connectivity. The requirements.txt confirms these directly.

The repository also includes three supporting scripts alongside the main setoolkit binary: seautomate for scripted non-interactive runs, seproxy for proxy-based interception, and seupdate for updating the toolkit. These are installed as separate executables when using the pyproject.toml path or the legacy system-wide installer.

A Dockerfile is present in the repository. It uses ubuntu:latest as a base, installs git and pip, clones the repository, installs from requirements.txt, and sets the entrypoint to ./setoolkit. This provides a self-contained container that avoids dependency conflicts with the host system.

Installing SET on Kali Linux and from Source

On Kali Linux, SET is available as a system package:

sudo apt update
sudo apt install set -y

This is the recommended path for Kali users and requires no additional setup. For other Linux distributions or macOS, the README provides a source installation path using a virtual environment:

git clone https://github.com/trustedsec/social-engineer-toolkit/ setoolkit/
cd setoolkit
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e .

This installs SET in editable mode inside the virtual environment. Once installed, the toolkit is launched with elevated privileges:

sudo setoolkit

From a source checkout, you can also run it directly:

sudo ./setoolkit

The legacy system-wide installer, `sudo python3 setup.py`, copies files to /usr/local/share/setoolkit, writes the configuration to /etc/setoolkit/set.config, and creates a launcher at /usr/local/bin/setoolkit. The README describes this path as the legacy layout; the venv path is the current recommended approach.

For development and testing, the pyproject.toml documents a shorter sequence:

python -m pip install -e .
python -m pip install pytest
python -m compileall -q .
pytest -q

Platform Constraints and Dependency Risks

The most significant platform constraint is the macOS designation: the README marks macOS support as experimental. There is no further detail in the provided repository files about which features work on macOS and which do not, or what the failure modes are. A team that needs to run SET on macOS should treat experimental as meaning untested rather than unsupported.

Windows is not directly supported. The README is explicit: Windows requires WSL or WSL2 running Kali or another supported Linux environment. Running SET from a native Windows Python installation is not a documented configuration.

The pymssql dependency carries a specific risk noted in requirements.txt: the pymssql project has been discontinued, and SET pins it below version 3.0. Any future Python version that breaks pymssql's compatibility will require either a workaround or a replacement library. The pinned version constraint means this risk grows over time as the Python ecosystem moves forward without pymssql maintenance.

The repository has no GitHub releases. Version 8.1.3 is defined in pyproject.toml but there is no corresponding GitHub release entry. Version tracking for SET requires reading pyproject.toml or running the tool and checking its self-reported version rather than using GitHub's release feed.

The Framework Approach Compared to Custom Tooling

The alternative to using SET is building phishing and social-engineering tooling from scratch for each engagement. Custom tooling gives the tester complete control over every detail: the exact HTTP headers, the look of a credential-harvest page, the payload delivery mechanism. It can be tuned to evade specific detection controls and tailored precisely to the target environment.

SET's trade-off is the opposite: speed and repeatability in exchange for flexibility. A tester who needs to run a standard spear-phishing simulation quickly, without writing new infrastructure for each engagement, can navigate SET's menus and be operational faster than building equivalent tooling from scratch. The framework also provides a documented audit trail: the configuration choices made in SET's menus are consistently structured, which helps when writing an assessment report.

The limitation is that SET is a known framework. Defenders who monitor for SET-specific patterns in HTTP traffic, payload signatures, or executable artifacts may detect an engagement that would succeed with bespoke tooling. The README does not document how SET handles evasion or obfuscation; a team facing a mature security operations center should weigh this trade-off before choosing SET over custom tooling.

Docker Deployment

The Dockerfile in the repository provides an alternative to a native installation. It builds from ubuntu:latest, installs git and python3-pip, clones the repository at depth 1, installs requirements.txt with pip3, runs the legacy setup.py installer, and sets the entrypoint to ./setoolkit. Running SET inside Docker isolates it from the host Python environment and avoids conflicts with other tools.

The docker-compose approach that SET's own README describes is not present in the provided files, but the Dockerfile is a direct path to a containerized run. The container uses the legacy system-wide layout rather than the venv path, so the setoolkit binary is available at the container's root working directory after the build.

One practical consideration: SET's interactive console requires a terminal (TTY). Running the Docker container without the -it flags will produce a non-interactive session where the menu-driven interface does not function. The seautomate script is the documented path for non-interactive use.

License, Maintenance, and Responsible Use

The pyproject.toml classifies the license as BSD, confirmed by the OSI Approved :: BSD License classifier. The actual license file is at readme/LICENSE in the repository. BSD permits use in commercial products and does not require releasing source for derivative works, but it does not grant permission to use the tool against systems or people without their consent: that obligation comes from law and the tool's own documented responsible-use terms.

The last push to the master branch was on 2026-06-04. The repository is not archived. Security vulnerabilities should be reported through the process in SECURITY.md rather than as public GitHub issues: the README explicitly asks reporters to avoid public disclosure of exploitable vulnerabilities.

The user manual, at readme/User_Manual.pdf in the repository, is the primary documentation for understanding individual attack modules. The README is brief by design; the manual carries the operational detail.

Editorial conclusion

SET is the right tool for a security team that already has written authorization to run social-engineering tests and needs a structured framework to execute phishing simulations, credential harvesting scenarios, and related exercises against its own organization. It is not the right tool for any assessment where explicit consent has not been established in advance: the README states this directly, and the BSD license does not override that requirement. Before running SET, confirm the version (currently 8.1.3) matches the Python environment (3.11 through 3.13), verify that macOS support is still marked experimental, and review the user manual at readme/User_Manual.pdf in the repository.

Frequently asked questions

Official sources

1. Issues
2. README
3. trustedsec/social-engineer-toolkit on GitHub