Capabilities this project will not add
Feintkit is a defensive test suite. It contains benign, simulated versions of known attack patterns so that a security product, or your own agent, has something realistic but harmless to detect and resist. This page lists what the suite will never contain, so that nobody is surprised and so that a request for any of it gets a short, fixed answer.
Read it together with DISCLAIMER.md (the usage rules), SECURITY.md (how to report a problem), and the misuse and threat model (what the suite protects, who it is protecting against, and where its protections stop).
The rule behind this page
Every scenario and every tool has to pass one test before it goes in:
If the artifact, as shipped, would cause harm when pointed at a real target, it does not go in; only simulations that need a defender to give them meaning do.
A simulation "needs a defender" when it has no effect of its own: the only thing that gives it meaning is a person or a product that notices it, blocks it, or resists it. A file with a hidden sentence, a server that lists a poisoned tool description, or a decoy request to a loopback address has no effect on a target until something reads it and reacts. A working exploit, a credential stealer or a scanner does the harm by itself, whoever is watching.
Each shipped scenario and package has a row in scenarios/LITMUS.json that says why it is harmless, which guard rule and which test enforce that, and what effect on a real target remains (none, or the exact residual such as a listener on 127.0.0.1). The spec linter fails when a scenario has no row.
What will not be added
1. Functional malicious payloads
No code that does damage when run: no shell command that is actually executed, no destructive file operation, no ransomware-like, wiper-like or worm-like behavior, no real payload of any kind. Where an attack's pattern involves running a command, the suite builds the command text and prints it as a "would run" line; it never starts a process with it. The suite has exactly one instruction sentence that asks an agent to do anything, and it asks only for a harmless acknowledgement token.
2. Real credential access or exfiltration
No reading of real credentials, keys, tokens, cookies, browser data, keychains, environment secrets, or personal files, and no sending of any such data anywhere. Scenarios use obviously fake decoys (FEINTKIT-FAKE-CRED-0000, FEINTKIT-FAKE-DATA-0000, invented tokens on reserved .invalid domains), record at most the names and length classes of what a caller supplies, and never store a supplied value.
3. Non-loopback network attack traffic
No scanning, probing, flooding, relaying, tunnelling, command-and-control, phishing delivery or any other traffic aimed at an address that is not the local machine. The suite's own network use is a loopback listener or request on 127.0.0.1 (the harness refuses any other host), plus two clearly separate maintenance tools (the installer, which downloads a release file from an https address the person gives it, and the fact re-check tool, which reads public documentation pages) that act only when a person runs them.
4. Persistence
No code that installs itself, survives a restart, registers a service, scheduled task or startup entry, edits shell profiles, or modifies an agent's real settings, memory, skills or instruction files. Scenarios that are about persistence of an instruction write inert files into their own output directory; a person decides whether to copy them anywhere.
5. Evasion of detection
No obfuscation, packing, encoding, sandbox or analysis detection, timing tricks, or any technique whose purpose is to avoid being seen by a defender. The suite does the opposite: every artifact carries a visible marker string, a safety banner and a manifest naming the signal a product should raise. The scenarios that hide text from a human reader (a comment, low-contrast pixels, invisible Unicode) do so in fixed, documented ways that a test can decode, because detecting hidden text is the point.
6. Exploit code
No code that takes advantage of a vulnerability in a real product, library, protocol implementation or service, and no proof-of-concept that would work against a real target. Scenarios describe a pattern and show its shape; they do not target a specific flaw in a specific release.
7. Anything that attacks a third party
No scenario, option, default or example whose effect lands on a system, account, person or organization that has not agreed to be tested. That includes real vendor, publisher or package names used to deceive, real addresses, real repositories or accounts, and the publication of anything under a name that exists. Invented names use reserved prefixes (feintkit-canary-) and reserved domains (.invalid, example.invalid), and the suite never installs, resolves or publishes them.
If you want one of these
Do not ask for it here. The project will not accept it: not as a pull request, not behind a flag, not in a separate "pro" or "advanced" edition, not as a scenario "made more convincing" for a demonstration. A request to relax any of the seven points above is declined.
The license (Apache-2.0) lets you fork the project and change your copy. If you decide to do that, you are responsible for what it does:
- Do it on systems you own or are authorized in writing to test.
- Do not distribute it under the name "Feintkit" or in a way that suggests it is this project or endorsed by it. The license grants no right to the project's name.
- Do not ship it as a release that a reader could take for an official one.
If you only need a scenario that is not in the catalog, open an issue describing the attack pattern and the signal a product should raise; a pattern that passes the test above can be added as a simulation. If you find something in this repository that breaks these rules, or a copy of the suite that does, see the "Abuse reports" section of SECURITY.md.