Detecting T1597 Search closed sources

How T1597 Search closed sources shows up before an intrusion starts

For a SOC lead, the central question is whether anything in the victim's own environment reveals that an adversary is researching the organization before an attack begins. T1597 Search closed sources is the ATT&CK technique for that planning activity: an adversary gathers information from sources that are not publicly accessible, such as paid or restricted-access data. ATT&CK splits it into two sub-techniques, one covering threat intelligence vendor data and one covering technical data bought from third parties. Confirm the current IDs and titles of both in the ATT&CK 20.0 release, since these pages target that version. The parent tactic, Reconnaissance, is defined by MITRE as: "The adversary is trying to gather information they can use to plan future operations." The MITRE ATT&CK tactic page for Reconnaissance gives the wider context.

Reconnaissance happens outside the victim's perimeter. MITRE describes ATT&CK as a globally accessible knowledge base built on observed adversary behavior, and this technique is a good example of why: a query to a paid data provider never touches your network, so the activity leaves no trace on your systems when it happens. Closed-source research takes place before initial access, so the earliest sign inside your estate is usually a downstream effect. Examples (illustrative only) include targeted phishing that uses details an outsider could only know from aggregated data, or sign-in attempts against accounts that were never publicly listed. Most detection therefore depends on your own logs: web and API access logs, mail gateway records, identity provider sign-in events and directory change history. Treat any single indicator as weak and correlate it over time.

The decision for the SOC lead is which of those logs to retain, for how long, and who owns correlation across them. Confirm that web, mail and identity sources reach the SIEM with enough history to spot slow, low-volume patterns that build up over weeks. Check that the telemetry you rely on maps to the data components referenced by the ATT&CK 20.0 detection content, and record the targeted version in every detection so that a later release which renames or deprecates content does not silently break coverage. Ask your threat intelligence provider what it collects and what it shares contractually before you assume a sensitive exposure is being monitored. Plan the response too: a lead about closed-source exposure should trigger a review of recently targeted accounts and publicly visible technical details, not an automatic incident.

Which data sources reveal T1597 activity and the tools that collect them

This table pairs each data component that ATT&CK detection strategies most often reference for Reconnaissance techniques with the signal it can reveal for T1597 and the open-source collector that captures it. Closed-source collection happens largely outside your environment, so these sources only show traces where your network, proxies or accounts touch a vendor or broker. Confirm the T1597 data component mapping in the ATT&CK 20.0 bundle before relying on any row.

Data component	Signal to look for	Open-source collector	What to confirm
Network Traffic Content (DC0085)	Inspected web content showing staff use of paid intelligence or broker sites, where lawful	Suricata TLS metadata and Zeek http and ssl logs in Security Onion	Inspection policy and legal basis, since encryption often hides content
Application Log Content (DC0038)	Proxy and SaaS audit entries for access to vendor portals or broker sites	Wazuh agents collecting proxy and web gateway logs	Whether proxy logs keep full URLs or only domains
Network Traffic Flow (DC0078)	Connections to known intel or broker domains, especially unusual volume from servers	Zeek conn logs and Suricata flow records in Security Onion	Your baseline of approved vendor traffic so feeds are not misread
Response Content (DC0104)	Responses from external services showing paid or restricted data was retrieved	Limited: Velociraptor artifacts on managed hosts and proxy captures	Whether any response content is visible, since this is often the weakest source
Endpoint and server coverage	Telemetry from the endpoints and servers where searches start	Wazuh and Velociraptor inventory of endpoints and browsers	Which groups, such as researchers or executives, lack coverage

Detection ideas for T1597 that SOC teams can build today

T1597 Search closed sources is hard to see because the adversary queries third-party data sources rather than the victim's systems. The cards below therefore focus on the signals that do reach the victim: web and API access patterns, identity and mail activity, and the internal workflows that a SOC can correlate against. Write each rule against a named ATT&CK version, express it in Sigma for portability, and tune it against known benign sources before going live.

Monitor brand and credential exposure queries

Some T1597 activity involves searching breach and paste collections for employee addresses, passwords or internal hostnames. The victim rarely sees those queries, but it often sees the follow-on use of exposed material. Correlate authentication failures against accounts that appear in external exposure feeds, grouping by source address and user agent. Confirm which feeds your organization licenses and how often they refresh, because stale data inflates false positives.

Correlate logins from new geographies

Access to a victim account using credentials harvested from closed sources often shows a source network or country the user has never used. Build a baseline per account over a rolling window and alert when a successful sign-in lands outside it, then join the result with recent failed attempts. Log fields to correlate include user principal, client IP, autonomous system, user agent and the authentication protocol. Expect travel, VPN egress and cloud relay addresses to produce noise that needs allowlisting.

Flag mass lookups of internal document references

Adversaries may pull leaked or purchased material that references internal file names, project codes or public-facing document paths. On the victim side, look for bursts of requests to document repositories or web paths that match those names, especially from a single client across many distinct objects. Set a threshold on distinct object requests per source within a short window, and exclude crawler user agents already known to your SOC. Application Log Content from the web tier is the primary source.

Detect unusual mail probing after leaks

Once contact details or addresses appear in closed sources, senders may test them with mail that bounces or is rejected for unknown recipients. Track the rate of rejected recipient addresses per sending host and flag hosts that enumerate many addresses in a short period. Mail gateway logs supply the sender, recipient, response code and timing fields. Mailing list migrations, newsletter platforms and misconfigured applications are common false positive sources.

Suppress known benign research sources

Threat intelligence vendors, security researchers and your own red team all generate traffic and searches that resemble T1597 activity. Maintain a dated register of sanctioned sources and red team windows, and encode it as allowlist logic that carries an owner and an expiry. Review suppressions at each ATT&CK version update, because releases can rename or revoke techniques and change how detections map. Record the reason for every suppression so that auditors can trace it.

Package rules in Sigma with version tags

Write each detection as a Sigma rule so it can move between SIEM and log platforms such as Wazuh or Security Onion with conversion tooling. Each rule should name the ATT&CK version it targets in its tags and record the data components it depends on, so that a future release does not silently break coverage. Validate every rule against replayed logs from a private cyber range before promoting it to production, and retire rules whose underlying technique is deprecated.

How to confirm the T1597 detection fires in a lab

This sequence turns the T1597 detection logic into a tested control by agreeing the emulation scope, recording expected telemetry and alerts, running the exercise in a private cyber range, and closing every gap with evidence. The output is a signed-off results record that shows which sub-techniques the detection catches and which still need work.

Agree emulation scope with the detection owner
The detection owner, usually the SOC lead or detection engineering lead, and the DeployOpen team agree in writing which T1597 sub-techniques are in scope, which lab or cyber range hosts the exercise, and which data sources and alert paths are in play. Confirm the ATT&CK version the mapping targets, since releases can rename, deprecate or revoke techniques. The step is done when the scope document is approved and names an accountable owner for every decision.
Select sub-techniques to test
Choose the two T1597 sub-techniques to test, prioritizing the ones where your organization has the highest exposure or the weakest existing coverage. Record why each was chosen and which detection strategy or analytic in your ruleset is meant to cover it. The step is done when each selected sub-technique is linked to a named rule or a documented gap, so no test runs without a target.
Record expected telemetry and alerts
Before the exercise, write down what should happen for each selected sub-technique: which data components should contain evidence (for example Network Traffic Content or Application Log Content), which log sources should carry it, and which alert should fire, with its severity and destination. This prediction is the baseline the results will be measured against. The step is done when the expectations are reviewed by the detection owner and frozen with a timestamp, so they cannot be edited after the run.
Run the exercise in the cyber range
The DeployOpen team runs the agreed exercise in the private cyber range, following the approved scope and keeping the activity inside the lab boundary. A second person from the client side observes the run and notes the start and end times of each activity. The step is done when every in-scope sub-technique has been exercised once and the observer has signed off the run log.
Compare results against expectations
Check the SIEM, the Wazuh or Security Onion alert queues, and the relevant log sources against the frozen expectations. For each sub-technique, mark whether the telemetry arrived, whether the rule matched, whether the alert reached the right queue, and whether the severity was correct. Logging delays and missing fields are recorded as separate findings. The step is done when every expectation has a result of matched, partially matched or missed.
Tune the rule and retest
For each gap, decide whether the fix belongs in the log source configuration, the parser, the rule logic or the alert routing. Make the change under change control, then rerun the same sub-technique so the before and after results can be compared. Keep the earlier results rather than overwriting them. The step is done when the retest shows the expected alert or a documented, accepted reason for leaving the gap open.
Record evidence and close the gap log
Store the frozen expectations, the observer log, the raw alert and telemetry exports, the rule version and the retest results together in one evidence folder per exercise. Update the gap log with each finding, its owner, its status and the date it was closed, and link each closed item to the retest evidence. The step is done when the gap log has no item without an owner and a status, and the detection owner signs the summary. This record also supports compliance readiness reviews, although it does not replace an independent assessment.

Preventive controls that reduce T1597 exposure

T1597 Search closed sources describes adversaries using information obtained from sources that are not publicly open, such as commercial or private data. The controls below reduce how much useful material exists to be found and how quickly your teams notice when it leaks. Confirm each mapping against the ATT&CK 20.0 mitigation relationships before you cite it in an audit file.

Pre-compromise planning

Pre-compromise (M1056) is the ATT&CK mitigation that covers activity before an adversary reaches your environment. For a self-hosted platform, this means keeping an inventory of which external data sources, vendors and threat-intelligence feeds your teams use and who holds those accounts. Confirm with the ATT&CK 20.0 relationship list whether M1056 is mapped to T1597 and its sub-techniques. Review the inventory on a set schedule.

Hardened software configuration

Software Configuration (M1054) asks you to set platform options so that they expose less information to outside parties. For self-hosted tools, review settings that publish version strings, verbose error pages, exported reports or shared dashboards. Check whether any internal configuration is synced to vendor or third-party services, since that data can end up in sources an adversary may later search. Confirm the mapping to T1597 in ATT&CK 20.0.

Audit of shared and exported data

Audit (M1047) is about checking that configurations and permissions match what you intended. Apply it to the places where internal material leaves your control, such as vendor support uploads, shared code repositories, public paste services and third-party analytics. Periodic reviews reveal material that would be valuable if a closed or commercial source collected it. Verify the T1597 mapping before relying on it.

Secure developer guidance

Application Developer Guidance (M1013) covers the coding and deployment standards that stop secrets and internal details from appearing in software artifacts. Require teams to keep credentials, internal hostnames and architecture notes out of build outputs, container images and tickets that third parties may access. Confirm with ATT&CK 20.0 whether M1013 relates to T1597 for your sub-technique scope.

Removing unused features

Disable or Remove Feature or Program (M1042) reduces the number of services, plugins and integrations that can leak information. Each unused connector to an external provider is another path where data can be collected outside your control. Inventory integrations in your self-hosted stack, disable those with no owner and document the decision. Check the ATT&CK 20.0 mitigation mapping before citing it.

User training on data handling

User Training (M1017) addresses how staff handle internal information in external tools, including commercial data brokers, AI services and public forums. Training should explain which datasets are sensitive and where they may not be pasted or uploaded. Ask your provider to show how training content is tracked against the controls it supports, and confirm the T1597 relationship in ATT&CK 20.0.

Triage and response when a T1597 alert fires

A T1597 alert asks one question: is someone preparing an operation against us, or is this a benign event that happens to touch information we hold? Most first alerts resolve as benign, so the analyst's first task is to establish where the signal came from. Record the rule identifier, the telemetry source and the ATT&CK version the rule maps to. Then check the source against known context: a threat intelligence platform query run by your own team, a researcher disclosure, a scheduled exposure review, or an internal exercise recorded in the change calendar. If the source cannot be tied to any of these, treat it as unexplained and keep going. Ask the rule owner to confirm the mapping, because a rule written for one version of the framework may not match its current wording.

Next, correlate the alert with what happened afterward. Pull the same identifiers, account names, hostnames or document references from the alert and search authentication logs, mail gateway events, web application logs and access records for the period your playbook defines. If an item that was exposed later appears in failed logins, password reset requests or unusual access from unfamiliar infrastructure, the event moves from informational to suspicious. If nothing follows, the decision is simpler. Where the source is confirmed and benign, monitor and add a time-limited suppression with a named owner and a review date. Where the source is unknown and later activity matches, block at the perimeter if the control allows it, and escalate to incident response. Confirm with application owners first, since blocking a third-party integration can cause an outage.

Notify the owners of any exposed information as soon as the decision is made. The data owner, the application or service owner and, where personal data is involved, the privacy or legal contact each need the specific item, not the full alert. Ask them to rotate affected credentials, review access or confirm whether the information is already public. Close the loop by writing the outcome into the case record: alert identifier, source assessment, correlation results, decision taken, owners notified, rule changes and the next review date. Keep the record consistent across alerts so that a later reviewer can see why a suppression exists. Use the same playbook in your cyber range exercises so that analysts practise the source check, the correlation window and the documentation step before a real alert arrives.

Rehearsing T1597 detection in a private cyber range

A private cyber range for T1597 needs a contained network, a set of seeded services that stand in for the client's externally visible assets and a telemetry pipeline that collects what the detection depends on. Because T1597 concerns closed sources such as commercial threat intelligence feeds, data broker records and other paid or restricted datasets, the range rarely reproduces those sources directly. Instead, the team models the signals that organizations can observe when their own data appears in such sources, such as credential exposure notices and unusual access to internal records, and confirms those signals reach the SIEM. The stack below is typical for self-hosted open-source deployments.

Isolated network segment: Keep the range in its own segment with no path to production, and document the boundary so the exercise cannot leak into live systems.
Log collection: Forward application and identity logs to Wazuh or a similar collector, and confirm timestamps and host names are consistent across sources.
Network sensors: Run Zeek or Suricata on the range segment so that Network Traffic Content and Network Traffic Flow records are available for correlation.
Detection content: Load the Sigma rules that map to the DET identifiers for the ATT&CK version your team targets, and record that version in the test plan.
Version control: Store range configuration and rule versions in Git so results can be reproduced.

Confirm with your platform owner which log sources exist in your environment before you claim coverage for any sub-technique.

How to measure T1597 coverage over time

Measuring coverage for T1597 Search closed sources is a lifecycle task, not a one-time mapping exercise. The first decision is to pin every coverage record to the ATT&CK version it was written against, because a score from one release cannot be compared with a score from another without a reconciliation step. Record the version (for example, the Enterprise ATT&CK 20.0 STIX bundle) alongside each detection, the data components it depends on, and the date the mapping was last checked. A coverage matrix that lacks this metadata will quietly drift out of sync with the framework and will mislead anyone reading it later.

Renames, splits and deprecations need an explicit review each time MITRE publishes a release. The MITRE ATT&CK updates page lists the changes for each version, and the v18 release notes describe the move from technique-embedded detections to detection strategies and analytics, along with changes to data components and the deprecation of data sources. For T1597 and its two sub-techniques, check whether the names, IDs, descriptions or data component references changed between v18, v19 and v20. Where a sub-technique's scope shifted, mark the affected rules as needing review rather than assuming they still cover the same behavior. Confirm any changes against the release notes for your target version, since this guidance does not restate them.

Schedule retests whenever a rule, a log source or a data component feed changes. In practice, that means a retest after any Wazuh or Sigma rule edit that touches closed-source search activity, after a change to the logging or proxy configuration that feeds the telemetry, and after an ATT&CK version upgrade. Use a small, repeatable test set that exercises the same behavior each time, and record whether the expected alert fired, how long it took to appear, and whether the telemetry was present at all. Treat a silent source as a finding in its own right, because a rule that never receives data will report zero detections and look healthy. Agree the retest cadence and ownership with your detection engineering lead before the next release cycle.

Common questions from SOC leads and detection engineers about T1597

How is T1597 different from T1593 and T1596?

T1597 covers adversary searches of closed or paid sources, such as commercial threat intelligence platforms and purchased technical data. T1593 covers open websites and domains, and T1596 covers open technical databases. The practical difference is visibility: closed sources usually sit behind an account or a contract, so the query never touches your network or your logs. Separate the three techniques in your mappings so that a coverage report does not imply you can see activity that happens on a vendor's platform. Confirm the exact definition and sub-technique list on the ATT&CK page for the version you target before you write rule metadata.

Which logs should we prioritize first for reconnaissance coverage?

Start with the data your own environment produces that can reveal exposure, because searches of closed sources are rarely visible to you directly. Prioritize the following:

Application log content from internet-facing services, to spot queries and access patterns that match your exposed data.
Network traffic content and flow records at your perimeter, to see inbound activity that follows leaked or purchased information.
Authentication logs for accounts and services whose identifiers may have been exposed in breach or vendor data.

The ATT&CK data components most often referenced for Reconnaissance include Network Traffic Content (DC0085), Application Log Content (DC0038) and Network Traffic Flow (DC0078), which is a useful starting point for log onboarding. Validate each source with a test event before you rely on it.

How do we keep our own threat intelligence team from triggering alerts?

Build an allowlist of the accounts, service identities, source addresses and platforms that your threat intelligence team uses, and tag them in the SIEM with an owner and an expiry date. Tie each entry to a change ticket so that suppressions are reviewed, not forgotten. Suppress by identity and source together, not by rule, so that a compromised analyst account still produces an alert. Test the suppression in a cyber range by running approved queries and confirming that the expected events are tagged while unexpected activity from the same identity still raises an alert. Review the allowlist whenever the team changes tools or vendors.

How should we version Sigma rules against ATT&CK releases?

Record the ATT&CK version each rule was written against in its metadata, and store the technique IDs in the rule rather than only in a dashboard. Pin your mapping to the Enterprise ATT&CK 20.0 STIX bundle for your current baseline, and create a review step for each new release. Releases can rename, deprecate or revoke techniques, and ATT&CK v18 replaced technique-page detections with detection strategies and analytics, so a rule that looked correct last year may now point at a changed definition. Keep a changelog in version control, and run a scripted check that flags rules whose technique IDs are no longer active.

How do we confirm a technique mapping in the STIX bundle?

Download the Enterprise ATT&CK 20.0 bundle from the attack-stix-data repository and search for the technique or sub-technique ID. Check that the object is an attack-pattern, that it is not marked as revoked or deprecated, and that its kill chain phases include the tactic you expect. For sub-techniques, confirm the parent relationship and the sub-technique flag. Write a short script that performs these checks for every ID in your rules, and store its output with the rule set so auditors can see when the mapping was last verified. Repeat the check whenever you change the baseline version.

Can we detect T1597 from our own network at all?

Direct detection is limited, because the search itself happens inside a closed source that you do not operate. Most practical signals are indirect. They include your data or credentials appearing in breach or dark web monitoring, alerts from threat intelligence vendors about your brand or infrastructure, and unusual inbound activity that follows exposure. Treat these as exposure monitoring, and document the gap in your coverage statement. Ask any monitoring vendor to state in writing which sources it covers, how often it refreshes, and what it cannot see. Pre-compromise (M1056) is the ATT&CK mitigation most often mapped to this group of techniques, so reducing what is exposed is usually the stronger control.

Can our team rehearse T1597 in a cyber range, and what would DeployOpen cover?

Yes, your team can build a rehearsal from ATT&CK data and open tooling, and the same scenario can run in a private cyber range. A rehearsal should define the exposed data, the expected signals and the response steps, then check whether analysts see the indirect signals and act on them. DeployOpen runs private cyber ranges and security training, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. Ask any provider to specify the environment, the telemetry it will generate and the evidence you will receive at the end.

How DeployOpen builds T1597 detections and range exercises

DeployOpen works on T1597 Search closed sources as a fixed-scope engagement inside the client's own environment, with the scope agreed in writing before work starts. The output is open-source detection content, validated telemetry and range exercises that the client's own team can run and maintain.

How we scope

Confirm which ATT&CK version the detection mapping will target, since releases can rename or deprecate techniques.
Agree which sub-techniques of T1597 are in scope and which telemetry sources the client can actually supply.
Record the written scope, deliverables and timeline before any detection work begins, with ongoing support available as a retainer.

How we build

Map T1597 detection strategies to the data components your environment collects, such as network traffic content or application logs.
Write detection logic in open formats such as Sigma rules and deploy it to the client's chosen platform, for example Wazuh or Security Onion.
Document the Pre-compromise mitigation and the monitoring gaps that remain, where visibility into external sources is limited.

How we hand over

Deliver detection rules, configuration and mapping documents with the ATT&CK version named in each file.
Provide a cyber range runbook describing how the team rehearses T1597 detection and response in a private environment.
Walk the client's security engineers through validation results and record which items the client owns after handover.

How we support

Review detection content when ATT&CK releases change T1597 or its sub-techniques, and record each revision.
Retest detections after telemetry sources or log formats change in the client's infrastructure.
Offer ongoing support, upgrades and continuous testing through a retainer agreed in writing.

T1597 Search closed sources