ShadowSpot Incidents
Each exposure or vulnerability discovered by ShadowSpot is surfaced as a finding in the XTron Console. This page covers how to access, manage, and remediate ShadowSpot findings.
Viewing Findings
Navigate to Incidents → ShadowSpot in the XTron Console. Filter by:
- Severity — Critical, High, Medium, Low
- Status — Open, In Progress, Closed
- Domain — Filter to a specific monitored domain
- Finding type — Exposed service, CVE, certificate, misconfiguration, etc.
Finding Types and Response Guidance
Exposed Service
A sensitive service is accessible from the internet without adequate access controls.
Common examples: Database ports open to the internet (MongoDB, Redis, Elasticsearch), administrative interfaces accessible without VPN (Kubernetes dashboard, Jenkins), development environments reachable publicly.
Response:
- Confirm the exposure is real and unintentional
- Restrict access using firewall rules or move behind VPN/bastion
- Check access logs for unauthorized access during the exposure window
- Rotate any credentials that may have been accessible
Known CVE
A software version with a known CVE is running on a discovered asset.
Response:
- Check the CVE details for exploitability and impact
- Determine if the service is actually exploitable in your environment
- Apply the vendor patch or upgrade to a non-vulnerable version
- If patching is delayed, apply compensating controls (WAF rule, network restriction)
Subdomain Takeover
A subdomain is pointing to a cloud resource that no longer exists, making it susceptible to takeover.
Response:
- Verify the subdomain is genuinely vulnerable
- Delete the DNS record or re-create the cloud resource it points to
- Prioritize — subdomain takeovers can be used for phishing and session hijacking
Certificate Issue
SSL/TLS certificate is expired, expiring soon, or configured with deprecated protocols.
Response:
- Expired: Renew immediately — expired certs cause browser warnings for all visitors
- Expiring soon: Schedule renewal this week
- Weak protocols (TLS 1.0/1.1): Disable in server configuration; update to TLS 1.2 or higher
Cloud Storage Misconfiguration
A cloud storage bucket (S3, GCS, Azure Blob) is publicly accessible.
Response:
- Immediately review the bucket contents — determine if sensitive data is exposed
- Remove public access permissions
- Enable access logging on the bucket
- If sensitive data was exposed, initiate your data breach response procedure
Finding Fields
| Field | Description |
|---|---|
id | Unique numeric ID |
title | Short description of the finding |
taskKey | Ticket key (e.g., SSINC-456) |
status_statusCd | Open, In Progress, Closed |
severity_label | Critical, High, Medium, Low |
category_name | Finding category |
domain | Affected domain |
assets | Affected asset (host, IP, port) |
url | Affected URL |
cvss | CVSS score (for CVE findings) |
epss | EPSS exploitation probability (for CVE findings) |
ransomware_exploited_cve | Whether this CVE is exploited by ransomware groups |
in_the_wild | Whether the vulnerability is actively exploited |
impact | Impact description |
remediation | Remediation steps |
verification_details | Evidence and confirmation details |
Accepting Risk
If a finding is intentional (e.g., a publicly accessible service by design), mark it as Closed via the XTron Console under Incidents → ShadowSpot → [finding] → Update Status, and add a note explaining the accepted risk.
Closed findings are excluded from active alerting for that asset and finding type combination.