LOOBins: a catalogue of the macOS binaries already on every machine

What the project is and where it sits

Living Off the Orchard: macOS Binaries (LOOBins) is a resource designed to provide detailed information on various built-in macOS binaries and how they can be used by threat actors for malicious purposes. The stated goal is to serve as a one-stop resource for cybersecurity professionals and researchers attempting to understand and defend against the potential risks associated with each binary.

The website carries a working list of living off the land macOS binaries that can be used for malicious purposes to achieve tactics such as command execution, privilege escalation, persistence, and data exfiltration. By outlining the functions and potential misuse of each binary, the resource aims to raise awareness about the growing threat picture in the macOS ecosystem.

That is a defensive framing and the project is consistent with it. Each entry records what a binary does, what an attacker might do with it, and how to detect that, which is the information a detection engineer needs and the information a defender would otherwise have to reassemble from a dozen advisory write-ups.

The site is at loobins.io, the project is GPL-3.0 licensed, the primary language recorded for the repository is Astro, and the default branch is main. The last push was on 2026-10-18 and there is a release the same day, 2.0.17, after 2.0.16 on 2026-10-11 and 2.0.15 on 2026-10-07. The repository is not archived, and the release cadence on the website is weekly or better.

How an entry is structured, and why the tags matter

Each LOOBin is categorized into MITRE ATT&CK tactics and various tags, allowing users to easily navigate and locate information on the macOS LOOBins of interest. Additionally, the resources provide example uses of each binary, recommendations and signatures on how to best detect malicious activity, and links to other third-party resources.

The ATT&CK categorisation is the part that makes this more than a list. Once an entry is tagged with the techniques it supports, you can work in the other direction: take a technique your detections do not cover, look up which built-in binaries support it, and close the gap. That is a different exercise from reading a list of binaries top to bottom, and it is the one a detection engineer actually has to do.

The detection recommendations are what make the entries actionable rather than descriptive. The project is not only saying that a binary can be misused, it is recording how to notice it, which is the harder half of the problem and the half that ages as tooling changes.

The example uses are there for the same reason. They show the shape of the activity a defender is looking for, which is a different thing from a step-by-step guide, and the framing in the README keeps them in that role.

Every LOOBin also carries links to other third-party resources, which matters because the project is explicit that it does not try to be the only reference on any given binary.

The JSON API and the Python SDK are the same data

The content contained in each LOOBin can also be programmatically consumed, and the README gives two ways to do it. All LOOBins can be consumed using the JSON API, or by using the Python SDK and CLI tool, PyLOOBins.

The PyLOOBins package is described in its own project metadata as a Python package for managing the LOOBins model and schema, at version 2.0.17, requiring Python 3.8 or newer, licensed GPL-3.0-or-later. The authors listed are infosecB and 0xv1n, and the console script is named pyloobins, mapped to pyloobins.cli:cli.

The dependency list tells you what the SDK is doing. pydantic for the data model, pyyaml for reading the corpus, click for the command line, jinja2 for templating, and stix2 for the ATT&CK side of the data. The STIX2 dependency is the interesting one, because it means the ATT&CK technique identifiers are carried as STIX objects rather than as loose strings, so the data can be joined with other STIX-based tooling instead of needing its own mapping layer.

The build is hatchling, and the package data configuration is where a small engineering decision shows. The LOOBin YAML corpus lives at the repo root, outside the package, so the website and CI can read it in place. A copy is then bundled into the wheel under the package, so an installed pyloobins can discover the data without relying on a walk up the filesystem. The sdist includes src/pyloobins and the LOOBins yml files.

So the answer to the question of which to use is that they are not alternatives. The API and the CLI are two views of one corpus.

Why it does not duplicate GTFOBins

The About section makes a scoping decision that is worth reading, because it is the clearest statement of what this project is for.

LOOBins does not include overlapping Unix binaries that are detailed in GTFOBins unless there are notable macOS-specific use cases, with sqlite3 given as the example. For more information on Unix binaries, the README refers you to the GTFOBins project.

That is good practice in a reference catalogue that is meant to be trusted. A living off the land list that overlaps with an existing one, with slightly different content and no indication of which is authoritative, is worse than one that explicitly defers. The scope is macOS-specific binaries and macOS-specific use cases, and the rest is pointed at the project that covers it.

The same reasoning shows in the contribution section. LOOBins is a living project and will likely never be complete, and it will require continuous updating as new binaries or use cases are discovered by the community. The ways to help are listed plainly: add new LOOBin binaries, update existing entries by adding new use cases, detection sources or resources, or by fixing a typo, help develop and maintain the PyLOOBins Python SDK and CLI, and submit an issue for any problems with the website or the SDK. The contribution guidelines are linked.

A catalogue that expects to be incomplete and asks for specific kinds of contribution is a different kind of artefact from a finished document, and it is built to be corrected in public.

The repository shows a site and a data pipeline in one tree

The top level listing shows a project that mixes a documentation site, a data corpus and a Python package, and the three are separated clearly.

The LOOBins/ directory is the corpus itself, the data that the website renders and the SDK serves, and the badge at the top of the README counts the files in it to show the total number of LOOBins. The web/ directory is the Astro site, and src/ is the Python package, with tests/ alongside it. There is a docs/ directory, which holds the PyLOOBins documentation including the readme the package metadata points at.

The separation is the reason the packaging works the way it does. The corpus is plain YAML files in a directory that both the site build and the CI can read directly, so there is no build step between authoring an entry and seeing it, and the Python package is a reader of that directory rather than an owner of it.

The tooling is visible too. There is a .pre-commit-config.yaml at the root, a pyproject.toml with the pylint, mypy, tox and hatch configuration, and a CLAUDE.md alongside the CONTRIBUTING.md. The mypy configuration is worth a glance: it targets src/pyloobins, uses the pydantic mypy plugin, and enables ignore_missing_imports with warn_unused_ignores, warn_redundant_casts and no_implicit_optional. The tox configuration lists a py38 environment first, which lines up with the 3.8 minimum in the package metadata.

The build status badge points at a workflow called validate_loobins, which is the check that the corpus stays well formed as people add to it.

Editorial conclusion

Adopt LOOBins as a detection reference if you defend macOS fleets, because the value is in a maintained, ATT&CK-tagged, machine-readable inventory rather than in prose anyone could write from memory. Do not treat it as a cookbook, since the example uses are illustrative of what defenders watch for rather than a manual, and the project is explicit that it will never be complete. Before you build tooling on it, note that the corpus lives at the repository root rather than inside the Python package, that a copy is force-included into the wheel so installed clients can find it, and that the API and the PyLOOBins CLI expose the same data.

Frequently asked questions

Official sources

1. infosecB/LOOBins on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases