Access-path context

Identity Exposure

Compromised credentials and sessions connected to the portals and relationships that could make them operationally useful — not a flat list.

Evidence-backedAnalyst-reviewedNo actor engagement

The screen

What your team sees.

Built on the same preserved evidence as every alert and perspective. Open the live demo

Identity ExposureExample tenant
Screenshot: the Identity Exposure evidence table — identities, their relationship, the portals they reach, compromise date and confidence.
Capability architecture

The identities that open doors.

Stealer logs and credential dumps are matched to your monitored identifiers, then tied to the portals, roles and relationships that decide whether an exposure matters.

01

Why it matters

  • A leaked password for a disused account and a live single sign-on session for a finance contractor look the same in a dump. They are not the same risk.
  • Third-party and contractor identities are routinely the hop an adversary uses, and they rarely appear in your own directory.
  • Credential monitoring that validates logins or probes your systems creates risk of its own.
02

ThreatCanary approach

  • Stealer logs, credential dumps and session material are collected, preserved with provenance and matched to your monitored identifiers.
  • Each exposed identity is connected to the portals it reaches, its relationship to you and the compromise date, with a confidence rating.
  • Monitoring domains are identifiers only — adding one never triggers DNS lookups, discovery, scanning, credential validation or contact with the organisation.
03

What you see

  • An evidence table of identities, their relationship, the portals they reach, compromise date and confidence.
  • An evidence-safe detail view for each identity that never renders images from collected content.
  • The identities that appear as hops in your adversary perspective and alerts.
04

Evidence produced

  • Identity exposure records with source provenance and compromise date.
  • Portal and relationship context for each identity.
  • Recommended defensive moves — revoke sessions, reset credentials — tied to the evidence.
Common questions

Questions teams ask before they commit.

Direct answers on scope, evidence, safety controls and how ThreatCanary differs from tools you already run.

01

Does Nullstar test whether a leaked credential still works?

No. Credential validation is one of the actions Nullstar never performs. Exposure is assessed from the preserved evidence — where the material appeared, when, and what it reaches — and the recommended defensive validation is for your team to run.

02

Which identities are covered?

Identities matching the monitoring identifiers configured for your tenant — your own domains and the contractor, supplier and partner identities you ask Nullstar to watch. Each is shown with its relationship to you so third-party exposure is not lost.

03

Will adding a domain cause any traffic to it?

No. Monitoring identifiers are matching keys only. Adding one never triggers DNS lookups, discovery, scanning or contact with the organisation.

Evaluate the capability

See this capability work against your attack surface.

Book a product walkthrough