Stage 01
Collection
Reach the places findings actually appear.
- Runs
- continuous
- Emits
- raw_observation
Continuous collection, not a quarterly scan
Platform
From raw external signal to a ticket somebody closes
Five stages: collection, attribution, correlation, prioritisation, response. Every vendor in this market claims all five. The one that decides whether the product is useful or exhausting is attribution — so this page spends real time on it, and on what happens when confidence is low.
- 01One input
- A domain name. Every asset, brand string and supplier link after that is discovered rather than declared.
- 02No agent
- Nothing is deployed inside your network. Collection runs from outside the perimeter, the way an attacker sees you.
- 03Scored, not sorted
- Every finding shows the inputs to its score and the weight each one carried. You can disagree with the maths.
- 04Closed, not counted
- A finding is finished when someone with the access to fix it has recorded what they did — including accepting the risk.
Architecture
One pipeline, five stages
Dark web monitoring, attack surface management and brand protection are not three tools sharing a login. They collect different material and then run through the same machinery, which is why a leaked credential and an exposed portal can arrive as one finding instead of two alerts in two consoles.
- Stage 02
Attribution
Decide whether it is actually yours.
- Runs
- on ingest
- Emits
- attributed_asset
- Stage 03
Correlation
Join the pieces into one finding.
- Runs
- on ingest
- Emits
- finding
- Stage 04
Prioritisation
Rank by what an attacker can actually do.
- Runs
- on change
- Emits
- scored_finding
- Stage 05
Response
Get it to the person who can close it.
- Runs
- on match
- Emits
- ticket · takedown
Stage by stage
Stage 01
Collection
Reach the places findings actually appear.
raw_observationCrawlers, resident accounts, feed subscriptions and vendor APIs pull raw material from the open web, Tor and I2P services, closed chat channels, code hosts, paste sites, certificate transparency logs, DNS and registration feeds, app stores and social platforms. Nothing is judged at this stage. A stealer log is stored as a stealer log, with the source, the collection method and the time it was seen attached to it.
The hard part
Sources rot. Forums move, marketplaces exit, channels re-key and gate access behind vouching. Collection has to keep working through that without a human noticing three weeks late that a feed went quiet. Provenance is recorded on every observation, because a finding you cannot trace back to where it came from is not evidence — it is an opinion.
Stage 02
Attribution
Decide whether it is actually yours.
attributed_assetEach observation is tested against your estate: registered domains, IP allocations and ASNs, certificate identities, mail domains, brand and product strings, named executives, plus the subsidiaries and suppliers you ask us to include. Matching is deliberately fuzzy, because homoglyphs, abbreviations, legacy trading names and post-acquisition brands all have to hit.
The hard part
This is the stage that decides whether the product is useful or exhausting. Attribution produces a confidence score, not a yes or no, and anything under the threshold goes to a review queue instead of straight into your alerts.
Stage 03
Correlation
Join the pieces into one finding.
findingObservations that describe the same underlying problem collapse into a single finding and pick up context. A credential pair in a stealer log, the same address in an older combolist, and a reachable remote-access portal on your estate are one story — not three tickets for three different people. A finding carries a timeline, the assets it touches, and the module that saw it first.
The hard part
There is no shared identifier across these sources. The same leak turns up five times, in three formats, under two names, weeks apart. Deduplication is therefore heuristic, so every finding keeps the individual observations that fed it and you can open them and disagree.
Stage 04
Prioritisation
Rank by what an attacker can actually do.
scored_findingScoring weighs exploitability against your business context. Is the service reachable right now, how likely is the leaked credential to still work given its source and its age, is the lookalike domain resolving and serving a login page — and on the other side, is this asset in production, does it hold customer data, is the account privileged. CVSS, where a CVE exists at all, is one input among several rather than the answer.
The hard part
Every scoring model is opinionated, and an opinion your team cannot inspect is one they will learn to ignore. So each score shows its inputs and their weights, and you can change the weights for your own estate.
Stage 05
Response
Get it to the person who can close it.
ticket · takedownAlerts route by module, severity and asset owner. Findings arrive in your ticket system with the evidence already attached, and the status syncs back so closing the ticket closes the finding. Impersonation findings can be handed to a managed takedown. Everything on the platform is available over the API, so this stage does not have to end in our interface.
The hard part
Most external intelligence dies in a shared inbox. A finding is only finished when somebody with the access to fix it has seen it and recorded what they did — including deciding to accept the risk, which is a legitimate outcome we track rather than nag about.
Stage 01 · Collection
Where the material comes from
Coverage is the whole argument at this stage. A platform that only reads the open web will tell you about a breach when a journalist does. These are the source families we collect from, and what each one is actually good for.
- open-web
Open web and search surfaces
Indexed and cached pages, exposed directory listings, public object-storage indexes, breach-aggregation sites and data-broker catalogues.
Finds
Documents that were never meant to be public, and exposure that predates whoever runs security today.
Cadence
daily re-crawl
- tor-i2p
Dark web marketplaces and forums
Tor hidden services and I2P sites: criminal marketplaces, initial-access broker boards, carding and fraud forums, ransomware leak sites and their mirrors.
Finds
Your data listed for sale, your name on a leak site, or a broker quietly advertising a route into your network.
Cadence
continuous, re-crawl on change
- closed-channels
Closed and invite-only channels
Telegram and Discord channels, IRC, gated forum sections and the distribution groups where infostealer logs are traded. Access is granted rather than crawled.
Finds
Stealer logs while they are still being traded privately, and coordination that happens before an attack rather than after it.
Cadence
continuous
- code-paste
Code hosts and paste sites
Public repositories and gists, CI logs, package registries, paste sites and their clones, plus the contents of published mobile app bundles.
Finds
Hardcoded keys, tokens and connection strings; internal hostnames; source that reached a personal account instead of yours.
Cadence
continuous
- ct-logs
Certificate transparency
Every publicly trusted certificate issued anywhere is written to a public log. We read those logs as they are appended.
Finds
Subdomains that never made it into your DNS inventory, and a certificate for a lookalike domain as the log records it — which is generally before the phishing page it was bought for goes live.
Cadence
streaming
- dns-rdap
DNS and registration feeds
Zone data, passive DNS, newly registered domain feeds, WHOIS and RDAP records, IP allocation and BGP announcements, reverse DNS.
Finds
Typosquats on the day they are registered, dangling CNAMEs pointing at deprovisioned cloud resources, and who actually holds that netblock.
Cadence
hourly batches
- app-stores
App stores and distribution
The official mobile stores plus third-party and regional APK mirrors and download aggregators.
Finds
Repackaged copies of your app, fakes using your name and identity, and abandoned builds of your own that are still installable.
Cadence
daily
- social
Social and messaging platforms
Public profiles, pages, groups, advertising libraries and marketplace listings across the major platforms.
Finds
Accounts impersonating your brand or your named executives, paid ads pointing at phishing pages, and counterfeit goods using your marks.
Cadence
daily
On source counts
Vendors like to advertise the number of sources they monitor. It is a poor measure: a hundred dead forums count for less than one live broker board, and the figure only ever goes up. We would rather show you the current source list during an evaluation, under NDA, and tell you where the gaps are. Ask about the sources that matter for your sector and we will say plainly whether we cover them yet.
Stage 02 · Attribution
Deciding what is actually yours
Discovery is easy. Attribution is the hard problem. The internet is full of things that mention your brand, resolve near your addresses or sit on infrastructure you happen to share — and almost none of it is yours.
The signals we weigh
No single signal is trusted on its own. Each one contributes a weight, positive or negative, and the weights are visible on the finding.
- seedWhat you give us
- One domain is the only required input. Brands, subsidiaries, known IP ranges, executive names and a supplier list are optional and make the first pass sharper.
- rdapRegistration records
- Registrant organisation strings, registrant and abuse contact domains, and RDAP entity handles, compared across everything already confirmed as yours.
- ctCertificate identity
- A certificate whose subject alternative names cover one confirmed host and one unknown host links the two. Issuer and account patterns add weight.
- dnsDNS topology
- Shared name servers, shared mail exchangers, SPF and DMARC records that reference your infrastructure, and reverse DNS naming conventions.
- netNetwork ownership
- ASN and netblock registration, and whether an address is announced by you or by a hosting provider with thousands of unrelated tenants.
- webResponse fingerprints
- Shared analytics and tag identifiers, favicon hashes, header ordering, and identical error or maintenance pages served from different hosts.
- brandBrand strings
- Trading names, product names and trademark records, plus their transliterations, abbreviations and homoglyph forms — the ones a squatter would reach for.
- humanYour confirmation
- Anything ambiguous goes to a person. Confirmations and rejections are remembered, so the same asset is not queued at you a second time.
attribution · review queueIllustrative
- asset
- vpn-emea.acme.example
- first seen
- 2026-09-04 04:12 UTC · ct-logs
- confidence
- 0.84
Evidence
- +0.34ctCertificate SAN also covers a confirmed domain
- +0.26rdapRegistrant organisation string matches exactly
- +0.20dnsName servers shared with 41 confirmed hosts
- +0.08webMaintenance page byte-identical to a confirmed host
- −0.04netNetblock announced by a shared hosting provider
0.84 < 0.90 threshold → held for confirmation, not alerted
Claiming what is not yours
An asset added in error becomes work. Someone spends a morning chasing a host they cannot reach, at a company they have never heard of. Do that twice and the team stops believing the inventory — at which point the real findings stop being read too.
Missing what is yours
Quieter and worse. The staging box a contractor registered on a personal card in 2019 is precisely what you bought the product to find. Under-claiming looks tidy in a demo and fails you in an incident, so borderline assets are surfaced for review rather than dropped.
Ownership and responsibility are scored separately
A CDN edge address is not your asset, but the hostname pointed at it is. A tenant on a vendor’s domain is not your asset, but its exposure is still your incident. Treating those as the same thing is how inventories become either wrong or useless, so each finding records who owns the asset and who has to act on it. Those are often different organisations, and one of them is usually a supplier you asked us to watch.
Stage 04 · Prioritisation
Ranked by exploitability, not by CVSS
A 9.8 on an isolated test box holding nothing is not your Tuesday morning. A 6.5 on the payroll portal, with a leaked credential we have no record of you rotating, is. CVSS describes a vulnerability; it does not describe your exposure — so it is an input to the score rather than the score itself.
What goes into the score
- exploitabilityCan it be used, right now
- Whether exploit code is public, whether the flaw is known to be exploited in the wild, whether the service answers from the internet today, how likely a leaked credential is to still work given its source, its age and whether you have recorded a reset, and whether a lookalike domain is resolving and serving a login form rather than sitting parked.
- asset-contextWhat the asset is
- Production or not, the data classification you gave it, the business unit it belongs to, and whether it appears in your own inventory at all. Unknown assets score higher on purpose: nobody patches what nobody knows about.
- blast-radiusWhat it reaches
- Whether the identity is privileged, whether single sign-on sits behind it, how many downstream systems trust it, and whether compromise of this one thing hands over the rest.
- corroborationHow sure we are
- How recently it was observed, how many independent sources saw it, and whether an authorised active check confirmed the exposure instead of inferring it. Thin evidence lowers the score rather than being quietly rounded up.
Overrides
The weighting is a default, not a verdict. You can change the weights per business unit, mark an asset as low consequence, and accept a risk with a reason attached. Accepted risk is a recorded outcome, not an ignored alert — it stops appearing in the queue and reappears if the exposure changes.
finding · DWM-2041Illustrative
dark-web-monitoring · credential exposure
Session cookie for sso.acme.example offered in an infostealer log
Critical9.1
Score breakdown
- Exploitability8.8
Session token issued 6 hours ago; token type carries no MFA re-prompt on reuse
- Asset context9.5
Identity provider — gates staff access to most internal apps
- Blast radius9.4
Subject holds administrative rights on three connected apps
- Corroboration7.0
Single source, first seen six hours ago, not yet re-observed
Weighted score9.1
Base CVSSn/a
No CVE exists for this finding. It is a credential exposure, not a software flaw — which is exactly the class of problem a CVSS-only queue ranks at zero.
Severity bands and default routing
Four bands, because five is where people start arguing about the difference between the middle two. Each band has a default destination you can change.
| Band | What it means | Default routing |
|---|---|---|
| Critical | Directly usable now, against something that matters. A fresh credential with no recorded reset, a live phishing page, an exposed administrative interface. | Immediate alert and ticket, with escalation if untouched |
| High | Usable with modest effort, or a serious exposure whose exploitability we cannot confirm without permission to check actively. | Immediate alert and ticket |
| Medium | Real exposure with no direct path yet. A registered typosquat not yet resolving, an aged credential, a verbose error page leaking internals. | Daily digest and ticket |
| Informational | Inventory and change facts you should know about but need not act on. A new subdomain, a new certificate, a change of registrant. | Weekly digest, queryable over the API |
Stage 05 · Response
Response, workflow and integrations
External intelligence usually dies in a shared inbox. The last stage exists to stop that: route the finding to whoever can close it, in the tool they already have open, with the evidence attached.
Alerting that routes
Alerts go to the team that owns the asset, not to one shared mailbox that everybody has muted.
- Rules match on module, severity, asset tag, business unit and owner
- Immediate for critical and high, digest for the rest, per destination
- Quiet hours with an override for critical findings
- Re-alert on change rather than re-alert on a timer
Findings become tickets
A finding arrives in your tracker with the evidence already attached, so nobody has to copy a URL into a description field at 23:00.
- Evidence, timeline and score breakdown written into the ticket body
- Status syncs back — closing the ticket closes the finding
- Recurrence reopens the original rather than filing a duplicate
- Project, issue type and priority mapped per severity band
Managed takedowns
For impersonation findings, we file and chase the request. You approve; we do the paperwork and the follow-up.
- Evidence pack captured at first sight, before the page is pulled
- Filed with the registrar, host, CDN, app store or platform abuse team
- Chased to closure, with every exchange recorded against the case
- You see the case status without asking anyone for an update
API and export
Nothing on the platform is only available in our interface. If your workflow lives elsewhere, take the data there.
- REST API over every finding, asset, score component and takedown case
- Outbound webhooks on create, change of score and change of status
- Signed CSV and JSON export, on demand or on a schedule
- Scoped API tokens, per environment, revocable and audited
routing rule · fraud-opsIllustrative
WHENmodule = brand-protection
ANDseverity >= high
ANDasset.tag contains "consumer"
THENnotify #fraud-ops — immediate
open ticket in FRAUD, map severity → priority
queue managed takedown, hold for approval
ELSEadd to the 08:00 digest for security-ops@
Where a takedown actually goes
A takedown is an administrative process, not a technical one. It succeeds or fails on evidence, jurisdiction and persistence, and it usually needs more than one recipient. These are the parties we file with, in the order that tends to work.
- Domain registrars and registries
- Hosting providers and CDNs
- DNS and nameserver operators
- Certificate authorities, for revocation
- Mobile app stores and APK mirrors
- Social platform trust and safety teams
- Browser and mail blocklist operators
- National CERTs, where jurisdiction requires it
We will tell you when a takedown is unlikely to land — some registrars in some jurisdictions simply do not respond — and what the alternatives are, rather than filing forever and reporting it as progress.
Integration targets
Findings should arrive where your team already works. Connectors ship one at a time, so ask which are live for your stack before you sign anything — we would rather tell you a connector is still on the roadmap than let you discover it during onboarding.
- ticketing
Ticketing and work tracking
- Jira
- Jira Service Management
- ServiceNow
- Linear
- Asana
- chat
Chat
- Slack
- Microsoft Teams
- siem
SIEM and log platforms
- Splunk
- Microsoft Sentinel
- Elastic Security
- Google SecOps
- soar
Automation and playbooks
- Webhook-driven SOAR
- Tines
- Torq
- Cortex XSOAR
- identity
Identity
- Okta
- Microsoft Entra ID
- Google Workspace
- SAML 2.0
- OIDC
- cloud
Cloud, read-only for asset context
- AWS
- Microsoft Azure
- Google Cloud
- Cloudflare
- data-out
Data out
- REST API
- Outbound webhooks
- CSV and JSON export
- Scheduled object-storage drop
- mail
Mail
- Distribution lists
- Shared inboxes
- PGP on request
If it is not on the list
The API and outbound webhooks cover everything a named connector does, so an unsupported tool is an afternoon of glue rather than a blocker. Tell us what you use during an evaluation — a connector that two or three organisations need tends to get built.
Deployment
How it runs, and how your data is handled
The platform sits outside your perimeter and looks in, the same way an attacker does. That keeps deployment simple, and it puts a hard boundary around what we can touch.
Nothing to install
There is no agent, no appliance and no collector inside your network. Everything runs from our infrastructure against material that is already externally visible. Onboarding is a list of domains and a set of logins, which is why a first pass can start the same day rather than after a change window.
Read-only by default
Default operation is passive: public records, third-party feeds, certificate logs, DNS and the open web. We resolve your names the way any client on the internet does. We do not send traffic at your hosts to see what happens, and we do not test credentials we recover.
Active checks need written permission
When you want an exposure confirmed rather than inferred, active verification is available. Scope, source addresses, rate limits and a time window are agreed in writing first. Non-intrusive checks only — no exploitation, no credential replay, no load. Widening the scope needs a new authorisation, not a phone call.
Encrypted in transit and at rest
Data is encrypted in transit and at rest. Recovered credentials are treated as the sensitive material they are: stored encrypted, revealed only to the roles you nominate, and every reveal written to the audit log so you can see who looked and when.
Single sign-on and role-based access
SAML 2.0 and OIDC single sign-on are available, with roles scoped by module and by business unit so a fraud team sees brand findings and not the credential vault. Viewer, analyst and administrator are separate roles. Every view and change is recorded.
Retention you set, deletion you can prove
Retention windows are set per tenant rather than by us. Findings, evidence and recovered credentials can be exported and then purged on request, and the purge is itself recorded so you have something to show an auditor.
What we are not claiming
No badges we have not earned
0DaySecure is a young company and the platform is still in development. Everything above describes a practice we operate, not an audited certification we hold, and we are not going to print a compliance logo on a marketing page to imply otherwise. If your procurement process needs a security review, start it early: we will walk your team through the controls we run today, say plainly which ones are still in progress, and put the answers in writing.
The same goes for hosting. If your policy requires a particular region or data residency arrangement, raise it in the first conversation and we will tell you what we can support rather than what you would like to hear.
Run it against your own domain.
Thirty minutes, your real estate, and a walk through the findings with the score breakdowns open. You keep what we find either way.
- One domain is all we need to start
- Passive collection only, unless you authorise more
- Findings are yours to keep