Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Submit
ToolsExploitsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

FeedsContactPrivacy© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
yowie — Finds the SaaS services an organisation subscribes to, using only externally observable data. Built for shadow IT discovery. | Kitploit
Tools/GitHubGitHub/joda32/yowie
Defensive ToolsOSINT (Open Source Intelligence)ReconnaissanceNetwork MappingVulnerability AnalysisDNS & Subdomain EnumerationInformation GatheringPenetration TestingSubdomain EnumerationRed TeamingEmail SecurityDNS Analysis
191 month agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
GitHubjoda32/yowie

yowie

Finds the SaaS services an organisation subscribes to, using only externally observable data. Built for shadow IT discovery.

View Repository
Share

Yowie

     ▄▄▓▓▓▓▓▓▓▓▓▄▄
   ▄▓▓▒▒▒▒▒▒▒▒▒▒▒▓▓▄    Yowie  ·  tracking down the SaaS nobody told you about
  ▓▓▒▒░░░░░░░░░░░▒▒▓▓
  ▓▒░░  ●       ●  ░▒▓  Domain      acme.com.au
  ▓▒░░      ▼      ░▒▓  Candidates  acme, acmecorp
  ▓▓▒░░   ╰───╯   ░▒▓▓
   ▀▓▓▒▒░░░░░░░░░▒▒▓▓▀
     ▀▀▓▓▓▓▓▓▓▓▓▓▓▀▀

Finds the SaaS services an organisation subscribes to, using only externally observable data. Built for shadow IT discovery: the services worth finding are the ones nobody told you about.

Named for the Australian bush cryptid, because you are hunting something everyone insists isn't there.

Yowie in action

574 signatures covering 412 vendors across nine detectors, plus 104 parked awaiting confirmation. Findings are graded and every one carries the record or response that produced it.

Build

go build -o yowie ./cmd/yowie

Go 1.22 or later. The signature packs are embedded in the binary, so the single file is all you need to deploy.

Usage

yowie [flags] <domain> [candidate ...]

The domain is the organisation's root domain. Candidates are the short strings a vendor tenant might be named after — trading names, abbreviations, old brands carried over from acquisitions. Supply as many as you can; each one is another chance to find a tenant. With none given, the first label of the domain is used.

yowie acme.com.au acme acmecorp acmegroup
yowie -format html -o report.html acme.com.au acme
yowie -format json acme.com.au | jq '.findings[] | select(.confidence=="high")'
yowie -only dns,spf,dmarc -compact acme.com.au
yowie -signatures ./signatures -validate

What it looks at

DetectorSignal
dnsTXT verification tokens, CNAME, MX and NS records
vanityVendor-hosted tenants named after the organisation (acme.zendesk.com)
httpApplication-layer fingerprints for services with no DNS footprint
spfThe full SPF include graph, following nested includes and redirects
dmarcDMARC aggregate/forensic report destinations
bimiBIMI logo and Verified Mark Certificate hosting
mta-stsMTA-STS policy contents
tenantMicrosoft tenant ID, federated identity provider, and sibling domains
ctSubdomains from Certificate Transparency logs, resolved and attributed

Select with -only or -skip, e.g. -skip ct,http for a fast DNS-only pass.

The last two deserve a note, because they find things a signature list cannot.

tenant asks Microsoft's unauthenticated endpoints who the domain belongs to. Autodiscover's federation information returns every domain attached to the same tenant, which routinely surfaces business units, acquisitions and abandoned brands. Each one is another domain worth scanning.

ct inverts the discovery model. Every other check asks "does this organisation use vendor X?" against a fixed list, so it can only find vendors somebody already wrote a signature for. CT asks "what has this organisation actually pointed its subdomains at?" A team that signs up for a product and wires up support.acme.com gets a certificate issued, and that certificate is public and permanent. Targets matching no signature are reported as leads, which is how you find the thing you did not know to look for.

Reading the output

Findings are graded, and the grade is the point:

  • Confirmed — a vendor-issued, domain-scoped indicator. Treat as in use.
  • Probable — strong, but could also be shared infrastructure or a namespace claimed by someone else. acme.blogspot.com might not be your acme.
  • Leads — weak or unattributed, including senders and hosts matching no known vendor. The noisiest bucket and the most likely to contain something nobody told you about.

Two independent detectors agreeing on a vendor promotes a Probable finding to Confirmed. Every finding carries the exact record or response that triggered it, so a report is defensible without re-running the tool.

The promotion has one exception, and it is the difference between "this tenant exists" and "this tenant is yours" — see the namespace note under accuracy.

-no-unknown drops the unattributed leads if you want signal only.

Output formats

-format cli (default), json, jsonl, csv, html. Use -o to write to a file. The HTML report is self-contained — no external assets — so it survives being emailed or dropped on a share drive.

Progress goes to stderr and results to stdout, so yowie -format json acme.com > out.json still shows a live progress line.

Signature packs

Signatures live in signatures/*.yaml. The binary embeds them; -signatures <dir> or YOWIE_SIGNATURES=<dir> loads from disk instead, which is how you iterate without rebuilding.

version: 1
pack: dns-txt
description: "Domain-ownership verification tokens published as TXT records."
defaults:
  confidence: high

signatures:
  - id: txt-1password
    vendor: "1Password"
    category: "Identity & Secrets"
    type: txt
    query: "{domain}"
    match:
      contains: "1password-site-verification"

{domain} expands to the root domain, {candidate} to each candidate string. A signature referencing {candidate} is evaluated once per candidate.

TypeMatchesNotes
txt, cname, mx, nsmatch.contains against the records of queryCase-insensitive
vanity_a, vanity_cnameBaseline comparison; no match blockquery must contain {candidate}
httpmatch.present, match.absent, or match.status aloneSee status handling below
spf_includematch.contains against the resolved SPF include graph
dmarc_ruamatch.contains against DMARC report destinations
cname_targetquery is a bare hosting suffixApplied to hosts discovered by ct; * matches one label

disabled: true parks a signature without losing the research behind it. notes: carries analyst guidance through to the report.

Run yowie -validate after editing. Validation is strict — an unknown key is an error, not a silent no-op — and the packs are also checked by go test, so a typo cannot quietly cost you coverage in every future scan.

The packs

PackContents
dns-txt, dns-cname, dns-mxVerification tokens and delegated hostnames. Live.
email-spf, email-dmarcSenders and DMARC processors. Live.
vanity-tenants, http-endpointsTenant hostnames and app fingerprints. Live.
cname-targetsHosting suffixes for CT-discovered subdomains. Live.
ai-servicesAI and LLM platforms. Parked.
file-transferManaged file transfer — MOVEit, GoAnywhere, Egnyte. Parked.
finance-procurementFinance, expense, payroll, procurement. Parked.
security-grcSecurity tooling and compliance automation. Parked.
graveyardUnverified entries, and platforms whose operator could not be identified. Parked.

Parked signatures and how to promote one

Five packs ship entirely disabled. They are structurally complete and pass validation, but their match criteria have never been confirmed against a live tenant, so they are not evaluated during a scan.

This is deliberate. A signature with a wrong contains value never fires and never errors — it just makes a vendor look covered when it is not. Shipping those disabled keeps the research in the repo without inflating the numbers.

Download Tool