DET0828: Detection of Network Trust Dependencies
This detection strategy is about recognizing when an adversary is interested in an organization’s network trust dependencies—relationships such as managed...
Analyst context for executives and security teams
This detection strategy is about recognizing when an adversary is interested in an organization’s network trust dependencies—relationships such as managed service providers, contractors, partner domains, or other third parties with connected and possibly elevated access. For leaders, the risk is not just data exposure; it is that public or elicited knowledge of trusted relationships can shape targeting decisions before an intrusion begins.
Executive priority
Treat this as a pre-incident resilience and third-party risk question: do we know which external organizations have trusted network access, and can we prove that this information is controlled, monitored, and reviewable? The object is tied to reconnaissance, so value comes from reducing unnecessary exposure, validating third-party access governance, and ensuring SOC and incident response teams can recognize early warning signals such as attempts to collect relationship or access information.
Technical view
ATT&CK provides no official detection text, platforms, or tactics for this detection strategy, but it explicitly detects T1590.003, Network Trust Dependencies, under reconnaissance on the PRE platform. SOC and IR teams should validate whether they can identify attempts to discover or solicit information about trusted providers, contractors, partner domains, and connected-access relationships. Detection engineering should focus on evidence that reveals enumeration, collection, or elicitation of trust-dependency information, while treating findings as context-rich leads rather than definitive compromise indicators.
Likely telemetry
- Public-facing web content and documentation that names trusted providers, contractors, partner domains, or connected services
- DNS, domain, certificate, and other internet-facing records that expose organizational relationships
- Inbound communications and phishing-for-information reports where trust relationships or access arrangements are requested
- Third-party access inventories, vendor access records, and network trust documentation
- Security awareness, help desk, vendor management, and incident intake records involving suspicious questions about connected access
Detection direction
- Validate that the organization has an authoritative inventory of network trust dependencies to compare against exposed or solicited information.
- Tune detections around suspicious requests for details about MSPs, contractors, partner domains, network connections, or privileged third-party access, especially when reported through phishing or social engineering channels.
- Review public and semi-public disclosures for unnecessary relationship details that could support targeting.
- Use relationship context carefully: reconnaissance activity may be low-signal and may not involve malware, endpoint events, or authenticated access.
- Avoid over-alerting on normal vendor-management, procurement, or support communications; detections should incorporate sender reputation, request context, business owner validation, and unusual timing or specificity.
Mitigation priorities
- Maintain and periodically review an inventory of third-party organizations and domains with connected or elevated network access.
- Limit unnecessary public disclosure of trusted network relationships and access arrangements.
- Ensure vendor access governance, least privilege, and periodic access review are in place for trusted third parties.
- Train help desk, vendor management, and business owners to report suspicious information requests about network relationships or access paths.
- Prepare IR playbooks to triage reconnaissance indicators involving third-party trust dependencies and to notify the correct relationship owners quickly.
Analyst notes and limits
This take is based on DET0828 and its relationship to T1590.003, Network Trust Dependencies. Because the official detection strategy description and detection guidance are not provided, the recommended approach emphasizes validation of available evidence classes, third-party access governance, and reconnaissance-oriented triage rather than claiming a specific analytic or platform coverage.
ATT&CK does not specify platforms, tactics, aliases, labels, an official description, or official detection logic for this detection strategy. Local environment inventories, public exposure review, third-party access records, and communication telemetry are required to determine practical coverage.
Detection of Network Trust Dependencies
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1590.003 | Network Trust Dependencies Sub-technique | This object detects Network Trust Dependencies. |
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 1844a3aab593… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0828Open source URL
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.