InternalAllTheThings: an Active Directory pentest cheatsheet you clone, not install

What problem InternalAllTheThings solves, and for whom

Internal assessments fail on coverage, not on tooling. An operator has a domain controller, a file share and a set of credentials, and the question is which of the known internal techniques apply here and in what order. InternalAllTheThings is a collection of pages that answers that question. The repository describes itself as Active Directory and Internal Pentest Cheatsheets, and it is organised as documentation rather than as code.

The audience is narrow and specific. It is written for people who already know what an internal assessment is: red teamers, penetration testers and defenders who need to understand the same techniques from the other side. It is not an introduction to security. A reader who does not know what a domain trust is will not get far, because the pages assume the surrounding vocabulary.

The second audience is contributors. The README asks readers to update pages by submitting a Pull Request, which means the project is maintained as a shared notebook. That matters for how you should treat it. A cheatsheet written by many hands accumulates both good technique and stale technique, and the repository carries no per-page version marker to tell you which is which.

How the cheatsheets are built and published

The top-level layout is small: docs/, assets/, overrides/, mkdocs.yml, a pre-commit config and a README. The content lives in docs/ as Markdown, and mkdocs.yml configures the static site generator that turns those files into the published version. The repository's primary language is listed as HTML, which reflects the generated output rather than hand-written source.

That structure has a practical consequence. Editing a page means editing Markdown, and the rendered site is a build artefact. The README points to an alternative display version at swisskyrepo.github.io/InternalAllTheThings, which is the same content served as a browsable site. For a reader, the web version is the faster path: navigation, search and cross-links are already built. For a contributor, the Markdown in docs/ is the source of truth.

The .pre-commit-config.yaml file indicates that some checks run before a commit is accepted. The repository does not document what those hooks enforce, so a contributor should read that file before sending a pull request rather than assuming formatting will be corrected automatically.

There is no application to run, no server component and no API. The data flow is one-directional: Markdown in docs/, a configuration in mkdocs.yml, a rendered site out. Anyone expecting a scanning engine will be disappointed, and that is the single most common misunderstanding about a project with this name.

Reading the cheatsheets offline and rendering them locally

The README does not give installation steps, because there is nothing to install in the usual sense. What it does give is a web version and an invitation to contribute through pull requests. If you want the content offline, or you want to edit a page, the practical route is to clone the repository and work from the files it contains.

The clone is the same for any Git host:

git clone https://github.com/swisskyrepo/InternalAllTheThings.git
cd InternalAllTheThings

After this you have docs/, mkdocs.yml and the rest of the tree on disk. The Markdown pages under docs/ are readable as plain text even without building anything, which is often enough when you only need one page.

The repository ships mkdocs.yml, which is the configuration file the site build reads. The README does not list the command to render it, so treat the file itself as the starting point and check it for the theme and plugins the build expects. The README also does not name a dependency list, so mkdocs.yml is the file to read when a build complains about a missing theme or plugin.

For a static copy you can host yourself, the same configuration file is what you point the build at. This writes the rendered site to the output directory configured in mkdocs.yml. From there any static file server will do. None of these steps change the content; they only render it.

Where the cheatsheet format breaks down

The main limitation is verification. A cheatsheet records that a technique exists, not that it still works against a current, patched environment. The README is explicit that content is provided as is, for learning purpose, and that the author and contributors take no responsibility if you break something. That disclaimer is honest, and it also tells you exactly what the project is not promising.

The second limitation is that there are no releases. The project publishes no versioned artefacts, so there is no changelog to diff between two points in time. If a page changes, you learn about it by reading the commit history, not by comparing tags. For a team that wants to pin a reference for an engagement, that is awkward: you can pin a commit hash, but nothing in the repository suggests a stable snapshot to pin to.

The third is that a wiki-shaped project has no enforcement of accuracy. There is a pre-commit configuration, but the README does not state that it validates technical claims, and no review process is described. Pages added by one contributor may sit unrevised for a long time.

Finally, this is the wrong tool for anyone who needs repeatable, auditable output. If your engagement requires a tool that produces findings with evidence, a Markdown page cannot do that. InternalAllTheThings informs an operator; it does not replace one.

InternalAllTheThings and HackTricks as different references

The most natural comparison is HackTricks, which appears repeatedly in the searches people run around this project. Both are community-written security references, and both are read rather than executed. The difference is scope and framing.

HackTricks is broad. Its coverage spans web, cloud, mobile, WordPress, AWS and more, and the related searches show readers arriving at it for those subjects. InternalAllTheThings is deliberately narrower: Active Directory and internal networks. If your question is about an internal domain, the narrower reference is more likely to have the page you want without a detour through unrelated material. If your question is about a cloud control plane or a web application, the broader reference is the one that covers it.

The second difference is presentation. InternalAllTheThings is an MkDocs site built from a repository whose README points to a hosted web version, so the reading experience and the contribution path are the same artefact. That is a design choice with a cost: the project is only as good as the pull requests it receives, and there is no editorial layer described in the README to arbitrate between conflicting advice.

Neither project is a scanner, and choosing between them is not a question of which is more capable. It is a question of which subject you are working on.

Maintenance, licensing and the cost of adopting a wiki

The repository is not archived, and the last push was on 2026-08-16. That is recent enough that the project is being touched, but a push date alone says nothing about how much of the content was updated or whether the changes were technical. Treat the date as evidence of activity, not of accuracy.

Upgrade cost is close to zero and also close to meaningless. There are no releases to upgrade between, no dependency to bump and no migration path. You pull the latest commits and read. The cost you actually pay is review time: someone on your team has to decide whether a given page still reflects a technique that works in your environment. That cost is real and it recurs every time you rely on the reference.

The license is not stated in the repository description or the README. That matters more here than for a library, because a cheatsheet is text you may want to quote, adapt into an internal runbook or redistribute to a client. Without a stated license, you cannot assume permission to do any of those things. Check the repository for a license file before reusing content outside your own reading, and if none exists, treat reuse as something to clear with the author rather than something to assume. Nothing here is legal advice; it is a pointer to the one fact you need before copying text into a deliverable.

Editorial conclusion

Use it if you already run internal assessments and want a checklist to work from, and read the web version at swisskyrepo.github.io/InternalAllTheThings before cloning anything. Do not use it as an automated scanner or as a substitute for a lab. First verify what a page actually claims by testing the technique in your own environment, because the README states the content is provided as is and the author takes no responsibility if you break something.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. swisskyrepo/InternalAllTheThings on GitHub