LOLBAS: the YAML catalogue of Microsoft-signed binaries that do more than they should

What LOLBAS actually is, and who the list is written for

LOLBAS stands for Living Off The Land Binaries and Scripts, and the repository has since added libraries to that scope. The README states the goal plainly: to document every binary, script and library that can be used for Living Off The Land techniques. The subject matter is Windows. A candidate has to be a Microsoft-signed file, either native to the operating system or downloaded from Microsoft, and it has to carry extra functionality beyond its intended use. The README says intended use cases are not interesting, with application whitelisting bypasses named as the exception.

The audience is narrower than the topic suggests. This is material for detection engineers, incident responders, purple teamers and red teamers who already know what a signed Microsoft binary is and want to know which ones can download a file, execute code, bypass UAC, dump process memory or modify logs. The README lists those categories explicitly, along with persistence, credential theft, surveillance and DLL side-loading or hijacking without relocating the file elsewhere in the filesystem. If you are looking for a product that watches for these behaviours, this is not it. The repository is a reference that other people's tooling consumes.

One YAML file per binary, and a static site that renders them

The architecture is deliberately flat. The yml/ directory at the top level holds the entries, the frontend at lolbas-project.github.io reads them, and the README describes the repository as the place where those YML files are maintained. There is no server component and no query API documented in the README. Consumers either read the rendered site or clone the repository and parse the YAML themselves.

That choice has consequences worth naming. A YAML directory is easy to diff, easy to review in a pull request and easy to mirror into an internal knowledge base. It is also easy to fork and let drift, because nothing in the repository forces an entry to be re-validated against a new Windows build. The README points contributors at CONTRIBUTING.md and at YML-Template.yml for the required format, which tells you the schema is treated as a contract. The repository layout confirms it: CategoryList.md sits alongside yml/, and Archive-Old-Version/ holds the previous iteration of the project. The primary language listed for the repository is XSLT, even though the entries are written in YAML. The work that matters is the YAML.

Installing LOLBAS and reading your first entry

There is nothing to install in the usual sense. The README gives no package, no binary and no setup command; it points at the hosted frontend and at the repository that feeds it. The practical installation is a clone and a look at the files.

git clone https://github.com/LOLBAS-Project/LOLBAS.git
cd LOLBAS
ls yml/

The third command lists the entry files. You should see one YAML file per documented binary, script or library. If you want the schema before you read an entry, open the template the README links for contributors.

cat YML-Template.yml

That template defines the fields a new entry has to carry. Reading it first makes the individual entries legible. The README also points at CONTRIBUTING.md for anyone who wants to add a binary, and the repository root also holds CategoryList.md. The README does not document a local preview of the website, so treat the YAML as the artefact and the site as a convenience.

The inclusion criteria are the real product

Most of the judgement in this project lives in the criteria, not in the entries. A binary has to be Microsoft-signed and has to do something beyond its intended purpose. The README's list of interesting functionality is effectively a taxonomy of attacker tradecraft: arbitrary code execution, pass-through execution of unsigned programs or scripts, compiling code, downloading, uploading, copying, persistence through an existing LOLBin, hiding data in alternate data streams, execution at logon, UAC bypass, credential theft, process memory dumping, keylogging or network tracing, log evasion or modification, and DLL side-loading without moving the file.

One exclusion is stated with unusual precision. The project does not approve binaries that allow NetNTLM coercion, on the grounds that most Windows binaries allow it. The exceptions are binaries that do it on ports other than the default, with rpcping named as the example, or binaries that allow direct credential theft. That single paragraph tells you more about the maintainers' standard than any amount of prose about quality. It also tells you something about coverage: the list is curated against a stated bar, so it is not a complete enumeration of every abusable signed binary on a Windows system.

Where LOLBAS stops being the right tool

The list documents behaviour; it does not observe it. Nothing in this repository watches a process tree, inspects command lines or emits an alert. If your problem is detection coverage, LOLBAS gives you the raw material, and you still have to write the rule, tune it against your environment and accept the false positives that come from legitimate administrative use of the same binaries. That gap is where most adoption efforts stall.

There is a second limit that follows from the criteria. Because the bar is Microsoft-signed files with unexpected functionality, a signed binary that is merely noisy or that performs its documented job is out of scope by design. A team looking for a general inventory of what runs on Windows endpoints is in the wrong repository. And the entries describe behaviour on Windows builds; the README says nothing about versioning entries against specific Windows releases, so an entry that was accurate when it was written may not match the build you are running. That is a property of a community-maintained catalogue, not a defect the maintainers can fix with a schema change. The last push to the repository was on 2026-09-26, so entries are being added and edited, but nothing in the README promises revalidation of older ones.

LOLBAS against GTFOBins, and the Linux question

The README thanks the team behind gtfobins.github.io for the frontend, which makes the relationship explicit: GTFOBins is the Unix counterpart, cataloguing binaries on Linux and similar systems that can be abused for the same purpose. The difference is scope. LOLBAS is tied to Microsoft-signed files on Windows, which is why its criteria talk about signing and about Windows-specific behaviours such as alternate data streams and UAC bypass. GTFOBins covers a different operating system with a different abuse surface, and an entry in one does not imply an entry in the other.

If your estate is mixed, you need both, and you should not expect the schemas to line up. The LOLBAS README does not describe a Linux section, and the criteria are written around Microsoft signing, so a Linux binary cannot satisfy them as stated. The same logic applies to the naming question that comes up often: LOLBin refers to a single binary, LOLBAS to the project and its wider scope of binaries, scripts and libraries. The README records that LOLBins was proposed by Philip Goh and that Jimmy followed with LOLScripts, and it lists #LOLLib and #LOLLibs among the project's hashtags.

Licence, maintenance and the cost of keeping entries current

The repository is licensed GPL-3.0, and the README directs readers to NOTICE.md for licence information rather than restating the terms. For most consumers this is a documentation question rather than a distribution question: if you clone the repository or mirror the YAML into an internal pipeline, you are copying GPL-3.0 material, and how that interacts with your own tooling is a question for your legal team, not for this article. The README gives no separate licence for the site content.

Upgrade cost is low in mechanical terms and higher in attention. The repository has no published GitHub releases, so there is no versioned artefact to pin; you track the master branch or a commit of it. The repository carries a YAML linting workflow under .github/, which means malformed entries are caught before merge, and that is the main quality gate visible from the outside. What no workflow can catch is an entry whose behaviour changed with a Windows update. If you consume the YAML in an automated pipeline, the honest position is that you own revalidation of the entries you depend on, and the repository gives you the file and the history to do it.

Editorial conclusion

Adopt LOLBAS if you are building detections, threat hunts or training material and need a schema-backed list of Microsoft-signed binaries with documented abuse paths; the YAML in yml/ is the part you consume, not the website. Do not adopt it if you want a scanner, an EDR rule pack or anything that executes: the repository ships documentation only, and the README states that binaries allowing NetNTLM coercion are rejected unless they work on non-default ports or enable direct credential theft, so absence from the list is not evidence a binary is safe. Verify first that the entry you care about still matches the Windows build you run, that it gives you the exact path and arguments you will alert on, and that you can clone the repository and lint the YAML before wiring it into a pipeline.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. LOLBAS-Project/LOLBAS on GitHub
4. Project website
5. README