How T1594 search of victim-owned websites shows up before an intrusion
If your public websites are the first thing an adversary reads, your SOC needs to know that T1594 Search victim-owned websites is reconnaissance aimed at your own sites. In MITRE ATT&CK Enterprise version 20.0, this technique sits under the Reconnaissance tactic (TA0043), whose stated purpose is to gather information the adversary can use to plan future operations. The adversary reviews your pages, linked scripts, page metadata, HTML comments, error pages and similar public material to learn how your applications are built, which frameworks and versions they run, and where the interesting functions live. None of this requires a login or a single exploit, which is why it is easy to miss.
From the victim's side, most of this activity looks like ordinary web traffic. Each request is valid, usually a plain page or asset fetch, and it arrives from the same kinds of sources that legitimate visitors, search crawlers and monitoring services use. The signal is therefore not one request but a pattern: a single source or a cluster of sources retrieving many pages, scripts and error paths in a short window, or retrieving files that normal users rarely need. Your web server and application logs, and any upstream proxy or content delivery network logs, are where that pattern is first visible. Confirm with your web platform team which of these logs are retained, for how long, and whether query strings and user agents are recorded, because those fields determine what you can baseline.
The practical decisions start before any alert fires. Decide which public content reveals more than it should, such as verbose error output, build metadata, version strings in headers or scripts, and developer comments left in production builds. Decide who owns review of that content and how often it is checked. Then confirm, in your own environment, how your web tier logs requests and where those logs land in your SIEM. ATT&CK maps this technique to the Pre-compromise mitigation (M1056), which reflects that much of the defensive work happens before the adversary acts. Treat the content review and log coverage as the controls you can actually verify, and record which ATT&CK version your detection mapping targets, since releases can rename or revoke techniques.
Which telemetry reveals T1594 and which open-source tool collects it
This table maps each telemetry source that can show T1594 activity against a victim's own websites to the open-source tool that typically collects it. Read it as a starting point: the detection value of each row depends on which fields your web tier actually logs. The main takeaway is that Application Log Content (DC0038) carries most of the signal, and Network Traffic Content (DC0085) only adds value where TLS is terminated inside your perimeter.
| Telemetry source | Role for T1594 | Open-source collection | What to confirm in your environment |
|---|---|---|---|
| Web server access logs | Primary DC0038 source. Record requested paths, status codes, user agents and client addresses for pages that expose site structure, such as sitemaps, directory listings and documentation paths. | Wazuh agents reading the web server log files, forwarded to the Wazuh manager | Whether access logs include the full request path, the referrer and the user agent, and whether they are retained long enough to baseline normal crawling |
| Reverse proxy and load balancer logs | Primary DC0038 source for sites fronted by a proxy. Often the only place where requests from many clients are recorded in one format. | Wazuh agents or log shipping into Security Onion for indexing and search | Whether the proxy logs the real client address or only the upstream address, and whether header values are truncated |
| Application logs | Supporting DC0038 source. Shows requests to application routes that the web server log may not separate clearly, including errors from probing of unknown endpoints. | Wazuh log collection with decoders for the application's log format | Whether the application writes request-level events, and whether sensitive values such as session tokens are masked before they reach the log |
| Network Traffic Content (full request inspection) | Secondary DC0085 source. Allows request content inspection where TLS is terminated inside the perimeter, such as at an internal inspection point. | Zeek for protocol-level HTTP logs and Suricata for signature and content matching, both surfaced through Security Onion | Whether TLS is terminated inside your perimeter; where it is terminated at a third-party edge, this source may show only encrypted traffic |
| Coverage limits | Visibility gaps reduce what any row above can show, such as content served from a CDN or third-party analytics on the site. | Not a collection tool. Document the gap in your detection notes. | Which hosts, sites and paths are excluded from logging, and whether CDN logs are available to the monitoring team |
| Mapping version | ATT&CK v18 replaced several data component references. This mapping targets Enterprise ATT&CK version 20.0. | Not a collection tool. Record the version in each detection rule so future updates can be reviewed. | Whether your rule library references DC IDs from before v18 and needs updating |
Detection logic for T1594 that SOC teams can tune
These cards describe detection ideas for T1594 Search victim-owned websites built on Application Log Content, the data component ATT&CK most often references for this technique family. Each idea is a starting hypothesis: thresholds only become meaningful once they are measured against the normal traffic profile of each site, and the false positive sources listed here should be excluded or labeled before alerts reach analysts.
Volume spikes on rarely visited pages
Build a per-path baseline of request counts over a rolling window, then alert when a low-traffic page, such as an internal-style documentation index or an old release note, receives a burst far above its normal range. Real users seldom reach these pages, so a sudden rise from a small set of sources is the clearest early signal of reconnaissance. Tune the multiplier and minimum count separately for each site, because a page that gets ten visits a day and a page that gets ten thousand need different thresholds.
Sequential crawling of sensitive paths
Watch for one source requesting documentation, configuration, metadata or source-map paths in quick succession, such as a run of files with predictable names across several directories. Count distinct sensitive path families touched per source per time window rather than raw requests, since a single hit on a sitemap is ordinary. Confirm which of these paths your own applications expose on purpose, and exclude them from the rule or lower their weight so that expected content does not generate noise.
Requests for non-existent directories
Alert when one source generates a high rate of 404 responses across unrelated directory names within a short window. Legitimate users typically produce a few broken links, while enumeration produces many misses that follow a pattern. Group misses by source address and user agent, and set the threshold from the observed ratio of 404 responses to successful responses for each site. Review how your web tier logs status codes, because some frameworks return 200 for missing routes and would hide this signal.
Repeated access to technical detail pages
Identify repeated requests to pages that disclose server versions, framework names, health or status endpoints, error traces or build information. Score these by how often a single source returns to them over days, not minutes, because slow and patient collection is common. Pair the rule with an inventory of which pages are meant to be public, so that status pages used by customers and published API references are documented as expected traffic.
False positive sources to exclude
Document and tag known benign sources before tuning thresholds. Common examples are search engine crawlers, uptime monitors, vulnerability scanners that your own team runs, and marketing or SEO tools that fetch pages on a schedule. Verify crawler identity through published address ranges or reverse lookups rather than trusting the user agent string alone. Keep these allowlists in version control with an owner and review date, so an attacker cannot quietly hide inside an exclusion that was never retired.
How to validate that the T1594 detection fires
This sequence proves that the T1594 detection works before anyone relies on it. A team replays a bounded, reconnaissance-style browsing pattern against a staging copy of the victim-owned site, then confirms the events reach the SIEM, the rule matches, and the alert quality is measured and recorded against a named ATT&CK version.
Agree scope and rules with the site owner
The detection team, the owner of the website, and the change approver agree in writing which staging host is in scope, which paths and request patterns will be simulated, the source addresses used, and who is notified when the exercise runs. The site owner confirms that the staging copy does not hold live customer data and that the test will not touch production. The step is done when the signed scope note is filed with the detection record and the owner has confirmed the staging endpoint is reachable only from the test source.
Define the simulated browsing pattern
The team writes down, in plain language, the browsing behavior that the T1594 detection is meant to catch: a burst of requests to pages that expose organization details, such as contact, careers, leadership, and document pages, followed by requests to less common paths that a normal visitor would rarely reach. The pattern is described by request type, volume class, and sequence, not by tooling. The written pattern is reviewed by the detection engineer and the site owner, and it is stored with the ATT&CK version the detection targets so that later runs can be compared to it.
Run the emulation against staging
A named operator runs the agreed pattern from the approved source against the staging copy, following the written plan without deviation. The operator logs the start and end time of each run and the identifier of the run, so the log events can be matched to the exercise later. The step is complete when the run record lists every planned behavior as executed or skipped, with a reason for any skip.
Confirm web server log events reach the SIEM
The engineer checks that the web server and application logs from the staging host are collected, parsed, and indexed in the SIEM, such as Wazuh or a Security Onion deployment, with the fields the rule depends on, including request path, method, status code, timestamp, and source address. The engineer searches for the run identifier or the test source to find the events. The step is done when every planned request has a matching event with complete fields, and any gaps in parsing or ingestion are logged as defects.
Confirm the rule matches the emulated pattern
The detection engineer runs the detection rule, written against Application Log Content (DC0038), over the indexed events from the run window and checks whether it fires on the emulated sequence. The engineer compares the matched events with the planned behaviors to calculate the match rate and notes any behavior that the rule missed. The step closes when the rule's hits, misses, and the exact conditions behind each miss are recorded in the validation report.
Measure time to alert and false positives
The engineer records the elapsed time between the first emulated request and the alert appearing in the case queue, using the SIEM timestamps. The engineer then reviews normal staging traffic from the same period, such as scheduled crawlers and internal monitoring, to see whether the rule raises alerts that a responder would dismiss. The step is done when time to alert, match rate, and the count of false positives with their causes are written into the report, and the results are compared to thresholds the organization agreed beforehand.
Re-run after site changes and record the ATT&CK version
Whenever the website is redesigned, a new content section or path family is added, or the logging configuration changes, the team repeats the emulation and the checks above. Each run records the ATT&CK version the detection targets, such as the Enterprise version used in the rule's mapping, and notes whether any technique or data component referenced by the rule has changed in a later ATT&CK release. The step is done when the updated report is filed, the rule's metadata shows the version it was validated against, and the owner has signed off on the re-run results.
Preventive controls that reduce what T1594 can reveal
T1594 relies on whatever a public website already exposes, so most of the defensive work happens before anything is published. The cards below cover the ATT&CK-mapped control for this technique and the supporting controls that shrink what an adversary can learn from public pages. Confirm the fit of each control against your own publishing pipeline and hosting model.
Pre-compromise as the primary control
ATT&CK maps Pre-compromise (M1056) to T1594, which is the mitigation that sits upstream of any compromise. For T1594 Search victim-owned websites, the practical question is what your organization publishes before an adversary ever looks. Treat every public page, script, and downloadable asset as an input to reconnaissance, and make the review of that output a named step in your release process with an owner.
Pre-release review of public content
Before a page goes live, review it for comments that reveal architecture, credentials placed in client code, and notes left by developers. Check that build output does not include source maps or debug bundles that expose original source paths and logic. Confirm that internal hostnames, staging domains, and admin paths do not appear in HTML, JavaScript, or error messages. Record the review result so the evidence survives staff turnover.
Build artifact and source map control
Build pipelines often copy more into the public web root than the application needs. Configure the pipeline so that source maps, lock files, environment files, and build metadata are excluded from deployment packages, or are served only to authenticated users. Verify the output by inspecting the deployed artifact rather than trusting the configuration file, since the published bundle is what an outside reader actually sees.
Internal hostname and comment hygiene
Internal hostnames, ticket references, and developer comments in public pages tell an outside reader how the organization names and organizes its systems. Add a check to the pipeline that scans rendered HTML and scripts for internal domain suffixes, employee names, and TODO or FIXME notes. Keep the scan list in version control so changes are reviewed, and confirm the list with the teams that own each site.
Software configuration of web servers
ATT&CK maps Software Configuration (M1054) to related Reconnaissance techniques, so it is a reasonable supporting control here. Review server banners, default error pages, directory listings, and verbose response headers that reveal product versions or framework names. Remove sample applications and default files from production images. Confirm with your platform team which settings the web server and reverse proxy actually support in your environment.
Developer guidance and periodic audit
Application Developer Guidance (M1013) and Audit (M1047) are also mapped to related Reconnaissance techniques. Publish a short secure publishing standard for developers that explains what must not appear in public content, then audit a sample of live pages on a schedule to catch drift. Ask the team which audit cadence and ownership model they can sustain, since the value of an audit depends on whether findings are tracked to closure.
Triage and response when a T1594 detection fires
The first triage decision is whether the activity comes from an approved source at all. Before anyone treats a T1594 alert as hostile reconnaissance, confirm that the requesting address is not an approved search engine crawler, uptime monitor, link checker, SEO tool or internal vulnerability scanner. Compare the source against your allow list and the scanner schedules your team owns, and check the user agent and request pattern against the crawler documentation published by the operators you expect to see. Record the result in the case ticket, including the time window, the source address range and the owner who confirmed it. An alert that matches a known crawler should be tuned with a documented exception, not silently closed, because a new source using the same user agent is a common way reconnaissance hides in routine noise.
If the source is not approved, look at what happened next. T1594 activity against a victim-owned website is usually followed by requests for resources that the pages do not link to prominently, such as configuration files, backup archives, development paths, sitemaps with restricted entries, or authentication endpoints like login, password reset and API token routes. In your application logs, pivot on the same source for the following 24 hours and flag any request that returns a success or redirect code on paths outside the normal navigation. Repeated failed logins from the same source against authentication endpoints move the case from information gathering toward credential access, and that change should be recorded as a separate finding. Confirm the time window and thresholds with your own baseline, since the right values depend on your traffic volume.
Next, review what the pages actually disclosed. Check whether the content the source viewed contains internal host names, staging URLs, version strings in page headers or generator tags, developer comments, email addresses, employee names, vendor references, or documents with embedded metadata. Decide with the content owner whether each item needs removal, rewording, access restriction or no action, and record that decision. Remove stale pages and exposed backups from the web root, and confirm the removal in the web server and content delivery network caches, not only in the content management system. If the disclosure is in a document, note who approved its publication. Escalate to incident handling if activity moves to other techniques, for example reconnaissance against exposed services, credential attacks against login pages, or any signs of a foothold in the hosting environment. Hand off with the case timeline, source list, log extracts and the disclosure review so the incident team does not repeat the collection.
Rehearsing T1594 detection in a private cyber range
The range should be a private copy of the public website, deployed in an isolated environment with its own logging stack, so that reconnaissance can be generated and observed without touching production. The copy should match the production content management system version, templates, routing rules and web server configuration as closely as the team can manage, because detection logic depends on how real pages and error responses look. A defined reconnaissance profile, run either by the blue team or by an approved red team, sets the sources, request patterns and pacing so that results can be compared across rounds.
- Website copy: Mirror the public site's structure and content types, with test data that contains no real customer information.
- Logging stack: Forward web server access logs, application logs and error logs to the same platform used in production, so analysts work with the same fields and parsers.
- Reconnaissance profile: Write down the request types, crawl depth, user agents and timing for each round, and record the operator's identity for the exercise.
- Access boundaries: Confirm written authorization, scope limits and a stop condition before the first run.
- Baseline: Capture normal traffic before the exercise so that analysts can separate test activity from ordinary visitors.
Before the first round, confirm with your team which log fields are present, how long they are retained and whether the range matches production closely enough to support the findings.
Injects are planned changes that the blue team introduces during the exercise, or that the exercise control team triggers, to see whether reconnaissance activity shifts in ways that the detection logic captures. Good injects reflect realistic website changes that a team would make in its normal work, so the exercise tests the detection rather than a hypothetical scenario. Each inject should have a stated hypothesis, an expected log signature and a planned rollback, and the exercise control team should record the time each change was made.
- New page exposing a build path: Publish a test page that reveals a development or build directory, then check whether requests to that path are logged, flagged and reviewed.
- Error message change: Alter the wording or detail of a not-found or server error page, then confirm that error-rate and status-code rules still trigger and that the change does not create noise.
- Crawler allowlist update: Add a known crawler to the allowlist, then verify that legitimate crawlers are classified correctly and that unexpected agents claiming to be that crawler are still flagged.
- Content removal: Remove a page that was previously indexed, then watch for requests to stale URLs and confirm that analysts can tell them apart from normal traffic.
- Rollback check: Revert each change and confirm that detection content returns to the expected baseline.
Ask your team to document each inject in a change record so the results can be linked to specific site changes later.
A rehearsal is useful only if it produces measurable outcomes that the team can review. Detection and response should be judged on three things: how long it takes for reconnaissance activity to generate an alert, how well analysts triage that alert, and whether the content owners fix the weakness and record the change afterwards. The exercise should avoid setting numeric targets unless the organization has agreed them internally, and the results should be compared across rounds rather than against an external benchmark.
- Time to alert: Measure the interval between the first matching request and the alert being raised in the monitoring platform, using timestamps from the same clock source.
- Triage quality: Check whether analysts identified the source, the targeted paths and the likely purpose of the activity, and whether they wrote down their reasoning.
- Escalation path: Confirm that the alert reached the right owner for the website and that the handoff was recorded.
- Content fixes: Track the corrections made after the exercise, such as removing exposed build paths, tightening error pages or correcting the crawler allowlist, and assign an owner and a due date to each.
- Lessons recorded: Store the exercise report with the detection rule versions tested, so the next rehearsal can confirm the fixes.
Before closing the exercise, confirm the ATT&CK version your detection content targets and that the report names it.
Questions detection engineers ask about T1594
How do I separate T1594 from T1593 and T1595 in logs?
Separate them by the target and the traffic pattern, not by the tool that generated the request. T1594 (Search Victim-Owned Websites) describes an adversary studying the organization's own sites, so the relevant evidence is requests against your public web properties that look like content harvesting: crawling of pages, documents, job postings, or developer resources. T1593 (Search Open Websites/Domains) covers third-party sources such as social media and public registries, which never touch your servers, so you will not see it in your web logs at all. T1595 (Active Scanning) is probing that sends traffic to hosts and ports to learn what exists, which shows up in network flow and as high volumes of requests to paths that do not exist. Build three separate rule families, tag each with its ATT&CK ID, and expect overlap when a single crawler performs both scanning and content harvesting.
How should I handle CDN and WAF logs when hunting for T1594?
Treat the CDN or WAF as the primary sensor, because it often sees requests before your origin does and may be the only place where client addresses and user agents are recorded accurately. Confirm which header carries the true client address after the CDN, since forwarded address headers can be spoofed unless the edge strips and rewrites them. Ingest edge logs and origin logs into the same pipeline and correlate them by request ID where the platform provides one. Expect the edge to serve cached content, which means some harvesting never reaches your origin. Ask your CDN and WAF vendors to confirm which fields are logged, how long they are retained, and whether bot-management classifications are included in the export.
How do I map alerts to ATT&CK version 20.0 and track changes in later releases?
Pin every rule to the ATT&CK version it was written against, and record the technique ID, sub-technique ID and data component references in the rule metadata. Enterprise ATT&CK version 20.0 is the baseline for these pages. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and each can rename, deprecate or revoke techniques, so a mapping that was correct on one release may need review on the next. Pull the STIX bundle for the version you target from the attack-stix-data repository, script a diff against your rule metadata, and review the MITRE updates pages each release. Assign an owner to that review so it happens on a schedule rather than after an incident.
How can I test T1594 detection rules without production traffic?
Replay recorded or synthetic web logs against the rules in a non-production environment, and build a small set of labeled test cases for each behavior you want to detect: broad page crawls, repeated requests to document libraries, and crawls that mix human-looking and bot-looking user agents. Label the test cases as illustrative until they are derived from your own site structure. Run the same replay through your SIEM with known expected outcomes and record true positives, misses and false positives for each version of the rule. A private cyber range lets you generate this activity against a copy of your public site under controlled conditions, which keeps production teams and third-party services out of the test. Confirm that the range environment mirrors your CDN and proxy header behavior, because a replay that strips forwarded headers will test different logic than production.
Which log fields are needed for reliable T1594 matching?
At minimum, you need a timestamp with time zone, the requested host and path, the HTTP method, the status code, the response size, the referrer, the user agent and a stable client identifier. Add the true client address as resolved after the CDN, the country or network autonomous system where available, and a request or session identifier that links edge and origin entries. Without the host field you cannot separate multiple sites behind one proxy, and without the true client address every rule will group CDN nodes together. Document the schema in a field map, and check it during onboarding and after every platform change. Ask your web platform team to confirm which fields are written to the access log by default and which require configuration.
Can we implement T1594 detection ourselves, and what does DeployOpen cover?
Yes, a team with web operations and SIEM skills can build basic T1594 detection in-house using open-source tools such as Wazuh, Security Onion, Suricata or Zeek, combined with Sigma rules that describe the logic. The harder work is the operating model: keeping rule mappings aligned to each ATT&CK release, maintaining log pipelines as the web stack changes, and rehearsing the response. DeployOpen plans, implements, customizes and documents self-hosted open-source platforms inside your own infrastructure, runs security testing, and operates private cyber ranges for exercises. Scope, deliverables and timelines are agreed in writing before work starts, and most engagements are fixed-scope. DeployOpen does not issue audit reports or certifications, so compliance evidence is reviewed by your independent auditor.
What should we confirm with our web and security teams before starting?
Confirm which public properties are in scope, who owns the CDN, WAF and origin logs, and how long each source is retained. Ask whether bot management is enabled, whether the edge rewrites forwarded client headers, and whether any content is served through third-party platforms that your logs do not cover. Agree on which team receives alerts, the expected triage path and the approval process for running test traffic against production or a copy of it. Record the ATT&CK version you target, currently Enterprise ATT&CK version 20.0 for these pages, so that every rule and test case has a clear baseline. The answers determine how much of T1594 you can observe at all, so capture them before writing any rules.
How DeployOpen builds T1594 detections and range exercises
Every T1594 engagement starts with a written scope that names the websites in scope, the logging sources the client can provide, the people who approve test activity, and the decisions the client expects from the work. DeployOpen plans the detection against ATT&CK version 20.0, the version these pages target, and records the data components the detection depends on, with *Application Log Content* (DC0038) as the primary one for this technique. Because ATT&CK can rename, deprecate or revoke content between releases, the mapping document states its version so that a later update to the knowledge base can be reviewed against it. Confirm with your own team which web server, reverse proxy and analytics logs can actually be forwarded, since that list determines what the detection can see.
Detection work then moves into the client's own logging stack. DeployOpen builds and tunes rules with the platform the client already runs or has agreed to adopt, such as Wazuh for log collection and rule evaluation, with Sigma rules translated to the target query language where needed. The tuning step covers the baseline of normal crawling by search engines, uptime monitors and internal tools, so that alerts reflect unusual access patterns rather than routine traffic. Ownership is agreed in writing: the client's SOC or platform team approves rule changes, and DeployOpen documents the reasoning behind each threshold so that a future analyst can see why it was set.
Detections are then exercised in a private cyber range that mirrors the client's web tier and logging pipeline, without touching production sites. Purple team sessions run agreed test activity, record which events were generated, and check whether the rules fired, how long the alert took to reach an analyst and whether the response playbook was followed. Results are written up as a report that lists gaps, false positives and the remediation owner for each item. DeployOpen runs security testing and cyber ranges and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, and the client should confirm early which evidence its assessor expects.
