How T1590 gather victim network information shows up before an intrusion
Most T1590 activity happens before an attacker touches your network, but some of it leaves traces you can see. If you need to know whether someone is mapping your network ahead of an attack, the honest answer is that you will rarely see the mapping itself. You will see the edges of it: probes that reach your public surface, lookups that concern your domains and address space, and requests that land on services you did not expect to be queried. T1590 Gather victim network information sits under the Reconnaissance tactic (TA0043), which MITRE defines as: "The adversary is trying to gather information they can use to plan future operations." In ATT&CK 20.0 the technique has 6 sub-techniques, so your detection plan should cover the whole family rather than a single behavior.
The information the adversary wants falls into a few groups: network topology, addressing, and domain and trust details. Topology covers how segments, gateways and perimeter devices connect. Addressing covers which IP ranges and hosts are in use. Domain and trust details cover how your DNS zones, directory services and external relationships are arranged. Much of this material is gathered from public records, third-party datasets and other sources outside your environment, so it never crosses your sensors. Detection therefore relies on victim-side signals: traffic that reaches your edge, DNS and certificate-transparency-style exposure that you can monitor for your own names, and changes in how your public services respond to unusual queries.
Plan around ATT&CK version 20.0, and record that version in every detection mapping you write, because releases can rename, deprecate or revoke techniques. Confirm the sub-technique list against the current STIX bundle before you build coverage reports, and ask your detection team which of the six sub-techniques your existing telemetry can actually observe. The result is a short, honest list of what you can see, what you cannot, and which gaps you will accept or close with exposure reduction and reconnaissance-aware hardening.
Which telemetry reveals gathering of victim network information
This table maps the four data components ATT&CK most often references for Reconnaissance techniques to the signal each can show for T1590 activity, and names an open-source collector for each. Read it as a coverage checklist: a row only helps if your organization actually retains that telemetry, so confirm each data component against the ATT&CK 20.0 detection strategies before relying on it.
| Data component | Signal for T1590 activity | Open-source collector | Coverage caveat |
|---|---|---|---|
| Network Traffic Content (DC0085) | Payload-level evidence of queries or requests that ask about the organization's address space, DNS records, routing or service banners | Zeek and Suricata on sensors at network boundaries, with selected content retained | Encrypted traffic hides content, so pair with flow and DNS metadata |
| Network Traffic Flow (DC0078) | Connection metadata showing outside sources touching DNS, mail or web-facing infrastructure in patterns that suggest enumeration | Zeek connection and DNS logs, Suricata flow records, forwarded to Wazuh or Security Onion | Flow data shows who connected, not what was asked, and short retention limits lookback |
| Application Log Content (DC0038) | Requests to public services that reveal network layout, such as unusual path probing, verbose error responses or header lookups against web servers and VPN portals | Web server access and error logs collected by Wazuh agents, plus reverse proxy logs | Only useful where logging is enabled and logs are not rotated out before review |
| Response Content (DC0104) | Responses returned by your own hosts and services that disclose network details, such as banners, certificate names or DNS answers, which show what an outside party can learn | Active checks run by the defender with Nmap or scheduled Wazuh policy checks, and captures of your own service responses via Zeek | Shows exposure, not an attacker's act, so it guides hardening more than alerting |
| Authoritative DNS query logs | Lookups for internal-looking host names, zone transfer attempts or repeated queries for mail and service records from unfamiliar sources | Zeek DNS logs and BIND or other resolver query logging forwarded to Wazuh | Recursive resolver logs may not show queries made directly to your authoritative servers |
| Mail gateway and certificate transparency records | Traffic to mail servers and newly issued certificates naming your hosts, which can expose internal naming conventions | Postfix or mail gateway logs via Wazuh, and public certificate transparency monitoring you run yourself | Certificate transparency is external, so it shows exposure but not who looked |
Detection ideas for T1590 that SOC teams can build first
T1590 activity is mostly quiet by design, so no single event proves it. The cards below combine volume, content and timing signals that edge and log sources already capture. Each one should be tuned against the organization's own baseline and checked against known scanners and approved testing before it pages anyone.
Sustained enumeration volume per source
Count requests from each external source address across a rolling window, grouped by the public hostnames and IP ranges you own. A single source that touches many distinct network-facing paths or hosts over days, rather than in one burst, suggests slow, deliberate collection of network layout. Set the threshold from your own baseline of normal external traffic per source, not from a vendor default. Check whether the source belongs to a known scanner, uptime monitor or approved penetration test before escalating.
Requests for network-description resources
Alert on external requests for files and endpoints that describe your network, such as published address plans, routing or DNS zone exports, status pages with internal host names, and documentation paths that were never meant for the public. Your web server and reverse proxy access logs, such as Application Log Content, usually record these requests. Build the watchlist with your platform and network teams, and review it after each infrastructure change so stale paths do not generate noise.
Repeated unusual protocol responses at the edge
Watch edge services for bursts of malformed requests, unexpected protocol negotiation, and repeated error responses from the same source, which can show an actor learning how a service is built and configured. Network Traffic Content and firewall or load balancer logs are the usual sources. Tune by service and by error class, since some legitimate clients generate the same errors during normal integration work. Confirm with the owning team whether a spike matches a planned change before treating it as reconnaissance.
External reconnaissance followed by internal alerts
Correlate external reconnaissance detections with later internal alerts from the same source or from hosts that the source's traffic reached. The pattern matters more than either event alone: external probing that is followed within a set window by authentication failures, new internal connections to exposed services, or endpoint alerts is a strong lead. Build the correlation rule in your SIEM, such as Wazuh or Security Onion, and set the window from how long your internal detections typically take to fire.
Scanner and test allowlist governance
Maintain a documented list of sources that are expected to probe your edge: vulnerability scanners, uptime monitors, content delivery health checks and approved penetration testers, each with an owner, a source range and an approval window. Tag matching events rather than deleting them, so reviewers can still see activity during the window. Expire entries automatically and review the list quarterly, because stale allowlist entries are a common way real reconnaissance goes unnoticed.
How to validate that a T1590 detection actually fires
This sequence proves, in a private cyber range under an approved emulation plan, that each T1590 detection produces an analyst-visible alert, how long that takes, and which telemetry supported it. It turns a detection rule into evidence that a defender can defend.
Agree the ATT&CK version and sub-techniques in scope
The detection owner and the threat intelligence or red team lead list which of the six T1590 sub-techniques the range will emulate, and record the ATT&CK version the mappings target. Because releases can rename, deprecate or revoke techniques, the version is written into the test plan before any work starts. Done means a signed-off scope sheet lists each sub-technique, its ATT&CK ID, the version and the detection identifiers under test. Confirm the version and any sub-technique changes against the MITRE ATT&CK updates page before the plan is approved.
Approve the emulation plan and rules of engagement
The red team or range operator writes an emulation plan that describes the intended adversary behavior in plain language, the victim assets involved, the expected source addresses, the time window and the stop conditions. Legal, the service owner and the on-call team approve it in writing. Done means the plan is versioned, approved and shared with the analysts who will watch the queue, so that expected activity is not mistaken for an incident. Command lines and tool specifics stay in the restricted operator notes, not in the shared plan.
Baseline telemetry before controlled activity
The platform team confirms that the log and network sources named in the detection strategy are arriving in the SIEM and the Wazuh or Security Onion stack, with correct timestamps and parsing. For T1590 this usually means network traffic content and flow records from the range boundary, plus any application logs on the exposed services. Done means a baseline query returns events for each source over a quiet period, and any gaps are logged as blockers. A detection cannot be validated against data that never arrived.
Run controlled activity and mark the start time
The operator executes the approved emulation steps for one sub-technique at a time against the range targets, and records the start time in UTC along with a run identifier. Analysts do not see the run details in advance, so the test measures real triage behavior. Done means each run has a unique ID, a start timestamp and a link to the operator's notes, and the activity is confined to the range. Repeat for each sub-technique before moving on.
Confirm the alert reaches the analyst queue
The detection engineer checks that the rule fires, that the alert is created in the case management or SIEM queue, and that it carries the expected severity, mapping fields and affected asset. The analyst on shift confirms they can see and acknowledge it through the normal workflow. Done means a screenshot or exported record shows the alert with the run ID in the queue, and a note records any alerts that fired but were routed to the wrong place or lacked context. A rule that only writes to a log index does not count as a working alert.
Record time to alert and supporting telemetry
For each run, the detection engineer calculates the interval between the operator's start time and the alert creation time, and lists the telemetry records that supported the detection. Results go into a run register with one row per run. Done means every run has a time to alert value, the source and event identifiers, the ATT&CK sub-technique mapping and the outcome (detected, partial or missed). Where a target for time to alert exists in the organization's own standards, compare against it, and confirm that target with the SOC lead rather than assuming one.
Tune the rule and retest the same run
When a run is missed or noisy, the engineer adjusts the detection logic or its data source, documents the change in version control with the reason, and reruns the same emulation step against the same scope. The retest checks that the earlier gap is closed and that benign traffic from the baseline period does not start firing. Done means the register shows before and after results for each change, and the updated rule is re-approved. Retests also confirm that the mapping still points to the ATT&CK version named in the scope sheet.
Close out with evidence for the review board
The detection owner writes a short validation report covering scope, version, plan approval, run register, tuning history and open gaps, and files it with the detection library. Any remaining gaps get owners and review dates set by the organization. Done means the report is stored with the rule, linked to the ATT&CK version, and available to internal audit or an external assessor who asks how the detection was proven. This report is evidence for the organization's own assurance program, not an audit opinion.
How external recon becomes an internal detection chain
The point of this section is that T1590 rarely shows up as one clean alert. Gathering victim network information is passive or lightly active, so most of the signal is weak on its own: a few unusual requests at the edge, a burst of DNS lookups against your public zones, or a certificate transparency entry for a host nobody remembers publishing. Detection works when those weak signals are carried into one place and read together. In the flow shown in the diagram section, edge telemetry from your web application firewall, reverse proxies, DNS resolvers and perimeter firewalls feeds a correlation layer, and that layer hands grouped events to an analyst queue. The diagram is the reference for the stages; this section explains the decisions at each hand-off.
Start by deciding which sources are in scope for correlation and who owns each one. For Network Traffic Content and Network Traffic Flow, confirm that the Suricata or Zeek sensors at your perimeter see the same traffic your web tier sees after TLS termination, because a gap there hides the requests you most need. For Application Log Content, confirm which fields your reverse proxy and application logs actually record, such as source address, user agent, requested path and response code, and whether timestamps are synchronized across sources. Map each source to a Wazuh or Security Onion data stream, and write down the retention period your policy requires, since the value of correlation depends on looking back weeks, not hours. These are decisions to record in your runbook, not defaults to assume.
Correlation is where the chain earns its value. Group events by source network, by target asset and by time window, then score the group against a few patterns: many distinct paths requested from one source, lookups for hostnames you do not publish, or requests that follow a pattern of port and service probing. Each weak signal should carry a low score on its own, and the group should cross a threshold before an analyst sees it. Tune that threshold against a baseline of normal crawler and monitoring traffic, and keep a documented allowlist for known scanners and your own vulnerability management tools. Analyst triage should then answer three questions: whether the activity touched a live service, whether it matches a known campaign, and whether any of your own assets were exposed by the findings. Validate the chain end to end in your cyber range before relying on it.
Preventive controls that reduce what T1590 can learn
T1590 succeeds when network details about your environment are easy to observe from outside or easy to pull from your own public and internal artifacts. The six ATT&CK mitigations below shrink that exposure at different points: what you publish, how systems are configured, what you review, what developers ship, which services you run, and what staff understand. Confirm each mapping against the ATT&CK 20.0 mitigation pages before you rely on it in an audit.
Limit exposed network descriptions
Pre-compromise (M1056) covers actions taken before an adversary reaches your environment, including what you publish about your network. Review public DNS records, job postings, vendor case studies, status pages and documentation for address ranges, network diagrams, cloud regions and internal hostnames. Remove or generalize what is not needed. Confirm the mapping details and the sub-technique coverage on the ATT&CK 20.0 mitigation page for M1056.
Review configuration exposure
Software Configuration (M1054) concerns how systems are set up so they reveal less about themselves. Check that management interfaces, administrative paths, version pages and default endpoints are not reachable from untrusted networks. Confirm that reverse proxies and load balancers do not leak internal addresses in headers or redirects. Record the owner for each setting so drift can be caught in configuration reviews.
Audit what is publicly visible
Audit (M1047) means reviewing your environment on a schedule and comparing it with what an outsider can see. Run an external review of your published IP space, certificates, and exposed services, then compare the results with your asset inventory. Findings that match nothing in the inventory point to shadow services or stale records. Keep the audit results and the remediation tickets as evidence for assessors.
Guide developers on what they expose
Application Developer Guidance (M1013) helps engineers avoid shipping details that reveal network layout. Typical leaks include internal hostnames in error messages, debug endpoints left enabled, API responses that list backend addresses, and client-side code that references internal services. Add these checks to code review and to pre-release testing. Confirm the mapping on the ATT&CK 20.0 mitigation page for M1013.
Remove unneeded services and banners
Disable or Remove Feature or Program (M1042) reduces what can be fingerprinted. Each unused service, plugin, sample page or management console adds a response that reveals software type and version. Inventory open ports and remove services that have no owner or business purpose. Where a service must stay, reduce the banner and version text it returns, then confirm the change with a follow-up scan.
Train staff on what not to share
User Training (M1017) addresses the human channel. Staff answering vendor questionnaires, posting troubleshooting questions online or sharing screenshots can reveal network topology without any technical flaw. Give engineers and support staff short guidance on what counts as network information, who approves external disclosure, and where to send vendor requests. Track completion so the training is evidence, not a one-time event.
What to do in the first hour after a T1590 alert fires
The first decision after a T1590 alert is whether the activity is authorized reconnaissance or an unknown party mapping your network. T1590 covers adversaries gathering network topology, IP ranges, domain names, DNS records and network security posture about a victim, so the alert usually points at a source that has queried or probed externally visible infrastructure. Start by confirming the source address or resolver, the time window, and the systems touched. Then compare the source against your list of approved scanners, penetration testing partners, external attack surface monitoring vendors and cloud provider scanners. Ask the owner of each approved source to confirm in writing whether they were active during that window. An alert that matches a scheduled engagement is closed with evidence, not dismissed from memory.
If the source is unapproved, correlate it before deciding on containment. Pull the same source from your perimeter and DNS telemetry, the Network Traffic Content and Network Traffic Flow records your sensors already hold, and any web or VPN logs that show follow-on requests. Check whether the same source has recently appeared in alerts for other reconnaissance techniques. Then decide between blocking and continued monitoring. Blocking an address at the edge is quick but tells the adversary you have noticed, so weigh that against the value of watching what they try next. Record the decision, the owner who approved it and the rule change, whichever way you go.
Preserve evidence before you change anything. Export the raw sensor records, DNS query logs and firewall or load balancer logs for the window to write-once storage, record hashes, and note who accessed them. Escalate to incident response when the source cannot be attributed, when correlation shows access beyond scanning such as authenticated requests or changes on exposed services, or when the activity coincides with other alerts. Hand over the alert identifier, the ATT&CK version your mapping targets, the evidence set and the open questions in one note. Confirm your own escalation thresholds and handoff contacts in advance with your incident response team, since this page does not set response timelines.
How to rehearse T1590 detection and response in a private cyber range
The range should mirror the parts of the client's environment that a victim-side observer would see during external enumeration: the public edge, the DNS and web entry points, and the monitoring that sits in front of them. DeployOpen builds the range inside the client's own cloud account, data center or air-gapped network, so the sensors and rules tested are the ones in production. Segmentation keeps the range isolated from live systems while still feeding the same log pipeline. Confirm with the client which sensors, retention periods and log sources are in scope before the exercise starts.
- Segmented network: An isolated range segment with a monitored edge, so injected traffic never reaches production hosts.
- Sensors at the edge: Network sensors such as Zeek or Suricata placed where external traffic enters the range.
- SIEM or XDR stack: A Wazuh or Security Onion deployment that receives the same events the production stack would receive.
- Representative targets: Public-facing hosts, web applications and DNS records that look like the client's externally visible footprint.
- Baseline capture: A recorded baseline of normal traffic so the team can judge what is new during the exercise.
Before the first inject, check that every sensor, log source and alert pipeline reports healthy, and record the versions under test.
Injects are scripted events that the facilitator runs or schedules to create the telemetry the detection must catch. For T1590, the goal is to vary the shape of external enumeration so the team learns which detections depend on a single pattern. The facilitator writes the inject plan in advance, records the time of each action, and keeps the plan private from the defenders until the debrief. Any scenario here is illustrative and should be adapted to the client's footprint and rules of engagement.
- Enumeration phases: Staged activity that starts with broad reconnaissance and narrows to specific hosts, so the team sees how the pattern changes over time.
- Varied source behavior: Activity from several source addresses, at different rates and times of day, to test whether correlation holds when one source is not obvious.
- Benign scanner noise: Authorized scanning from a known internal or vendor source, so the team practices separating expected noise from hostile activity.
- Timed markers: Each inject logged with a start and end time so detection latency can be measured against the facilitator record.
- Controlled stop conditions: Clear limits on request volume and target set, agreed in the rules of engagement.
Review the inject log with the client to confirm that every action stayed within the agreed scope.
Good detection in the range means three things happen in sequence: an alert fires, correlation links it to related events, and triage reaches a clear decision. Measure each step separately. An alert that fires but is never linked to other activity is a weak signal. Map the detection logic to the ATT&CK version the team targets, and record that version, because ATT&CK releases can rename or deprecate techniques. Data components relevant to this technique include Network Traffic Content and Network Traffic Flow, so check that both are collected at the edge.
- Alert fires: The relevant rule or analytic produces an alert within the time the team has agreed as acceptable, with the expected fields populated.
- Correlation links it: Related events from different sensors are grouped into one case rather than left as isolated alerts.
- Triage reaches a decision: The analyst classifies the activity as malicious, benign or undetermined, with the reasoning written down.
- Coverage map: Each inject is matched to the detections that caught it, and gaps are listed by sub-technique.
- Detection latency: The gap between the facilitator timestamp and the alert timestamp is recorded for each inject.
Check that the coverage map names the ATT&CK version used, and that every missed inject has a recorded reason.
Good response means the team records a documented decision, preserves evidence in a form that holds up later, and feeds the lessons back into detection tuning. The exercise should show who decides whether activity is escalated, who owns the edge controls, and how the outcome is communicated. Practice the handoff from triage to the response owner, because gaps in that handoff are common in external-facing activity that never becomes a confirmed incident. Tuning changes should be reviewed, approved and tested in the range before they reach production.
- Documented decision: A written record of what was decided, by whom, and on what evidence, stored in the case system.
- Evidence preserved: Relevant logs, packet captures and sensor records exported with hashes or timestamps, so they can be reviewed later.
- Escalation path: A tested route from the analyst to the incident owner and, where required, to legal or the communications lead.
- Tuning recorded: Each rule change logged with the reason, the expected effect on noise, and the test that confirmed it.
- Post-exercise review: A debrief that compares the team's decisions with the facilitator record and assigns owners for each gap.
Confirm with the client how long evidence must be retained and who approves tuning changes before the next exercise.
Questions SOC leads and detection engineers ask about T1590
How do we separate T1590 activity from routine internet scanning of our perimeter?
Treat T1590 as a pattern to baseline, since the technique covers gathering network details about your organization. Benign internet scanning runs constantly, so the signal sits in what is requested, from where, and whether the pattern changes. Build baselines for your externally visible address ranges and public services, then alert on new sources that touch services they have never touched before, repeated queries aimed at network configuration details on public-facing hosts, and activity that starts shortly after a change to your public footprint. Network Traffic Flow and Network Traffic Content, the data components ATT&CK most often references for Reconnaissance techniques, let you compare volume, timing and request shape over time. Keep a documented allowlist for known research and monitoring providers, and review it on a fixed schedule. Confirm with your analysts which sources are approved before you suppress anything.
Which data components should we map first for T1590 detection?
Start with Network Traffic Flow (DC0078) and Network Traffic Content (DC0085), because ATT&CK ties both most often to Reconnaissance techniques and their sub-techniques, and most networks already produce flow records. Flow metadata gives you source, destination, ports, volume and timing at modest storage cost, which makes it the practical base layer. Content adds protocol detail where your sensors can decode it, which helps you tell DNS and web queries apart. Next, add Application Log Content (DC0038) from web servers, DNS resolvers and VPN gateways, and Response Content (DC0104) where your environment produces it. Before writing any rule, confirm which of these components your sensors actually collect, because a detection built on a component you do not collect remains a plan on paper. You can check the current mapping for each version in the enterprise-attack 20.0 STIX bundle.
What do we do about sub-technique coverage gaps for T1590?
Treat each of the six T1590 sub-techniques as its own coverage line, with a named owner, the data components it needs, and a status of covered, partially covered or uncovered. For each partial or uncovered line, decide whether to add a sensor, extend a log source, or accept the gap in writing. Accepted gaps need a compensating measure and a review date. Pre-compromise (M1056) is the ATT&CK mitigation mapped to this family, and it points you toward reducing what your organization exposes publicly before an adversary gathers it, which shrinks the detection burden over time. Record each decision in your detection register so that a later reviewer can see why a gap existed and what changed. Do not report a gap as covered because a broader rule partly fires. Test that the rule responds to the activity it claims to catch, and keep the test result with the coverage line.
How often should we re-map detections to a new ATT&CK version?
Re-map whenever a MITRE release touches the technique or sub-technique IDs you rely on, and check the ATT&CK updates page for each release. Recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Version 18 replaced detections in technique pages with detection strategies and analytics and deprecated data sources, so rule metadata written against older content may no longer match the current structure. Pin every detection to the ATT&CK version it targets, compare technique and sub-technique IDs against the new STIX bundle, and update references where IDs were renamed, deprecated or revoked. Ask your team to confirm the cadence that fits its change process, and log each re-mapping as a versioned change so that audit trails stay readable.
How can we show auditors our T1590 detection coverage without claiming certification?
Show a traceable chain for each sub-technique: the T1590 identifier, the ATT&CK version you targeted, the rule or analytic, the data component it reads, the exercise result, and the alert or ticket it produced. That chain gives an assessor evidence to sample, which is more persuasive than a coverage percentage. Be precise in your wording. ATT&CK is a globally accessible knowledge base, so your statement should say that your detections map to the framework, and it should make no claim of certification against it. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports and attestations. Ask your auditor which control framework and control identifiers they will test against, then map your evidence to those identifiers in your own words.
Can our own team rehearse T1590 detection without an outside partner?
Yes, a capable internal team can rehearse T1590 detection if it has a private test environment, a written exercise plan, and a second person to validate the results. Staffing and access to a range decide how much one team can handle in each cycle. Outside help usually makes sense when you need independent validation, when sensors are spread across several clouds or sites, or when analysts are busy with live operations. Ask any provider for a written scope that lists the sub-techniques, data sources, sensors and deliverables before work begins. DeployOpen runs fixed-scope cyber range exercises and security testing inside the client's own environment, and it can plan that work around your existing team. Whatever model you choose, record who ran each exercise and what the analysts saw, so the results remain usable for tuning and for later review.
How DeployOpen builds T1590 detections and range exercises
DeployOpen approaches T1590 Gather victim network information as a fixed-scope engagement: we agree what is covered, build the detection in your own open-source stack, and rehearse it in a private cyber range before handover. Every step is written down so your team can run and audit the detection after the engagement ends.
How we scope
- Confirm which T1590 sub-techniques apply to your externally visible network footprint and their owners.
- Record the ATT&CK version the detection mappings will target, so later releases do not silently change them.
- Agree in writing which log sources, such as Network Traffic Content and Network Traffic Flow, are in scope and accessible.
How we build
- Write detection logic in Sigma-style form and map it to your Wazuh, Zeek or Suricata pipeline, described in words.
- Tune thresholds against your normal external scanning and crawler noise so alerts reflect true reconnaissance activity.
- Document data gaps where a sub-technique cannot be observed from your current telemetry, and recommend collection changes.
How we hand over
- Deliver detection rules, mapping tables and runbooks in a form your analysts can version, review and reuse.
- Run a private cyber range exercise that replays reconnaissance behavior against the detection and records the results.
- Provide a written validation report listing what fired, what was missed and what remains to be confirmed in your environment.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support is available as a retainer for rule updates when ATT&CK releases change T1590 mappings.
- Ask us to confirm the current ATT&CK release and any deprecations affecting T1590 before each rule review.
