Attack Surface Management (ASM)

New Scan

Organizations to scan — one scan per organization

Scan type Scanner Target group Seeds — domains, IPs, CIDR ranges or URLs (comma-separated)

Authentication — this scan type tests behind login. Credentials are stored for this customer and reused on future authenticated scans.

Headers / cookies — token or session auth (e.g. Cookie: session=…, Authorization: Bearer …)

API definition — upload an OpenAPI/Swagger or Postman file so the scan tests API endpoints a crawler never reaches. Endpoints outside this customer's scope are dropped.

Access-control testing — add a second, lower-privilege user and the scan replays each authorized page as that user and anonymously (read-only), flagging pages that return the same content to someone who should not see them. Leave blank to test only the anonymous case.

Headers / cookies for the low-privilege user

Login steps (advanced) — for logins that need a CSRF token, redirects, or more than one page, paste a login sequence (JSON) instead of relying on the single form login above. The scanner runs the steps, carries cookies between them, and uses the resulting session. Show format.

{"steps":[
  {"method":"GET","url":"https://app/login","capture":[{"var":"csrf","from":"form_input","name":"csrf_token"}]},
  {"method":"POST","url":"https://app/login","fields":{"email":"u@x","password":"...","csrf_token":"{{csrf}}"}}
],"success":{"contains":"Sign out"}}

Authorized user login steps Low-privilege user login steps

Check a token — paste a JWT or an Authorization header to check it for alg=none, a guessable signing secret, and missing or long expiry. Offline; nothing is stored. Session tokens are also checked automatically on every web-app scan.

When

Authorizations — testing is authorized by this attestation, not limited by scope. Confirm both to launch. A Rules-of-Engagement record can be created from this test for signature, but is not required to run.

I am authorized to test the target(s) listed above. The customer owns these targets and is responsible for this testing. Rules of Engagement — link this test to a signed RoE (optional)

Scan Queue Health

Currently running

Scan	Customer	Kind	Target	Node	Running for

Completed scans

Scan	Customer	Result	Jobs	Started

Scheduled Scans — Continuous Monitoring

Create a continuous monitor from the New Scan form above — set When to Every hour, 6 hours, Daily, Weekly or Monthly. Active monitors are listed here; pause or remove them any time.

Engagement	Type	Every	Mode	Via	Next run	Last run	Status

Scan History

When	Client	Type

Cloud Scanner Nodes

Scanner Nodes run every scan — the console never scans, only stores results. Cloud nodes are Inceptus-hosted and run external/OSINT scans; on-site nodes (below) run inside a customer's network for internal scans. Both are Scanner Nodes.

Node name

Install command for : shown once

On a fresh Ubuntu 22.04 or 24.04 server with a static public IP, run this one line (it downloads and verifies the scanner package automatically — nothing to unpack):

The token is only stored hashed. If it is lost, revoke the node and add a new one.

Download if the one-liner can't run (no direct internet, a TLS-inspecting proxy, or an air-gapped host): copy the .sh to the server and run sudo bash install-node-<name>.sh.

Node	Location	Status	Version	Egress IP	Engines	Host (vCPU · RAM · usage)	Current job	Jobs	Last check-in

Allowlist IPs: no active nodes yet

Scan Limits

0 = no limit

Running at once, per organization Started per organization, per 24 hours Running at once, per MSP

Applies to scans people start. Automatic monitoring scans are not limited.

Where Scans Run

External and cloud scans run on External scans Cloud scans

New On-Site Scanner Node

An on-site Scanner Node (formerly "collector") runs inside a customer's network so internal scans reach private hosts. It's the same Scanner Node, deployed on-site.

On-Site Scanner Nodes

Node	Location	Status	Version	Egress IP	Engines	Host (vCPU · RAM · usage)	Current job	Jobs	Last check-in

OSINT — —

Runs on demand; a passive OSINT monitor also refreshes automatically every 12 hours (see Scheduled Scans).

OSINT Domains

Apex / TLD domain Verify via

Domain	Method	Status	Publish this record

Repositories to Secret-Scan

Authorized git repositories are scanned for leaked credentials (secrets in source and full commit history) on the next scan, using gitleaks. HTTPS git URLs only — add only repositories you are authorized to scan.

Git repository URL

Repository

Breached Credentials & Dark-Web Exposure

Domain	Breach source	Date	Exposed accounts	Data exposed	Severity

Email Authentication

Domain	SPF	DMARC	DKIM	DNS records

Email authentication posture (SPF / DMARC / DKIM, including M365 selectors) is collected by an OSINT scan on a scanner node and shown here from the stored snapshot. Run New Scan → "OSINT scan" with the domains as seeds to populate or refresh it. The console does not probe DNS itself.

Typosquatting & Look-Alike Domains

Look-alike domain	Technique	Risk	Status / note

Certificate Transparency — Discovered Subdomains

Subdomain	First seen	Issuer	Note	Severity

Internet-Facing Services

Host	IP	Port	Service	Product	TLS	Severity

Exposed Cloud Storage

Provider	Bucket / container	Access	Contents	Note	Severity

Code & Secret Leaks

Location	Kind	Secret / reference	Note	Severity

Dark-Web & Threat-Actor Chatter

Source	Context	Date	Severity

Attack-Surface Enumeration

Subdomains from Amass / subfinder and theHarvester's hosts, combined and de-duplicated. The Sources column shows where each one was found.

Subdomain	IP	ASN	Netblock	Sources

Harvested Emails & Staff

Correlations

Cross-source correlations — findings that only emerge when several OSINT sources line up (e.g. a breached credential that also appears in a code leak). Shown only when the OSINT scan produces correlations.

Correlation	Detail	Modules	Severity

Cloud Posture — All customers

Add and verify a customer's cloud accounts below, then run a Cloud posture scan (Scans → Scan type) to populate this dashboard.

Cloud Posture Findings

Severity

Misconfigurations found by the latest cloud-posture scan of this customer's verified accounts (deduplicated, most severe first).

Severity	Finding	Resource	Category

Cloud accounts

Provider Account ID

Provider	Account ID	Access	Status

$10 per month per verified account

Auto-fix role (optional, AWS)

To let admins apply a few safe fixes after a second admin approves, the customer creates a second IAM role, separate from the read-only one, with the same trust policy and only this permissions policy. Fixes available: .

Users

Email	Role	Auth	Status

Email (SMTP)

Host Port Username Password From address STARTTLS

Alerts & Notifications

Type	Target	Events

OSINT Feed Keys

Feed Enabled API key

Feed	Status	API key

SIEM export

Stream each completed scan's findings to your SIEM. Demo scans are never sent. HTTP collector: https://…. Syslog: udp://host:514 or tcp://host:514 (one RFC 5424 line per finding; CEF format recommended).

Enabled Collector URL Format Minimum severity Auth header / token

AI model

—

Set the provider and model in /etc/inceptus-asm/env (ASM_AI_PROVIDER / ASM_AI_BASE_URL / ASM_AI_MODEL). See Help → “Choosing the AI model”.

Custom checks

Upload your own nuclei templates (YAML). They run on every scan alongside the built-in checks. Templates that execute code on the scanner (nuclei code, javascript, headless) are rejected.

Template (YAML)

ID	Name	Severity	Status

Authentication — Microsoft 365 / Google / SSO

Enable single sign-on Identity provider

Directory (tenant) ID Application (client) ID MSPs and customers sign in with their own Microsoft 365 (multi-tenant app) Graph app secret

Map signed-in users to org Groups claim Auto-provision on first login Sync role from groups each login

Sign in with Google — paste the OAuth 2.0 Client ID from a Google Cloud project (APIs & Services → Credentials → Web application). Works alongside Microsoft 365 and is independent of the SSO toggle above: the Google button appears on the sign-in page as soon as a Client ID is saved. Only managed Google Workspace accounts on a user's own email domain are accepted; personal Gmail is rejected. Add this console's origin to the OAuth client's Authorized JavaScript origins and redirect URIs.

Google OAuth Client ID

Advanced (override derived endpoints)

Issuer JWKS URL Audience Email claim

Directory Sync (SCIM)

Token	Label	Created

SCIM endpoint: <base>/scim/v2

Group → Role Mapping (SSO / Directory)

IdP group ASM role

IdP group	ASM role

Audit Log

When	Actor	Action	Detail	Outcome

Attack Surface Management

Welcome to Inceptus ASM

Attack Surface Management (ASM)