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.
The loop below is a loop for that reason: 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, because the source link 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 it 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 gives it 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. Every capability writes into the same correlated exposure model instead of keeping its own list, so one leaked credential raises a single alert, not one from each capability that saw it.
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 question that decides 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.
- 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, with 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
The last beat gets the finding into the system your team already works in, with the evidence attached.
Findings route to the queue you already run, through 86 native integrations across SIEM, SOAR, EDR, ticketing, IdP, cloud and secrets management. Each carries provenance, ownership and disposition. Where the answer is a takedown and not a ticket, it is dispatched under contractual SLA. Every state change is recorded, so the trail stands up as audit evidence.
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.
Where the answer is a removal and not a ticket, the last beat forks once more, and the fork is about who receives the notice. A website takedown goes to the provider that holds the files; a domain takedown goes to the registration, which is a different counterparty with a different evidence bar. Which layers can act at all, and what each one will accept, is set out in the provider directory.
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, not 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 in scope is reachable from the public internet, which 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 every one is reviewed before it is sent. None are fired automatically on a match.
The technical-architecture briefing goes further: data sources, the exposure-model schema, scoring inputs, the validation pipeline and integration topology. It is walked through live with your team against your own estate, not 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.