From an apex domain to a routed alert, in detail.
The platform-overview page sketches the loop in four steps. This page walks the same loop in detail — what runs where, what gets stored, what triggers what, and why one correlated exposure model is the spine that ties it all together.
The spine
One correlated exposure model, every capability writing into it
Most exposure stacks are several products in a bundle. Each keeps its own list of what it found, so the same host appears in three of them under three names and nothing reconciles. The work of correlating lands on whoever is on triage that morning.
ShadowMap runs the other way round. There is one typed model of your domains, hosts, services, applications, employees and vendors, and every capability reads from and writes into it. A credential surfaced from a stealer log is attached to the identity it belongs to and the systems that identity opens. A secret found in a public repository is attached to the service it authenticates against. A look-alike domain is attached to the brand it imitates and separated from the partner properties that legitimately carry your name.
That is why the loop below is a loop rather than four products in sequence: what the validate step proves changes how the next discovery pass is prioritised, because both are operating on the same objects.
What the model holds
- Assets
- Domains, subdomains, hosts, ports, services, web applications, APIs, mobile apps, cloud resources and certificates.
- Identities
- Employee and customer identities seen in breach and stealer-log material, tied to the systems they authenticate against.
- Artefacts
- Leaked code, exposed secrets, files, buckets and paste-site material, preserved as evidence rather than as a link that may be gone tomorrow.
- Actors and context
- Threat-actor profiles, campaigns and indicators, filtered to the technologies and sectors actually present in your estate.
- Ownership and state
- Who owns each asset, what has been triaged, what is in flight, what was closed and on what evidence.
The loop
Discover, enrich, validate, act
Running continuously, not as a quarterly engagement. The steps under each beat are the mechanics from the module pages themselves.
Discover
Everything starts from an apex domain. Nothing is installed, no credentials are handed over, and nothing is asked of the asset owner — if it is reachable from the public internet, it is in scope.
Discovery fans out from the domains you name into the estate you did not: subsidiaries with their own registrars, acquisitions still carrying old branding, marketing properties a business unit spun up without telling anyone. Attribution is the hard part and the part that decides whether the rest is useful — a hostname that merely resembles yours is noise, so every asset carries the evidence that ties it back to you.
What runs, and in which module
- 1 Seed. Start from your apex domain(s); ShadowMap fans out via passive + active discovery sources.
- 2 Map. Build a typed inventory: domains → hosts → services → web apps → APIs → mobile apps → cloud resources.
- 3 Score. Each asset + finding scored by severity, exploit availability, and your business-context criticality.
- 4 Notify. New + changed exposures route to Slack, Jira, ServiceNow, Splunk, or whatever ticketing you already live in.
- 1 Seed. Use your attributed inventory from Attack Surface + employee email patterns + brand keywords as the search seed.
- 2 Crawl. Continuous crawling of public-repo APIs, paste sites, search indexes, and cloud-bucket directories.
- 3 Match. Pattern + entropy detection for secrets; content matching for branded data; ownership attribution from commit metadata.
- 4 Triage. High-severity → page; medium → ticket; low → digest. Auto-revocation playbooks for known cloud-creds providers.
- 1 Watch. Continuous ingestion from domain registration feeds, social-platform APIs, app stores, and phishing-kit feeds.
- 2 Match. String-distance + image-similarity + content fingerprinting against your registered brand assets.
- 3 Confirm. Active probes against suspects to confirm intent (live phishing kit? credential harvester? content scraping?).
- 4 Take down. Orchestrated takedown via registrar / host / platform with SLA tracking and evidence capture.
Enrich
A discovered asset on its own is a row in a table. Enrichment is what turns it into something with a name, an owner and a reason to care.
Each finding is joined against the rest of the platform: the credentials circulating for that domain, the code and secrets published against it, the actors currently targeting that sector, the vendor that operates it. This is the step that makes one leaked credential a single alert, not one from every capability that saw it, because they all write into the same correlated exposure model rather than keeping separate lists.
What runs, and in which module
- 1 Ingest. Continuous ingestion from telegram dump channels, dedicated-leak forums, ransomware sites, and stealer-log feeds.
- 2 Index. Normalised + searchable index keyed on email, domain, subdomain, and application URL.
- 3 Match. Your attributed inventory + employee identifiers used as standing queries. New matches alerted in near-real-time.
- 4 Respond. Auto-ticket for password rotation; session revocation guidance; scope-of-impact reporting for breach notification decisions.
- 1 Collect. OSINT, dark-web sources, vendor feeds, government CERTs, and proprietary research aggregated into a single corpus.
- 2 Curate. Analyst team validates, attributes, and scores. Confidence levels published; sources cited.
- 3 Match. Your sector + geography + stack used as standing query against new and updated content.
- 4 Distribute. Briefings to execs; tactical IoCs to SIEM; campaign updates as Slack/email digests; full corpus searchable.
- 1 Aggregate. 97 curated source feeds pulled continuously, normalised, and deduplicated against a 90-day rolling window.
- 2 Score. Each IoC scored by source confidence × match against your attributed inventory × threat-actor relevance to your sector.
- 3 Filter. Only the high-relevance IoCs cross into your environment. The rest stay searchable but don't flood your SIEM.
- 4 Push. Native integrations to your SIEM, SOAR, and EDR — with bidirectional confirmation when the IoC matches.
Validate
Discovery without validation is a list of maybes. Validation answers the only question that changes what a team does on Monday: can this actually be used?
Where it is safe and authorised, CART tests whether a discovered exposure is genuinely usable — whether the secret is live, whether the credential still authenticates, what it opens and what blast radius that creates. Checks are non-destructive and run inside the scope agreed at onboarding. Recovered credentials are reported so you can revoke them, never used to demonstrate access.
What runs, and in which module
- 1 Prioritise. Pull high-relevance exposures from Attack Surface, Data Exposure, and Dark Web. Score by exploitability + business impact.
- 2 Bound. Targeting is limited to inventory already discovered and attributed to you. Discovery and enumeration always precede any active validation.
- 3 Probe. Active validation against the prioritised set. Safe-by-default; more aggressive modes only against explicitly agreed scopes.
- 4 Evidence. Confirmed findings carry live status, affected services, blast radius, request and response evidence, probe history and a workflow state — not a banner or a scanner signature.
- 1 Onboard. Add vendors via domain, business name, or DUNS. A typed inventory + dark-web identifiers built within 24 hours.
- 2 Monitor. The same continuous monitoring you run on your own estate — every capability, applied to each vendor in the portfolio.
- 3 Score. Per-vendor score updated daily; portfolio view ranks vendors by composite risk and trend direction.
- 4 Alert. Material drift, new ransomware-leak appearances, or major credential exposures route to procurement / vendor-management workflows.
Act
A finding that stays in our console has not helped anyone. The last beat is getting it into the system your team already works in, with the evidence attached.
Findings route to the queue you already run — 86+ native integrations across SIEM, SOAR, EDR, ticketing, IdP, cloud and secrets management — carrying provenance, ownership and disposition. Where the answer is a takedown rather than a ticket, it is dispatched under contractual SLA. Every state change is recorded, which is what makes the trail usable as audit evidence rather than as a screenshot.
What runs, and in which module
- 1 Ingest. Every capability pushes findings + state into one event stream with a normalised schema.
- 2 Correlate. Findings linked by shared assets / actors / IoCs into incidents — one workflow per incident, not per finding.
- 3 Route. Incidents route by team, severity, and SLA — into Slack, Jira, ServiceNow, or whatever your ops team uses.
- 4 Audit. Every action logged tamper-evidently. Evidence packs exportable for compliance frameworks, board readouts, and audits.
- 1 Watch. Continuous ingestion from domain registration feeds, social-platform APIs, app stores, and phishing-kit feeds.
- 2 Match. String-distance + image-similarity + content fingerprinting against your registered brand assets.
- 3 Confirm. Active probes against suspects to confirm intent (live phishing kit? credential harvester? content scraping?).
- 4 Take down. Orchestrated takedown via registrar / host / platform with SLA tracking and evidence capture.
Cadence and boundaries
What runs when, and what we will not do
Rediscovery every 24 hours
The estate is re-enumerated daily and diffed against yesterday. A new subdomain, a newly opened port, a rotated certificate or a service that changed banner is surfaced as a change, not buried in a full re-list.
Continuous collection
Dark-web, breach and paste-site collection runs continuously rather than on the scan cycle, because a credential appearing at 02:00 should not wait for the next pass.
Outside-in only
No agent, no appliance, no credentials, no cooperation required from the asset owner. Everything is reachable from the public internet by definition, which is the point — it is what an attacker sees.
Non-destructive by default
Validation confirms whether a path is reachable and usable. It does not exploit for impact, does not pivot, and runs only inside the scope agreed at onboarding.
Credentials are reported, never used
Where a recovered credential is found to still authenticate, that fact is reported so you can revoke it. It is not used to reach further into the estate.
A human gate before dispatch
Takedowns are requested against third parties in your name, so they are reviewed before they are sent rather than fired automatically on a match.
For an engineering deep-dive beyond this — data sources, the exposure-model schema, scoring inputs, the validation pipeline and integration topology — the technical-architecture briefing is walked through live with your team against your own estate rather than handed over as a PDF. Mention it when you book the demo. Each capability page also covers its own mechanics in full.
Want the architecture deep-dive?
Mention 'technical architecture briefing' in the demo request and we'll bring our principal engineer. Bring your own architects; we'll bring the diagrams.