mihari is a Ruby query aggregator that feds searches across services like Shodan, Censys, and VirusTotal into persistent, rule-driven monitoring for authorized threat hunting teams.
| Tool | ninoseki/mihari — a query aggregator for OSINT-based threat hunting that runs multi-service searches from a single rule and persists findings |
| Category | OSINT threat intelligence and attack surface monitoring |
| Primary Use | Continuously monitoring services such as Shodan, Censys, crt.sh, and VirusTotal Intelligence for artifacts matching hunting rules, with results stored in a database for diffing and triage |
| Safe Use | Designed for authorized threat hunting, defensive monitoring of your own attack surface, and threat intelligence research on consented or public data sources only |
| Telemetry Note | All queries are visible to the upstream services (Shodan, Censys, VirusTotal, etc.) and consume their API quotas; findings and rule execution history persist in mihari's local database, making it a defensible, auditable research trail |
mihari, hosted at ninoseki/mihari, is a Ruby gem that addresses one of the most persistent annoyances in OSINT-driven threat hunting: the same artifact has to be checked against half a dozen different services, each with its own query syntax, authentication model, and export format. mihari collapses that workflow into a single rule that fans out across multiple sources and persists results in a database. With 943 stars, an MIT license, and active CI pipelines for both Ruby and Node.js components, it sits comfortably in the maintained, production-usable tier of open-source threat intelligence tooling. The project is distributed as a gem on RubyGems, so installation follows the standard gem install mihari pattern rather than any bespoke bootstrap.
The core abstraction, per the README, is the rule. A rule encapsulates multiple searches across multiple services, meaning you can express something like "look for this certificate fingerprint on Shodan and this related domain on SecurityTrails" as one declarative unit. When the rule runs, mihari queries each configured source, collects the results, and — critically — persists them. This persistence is what distinguishes it from ad-hoc CLI querying: on subsequent runs, the tool can identify what is new versus what was already seen, which is exactly the property continuous monitoring and alerting depend on. For defenders tracking their own organization's footprint, this diffing behavior turns one-shot lookups into an evolving dataset.
The breadth of default integrations is the tool's headline feature. Out of the box, mihari supports Censys, CIRCL passive DNS and passive SSL, crt.sh, dnstwister, Fofa, GreyNoise, HunterHow, Onyphe, OTX, PassiveTotal, Pulsedive, SecurityTrails, Shodan, urlscan.io, Validin, VirusTotal, VirusTotal Intelligence, and ZoomEye. That list spans three distinct categories of OSINT data: certificate transparency via crt.sh, passive DNS via CIRCL and SecurityTrails, and internet-wide scanning via Shodan, Censys, Fofa, HunterHow, and ZoomEye. A rule can therefore correlate an artifact across passive DNS records, newly issued certificates, and live service banners in one execution.
From an architecture standpoint, the Ruby CI badge combined with a separate Node.js CI badge hints at a polyglot build. The Node.js component is plausibly a web frontend or dashboard layer bundled with the gem — common in this class of tool, where the backend handles query orchestration and persistence while a JavaScript layer renders the UI over findings. The README does not elaborate, but the dual-pipeline CI, along with Coveralls coverage tracking and a CodeFactor quality badge, signals a project that treats itself as software first and a script collection second. The master branch is the default development target, and the documentation site at the project's GitHub Pages domain carries the operational detail the README intentionally omits.
For an authorized workflow, the natural placement of mihari is in a threat intelligence or attack surface monitoring pipeline. A blue team with legitimate ownership of a domain portfolio can encode rules that watch for newly issued subdomain certificates via crt.sh, typosquat registrations via dnstwister, and exposed services on owned IP ranges via Shodan or Censys. Because results persist locally, the team builds a longitudinal record — when an artifact first appeared, and through which source — which is directly usable for incident triage and reporting. The same mechanics serve threat researchers tracking adversary infrastructure, since rules can be written around known indicators and re-run on a schedule to catch new infrastructure as it is registered or brought online.
The reference to JSAC2024 workshop materials is worth noting for anyone evaluating the tool seriously. The existence of a structured workshop with exercises suggests the author has invested in teaching the tool's mental model, not just shipping code. That is a meaningful signal for adoption decisions: a query aggregator is only as good as the rule-writing ergonomics, and a workshop implies those ergonomics are stable enough to be taught. Prospective users should treat the workshop materials and the official documentation site as the primary onboarding path, since the README is deliberately a concise overview rather than a manual.
Operationally, there are practical considerations any deploying team should account for. Every integration in the list requires its own credentials or API keys for the commercial and freemium services (Shodan, Censys, VirusTotal, GreyNoise, and so on), and query quotas are consumed on each rule run. Teams running frequent scheduled rules against rate-limited tiers will want to model their query volume against their subscription limits before committing to aggressive polling intervals. The free sources — crt.sh and CIRCL passive DNS among them — carry no keying burden but can be the slowest to respond, which matters when a rule's total runtime is bounded by its slowest source.
From a defensive telemetry perspective, mihari is a well-behaved citizen. It does not touch target infrastructure directly; every query goes to third-party data providers, so there is no scan traffic landing on any victim network. Its footprint is entirely local: a database of findings and rule execution history, plus API access logs at each provider showing the queries issued. That makes it a good fit for environments where active scanning of owned assets is politically or contractually off the table — you get continuous visibility into exposure through other parties' scan data instead of your own packets.
Comparing it to adjacent tooling helps place it. There are dedicated clients for each source — shodan CLI, censys search library, vt tooling — but they are per-source silos. There are also commercial threat intelligence platforms that do multi-source correlation, but they are expensive and closed. mihari occupies the middle ground: open source, MIT-licensed, self-hosted, and opinionated about the rule-plus-persistence model rather than trying to be a full TIP with case management and enrichment graphs. Teams that need those heavier features will outgrow it; teams that need scheduled cross-source queries with new-artifact detection will find it does precisely that.
In summary, mihari is a focused, maintained, and credibly engineered answer to multi-source OSINT querying for authorized threat hunting. Its value proposition is the aggregation layer and the persistent rule model layered over services most intelligence teams already pay for, and its documentation and workshop ecosystem lower the barrier to adoption. For defenders and researchers operating within their authorization boundaries, it is a solid building block for continuous monitoring pipelines — install it with gem install mihari, read the official documentation site, and start with a single-source rule before composing the multi-service queries where it earns its keep.
ninoseki/mihari.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.