Network Trust Dependencies (T1590.003)

Ultimate Guide to Gather Victim Network Information - Network Trust Dependencies: Attack & Defense

---

Network Trust Dependencies involve mapping relationships between organizations, domains, and third-party services to identify valuable attack paths that bypass direct security controls. Think of it as drawing a map of who trusts whom in the digital world to find the weakest link in the chain.

---

---

---

Understanding Network Trust Dependencies in Simple Terms

Imagine you're trying to get into a highly secure office building. The front door has multiple guards, biometric scanners, and reinforced locks, it's practically impenetrable. But what if the building shares a ventilation system with the coffee shop next door? Or what if the CEO's personal assistant uses the same dry cleaner as you?

Network Trust Dependencies work on the same principle. Instead of attacking your main network directly, attackers look for the digital equivalent of shared ventilation systems, trust relationships between your organization and others that could provide a backdoor entry.

These dependencies come in many forms: cloud service providers that sync with your directory, managed security providers with remote access, subsidiaries with domain trusts, or even vendors with VPN connections to your billing systems. Each represents a potential attack vector that might be less defended than your primary perimeter.

---

Decoding the Jargon: Key Terms for Network Trust Dependencies

Before diving deeper, let's clarify essential terminology. Understanding these terms will help you grasp both the attack and defense aspects of this technique.

Term	Definition	Why It Matters
Domain Trust	A relationship between two Active Directory domains that allows users in one domain to access resources in another	Attackers can move laterally between trusted domains once they compromise one
Federation Trust	An authentication agreement between organizations using protocols like SAML or OAuth	Compromising a federated partner can lead to access in your environment
Third-Party Risk	The security risk introduced to your organization by vendors, suppliers, or partners	Your security is only as strong as your weakest trusted partner
Attack Surface	All possible points where an unauthorized user can try to enter your systems	Trust dependencies dramatically expand your attack surface beyond your control
Supply Chain Attack	An attack that targets a less-secure element in the supply chain to reach the primary target	Network trust dependencies are the reconnaissance phase for supply chain attacks

---

The Attacker's Playbook: Executing Network Trust Dependencies

Step-by-Step Breakdown

A sophisticated attacker doesn't start by trying to breach your firewall. They begin by understanding your ecosystem. Here's their typical playbook:

1. Initial Reconnaissance: Using OSINT (Open Source Intelligence) tools to identify your organization's public relationships, cloud providers, subsidiaries, known vendors.
2. Trust Mapping: Enumerating domain trusts (using tools like nltest or BloodHound) and federation relationships from publicly accessible endpoints.
3. Target Selection: Identifying the weakest link in your trust chain, often a smaller company with fewer security resources.
4. Initial Compromise: Breaching the selected third party using conventional methods (phishing, exploiting vulnerabilities).
5. Trust Exploitation: Using the established trust relationship to pivot into your environment, often with valid credentials.

Red Team Analogy & Mindset

Think like a burglar casing a neighborhood. You don't just look at the target house; you observe who delivers packages, which houses share fences, who has alarm signs and who doesn't. The goal is to find the easiest path, not the most direct one.

From a red team perspective, Network Trust Dependencies represent low-hanging fruit. Why spend months trying to breach a Fortune 500 company's defenses when you can breach their small marketing agency that has VPN access to their internal networks?

Tools & Command-Line Examples

Attackers use a combination of public and custom tools to map trust relationships:

• BloodHound: The gold standard for mapping Active Directory trust relationships and attack paths
• Adalanche: Alternative to BloodHound with different visualization capabilities
• PowerView: Part of the PowerSploit suite for enumerating domain trusts
• nltest: Built-in Windows tool for querying domain trust information

Example Commands:

# Enumerate domain trusts using nltest (Windows native)
nltest /domain_trusts /all_trusts

# PowerView command to get domain trusts
Get-DomainTrust -API

# Using BloodHound Collector (SharpHound)
SharpHound.exe --CollectionMethods All --Domain corp.example.com

# Checking for federated domains via Office 365 (recon)
Get-MsolDomain -TenantId <tenant_id>

Real-World Campaign Example

The SolarWinds SUNBURST attack is perhaps the most famous example of trust dependency exploitation. Attackers didn't breach Microsoft, Cisco, or government agencies directly. Instead, they compromised SolarWinds' software build system and distributed trojanized updates to 18,000+ customers.

This campaign demonstrated how a single trusted vendor with widespread network access could become the perfect attack vector. The attackers performed extensive reconnaissance to understand SolarWinds' position in various trust networks before executing their compromise.

Another notable example is the APT29 (Cozy Bear) campaign against multiple governments, where they exploited trust relationships between government agencies and think tanks to gain initial access.

External Report: For a detailed analysis of supply chain attacks leveraging trust dependencies, see the Mandiant SUNBURST technical analysis.

---

The Defender's Handbook: Stopping Network Trust Dependencies

Blue Team Analogy & Detection Philosophy

As a defender, you need to think like a building security manager who doesn't just secure their own building, but also knows which contractors have keys, which adjacent buildings share infrastructure, and who has after-hours access privileges.

Your detection philosophy should shift from "protect our perimeter" to "understand and monitor all trust relationships." This means implementing controls that can detect abnormal use of legitimate trust relationships.

SOC Reality Check: What to Look For

In a typical Security Operations Center, trust dependency attacks often manifest as:

• Legitimate account anomalies: A vendor account accessing resources at unusual times or from unexpected locations
• Cross-domain authentication spikes: Sudden increases in authentication requests between trusted domains
• Third-party tool misuse: Legitimate remote management tools being used for lateral movement
• Impossible travel scenarios: User authenticating from a vendor network and your network in unrealistic timeframes

The challenge is separating malicious activity from legitimate business use. This requires establishing baselines for normal trust relationship usage.

Threat Hunter's Eye: Practical Query

Here's a Sigma rule to detect suspicious cross-domain authentication patterns that could indicate trust relationship exploitation:

# Sigma Rule: Suspicious Cross-Domain Authentication Pattern
# Identifies authentication attempts between domains that rarely communicate
# Useful for detecting trust relationship exploitation
title: Suspicious Cross-Domain Authentication
id: a7b3c9d2-4e5f-6a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects unusual authentication patterns between trusted domains
author: MITRE ATT&CK Field Guide
date: 2024/03/15
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769  # Kerberos Service Ticket Operations
        TicketEncryptionType: '0x17'  # RC4 (often used in attacks)
        ServiceName: '*$@*'  # Service account
        ClientAddress: '192.168.*'  # Internal IP range
    filter:
        ServiceName: 
            - '*DC$@*'  # Exclude domain controller communication
            - '*SQL$@*'  # Exclude common service accounts
    condition: selection and not filter
fields:
    - ClientUserName
    - ServiceName
    - ClientAddress
    - TicketEncryptionType
falsepositives:
    - Legitimate cross-domain service accounts
    - Domain migration activities
level: medium

For Azure/Microsoft 365 environments, use this KQL query to detect unusual federation trust usage:

// Azure Sentinel KQL: Unusual Federation Trust Usage
// Monitors authentication from federated domains for anomalies
SigninLogs
| where ResourceId contains "office365"
| where Identity contains "@"  // Ensure we have UPN format
| where UserType == "Guest" or Identity has "@partnerdomain.com"  // External identities
| where ResultType == "0"  // Successful logins
| summarize LoginCount = count(), DistinctIPs = dcount(IPAddress), 
    LastLogin = max(TimeGenerated) by Identity, AppDisplayName
| where LoginCount > 10 and DistinctIPs > 3  // Thresholds may vary
| order by LoginCount desc

Key Data Sources for Detection

• Active Directory Security Logs (Event ID 4769): Kerberos service ticket requests between domains
• Azure AD Sign-in Logs: Federation and cross-tenant authentication events
• VPN/Remote Access Logs: Third-party vendor access patterns
• DNS Query Logs: Lookups for partner domains and services
• CloudTrail/Azure Activity Logs: Cross-account API calls in cloud environments
• Network Flow Data: Communication patterns between your network and third parties

---

Building Resilience: Mitigation Strategies for Network Trust Dependencies

Actionable Mitigation Controls

Mitigating Network Trust Dependencies requires a combination of technical controls and process improvements:

1. Implement Zero Trust Architecture: Replace implicit trust with explicit, verified access for every request regardless of source.
2. Conduct Regular Trust Relationship Audits: Document and review all domain trusts, federation relationships, and third-party access quarterly.
3. Apply the Principle of Least Privilege: Third parties should only have access to what they absolutely need, for the minimum time necessary.
4. Segment Network Based on Trust Levels: Isolate third-party access zones from critical internal systems.
5. Monitor Trust Relationship Usage: Implement alerts for unusual cross-domain authentication patterns.
6. Include Third Parties in Security Testing: Require security assessments for vendors with network access and include them in red team exercises.

Red vs. Blue: A Quick Comparison

Attacker's Goal (Red Team)	Defender's Action (Blue Team)
Map all trust relationships to identify attack paths	Maintain an authoritative inventory of all trust relationships
Find the weakest link in the trust chain	Apply consistent security requirements across all trusted entities
Use legitimate trust to bypass security controls	Implement conditional access and anomaly detection on trust usage
Move laterally through trusted domains	Segment networks and enforce inter-domain boundary controls
Maintain persistence through trusted third parties	Regularly review and recertify all third-party access

---

Network Trust Dependencies Cheat Sheet

---

Conclusion and Next Steps

Network Trust Dependencies represent one of the most insidious reconnaissance techniques because they exploit legitimate business relationships. As organizations become more interconnected, our attack surface expands beyond our direct control.

The key takeaway is that trust is a vulnerability that must be managed. You can't eliminate trust relationships, business requires them, but you can make them visible, monitor their usage, and apply consistent security controls across all trust boundaries.

Your Action Plan:

1. Conduct a trust relationship inventory this quarter. Document all domain trusts, federation relationships, and third-party network access.
2. Implement the detection queries provided in this guide to establish baseline monitoring.
3. Review and tighten third-party access controls using the principle of least privilege.
4. Begin your Zero Trust journey by implementing conditional access policies for cross-domain authentication.

Continue Learning:

• Explore related techniques like Domains - T1590.001 and DNS - T1590.002 for comprehensive reconnaissance defense.
• Read the NIST Cybersecurity Supply Chain Risk Management Practices for comprehensive third-party risk guidance.
• Watch the MITRE ATT&CK YouTube walkthrough on Reconnaissance techniques for visual learning.

Remember: In cybersecurity, you're only as strong as your weakest trust relationship. By understanding and securing these dependencies, you're building a more resilient defense that extends beyond your organizational boundaries.