How T1593 search open websites and domains shows up before an intrusion
For a SOC lead, the central problem with reconnaissance is that it happens before any alert fires. T1593 Search Open Websites/Domains is the activity, under the Reconnaissance tactic (TA0043), in which an adversary gathers information from public websites and domains to plan later operations. The technique has 3 sub-techniques, and the activity is often invisible on the victim's network because it takes place on infrastructure the victim does not own. The practical question is therefore not whether the activity happens, but which parts of it your organization can see and which parts it cannot. Start by confirming with your own team which public sites, domains and third-party pages expose details about your people, systems and suppliers, since those are the sources an adversary can read without touching your environment.
ATT&CK describes itself as a globally accessible knowledge base of adversary tactics and techniques based on real-world observations, so the technique entry should be read as a catalog of observed behavior rather than a complete list of what an adversary might do. Treat that as a reason to plan for visibility gaps, not to assume them away. The decision to make now is which signals you will treat as useful evidence. Where the activity leaves no trace on your side, your detection work shifts toward the points where it can touch you, such as inbound requests to web properties you operate and changes to the public content you publish. Confirm the ATT&CK version your detection mappings target before you build on them, because releases can rename or deprecate techniques.
Which telemetry reveals T1593 and which open-source tool collects it
This table maps each public-footprint signal that can reveal T1593 activity to its data source, what to look for, and the open-source collector that gathers it. Read it as a starting inventory: confirm each data component against the T1593 detection strategies in your target ATT&CK version before you build rules, because adversary searches of open websites mostly happen outside your environment.
| Signal | Data source and what to look for | Open-source collector |
|---|---|---|
| Web server access logs | Your public web tier logs. Look for bursts of requests for sitemaps, robots.txt, old or unlinked paths, backup file names and documentation pages from a single source that does not match normal visitor patterns. Treat as Application Log Content (DC0038) where the logs are at application level. | Wazuh log collection from web server files, with Security Onion or Zeek HTTP logs as a second view |
| Reverse proxy and CDN request logs | Edge logs that show request paths, user agents and status codes across all public hostnames. Look for systematic crawling of hostnames or paths that no legitimate client uses, and for high ratios of 404 responses from one range. | Wazuh decoders for proxy logs, Zeek HTTP analysis on mirrored traffic where you control the sensor |
| Passive DNS and DNS query records | Resolver logs for your own zones and recursive resolvers. Look for lookups of names you do not publish, or sweeps across subdomain labels. Confirm with your DNS provider which query logs it retains and for how long. | Zeek DNS logs, Security Onion DNS views, Wazuh ingestion of resolver logs |
| Certificate transparency monitoring | Public certificate logs that list hostnames issued for your domains. Watch for new hostnames that appear before a project is announced, and for lookalike domains that include your brand terms. | Open-source certificate transparency watchers run on a schedule, with results forwarded to Wazuh as alerts |
| External attack surface inventory | Results from scheduled checks of your own public hosts, ports and banners. Use it to know what an outside searcher can already see, so that exposure found by search engines is not a surprise. This is inventory, not proof of T1593 activity. | Scheduled scans run by your team, with results indexed in Wazuh or a case management store |
| Search engine and public code exposure | Alerts on new indexed pages or public repositories that mention your domains, internal hostnames or configuration file names. Confirm which search feeds you can monitor legally and at what cadence with each provider. | Scheduled alert queries with results stored as Wazuh or Velociraptor artifacts for analyst review |
| Mirrored network traffic for inbound web requests | Full or session-level capture of inbound HTTP and HTTPS metadata at the perimeter. Use it to attribute request bursts to sources and to correlate with access logs. Payload inspection of encrypted traffic needs a decision on TLS termination. | Zeek for session and HTTP metadata, Suricata for signature alerts, Security Onion for combined views |
| Data component coverage check | Network Traffic Content (DC0085), Application Log Content (DC0038), Network Traffic Flow (DC0078) and Response Content (DC0104) are the components most referenced for Reconnaissance. Confirm which of these the T1593 detection strategies reference in the ATT&CK version you target, because the list can change between releases. | Review in the ATT&CK STIX bundle for your target version, then map each component to a collector above |
Why detection mappings must name the ATT&CK version
Every T1593 detection rule should name the ATT&CK version it targets. ATT&CK v18, released October 28, 2025, replaced the detections in technique pages with detection strategies (DET IDs) and analytics, and it made major updates to data components (DC IDs) and deprecated data sources. v19 followed on April 28, 2026, and v20 on October 13, 2026. A rule that cites T1593 or one of its sub-techniques without a version tag cannot be checked against the right mapping when the framework changes, so the detection engineer cannot tell whether the coverage claim still holds.
Releases can rename, deprecate or revoke techniques, and sub-technique structure can change with them. Treat each release as a possible change to the T1593 family and to the data components its detection strategies reference, including Network Traffic Content (DC0085) and Application Log Content (DC0038). For each rule, record the target version in the rule metadata (for example, a attack_version field in a Sigma rule), and link the rule to the detection strategy ID it implements. Before a rule is promoted, check the technique ID, sub-technique IDs and tactic against the enterprise-attack STIX bundle for that version, which MITRE publishes in the attack-stix-data repository. Confirm the exact bundle file for the version you target in that repository, since file names change between releases.
Build the check into your change process rather than running it once. When a new version is released, diff the T1593 entries in the new bundle against your target version, list any renamed, deprecated or revoked objects, and open a review for each rule that references them. Ask your SIEM or detection platform vendor, and any managed detection provider, which ATT&CK version their out-of-the-box T1593 content maps to, and whether they update mappings when MITRE publishes a release. Keep the version history with the rule in version control so an auditor can see which mapping was in force on a given date.
Detection ideas for T1593 described in words
T1593 Search open websites/domains is largely invisible to the victim because it happens on public infrastructure, so detection depends on the traces an outside party leaves on your public web tier, your DNS and your certificate ecosystem. The cards below describe four signals that connect those traces to the technique, each with logic in words, a tuning starting point and the main source of false positives.
Unusual crawling volume on public pages
Count requests to public pages per source over a rolling window and compare each source against a baseline built from your normal search engine and monitoring traffic. A single address or small network range that requests a large share of public pages in a short period, or that walks the site faster than any human browser, deserves review. Check user agents, request pacing and whether the source also fetches robots.txt before crawling. Tuning threshold: start from the 95th percentile of per-source request counts observed over several weeks, then adjust. Main false positive: legitimate search indexers, uptime monitors and partner integrations.
Requests for unlinked content
Alert when sources request paths that no page on the site links to, such as guessed directory names, old release paths or backup-style file names. Build the list of valid paths from your site map and content management system, then flag misses that return successful responses or that cluster from one source. An outside party that requests many unlinked paths is often mapping content that was never meant to be discovered. Tuning threshold: start with more than a small number of distinct unlinked paths from one source within an hour, and tune against the 404 rate you see today. Main false positive: broken links from users, redirects after a site migration and vulnerability scanners you run yourself.
Spikes in lookups against your domains
Track DNS query volume for your public names, especially for subdomains that are not published in any public page, such as staging, admin or internal-style names. A sudden rise in queries for many distinct subdomains from resolvers outside your region, or from resolvers that normally send little traffic to you, can indicate an outside party enumerating your namespace. Correlate with passive DNS and certificate data your team already collects. Tuning threshold: set an alert at a multiple of the daily median for distinct subdomain queries, confirmed over a week of baseline. Main false positive: marketing launches, new service rollouts and security scanning vendors.
New certificates and DNS record changes
Subscribe to certificate transparency monitoring for your domains and review every newly issued certificate, along with unexpected changes to public DNS records. A new certificate for a hostname nobody on your team requested can reveal an outside party cataloging services, or an attacker preparing a look-alike site. Confirm each issuance against your change records and certificate inventory, and check which certificate authority was used. Tuning threshold: alert on any certificate for a name not in your inventory, and treat ordinary renewals as expected events. Main false positive: approved renewals, third-party hosting providers and internal teams issuing certificates outside the central process.
How to validate the T1593 detection in a lab before trusting it
This sequence confirms that the T1593 detection fires for the behavior it is meant to catch, reaches the SIEM with usable fields, and alerts at the tuned threshold, so the team can trust the alert before it reaches production triage. Each step produces a recorded result tied to the ATT&CK version under test.
Define the expected behavior in writing
The detection engineer writes down what T1593 looks like in the team's own telemetry: which sub-technique is in scope (search engines, social media, or code repositories), which data sources should carry the signal, and which activity is benign, such as a crawler, a monitoring service, or a marketing tool. The owner of the detection and a reviewer sign the statement. The step is done when the expected behavior, the benign baseline, and the pass or fail criteria exist as a reviewed document that names the ATT&CK version being tested, so later results can be compared against it.
Confirm the mapping against the target ATT&CK version
Before building test cases, the engineer checks the technique and sub-technique IDs, the referenced data components, and the mitigations against the ATT&CK version the team targets. Technique pages changed with the move to detection strategies and analytics in ATT&CK v18, so the engineer should confirm the current analytic text and data component names in the Enterprise matrix and the STIX bundle for that version. The step is complete when the mapping sheet lists the version, the IDs checked, and any changes since the last review.
Replay benign and simulated activity against a test domain
In a cyber range or isolated lab, the team replays two kinds of activity against a test domain they own: ordinary visitor and crawler traffic that the detection should ignore, and simulated open-source research activity that it should catch. The activity is scripted and repeatable, and no third-party property is touched. The engineer records the start and end time of each run and the run identifier. The step is done when every planned run has a log of what was sent, so the results can be matched to expected outcomes.
Check that signals reach the SIEM with expected fields
The analyst checks that the relevant telemetry, such as Network Traffic Content, Application Log Content, or Network Traffic Flow where the sub-technique depends on it, arrives in the SIEM from the test source. For each field the detection relies on, such as source address, user agent, request path, referrer, or timestamp, the analyst confirms it is present, parsed, and populated in the expected format. Missing or renamed fields are logged as defects. The step is complete when a field-by-field table shows each required field as present or missing for every test run.
Measure whether alerts fire at the tuned threshold
The engineer compares the alert outcomes with the expected results for each run. Simulated activity should produce an alert when it crosses the tuned threshold, and benign traffic should not. Where the rule counts events over a time window, the engineer tests activity just below and just above the threshold to confirm the boundary behaves as written. Each run is marked as a true positive, false positive, missed detection, or threshold miss. The step is done when the counts are recorded per run, not summarized from memory.
Review false positives and tune once
The team reviews every false positive and missed detection with the detection owner and makes one documented change at a time, such as narrowing a user-agent match, adjusting an allowlist for known monitoring services, or changing a window size. After each change the replay is repeated so the effect is measured rather than assumed. The step is complete when each change has a before-and-after result attached to the ticket, and any unresolved gap is listed with an owner.
Record results with the ATT&CK version and sign off
The engineer writes a validation record that names the rule version, the ATT&CK version tested, the data sources and fields used, the run identifiers, the outcome counts, and the known limitations. An independent reviewer checks the record against the logs before the detection is promoted to production. The record is stored with the detection so that a later ATT&CK release, which can rename or deprecate techniques, triggers a documented retest rather than a silent assumption that the detection still holds.
Preventive controls that reduce what T1593 can learn
T1593 is hard to block outright because the information sits on public pages. The controls that matter reduce how much an adversary can learn from those pages and make the searches that do happen visible. The two ATT&CK mitigations that map to this technique, Audit and Application Developer Guidance, cover the content you publish and the logging you keep.
Review what public pages disclose
Start with an inventory of what your public websites and domains reveal: page source comments, metadata, generator tags, error pages, document properties on downloadable files, and staging or test hostnames that resolve publicly. Adversaries use these details to infer technology stacks, naming conventions and staff roles. Under the Audit mitigation (M1047), schedule periodic reviews of this content and record the owner and the decision for each finding. Ask your team to confirm which items are required for business purposes and which can be removed.
Strip metadata before publication
Put a publishing check in the content pipeline so that images, PDFs and office documents lose embedded author, revision and location fields before they go live. Pair this with build settings that suppress version banners and framework identifiers in production responses. Under Application Developer Guidance (M1013), developers should treat public output as part of the threat surface during design reviews. Ask engineering leads to confirm which build flags and templates already do this and which still need a change request.
Keep audit logs for public-facing applications
Enable and retain access logs on every internet-facing web application, reverse proxy and API gateway, including request paths, status codes, user agents and referrers. Without these records, a burst of crawling against directory listings or old endpoints leaves no trace. Under the Audit mitigation (M1047), confirm that logs are forwarded to a central store that the security team can query, and that retention meets your policy. Verify with a sample search that a crawl from an unfamiliar source is visible within your normal workflow.
Control exposure of development and test assets
Staging sites, backup files, old repositories and debug endpoints are common sources of detail that were never meant for the public. Application Developer Guidance (M1013) supports separating these environments from public DNS and requiring authentication for them. Inventory certificate transparency records and public DNS for your domains, so that unexpected hostnames surface to the owning team. Ask the owners to confirm which hostnames are intentionally public and which should be retired or restricted.
Confirm mappings for your ATT&CK version
The mitigations listed here are the ones ATT&CK maps to this technique and its sub-techniques, but mappings can change between releases. Before you rely on them in a control register or an assessment, check the relationships in the STIX bundle for the ATT&CK version you target. Name that version in your documentation, since releases can rename or deprecate techniques. Ask your implementation partner or internal ATT&CK owner to record the bundle version used for each mapping.
What the SOC does when a T1593 detection fires
The first decision is whether the alert reflects authorized activity. Before anyone opens an incident, the analyst should check the change calendar, the list of sanctioned external scanners and monitoring services, and any brand protection or threat intelligence vendor the organization has engaged. Search engine crawlers, uptime monitors and certificate transparency tools can all generate lookups against public pages and domains that look like reconnaissance in isolation. Confirm the source addresses, user agents and query patterns against that inventory. If the activity matches an approved service, record the match, close the alert and note the service owner so the allowlist can be reviewed later.
If the activity is unexplained, establish scope in a fixed order. Identify which public host, path or domain was touched, and what content was exposed there, such as documentation, configuration files, staging hostnames or job postings that reveal internal technology. Then check whether the same source later reached internal systems, sent authentication attempts against exposed services, or followed a sequence of requests that suggests the adversary acted on what it found. Correlate the web server access logs with proxy, VPN and identity provider records for the same window. Activity that stays on public content with no follow-on traffic usually supports a monitoring or staff-led investigation, not an incident. Escalate to incident response when follow-on activity against internal assets is confirmed, when the exposed content includes credentials or secrets, or when the source cannot be explained by an approved owner.
Preserve evidence before anything is changed, then tune. Export the relevant web, proxy and DNS logs with their original timestamps and hashes, and retain them under the retention rules your legal and compliance teams have set. Notify the owners of any exposed content so they can remove or rotate what was revealed, and record the removal as a finding. After the review, adjust the rule: add confirmed scanners to the allowlist with an expiry date, narrow thresholds that fired on normal crawling, and document each change against the ATT&CK version the rule targets. Confirm with your own change process how these updates are approved, because an overly broad exclusion can hide the next real lookup.
Rehearsing T1593 detection in a private cyber range
The range is a private environment that the client or DeployOpen owns and operates, isolated from production and from the public internet. It holds a test domain, a representative web application with public-facing pages, and a logging stack the defending team controls. Because T1593 is about searching open websites and domains for information, the range needs content that resembles what an organization exposes publicly, such as job postings, documentation pages, version strings and contact pages, all seeded with clearly fictional data. Confirm with your own team which components are in scope before anything is built.
- Test domain and web tier: A registered or internally resolvable test domain, with a web application that serves realistic but fictional public content.
- Logging stack: Web server access logs, application logs and any reverse proxy or CDN logs forwarded into a SIEM such as Wazuh, with retention long enough to review the full exercise.
- Network sensors: Zeek or Suricata placed on the range segment so that inbound web requests are visible at the network layer.
- Ownership and access: A named owner for each component, with documented admin accounts and a rollback procedure.
- Scope document: A written scope and rules of engagement that define allowed hosts, time windows and stop conditions.
Confirm the logging retention and sensor placement with your platform team before the first exercise.
Injects are scripted, benign reconnaissance-style activities that the red team plans in advance and runs on a schedule agreed with the blue team. For T1593, injects mimic how an outside party would research an organization using public web content: reviewing pages, following links, querying for indexed pages and checking for exposed technology hints. Each inject is written as a plan with an objective, the expected log footprint, and a stop condition. The red team does not improvise outside the written scope, and the blue team is not told which inject is running at a given time unless the exercise design calls for it.
- Inject catalog: A numbered list of planned activities, each mapped to the ATT&CK version the team targets and to its T1593 sub-technique.
- Expected footprint: For each inject, the log sources and fields that should show the activity, written before the run.
- Pacing and volume: Agreed request rates and time windows, so the exercise does not disrupt other range users.
- Stop conditions: Clear triggers, such as unexpected impact on the range or a request to halt, that end an inject immediately.
- Deconfliction contact: A named person who can pause the exercise at any time.
Check that every inject traces back to a line in the written scope before the exercise begins.
Good detection is measured by what the team sees, how quickly it sees it, and what it does next. Each inject should be compared against the expected footprint so that the team can state which activity was logged, which was missed and why. Response is judged on triage quality: whether the analyst recorded the indicators, reached a severity decision with stated reasons, and escalated according to the runbook. The exercise closes with a post-exercise tuning record that links each finding to a rule change, a logging gap or a documented accepted risk.
- Alert timing: Time from inject start to first alert, recorded for each inject, with the gap explained when it is long.
- Triage notes: Analyst notes that list the source, the affected host, the decision and the reason for it.
- Coverage gaps: Injects with no alert or no log entry, each assigned to an owner.
- Tuning record: A table of rule changes, threshold changes and suppressions, each with the Sigma or SIEM rule identifier and a reviewer's sign-off.
- Retest plan: A scheduled rerun of the same injects after tuning, so the team can confirm the change worked.
Check that the tuning record shows before and after results for every change.
Questions SOC leads and detection engineers ask about T1593
How do we tell authorized scanning from T1593 reconnaissance?
You separate them by provenance and intent, not by the query itself. T1593 activity is searching public sources such as websites, domains and their content, which happens entirely outside your network, so your visibility is limited to what reaches your own web and DNS properties. Keep a register of authorized assessment sources, such as your penetration testers, your attack surface monitoring vendor and your partners, with their IP ranges, user agents and time windows agreed in writing. Alerts that match a registered source are tagged and closed automatically. Anything else that enumerates paths, certificates or subdomains against your properties goes to triage. Test the register against a scheduled exercise so the tagging logic is proven before it is trusted.
Which logs are most useful for detecting T1593 against our own properties?
Most T1593 work happens in public sources you cannot observe, so the useful signals are the traces that reach your own estate. The most useful are:
- Web server and reverse proxy access logs, which show requests for unlinked paths, sitemap and robots file probing, and repeated 404 responses from one source.
- Application logs, which expose searches against content that was never meant to be indexed.
- DNS query logs and certificate transparency monitoring, which show new subdomains appearing and being queried.
- Network traffic content and flow data from your perimeter, for correlation.
Data component mapping in ATT&CK should be confirmed against the detection strategies for the version you target, because data component IDs changed in v18.
How do we version detection rules against ATT&CK releases?
Record the ATT&CK version in the rule metadata and in your mapping file, and treat every rule as tied to that version. ATT&CK v18 released on October 28, 2025 replaced detections in technique pages with detection strategies and analytics, and data sources were deprecated in favor of data components. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques, so review your T1593 mappings at each release and log the diff. Keep the rule logic in version control so you can explain why a rule changed.
How can we test T1593 detections without creating real exposure?
Test against a private cyber range that mirrors your web, DNS and logging stack, not against production or third-party sites. Your team or an authorized tester generates simulated search and enumeration traffic against a lab copy of your public-facing properties, with the scenario, timing and expected log outcomes written down beforehand. This proves that your access logs, DNS logs and correlation rules fire without touching real customers or third-party systems. Keep the exercise scope written, name a rules owner, and retain the results as evidence for your detection validation record.
Can we run this ourselves, or do we need an outside partner?
Many SOC teams can run the logging and rule work in-house if they already operate a SIEM and web and DNS telemetry, and the main skill gaps are usually threat intelligence mapping and range design. An outside partner is useful when you need a fixed-scope build of the logging pipeline, a documented validation exercise, or an independent view of coverage. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, runs security testing and private cyber ranges, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.
When should we confirm T1593 mappings in the STIX bundle?
Confirm mappings every time you change the ATT&CK version your detections target, and whenever a mapping drives a rule you plan to deploy. MITRE publishes ATT&CK content in STIX 2.1 format in the attack-stix-data repository, with one bundle per domain and version, so you can query the relationships directly rather than relying on a summary. Check the Enterprise bundle for the version you target, confirm that T1593 and its sub-techniques still exist with the expected tactic, and check which data components and mitigations the detection strategies reference. Record the bundle file name and version in your change log so auditors can reproduce your mapping.
What is the first step if a T1593 alert shows unexpected enumeration of our domains?
Start by confirming whether the activity matches a registered authorized source, then assess whether it reached anything sensitive. Pull the related web, DNS and certificate records for the window, check whether the paths or subdomains requested exist and were exposed, and look for follow-on activity such as authentication attempts or requests to restricted content. If nothing is authorized and no sensitive content was reached, record the event, consider whether content or certificate hygiene needs attention, and update the detection if it was noisy or missed. Escalate under your incident process if sensitive exposure or follow-on activity is found.
How DeployOpen builds T1593 detections and range scenarios
DeployOpen approaches T1593 Search open websites/domains as a fixed-scope engagement inside your own infrastructure, with detection logic written against the ATT&CK version you name in the scope. The work covers open-source telemetry, validation in a private cyber range and documentation your team can run without us.
How we scope
- Written scope names the T1593 sub-techniques, log sources and platforms covered before work starts.
- We confirm which ATT&CK version the detection mappings target, since releases can rename or deprecate techniques.
- Scope lists which web-facing assets, DNS records and public content sources are in or out of monitoring.
How we build
- We implement detection logic for web server, proxy and DNS telemetry in your chosen open-source stack.
- Detection rules are written in Sigma format and mapped to the ATT&CK data components they rely on.
- We tune rules against your own traffic baseline so that benign crawling and search engine activity is labeled rather than alerted on.
How we hand over
- Deliverables include rule files, data source mapping, configuration notes and a runbook for analysts.
- A validation report records which cyber range scenarios were run and which detections fired in each.
- Your team receives training on triage steps, false positive handling and how to update rules for new ATT&CK releases.
How we support
- Ongoing support, rule updates and continuous testing are available as a retainer after handover.
- Retainers can cover review of new ATT&CK releases and changes to your public web footprint.
- Confirm the response times, support hours and escalation path with us in the written quote.
