TL;DR — The Huntbase Hub is public at hub.huntbase.io. It holds 149 threat hunts built from current public research: 697 queries covering 158 ATT&CK techniques across Windows, Linux, macOS and cloud. Every hunt is reviewed by a person before it is published, and every one is an open hunt.md file you can read, download or fork. No account.

→ hub.huntbase.io

The problem

Most threat research never becomes a hunt.

A good write-up lands. It gets shared, bookmarked and discussed. Turning it into something you can run against your own environment is a different job: read it closely, work out which stages you could actually see, write the queries for your sources, decide what a negative result would mean. That is half a day for someone who knows what they are doing, and it competes with everything else on their list. So it mostly doesn't happen, and the research stays something people have read rather than something they have checked.

We have been working on that gap.

What a hunt on the hub contains

Take one from this month. Huntress published research on MacSync Stealer: a malvertised search for a well-known AI tool leads to a ClickFix lure that has the user paste a curl one-liner into their terminal, which runs a background zsh loader and an in-memory AppleScript that steals credentials and keychains. The hub has a hunt for the scripted delivery and credential theft and a second one for the persistence stage.

The first has:

• A hypothesis you could be wrong about: an attacker has deployed MacSync Stealer on a macOS host by tricking a user into executing a curl-to-zsh one-liner, which then runs in-memory scripts to harvest credentials and keychains.
• Steps, not just queries: twelve of them. Four queries, a prevalence analytic that surfaces rare script content, gates that only open the expensive queries once the curl-to-shell lead looks suspicious, and the response and close-out tasks that follow.
• A coverage map. Three stages of the intrusion are covered by named steps. Three more are marked out of scope because they belong to the other hunt in the series. You can see what this hunt does not look for.
• Named blind spots. For example: most macOS systems do not log script block content by default, and without it the stealer's in-memory logic is invisible. Each blind spot says which data is missing, what the risk is, and who would own fixing it.
• Guardrails for whoever, or whatever, runs it: claims need evidence, telemetry is untrusted, and missing data is not treated as a clean result.
• The source, linked and credited.

That last guardrail matters more than it looks. The easiest way to get a hunt wrong is to find nothing and conclude there is nothing.

How a hunt gets published

Hunts are drafted by machine from public threat research, and then reviewed by a person. We want to be exact about which part is which.

The pipeline reads a piece of research and drafts a hunt. That draft goes into a private review queue as a pull request with an issue beside it. Nothing reaches the hub until a reviewer has approved it and the pull request has been merged. Rejected hunts are closed and never published.

The review checklist is short, and it is where most of the value is:

• Is it one real intrusion or technique? Digests, listicles and product notices get rejected.
• Would the queries still work when the indicators rotate? At least one step has to describe behaviour rather than match a list of domains or hashes.
• Do the steps fit the scenario? A hunt should not look like every other hunt. Steps that exist to fill a template come out.
• Are the blind spots specific? They should name the log source, field or retention that is actually missing.
• Is the severity earned? Critical is for exploited-in-the-wild vulnerabilities or named actors with observed intrusions.
• Is the original research credited?

We will get some of these wrong. When we do, open an issue at github.com/huntbase-io/hunts and we will fix the hunt in public.

Why hunt.md

Every hunt on the hub is a hunt.md file: Markdown with YAML frontmatter, one heading per step, fenced blocks for the queries. We announced the format in August. The spec is MIT-licensed and now at v0.7.

The reason it matters here is practical. A hunt.md file reads fine in a browser or an editor with no tooling at all. It diffs cleanly, so you can review a change to a hunt the way you review a change to code. And nothing about it ties you to us. Fork a hunt, rewrite the queries for your own stack, keep it in your own repository.

Using it today

• Browse by ATT&CK technique, product or CVE at hub.huntbase.io.
• Download any hunt as hunt.md, or fork the lot from github.com/huntbase-io/hunts.
• Get new hunts by email. The weekly hunts newsletter starts today and goes out every Tuesday.
• Follow the feed if you prefer RSS.

Honest status

• ~149 hunts is a start. Coverage follows what gets published as public research, so it leans towards Windows and towards campaigns that vendors write up well.
• Queries are written against a normalised schema, so you will need to adapt field names to your own sources.
• Review is done by a small team. It catches bad hunts. It does not guarantee a hunt is complete for your environment, which is what the blind spots section is for.

If there is a threat you wish someone had already written the hunt for, tell us. That list is what we work from.

Later this week we will have more to say about running these hunts in Huntbase.

→ hub.huntbase.io