mihari Review

Hunting adversary infrastructure with OSINT sources can get old quickly. Writing a Shodan query for a Cobalt Strike certificate works initially, but running it repeatedly becomes tedious. Comparing results over time is a chore.

Combining the Shodan query with Censys and URLScan yields IP addresses, some new and some repeats. Recalling which ones appeared last month is difficult. The query itself is straightforward, but the repetition is time-consuming.

The hunting logic is sound, but the workflow around it is what slows you down. Manually comparing results creates a bottleneck.

mihari is built for exactly that bottleneck.

This isn't another threat intel dashboard. It's an OSINT framework built on code and rules. You formalize queries, schedule them, store results. It only shows you what's new. The key is comparing against historical data. That's what sets it apart.

As

What mihari Does

mihari runs queries across Shodan, Censys, VirusTotal, URLScan. You can configure it to point at the sources you need.

The tool does more than just collect data. It deduplicates and enriches the data, then stores the results in a database. It compares the results to past runs and flags new hits.

The core value is that it's not a one-time search. Instead, it provides a hunting workflow that you can schedule. This eliminates the need for manual diffs.

Rules drive the process. A rule specifies the query, source, and enrichment. This results in reusable hunting artifacts. You can schedule, version, and share these artifacts.

The approach involves recurring hypotheses. Queries become assets, rather than actions. They become content. This represents a shift in perspective.

Rule Architecture and Query Sources

mihari expresses hunts as YAML rules. This is not just a config convenience, it's what makes the tool fit into code-first security workflows.

A YAML rule specifies sources, such as Shodan, Censys, VirusTotal. It defines what to search for, like TLS certs, domains. It also outlines what to do with results, such as run analyzers, add context.

You write one rule and get structured results, without needing browser tabs. A hunt for new Cobalt Strike infra might query Shodan for TLS certs, Censys for exposure patterns, URLScan or VirusTotal for extra context.

Sources include Shodan, Censys, VirusTotal, URLScan, PassiveTotal, GreyNoise, MISP, BinaryEdge. Your results depend on the sources you configure.

The analyzer pipeline adds context. IPs, domains, URLs get enriched. You get more than just "new IP matches". You get reputation data, context, at discovery.

The YAML model captures hunting logic and enrichment in one definition. This makes it repeatable. That's the value.

Database-Backed New Artifact Detection

This is where mihari adds real value.

The framework stores past results in a backend like SQLite or PostgreSQL. When a rule runs again, mihari compares the current output to its stored history. It identifies new artifacts. The output of a scheduled rule is what's new, not everything matching the query.

Recurring OSINT hunting just got a lot less painful. Manual comparison works for small result sets and infrequent checks. However, it does not work when you're tracking multiple actors, infrastructure, data sources.

With mihari, recurring hunting resembles detection engineering. A rule describes a hypothesis. The system runs it on schedule. The delta matters. OSINT hunting shifts from repetitive research to an operational signal pipeline. Mihari provides Slack, Telegram, MISP.

Analysts get alerts, no need to log in and check.

The push model makes recurring hunting practical.

Threat Hunting Workflow Applications

Mihari Use Cases

C2 infrastructure hunting is a prime target. You know the telltale signs of Cobalt Strike, Metasploit, Havoc. Encode those into rules. Mihari will find new matches.

Rules become watchpoints. No more manual reruns. You get alerted to emerging infrastructure.

Phishing sites are another area. Certificate transparency logs, domain searches can be rules. New phishing kits pop up, Mihari catches them.

Tracking actors works too. They use certain banners, cert subjects, ASN combos. Formalize those patterns in YAML. Future discoveries are automated.

The pattern's simple: write a rule once, run forever. No more hoping analysts recall details. Mihari handles it.

That's it.

mihari vs Watcher and Manual Hunting

Watcher is the broader platform, with a web app, CertStream monitoring, AI-assisted triage, and dashboards. mihari is narrower and more code-focused.

That's not a weakness if your team uses version control, CLI tools, and scheduled jobs. mihari shines here. It treats hunting content like code and manages it like detection content.

Manual hunting requires you to diff yourself a lot. mihari removes that. Analysts write rules and review artifacts, not re-run queries or compare spreadsheets.

Git workflows and YAML content are a good fit.

Verdict

Mihari solves a real OSINT problem: recurring queries are easy to write but hard to run manually. Its database-backed model detects new artifacts. It turns recurring hunts into continuous monitoring.

Mihari is used by CTI analysts and threat hunters. They know their sources and want to codify hypotheses into rules. There is no web UI, a tradeoff for simplicity, scriptability, and code-first workflows.

The quality of Mihari's output depends on the rules and sources used. Good APIs and well-crafted rules produce high-signal alerts. Weak integrations and vague rules produce noise. Mihari replaces manual comparisons if you rerun OSINT searches.