How T1602 data from configuration repository shows up on your network
Network teams keep device configurations in central repositories such as backup servers, configuration management databases and automation controllers, and they need to know when those stores are read in bulk. Under MITRE ATT&CK technique T1602, Data from configuration repository, an adversary collects configuration data from such a repository. In ATT&CK v20.0 the technique belongs to the Collection tactic (TA0009) and has two sub-techniques, which describe different ways of pulling device data out of a repository. Your first decision is to name which repositories hold device configurations, because those are the stores the detection must cover.
Configuration data is valuable to an intruder because it describes the network itself. It can reveal topology, including which devices exist, their management addresses and how they connect. It can contain credential references, such as service account names, shared secret locations or login scripts. It also exposes trust relationships, such as routing neighbors, VPN peers and the management stations that devices accept commands from. An illustrative case: an attacker who gains a foothold on a backup host and copies the latest configuration exports holds a map for planning lateral movement, without touching a single production device. The technique typically appears after initial access and during discovery, once the attacker is looking for a complete picture of the environment.
Start by confirming which accounts and hosts can read each repository, and whether those reads are logged at the file, API or database level. Ask your device vendors which fields, such as enable secrets or SNMP community strings, are stored in plain text or in reversible form in exports. The detection in this topic relies on network telemetry such as Network Traffic Content and Network Connection Creation, so check that sensors see traffic to the repository servers. Name the ATT&CK version you target in every detection mapping, here v20.0, because releases can rename, deprecate or revoke techniques.
Which data sources and open-source tools reveal T1602
This table maps the ATT&CK data components relevant to T1602 to the signal each can reveal and the open-source collector that can capture it. Read each row as a candidate source, then confirm which data components the detection strategies for your target ATT&CK version reference in the STIX bundle. The main takeaway is that network telemetry shows most management-plane access, while device logs and backup destinations corroborate it.
| Data component | Signal to look for | Open-source collector |
|---|---|---|
| Network Traffic Content (DC0085) | Management protocol payloads from hosts that are not approved administration sources | Zeek protocol logs and Suricata rules, aggregated by Security Onion |
| Network Connection Creation (DC0082) | New sessions to device management ports from workstations or servers outside the admin network | Zeek connection logs and Suricata flow metadata, viewed in Security Onion |
| Network Traffic Content (DC0085), SNMP | Bulk SNMP reads of configuration objects from sources that are not monitoring systems | Zeek SNMP logs and Suricata SNMP rules (confirm coverage for your device models) |
| Device syslog and authentication events | Logins, show-command activity or configuration export events recorded by the device | Wazuh device syslog collection and rules, with Security Onion as a second view |
| Configuration transfer destinations | Outbound transfers of device configuration files to hosts other than the approved backup system | Zeek connection and file logs, with Suricata alerts on unapproved destinations |
| Approved admin and backup baseline | Expected administrator sources, jump hosts and backup schedules used to tune alerts | Wazuh rule tuning and Security Onion dashboards, built from your own inventory |
How configuration repositories become a collection target
Configuration repositories become a collection target because they concentrate, in one place, the settings that define how a network device authenticates users, routes traffic, filters packets and reaches its management plane. On a router, switch or firewall, the running configuration and the startup configuration are the most complete picture of that device, and in many environments they also hold credential material, pre-shared keys, SNMP community strings and management addresses that were never meant to leave the device in readable form. For T1602 Data from configuration repository, the defender's first task is to inventory where those repositories live: on the device itself, on a central configuration management or backup server, and in any scheduled export or version control system that copies them. Each location is a different detection surface and a different owner.
What separates bulk retrieval from normal administrative access is the shape of the activity, not the protocol alone. An engineer who pulls one configuration after a change window produces a single, expected event tied to a known change ticket. Retrieval of configurations from many devices in a short interval, from an account or host that does not normally perform backups, or outside the backup schedule, looks different even when every individual request is authorized. The sub-technique distinctions matter here: ATT&CK separates collection from a device's own repository from collection from a configuration repository held elsewhere, and the telemetry, owners and response steps differ for each. Confirm with your network team which devices hold configurations locally, which export centrally, and which accounts are permitted to do either.
Detection logic for T1602 that SOC teams can tune
T1602 Data from Configuration Repository is hard to separate from routine network management, so the detections below work together rather than alone. Each one looks at a different property of the same activity: where the traffic comes from, who or what is asking for it, and when it happens. Tune every threshold against your own device management baseline and the ATT&CK version your mappings target, which for these pages is Enterprise ATT&CK 20.0.
Volume and direction of repository traffic
Baseline how much configuration repository traffic leaves device management networks each day, by device group and by destination. Alert when a device or segment sends a sharp increase in bytes or session count toward repository endpoints, or when traffic flows in an unexpected direction, such as repository reads from a device that normally only pushes telemetry. Network Traffic Content and Network Connection Creation are the main telemetry for this check. Tune the baseline per device role, because a core switch and an access switch should not share one threshold. Expect false positives from scheduled configuration backups, firmware staging and monitoring pollers that pull large config sets.
Unusual source hosts and service accounts
Build an allowlist of the hosts and service accounts that legitimately reach configuration repository endpoints, such as the network automation server, the backup platform and the change management pipeline. Alert when any other host, or a known account used from a new host, connects to those endpoints. Pair the connection record with the authentication record for the same session so the account and source are checked together. Expect false positives when engineers troubleshoot from jump hosts or when a new automation tool is added without updating the allowlist, so require a change ticket reference for every allowlist update.
Activity outside maintenance windows
Define maintenance windows per device group in your change calendar and flag repository access that falls outside them. Route out-of-window events to a higher severity queue, and correlate them with change tickets opened in the same period. This check is most useful for repository reads that occur at night or on weekends, when no approved change is active. Backup schedules and time zone offsets are the most common sources of false positives, so confirm that the time source used in your logs is synchronized and that scheduled jobs are listed in the calendar before tuning the window.
Bulk retrieval across many devices
Look for one source fetching configuration from a large number of devices in a short period, which differs from routine per-device backup pulls. Count distinct device targets per source per hour and set a threshold based on your largest legitimate job, plus a margin you agree with the network team. Network Connection Creation records make this count straightforward when the repository is reached through a single broker. Common false positives include fleet-wide compliance scans and mass firmware checks, so keep a named schedule for those jobs and suppress only the matching source and time window.
Repository access without a matching change record
Match each repository session against an approved change or scheduled job identifier, and alert when a session has no matching record. This check depends on how well your automation tools tag their sessions, so confirm which fields your configuration management tools write to logs before building the rule. Treat missing tags as a logging gap to fix first, because otherwise every unattributed session becomes noise. Expect false positives from manual, read-only checks by operators, which you can handle with a separate, lower-severity rule for named operator accounts.
How to validate a T1602 detection in a lab before production
This sequence proves that a T1602 detection fires on the expected network device telemetry, stays quiet on normal configuration activity, and can be reproduced after every rule change. It produces a dated validation record that a change board or assessor can review.
Confirm the detection logic against ATT&CK data
Before any test, the detection owner checks the rule against the technique and sub-technique definitions in the Enterprise ATT&CK bundle for the version the team targets, such as version 20.0. They confirm the rule references the data components the platform actually collects, including Network Traffic Content and Network Connection Creation, and that the sub-techniques under T1602 are covered or explicitly out of scope. The step closes when the rule's ATT&CK version, technique IDs and data component dependencies are written into the test plan.
Define the scenario and expected telemetry
The purple team lead writes a scenario in words describing the adversary goal of gathering configuration data from a network device, the lab device roles involved, and the access path the range permits. For each step of the scenario, the team lists the telemetry that should appear, the log source, and the fields expected to be populated. The output is a telemetry expectation table that the detection owner signs off before the exercise starts. Commands and payloads stay out of the plan and are handled by the range operators under their own procedures.
Set pass and fail criteria in advance
The team agrees, before execution, what counts as a pass: the alert fires within the agreed window, lands in the expected index with the required fields, and routes to the correct queue. A fail includes no alert, an alert with missing fields, or an alert that fires on a benign baseline activity used as a control. The criteria should also cover false positive review, so that a noisy rule cannot pass on volume alone. Recording these criteria before the run prevents tuning the result to match what happened.
Run the emulation with a benign control set
The range team executes the agreed scenario against the lab network devices in a controlled window, with a parallel set of routine administrative activities that should not trigger the rule. The detection owner watches the SIEM and the sensor pipeline live, noting whether telemetry reaches the platform and whether any control activity produces an alert. The step closes when the run log, the scenario steps and the control activities are all time-aligned and archived.
Record timestamps, alert IDs and versions
For each scenario step, the analyst records the event timestamp on the device, the sensor capture time, the alert timestamp, the alert identifier, the rule version and the ATT&CK version the rule targets. Records should also name the platform build and sensor configuration in use. These fields make it possible to measure detection latency against the criteria and to reproduce the run later. The record is complete when every scenario step has a matched row or an explicit note that no telemetry arrived.
Assess the result against the criteria
The team compares the run record with the pass and fail criteria set earlier and marks each criterion as met, not met or partly met, with a reason. Gaps are logged as findings with an owner, such as missing telemetry from a device class, a field that does not parse, or a false positive on the control set. Findings are reviewed with the detection engineering and network teams, and the decision to promote, tune or hold the rule is recorded. The step closes with a signed validation summary.
Re-test after every rule or telemetry change
Any change to the rule, its thresholds, the sensor configuration or the device logging settings triggers the same scenario and control set against the new version. The team compares the new record with the previous one, confirms that earlier passes still hold, and checks that the ATT&CK version reference is current, since releases can rename, deprecate or revoke techniques. Regression results are stored alongside the original validation so that an assessor can see the detection history. The step closes when the re-test record is filed under the same rule identifier.
Preventive controls that reduce T1602 exposure
Preventive controls shrink what an adversary can collect from a configuration repository and make that collection harder to hide. The cards below cover encryption of stored configuration, controlled management access, account scope, change baselines, and vendor verification. Each control lowers exposure on its own, and the detection work on this page depends on these controls being in place.
Encrypt stored configuration
ATT&CK maps Encrypt Sensitive Information (M1041) to this technique. Running configurations, startup files, backup archives and exports often hold credentials, pre-shared keys and SNMP community strings that a collector can read in full. Encrypting these at rest and in transit, with keys held outside the device, means a copied file yields little usable material. Ask each device vendor which configuration elements are encrypted by default, whether secrets are masked in show and export output, and where decryption keys are stored.
Isolate the management plane
Configuration repositories are most exposed through administrative sessions and the systems that collect configurations from network devices. Place device management interfaces on a dedicated management network, route administration through hardened jump hosts, and restrict which source addresses can reach them. Log every session that retrieves configuration so that the network telemetry in this page has a baseline to compare against. Confirm with each vendor which management protocols and export functions can be disabled or limited to specific roles.
Enforce device account scope
Restrict who can read full configurations. Separate roles for viewing operational state from roles that can export or back up the running configuration, and use named accounts instead of shared credentials. Apply multi-factor authentication to administrative access, which ATT&CK maps as M1032, and review export rights on a fixed schedule. Service accounts used by backup tools should hold read access only to the configurations they need, with credentials kept in a secrets vault.
Baseline and track configuration changes
ATT&CK maps Software Configuration to this technique. Confirm its mitigation ID in the Enterprise ATT&CK 20.0 bundle before citing it in a control register. In practice this means a known-good configuration baseline for each device class, version-controlled backups, and alerts when a running configuration diverges from that baseline. Confirm which change logging, archive and rollback features your vendor supports, and whether those logs can be forwarded to your SIEM.
Confirm vendor controls in writing
Vendor documentation often differs from default deployments, so verify each claim in your own environment. Ask for the list of configuration elements that are encrypted, the algorithms and key lengths used, how keys are generated and rotated, and whether a backup export includes secrets. Record the answers in the scope of your hardening work, then retest after every firmware upgrade, since a change in default behavior can reopen exposure.
Triage steps when a T1602 alert fires on a network device
The first decision on a T1602 alert from a network device is whether the activity came from an expected administrator or automation path. Confirm the source host, the management session and the account that read or exported the configuration. Check the source address against your jump hosts, the network team's management subnets and the backup server's address, and confirm the account's role in your device authentication system. Note the time, the device model and the configuration object involved, because the detection is built on Network Traffic Content and Network Connection Creation telemetry and those records show which session reached the device and what it transferred. If the source is an unknown host or an account that does not normally manage that device, treat the alert as suspicious until proven otherwise.
Next, check whether a change ticket or scheduled backup job explains the activity. Ask the network operations team for the change record covering that window, and check your configuration backup scheduler for a job that pulls running configurations from that device. A routine export by a backup tool is common and should close quickly if the host, account, schedule and transfer size all match the job definition. If none of these explain the session, do not close the alert on the basis of a ticket that was opened after the fact. Preserve the relevant logs first: device syslog and authentication records, firewall and flow records for the session, the SIEM raw events and the alert itself, exported with hashes and retained under your evidence procedure.
Then review the integrity of the device configuration against its last known good copy. Compare the current running configuration with the most recent approved backup, looking for unexpected new accounts, altered access lists, changed SNMP community or key material and new management sources. Do not reconfigure or reboot the device during triage, since that can destroy volatile evidence and disrupt service. If the configuration differs in ways no change record supports, or the session cannot be attributed, escalate to the incident response lead and the owner of the device platform, and follow your incident handling procedure for credential rotation. Record each decision point, including why an alert was closed, so the outcome can be tested again in your cyber range exercises.
Rehearsing T1602 detection and response in a private cyber range
Build the lab with representative network devices, or virtual appliances that behave like them. An illustrative set might include a switch, a router, a firewall and a management server that holds configuration backups. Confirm with each vendor which images, licensing terms and management interfaces apply before you deploy anything into the range.
- Device role mapping: Record which device holds which configuration, who is expected to access it and from which network segment, so the exercise can judge whether a session was unusual.
- Baseline configuration store: Keep a repository of known-good configuration files with access logging enabled, so the team can compare what was read against what should be read.
- Management path segmentation: Place the configuration repository on a segment where expected traffic is documented, so unexpected sessions stand out in the telemetry.
- Logging parity: Confirm which device logs can reach the pipeline natively and which need a syslog forwarder or agent.
- Reset points: Snapshot each device and the repository so exercises can be repeated from the same starting state.
Check that every device role in the lab has a documented expected-traffic profile before the exercise starts, because detection results are only meaningful against a known baseline.
Use Zeek for network metadata and, where your policy allows, protocol-level content. Use Suricata for signature and protocol alerts. Use Wazuh to collect device syslog and repository access logs, then correlate them with custom rules. The goal is to confirm that the two network data components referenced for this technique produce records that a rule can act on, and that the rules run against the ATT&CK version you target.
- Network Traffic Content (DC0085): Confirm that Suricata or Zeek parses the protocols used to reach the repository host in your lab, and note any protocol the sensors cannot inspect.
- Network Connection Creation (DC0082): Use Zeek connection logs to show new sessions from hosts that have no reason to reach the repository.
- Wazuh decoding and rules: Ingest device syslog and repository access logs, then map them to rules kept in version control with the ATT&CK technique and the target version noted in each rule.
- Clock alignment: Keep sensor, device and Wazuh clocks synchronized so the timeline in each alert matches the inject schedule.
- Alert content: Require each alert to carry the device, source host, repository object and time, which the analyst needs for triage.
Check that each rule fires on a replayed lab capture and that a missing field is treated as a pipeline defect, not as a finding about the attacker.
Injects are scripted events that the exercise lead releases into the range on a schedule the team does not see in advance. Each inject should describe a situation the SOC can observe in its own tools, such as an unexpected session to the configuration repository from a workstation outside the administrative group (illustrative). Measure the exercise against the team's own agreed baseline, and record the time to triage without setting an external target you have not agreed.
- Triage quality: The analyst records the affected devices, the scope of configuration data that may have been read and whether that data is sensitive.
- Time to triage: Track how long each step takes in the exercise log, then compare runs of the same inject over time within your own environment.
- Handoff quality: The incident ticket includes evidence references, a timeline, and a named owner on the network team who will act on the devices.
- Mitigation check: Verify that stored configuration is encrypted and that repository access is restricted, referencing the Encrypt Sensitive Information and Audit mitigations in your findings.
- Debrief record: Capture which alerts fired, which were missed and which fields were missing, and assign each gap to a rule, pipeline or process owner.
Check that the handoff package lets the network team act without asking the SOC for basic facts, because a fast triage that stalls at handoff does not reduce the impact.
Questions SOC leads and detection engineers ask about T1602
Which telemetry should we collect first to detect T1602?
Start with Network Traffic Content and Network Connection Creation, the two data components that ATT&CK detection strategies most often reference for Collection techniques. Network Connection Creation shows which hosts open sessions to your configuration repositories and management planes, and from which sources. Network Traffic Content, where your sensors can decode it, shows what was requested and returned. Before you write rules, confirm that your sensors actually see traffic to the network devices and repository servers in scope, including management VLANs and out-of-band paths. Coverage gaps there matter more than rule sophistication. Document each source, its retention and its blind spots so the detection's limits are clear to the people who depend on it.
How do we separate configuration backups from data collection?
Separate them by baseline, not by signature. Configuration backups are usually scheduled, come from known management hosts, use dedicated service accounts and target a fixed set of repositories. Collection activity tends to deviate from that pattern in timing, source, destination or volume. Build a baseline of your backup jobs from your own change records and device inventory, then alert on deviations such as backups initiated from unexpected hosts, outside maintenance windows, to new destinations, or in unusual sizes. Keep the allowlist narrow and reviewed, and treat every exception as a ticket with an owner and an expiry. Confirm the baseline with the teams that run the backup tooling before you tune anything.
How do we handle ATT&CK version changes in our detection mappings?
Name the ATT&CK version every detection targets, for example Enterprise ATT&CK 20.0, in the rule metadata and in your coverage register. MITRE publishes ATT&CK content as STIX 2.1 bundles per domain and version, so you can diff the technique and sub-technique records between releases in a repeatable way. Releases can rename, deprecate or revoke techniques, and ATT&CK v18 moved detections into detection strategies and analytics with new data component IDs. Schedule a review after each release, check the release notes, and update mappings in version control with a changelog. Ask your detection platform vendor or community maintainers how they track these changes before you rely on them.
How can we test T1602 detection rules without production risk?
Test in a private cyber range that mirrors your network devices, repository servers, management paths and sensors, using synthetic data and approved test accounts. Define the exercise in writing: the scope, the systems involved, who is informed, and the stop conditions. Then check that your telemetry reaches the platform, that the rule fires on the intended activity, and that it stays quiet during normal backup jobs. Record the results against the ATT&CK version you target, and rerun the tests after each rule change or sensor update. A range also lets you rehearse the response runbook, so the first real alert does not become the first test.
Can our own team run this detection without outside help?
Often yes, provided the team already operates the telemetry sources and has someone who can write and tune rules. The work usually includes confirming sensor coverage, building the backup baseline, writing and tuning the detection, validating it in a test environment and documenting the response steps. Gaps tend to appear in the validation and in keeping mappings current after ATT&CK releases. DeployOpen implements, customizes, integrates and documents self-hosted open-source platforms in your own infrastructure, and it runs security testing and private cyber ranges. Work is usually fixed-scope, with scope and deliverables agreed in writing before it starts, and ongoing support is available as a retainer.
Which mitigations reduce exposure to T1602 on network devices?
The mitigations that ATT&CK maps most often to Collection techniques include Encrypt Sensitive Information (M1041), which covers protecting configuration data at rest and in transit, and Audit (M1047), which supports reviewing access to repositories. For T1602, also review Software Configuration, the ATT&CK mitigation that addresses how device and platform configuration is managed. Confirm with your network and platform teams which secrets appear in configuration files, whether repositories are encrypted, and which accounts can read them. Prevention works best alongside the detection, because it limits what a collected configuration reveals.
What evidence should we keep to show T1602 controls to an assessor?
Keep evidence that shows the control works, not only that a rule exists. That includes the detection's ATT&CK version and mapping, the telemetry sources and their coverage, the backup baseline and its approval history, test results from the cyber range, alert samples, and the response runbook with its exercise records. Tie each item to the control or requirement it supports in your compliance framework. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early which evidence format your assessor expects.
How DeployOpen builds T1602 detections and range scenarios
DeployOpen treats T1602 Data from configuration repository as a scoped engagement on your own network devices, not a generic detection library. Work starts with a written scope that names the device families, telemetry sources and ATT&CK version in play, then moves through build, testing, handover and optional ongoing support.
How we scope
- Inventory which network device families, configuration repositories and management paths fall inside the written scope for T1602
- Confirm which Network Traffic Content and Network Connection Creation sources can reach your Wazuh, Zeek or Suricata pipeline
- Record the ATT&CK version the detection mapping targets, so later releases can be compared against it cleanly
- Agree in writing which sub-techniques are covered and which are excluded before any work begins
How we build
- Map detection logic for each in-scope device type to Network Traffic Content and Network Connection Creation data components
- Write detection rules in open formats such as Sigma and tune them against baseline configuration backup traffic from your environment
- Configure collection, parsing and alert routing in the open-source stack you already run or agree to adopt
- Document known false positives from scheduled backup jobs and automation accounts before the rules go live
How we hand over
- Deliver rule files, pipeline configuration and a written mapping from each detection to its ATT&CK technique and data component
- Provide a cyber range scenario that replays benign and simulated T1602 activity so your analysts can confirm alerts fire
- Hand over runbooks that describe triage, containment and evidence collection for configuration repository access on devices
- Include a validation checklist your team can rerun after each rule change or ATT&CK update
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Ongoing support, rule tuning and re-testing after ATT&CK releases are available as a retainer
- Confirm with DeployOpen during scoping which support hours, response paths and upgrade cycles apply to your environment
- Request a quote based on the written scope, since DeployOpen does not publish a price list
