Subdomain Intelligence OSINT

A defensive subdomain finder and public exposure monitor for authorized domains.

Subdomain Intelligence OSINT helps authorized users discover, validate, profile, monitor, and prioritize subdomains for domains they own or are permitted to assess. It combines passive OSINT, DNS validation, wildcard filtering, public exposure classification, HTTP/TLS profiling, technology detection, cloud/CDN/SaaS provider detection, monitoring, reports, and structured output.

It is built for security teams, bug bounty hunters, agencies, IT teams, DevOps teams, and OSINT analysts who need more than a basic subdomain finder. The Actor does not just list names; it helps explain what each subdomain appears to be and which assets are worth reviewing first.

Find subdomains, then understand what they actually are: live, auth-gated, forbidden, DNS-only, unresolved, wildcard-only, cloud-hosted, SaaS-backed, login-related, API-like, admin-looking, staging/dev, or newly changed.

Safety notice

This Actor is for authorized domains only. It performs non-invasive checks, uses homepage-only profiling, and does not exploit services, bypass authentication, crawl websites, fuzz paths, run broad port scans, create accounts, or claim DNS/cloud resources. Possible takeover indicators are informational and require manual verification.

What is Subdomain Intelligence OSINT?

Subdomain Intelligence OSINT is a defensive subdomain scanner and OSINT monitor for authorized domains. It gathers subdomain candidates from passive and optional API-key sources, validates them with DNS, checks how they appear from the Actor runtime, detects visible providers and technologies, monitors changes over time, and returns results in datasets, reports, graph exports, and key-value outputs.

The goal is practical asset intelligence: understand which names resolve, which are publicly reachable, which appear to require authentication, which point to cloud or SaaS providers, which changed since the previous run, and which should be reviewed first.

What can this Actor do?

Discovery

• Passive OSINT subdomain discovery.
• Certificate transparency discovery via crt.sh.
• Archive enrichment through Common Crawl and Internet Archive CDX indexes.
• Optional API-key sources implemented for SecurityTrails, VirusTotal, Censys, Shodan, BinaryEdge, ProjectDiscovery Chaos, urlscan.io, and GitHub Code Search.
• User-provided knownSubdomains for seed or profile-only workflows.
• Optional bounded DNS brute-force, SRV discovery, permutations, and AXFR checks when enabled.

Disabled source stubs currently include AlienVault OTX, ThreatMiner, RapidDNS, FOFA, ZoomEye, and Hunter. They skip cleanly and do not emit fake results.

Validation

• DNS validation for selected record types.
• Resolved and unresolved classification.
• Wildcard DNS detection and wildcard evidence.
• CNAME chain handling with loop protection.
• Public, private, and reserved IP classification.

Public exposure profiling

• Public live HTTP/HTTPS.
• Authentication required.
• Forbidden/access-controlled.
• Redirected.
• DNS-only.
• TLS-only.
• Private or reserved IP exposed through public DNS.
• Wildcard-only.
• Blocked or timeout from this Actor runtime.
• Unknown when evidence is insufficient.

HTTP profiling uses HEAD first and limited GET fallback on /. It does not crawl pages or try arbitrary paths.

Technology and provider detection

• Web server, framework, CMS, analytics, and monitoring signals where visible.
• Header, cookie, DNS/CNAME, TLS, favicon, and homepage metadata signals.
• CDN, WAF, cloud, PaaS, object storage, SaaS, identity provider, support, documentation, and status platform indicators.
• Homepage-only service classification such as website, API, login, admin, docs, status page, object storage, identity, monitoring, support, redirect, parking, or unknown.

Monitoring

• compareWithPrevious mode to compare against a stored baseline.
• updateBaseline mode to compare and update the baseline after a successful run.
• First-seen, last-seen, times-seen, new, removed, and changed asset tracking.
• DNS, CNAME, IP, provider, HTTP status/title, TLS, exposure, accessibility, technology, and priority change detection.
• Optional alerts through configured generic, Slack, or Discord webhooks.

Use Apify schedules or Actor tasks to run monitoring on a recurring cadence. The Actor does not create schedules by itself.

Prioritization

• Confidence score based on source quality, DNS evidence, wildcard behavior, and profiling signals.
• Exposure priority score based on public exposure, service type, naming indicators, provider signals, possible dangling CNAME indicators, and monitoring changes.
• Human-readable explanations and evidence for dataset rows.

Reports

• Markdown report.
• HTML report.
• JSON report.
• Asset graph exports in JSON and Cytoscape JSON, with optional GEXF output.
• Optional homepage screenshots when screenshot profiling is enabled.

Who is this Actor for?

• Security teams building an external asset inventory.
• Bug bounty hunters working within program scope.
• Agencies doing authorized client attack-surface reviews.
• IT and DevOps teams validating DNS and public exposure.
• OSINT analysts collecting structured domain intelligence.
• Asset management teams that need recurring monitoring and change detection.
• Red teams working with explicit authorization.

Common use cases

• Build a subdomain inventory for one or more root domains.
• Find live and auth-gated HTTP/HTTPS hosts.
• Detect newly created staging, dev, admin-looking, or login-related subdomains.
• Understand cloud, CDN, WAF, SaaS, identity, support, docs, and status-page dependencies.
• Monitor changes on a schedule and alert on high-priority changes.
• Prepare a client-facing public exposure report.
• Feed structured dataset rows into another AI agent, MCP workflow, SIEM, ticketing system, or analysis pipeline.

How to use this Actor

1. Confirm you are authorized to assess the domains.
2. Enter one or more root domains such as example.com.
3. Choose a search level:
   • quick: fast passive discovery, DNS validation, and lightweight profiling.
   • deep: recommended default; passive discovery, small bounded DNS candidate generation, DNS validation, and profiling.
   • extraDeep: broader enabled sources, larger bounded candidate generation, permutations, and full profiling options.
4. Optionally add API keys, monitoring, alert, screenshot, passive-only, or profile-only settings through JSON input or a saved Actor task. The default Store form is intentionally limited to the fields most users need.
5. Run the Actor.
6. Review the dataset rows and key-value store reports.

Input examples

Quick scan

{
  "authorizedUseOnly": true,
  "domains": ["example.com"],
  "searchLevel": "quick"
}

Deep scan

{
  "authorizedUseOnly": true,
  "domains": ["example.com"],
  "searchLevel": "deep"
}

Monitoring scan

{
  "authorizedUseOnly": true,
  "domains": ["example.com"],
  "searchLevel": "deep",
  "monitoringOptions": {
    "monitoringMode": "updateBaseline"
  }
}

Passive-only scan

Passive-only and profile-only are advanced JSON workflows for saved Actor tasks or API calls.

{
  "authorizedUseOnly": true,
  "domains": ["example.com"],
  "mode": "passiveOnly"
}

Profile-only scan

{
  "authorizedUseOnly": true,
  "domains": ["example.com"],
  "knownSubdomains": ["www.example.com", "api.example.com"],
  "mode": "profileOnly"
}

Extra deep scan with API keys

{
  "authorizedUseOnly": true,
  "domains": ["example.com"],
  "searchLevel": "extraDeep",
  "apiKeys": {
    "securityTrails": "YOUR_SECURITYTRAILS_API_KEY",
    "virusTotal": "YOUR_VIRUSTOTAL_API_KEY",
    "shodan": "YOUR_SHODAN_API_KEY",
    "censysId": "YOUR_CENSYS_ID",
    "censysSecret": "YOUR_CENSYS_SECRET",
    "binaryEdge": "YOUR_BINARYEDGE_API_KEY",
    "chaos": "YOUR_PROJECTDISCOVERY_CHAOS_API_KEY",
    "urlscan": "YOUR_URLSCAN_API_KEY",
    "githubToken": "YOUR_GITHUB_TOKEN"
  }
}

API keys are optional, redacted from normal outputs, and subject to each provider's rate limits and account permissions. In extraDeep search, auto source selection uses the API-key sources for which you provide credentials. You only need custom mode, sources, dnsOptions, bruteForceOptions, httpOptions, profileOptions, reportOptions, limits, or outputOptions when building an advanced API workflow.

What data does it return?

The default dataset contains one row per unique FQDN.

Field	Meaning
rootDomain	Authorized root domain the FQDN belongs to.
fqdn	Fully qualified subdomain.
sources	Source IDs that observed the FQDN.
resolved	Whether DNS resolution succeeded from this Actor runtime.
publicExposureStatus	High-level exposure classification such as live HTTP, auth required, DNS-only, unresolved, or wildcard-only.
accessibilityLevel	Observed reachability level from this Actor runtime.
dnsProfile	DNS status, record types, records, CNAME chain, wildcard match, and IP exposure indicators.
httpProfile	Homepage-only HTTP/HTTPS status, redirects, title, headers, content type, and optional metadata path checks.
tlsProfile	TLS handshake and certificate metadata where HTTPS is reachable.
technologyProfile	Detected visible technologies with evidence.
providerProfile	Cloud, CDN, WAF, SaaS, identity, support, documentation, or monitoring providers observed from signals.
serviceProfile	Service classification such as API, login, admin, docs, status page, object storage, monitoring, support, or website.
authProfile	Authentication indicators such as Basic auth, login form, SSO redirect, or forbidden.
confidenceScore	0-100 confidence score based on source and validation evidence.
exposurePriority	Priority level for manual review: info, low, medium, or high.
riskTags	Informational tags such as multi_source_confirmed, dns_only, admin_or_auth_name, or possible_takeover_indicator.
explanation	Human-readable explanation of the row.
changeType	Monitoring change type, when baseline comparison is used.
changeSeverity	Severity of a detected monitoring change.

Example result

{
  "rootDomain": "example.com",
  "fqdn": "login.example.com",
  "sources": ["crtsh", "securityTrails"],
  "resolved": true,
  "publicExposureStatus": "public_auth_required",
  "accessibilityLevel": "auth_gated",
  "providerProfile": {
    "detectedProviders": [
      {
        "provider": "Cloudflare",
        "category": "cdn",
        "confidence": 95
      },
      {
        "provider": "Okta",
        "category": "identity",
        "confidence": 85
      }
    ]
  },
  "technologyProfile": {
    "detected": true,
    "technologies": [
      {
        "name": "Cloudflare",
        "category": "cdn",
        "confidence": 95
      }
    ]
  },
  "serviceProfile": {
    "primaryServiceType": "login",
    "serviceTags": ["login_required", "sso_redirect"]
  },
  "confidenceScore": 82,
  "exposurePriority": "medium",
  "explanation": "login.example.com resolves publicly and responds over HTTPS. Homepage and redirect signals suggest an auth-gated login flow behind Cloudflare with an Okta identity provider indicator."
}

Public exposure statuses explained

• public_live_http: DNS resolves publicly and HTTP/HTTPS returns useful content.
• public_auth_required: HTTP 401, login content, or SSO/authentication indicators were observed.
• public_forbidden: HTTP 403 or access-denied indicators were observed.
• public_redirect: the host redirects to another host or service.
• public_dns_only: DNS resolves publicly but HTTP/HTTPS was not reachable.
• public_tls_only: TLS was reachable but useful HTTP content was not observed.
• private_ip_exposed_in_public_dns: public DNS returned a private or non-routable IP address.
• reserved_ip_exposed_in_public_dns: public DNS returned reserved, documentation, multicast, CGNAT, or similar non-public ranges.
• unresolved: public DNS did not resolve from this Actor runtime.
• wildcard_only: the host appears to exist only because of likely wildcard DNS.
• blocked_or_timeout: the host timed out, reset, or appeared blocked from this Actor runtime.
• third_party_service: signals indicate the host points to an external SaaS/cloud service.
• unknown: evidence was insufficient to classify.

A 401 or 403 response is still useful public exposure intelligence. It means the service responded publicly, even if access is controlled.

Accessibility levels explained

• not_resolvable: DNS did not resolve.
• dns_only: DNS resolved, but HTTP/TLS reachability was not observed.
• network_reachable: lower-level network or TLS reachability was observed.
• http_reachable: HTTP/HTTPS responded.
• auth_gated: authentication appears required.
• forbidden: access is publicly reachable but forbidden.
• public_content: public content was observed.
• redirect_only: the host redirects without meaningful local content.
• unknown: there was not enough evidence to classify reachability.

Technology detection

Technology detection is best effort and evidence-based. It uses visible headers, cookies, DNS/CNAMEs, TLS metadata, favicon hashes when enabled, and homepage metadata where available. It does not crawl the site, interact with applications, or request arbitrary paths.

The Actor reports version hints only when they are explicitly visible. It does not infer vulnerabilities from versions and does not claim that software is outdated.

Implemented signatures include examples such as Cloudflare, Akamai, Fastly, Amazon CloudFront, nginx, Apache HTTP Server, React, Next.js, WordPress, Shopify, Google Analytics, Google Tag Manager, Grafana, Kibana, Prometheus, Sentry, Datadog, and New Relic.

Provider detection

Provider detection uses visible signals from headers, CNAMEs, DNS, TLS, redirects, and homepage metadata. Supported provider examples include:

• CDN/WAF: Cloudflare, Akamai, Fastly, AWS CloudFront.
• Cloud/PaaS/storage: AWS, AWS S3, AWS API Gateway, AWS Elastic Beanstalk, Azure App Service, Azure Front Door, Azure Blob Storage, Google Cloud, Firebase, Google App Engine, Vercel, Netlify, Heroku, GitHub Pages, GitLab Pages, Render, Fly.io.
• SaaS/support/marketing/docs/status: Shopify, Zendesk, Help Scout, Intercom, HubSpot, Atlassian, Statuspage.
• Identity: Okta, Auth0, Microsoft Entra ID / Azure AD, Google Workspace, Keycloak, Ping Identity, OneLogin.

These are provider indicators, not proof of ownership or risk by themselves.

Confidence score

confidenceScore is a 0-100 estimate of how strongly the Actor believes the FQDN is a meaningful asset candidate.

Higher confidence usually comes from resolved DNS, multiple independent passive sources, live HTTP/HTTPS, recent certificate/archive evidence, non-wildcard DNS records, or user-provided known subdomains.

Lower confidence usually comes from archive-only unresolved names, wildcard-only matches, or brute-force-only candidates.

Exposure priority score

priorityScore and exposurePriority help decide what to review first. This is prioritization, not proof of vulnerability.

Priority can increase for live services, auth portals, admin/staging/dev keywords, possible dangling CNAME indicators, object storage indicators, monitoring/dashboard names, external SaaS dependencies, visible technology versions, and newly discovered hosts.

Priority can decrease for unresolved, wildcard-only, parked, or simple redirect-only hosts.

Possible takeover indicators

Possible takeover indicators are informational signals based on DNS, CNAME, and provider patterns. The Actor does not attempt to claim, create, exploit, or verify ownership of third-party resources. Manual verification is required, and any review should follow the provider's rules and the domain owner's authorization.

Monitoring and change detection

Monitoring modes are designed for recurring Apify schedules and Actor tasks:

• singleRun: run once without baseline comparison.
• compareWithPrevious: load the previous baseline and write CHANGES without updating the baseline.
• updateBaseline: compare with the previous baseline if present, write CHANGES, then update the baseline after a successful run.

Dataset rows can include firstSeenAt, lastSeenAt, timesSeen, previouslySeen, isNew, changeType, changeSeverity, and changeReasons.

Detected changes include new and removed subdomains, DNS record changes, CNAME/IP/provider changes, HTTP status/title changes, TLS certificate changes, public exposure changes, accessibility changes, technology changes, new possible takeover indicators, new high-priority assets, new live admin/auth hosts, new dev/staging hosts, and private/reserved IP exposure through public DNS.

Reports and outputs

Key-value store outputs include:

• OUTPUT: run summary, totals, warnings, output keys, and recommended next mode.
• REPORT_MARKDOWN: Markdown report.
• REPORT_HTML: lightweight HTML report.
• REPORT_JSON: structured report.
• SOURCE_STATS: source status, runtime, candidate counts, skipped reasons, warnings, and errors.
• PROFILE_STATS: DNS/profile summary and non-fatal profiling errors.
• CHANGES: monitoring diff results.
• BASELINE: current compact baseline snapshot.
• GRAPH_JSON: asset graph.
• GRAPH_CYTOSCAPE_JSON: Cytoscape-compatible graph.
• GRAPH_GEXF: optional GEXF graph export when graph output is enabled.
• ALERTS_JSON: alert payload and send status.
• ALERTS_MARKDOWN: alert text.
• ERRORS: structured non-fatal and fatal errors.
• RUN_CONFIG_SANITIZED: normalized configuration with secrets redacted.
• SCREENSHOT_INDEX: screenshot metadata when screenshot profiling is enabled.

API usage

JavaScript

import { ApifyClient } from "apify-client";

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });

const run = await client.actor("YOUR_USERNAME/subdomain-intelligence-osint").call({
  authorizedUseOnly: true,
  domains: ["example.com"],
  searchLevel: "deep",
  profileOptions: { enabled: true }
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items.slice(0, 5));

Python

from apify_client import ApifyClient
import os

client = ApifyClient(os.environ["APIFY_TOKEN"])

run = client.actor("YOUR_USERNAME/subdomain-intelligence-osint").call(
    run_input={
        "authorizedUseOnly": True,
        "domains": ["example.com"],
        "searchLevel": "deep",
        "profileOptions": {"enabled": True},
    }
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
print(items[:5])

Scheduling and alerts

Use Apify schedules or saved Actor tasks to run monitoring regularly. A common pattern is:

1. Run once with monitoringMode: "updateBaseline".
2. Schedule recurring runs with the same domains and baseline settings.
3. Review CHANGES, OUTPUT, and the generated reports.
4. Optionally enable generic, Slack, or Discord webhooks and set minimumAlertSeverity.

Alerts are concise and should focus on new or high-priority changes. Webhook failures are non-fatal and are recorded in ERRORS.

Pricing and performance notes

Pricing depends on how the Actor is configured in Apify Store. Runtime and cost drivers can include:

• Number of root domains.
• Selected search level.
• Number of discovered subdomains.
• DNS validation volume.
• HTTP/TLS profiling volume.
• Screenshot profiling.
• Premium/API-key source usage.
• Monitoring, report generation, and graph output.

Use quick for lower-cost inventory runs, deep for general use, and extraDeep for broader authorized reviews. Advanced JSON input still supports passive-only and profile-only workflows.

Limits and caveats

• No OSINT source finds every subdomain.
• Source availability, rate limits, and response formats can change.
• API keys can improve coverage but are optional and provider-limited.
• Wildcard DNS can create noisy or misleading candidates.
• Some services block datacenter traffic or the Actor runtime.
• Some hosts are only reachable from internal networks.
• Technology and provider detection are best effort and evidence-based.
• Screenshots are optional and can increase runtime.
• The Actor does not perform vulnerability scanning, exploitation, authentication bypass, path fuzzing, or broad port scanning.

Troubleshooting

No results found

Confirm the domain is correct, authorized, and registrable. Try deep or extraDeep, provide known subdomains through advanced JSON input, or add API keys for optional sources.

Many wildcard-looking results

The domain may use wildcard DNS. Review wildcardMatch, dnsProfile.wildcardEvidence, confidence score, and source evidence before acting on results.

HTTP timeouts

Some hosts block datacenter traffic, only respond internally, or do not serve web traffic. Check DNS fields, TLS fields, and blocked_or_timeout classifications.

401 or 403 responses

These are not failures. They indicate a public-facing service responded but appears access-controlled.

Missing API-key sources

API-key sources skip cleanly when keys are missing. Add the relevant key under apiKeys through JSON input or a saved task and use extraDeep for the broadest automatic source selection.

Screenshots not generated

Screenshots run only when profileOptions.screenshotProfiling.enabled is true and the mode is not disabled. They are capped by maxScreenshots and only target selected live or priority hosts.

Monitoring baseline not found

Run once with monitoringMode: "updateBaseline" to create the baseline. Use the same baseline store name and key prefix for future runs.

Source rate limits

Optional API sources are subject to provider quotas and rate limits. Review SOURCE_STATS for skipped, timeout, or error status.

FAQ

Is this a vulnerability scanner?

No. It is a defensive subdomain intelligence, DNS validation, public exposure profiling, and monitoring Actor. It does not exploit services or confirm vulnerabilities.

Can I use it on domains I do not own?

Use it only on domains you own or are explicitly authorized to assess.

Does it exploit subdomain takeover?

No. Possible takeover indicators are informational DNS/CNAME/provider signals. The Actor does not claim resources, create accounts, or verify takeover by interaction.

Why are unresolved subdomains included?

Unresolved names can still be useful historical or monitoring signals, especially when observed in certificate transparency or archive sources. You can exclude unresolved items through output options.

Why does a 403 still count as public exposure?

A 403 means a public-facing service responded and denied access. It is access-controlled, but still externally reachable from this Actor runtime.

Can I monitor domains over time?

Yes. Use compareWithPrevious or updateBaseline and run the Actor through Apify schedules or saved tasks.

Can I export results?

Yes. Use the default dataset, JSON/Markdown/HTML reports, graph exports, and key-value store outputs.

Can I use this with an AI agent?

Yes. Dataset rows use structured camelCase fields, evidence arrays, explanations, confidence scores, priority scores, and graph outputs that are suitable for AI-agent and MCP workflows.