T1602 — Data from Configuration Repository

coverage gap

Technique: T1602
Tactics: Collection
MISP citations: 0
KEV CVEs mapped: 1
Community rules: 0
thrunt rules: 0
Upstream: https://attack.mitre.org/techniques/T1602

MITRE description

Adversaries may collect data related to managed devices from configuration repositories. Configuration repositories are used by management systems in order to configure, manage, and control data on remote systems. Configuration repositories may also facilitate remote access and administration of devices. Adversaries may target these repositories in order to collect large quantities of sensitive system administration data. Data from configuration repositories may be exposed by various protocols and software and can store a wide variety of data, much of which may align with adversary Discovery objectives.(Citation: US-CERT-TA18-106A)(Citation: US-CERT TA17-156A SNMP Abuse 2017)

KEV CVEs mapped to this technique

Per MITRE CTID's hand-curated KEV→ATT&CK mappings — these are the actively-exploited vulnerabilities behind this technique's KEV signal.

CVE-2025-31324

Detection coverage

thrunt disposition — no rule banked

on-box CLI path already fires adjacent cisco/aaa rules; the technique-defining SNMP/Smart Install remote-read path produces no default single-event log

T1602's live tradecraft is remote configuration harvest from network devices — SNMP walks with guessed or default community strings and Smart Install (tcp/4786) config retrieval, the DHS TA18-106A playbook — plus the CTID-mapped CVE-2025-31324 SAP NetWeaver chain on the enterprise side. Base Sigma splits this into a covered half and an invisible half. The on-box half is covered: if an actor authenticates to a device and runs 'show running-config' or copies the config off-box, the community cisco/aaa rules Cisco Collect Data and Cisco Stage Data already fire on those exact command strings (they carry host-analog tags — t1005, t1552.001, t1074 — rather than t1602, but the events alert). The technique-defining remote-read half is invisible to standard telemetry: Cisco IOS does not syslog SNMP GET/GETBULK operations at default logging levels, and Smart Install retrieval is documented for detection via netflow on tcp/4786 and packet capture, not via stable syslog message IDs a Sigma rule could key on. Any rule we published would either duplicate the existing CLI rules or match log lines most estates never generate. Compensating controls: disable Smart Install (no vstack), enforce SNMPv3 with views and ACLs, and watch netflow for udp/161 and tcp/4786 from non-NMS sources. The CVE-2025-31324 entry chain itself already has six dedicated SigmaHQ emerging-threat rules.

Compensating controls

Disable Smart Install ('no vstack') estate-wide; verify with 'show vstack config'
SNMPv3 with authPriv, MIB views, and source ACLs; retire v1/v2c community strings
Netflow/NDR watch for udp/161 and tcp/4786 sourced from non-NMS hosts
Existing cisco/aaa CLI rules (Cisco Collect Data, Cisco Stage Data) for the authenticated on-box path
SigmaHQ CVE-2025-31324 emerging-threat rules for the SAP NetWeaver entry chain

Revisit when: A SigmaHQ logsource convention for netflow/Zeek SNMP telemetry or standardized NMS-side SNMP audit-log ingestion — an 'SNMP config-OID read from non-NMS source' rule becomes writable then. Also flips if estates commonly export CISCO-CONFIG-COPY-MIB (ccCopyTable) trap logging, which would give a single-event record of SNMP-initiated config copies.

Signal counts reflect the current corpus snapshot: MISP citations are regex-extracted from CIRCL OSINT event text and galaxy tags; KEV mappings come from MITRE CTID; community coverage is the SigmaHQ rule inventory (core, emerging-threats, threat-hunting collections) at release —. Rule bodies are not mirrored — links go upstream.