Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1590.003: Network Trust Dependencies

Adversaries may gather information about the victim's network trust dependencies that can be used during targeting. Information about network trusts may include a variety of details, including second or third-party organizations/domains (ex: managed service providers, contractors, etc.) that have connected (and potentially elevated) network access.

Adversaries may gather this information in various ways, such as direct elicitation via Phishing for Information. Information about network trusts may also be exposed to adversaries via online or other accessible data sets (ex: Search Open Technical Databases).[1] Gathering this information may reveal opportunities for other forms of reconnaissance (ex: Active Scanning or Search Open Websites/Domains), establishing operational resources (ex: Acquire Infrastructure or Compromise Infrastructure), and/or initial access (ex: Trusted Relationship).

EnterpriseT1590.003Sub-techniqueObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Network Trust Dependencies is a reconnaissance behavior where an adversary tries to learn which third parties, domains, managed service providers, contractors, or other connected organizations have trusted network access. The business risk is that an attacker may use this knowledge to choose a softer route into the organization or to plan follow-on activity around trusted relationships rather than attacking the primary environment directly.

Executive priority

Treat this as a pre-compromise exposure-management issue, not only a SOC alerting problem. Leaders should ask whether the organization knows which external parties have connected or elevated access, what information about those relationships is publicly visible, and whether those trust paths are governed with evidence suitable for audit, incident response, and third-party risk decisions. This matters for resilience because a trusted dependency can become a targeting path even before any intrusion is observed.

Technical view

This is an enterprise ATT&CK sub-technique under Gather Victim Network Information in the Reconnaissance tactic, with PRE as the platform context. ATT&CK does not provide official detection text for this object, but it is related to DET0828, Detection of Network Trust Dependencies, and M1056, Pre-compromise. SOC, threat intelligence, and exposure-management teams should validate whether they can identify public or accessible disclosures of network trust relationships, phishing-for-information attempts seeking trust details, and signs that external technical data sources reveal partner, contractor, domain, or remote-access dependencies. IR teams should include trusted relationships in scoping questions when investigating reconnaissance or suspected third-party targeting.

Likely telemetry

  • External attack surface and public web/domain content that may disclose MSPs, contractors, partner domains, remote access paths, or trust relationships
  • Open technical database exposure related to domains, infrastructure, or connected organizations referenced by the ATT&CK description
  • Phishing-for-information reports or security mailbox submissions asking about vendors, access paths, domains, or network relationships
  • Logs or records from externally visible scanning activity when available, especially if followed by interest in trusted-party infrastructure
  • Third-party access inventories, network trust documentation, IAM records, and remote connectivity records used to validate what trust dependencies actually exist

Detection direction

  • Because official ATT&CK detection guidance is not provided, start by mapping what information about network trusts is externally discoverable and compare it with approved third-party access inventories.
  • Tune monitoring around reconnaissance indicators that reference vendors, contractors, managed service providers, domains, or connected organizations, while accounting for legitimate procurement, support, audit, and partner communications as false-positive sources.
  • Use the relationship to the parent technique, Gather Victim Network Information, to correlate this behavior with broader reconnaissance such as open website/domain research, open technical database searches, active scanning, or phishing for information when those signals are available.
  • Validate whether SOC and threat intelligence workflows preserve enough context to distinguish generic scanning from reconnaissance focused on trusted relationships.

Mitigation priorities

  • Prioritize pre-compromise controls: reduce unnecessary public disclosure of trusted network relationships and maintain an accurate inventory of third parties with connected or elevated access.
  • Review third-party and contractor access paths for least privilege, business justification, and documented ownership before focusing on detection alone.
  • Include network trust dependencies in attack surface management, third-party risk reviews, and incident response playbooks so teams can quickly assess whether a trusted route is relevant during an investigation.
  • Use compliance and governance evidence to prove that external dependencies are known, reviewed, and limited, rather than relying on informal knowledge of vendor connections.
Analyst notes and limits

The object is reconnaissance-focused and pre-compromise, so value comes from exposure reduction and validation of trust governance. The supplied relationship to M1056 supports proactive mitigation framing, and the relationship to DET0828 supports detection-strategy validation, but no detailed official detection logic is included in the supplied ATT&CK fields.

This take is limited to the supplied ATT&CK description, external references, and relationships. It does not establish active exploitation, actor use, specific tooling, or guaranteed detection coverage. Local inventories, third-party access records, public exposure reviews, and SOC telemetry are required to determine actual organizational risk.

Official MITRE ATT&CK definition

Network Trust Dependencies

Adversaries may gather information about the victim's network trust dependencies that can be used during targeting. Information about network trusts may include a variety of details, including second or third-party organizations/domains (ex: managed service providers, contractors, etc.) that have connected (and potentially elevated) network access.

Adversaries may gather this information in various ways, such as direct elicitation via Phishing for Information. Information about network trusts may also be exposed to adversaries via online or other accessible data sets (ex: Search Open Technical Databases).[1] Gathering this information may reveal opportunities for other forms of reconnaissance (ex: Active Scanning or Search Open Websites/Domains), establishing operational resources (ex: Acquire Infrastructure or Compromise Infrastructure), and/or initial access (ex: Trusted Relationship).

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1590 Gather Victim Network Information This object subtechnique of Gather Victim Network Information.
Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
c6e642973ffecd29...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle c6e642973ffe…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Pentesting AD Forests

    García, C. (2019, April 3). Pentesting Active Directory Forests. Retrieved October 20, 2020.

    Open source URL
  2. [2]
    mitre-attack T1590.003
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.