Overview

Network Trust Dependencies reconnaissance (T1590.003) is a pre-compromise technique where adversaries map out the trusted third-party relationships connected to a target organization — think managed service providers, cloud vendors, contractors, and federated partners. By understanding which external entities have elevated or implicit network access, attackers identify soft entry points they can exploit later through techniques like Trusted Relationship (T1199) or supply chain compromise.

Because this reconnaissance happens largely outside your perimeter — in public databases, OSINT sources, and through social engineering — there is no single log entry that screams "attacker." Every security team still needs visibility into this threat because the intelligence gathered here directly feeds higher-impact attacks, and early detection of the reconnaissance phase is your best chance to disrupt the kill chain before the attacker ever touches your environment.

Attacker Perspective

Attackers treat network trust mapping as essential groundwork — before picking a lock, they figure out which doors are already propped open by trusted third parties.

• OSINT aggregation via theHarvester and Maltego: Attackers run theHarvester -d targetcorp.com -b all to enumerate MX records, SPF entries, and linked domains, then pivot in Maltego to graph trust relationships between the target and its vendors or MSPs.
• DNS and certificate transparency mining: Using tools like amass enum -d targetcorp.com -include-unresolvable or querying crt.sh for wildcard and SAN certificates, attackers identify partner subdomains (e.g., vpn.msp-partner.targetcorp.com) that reveal trusted network interconnections.
• Phishing for org-chart and vendor data: Spear-phishing emails impersonating IT helpdesk or procurement teams trick employees into disclosing which MSPs manage their infrastructure, which contractors have VPN access, or what SaaS platforms are in use.
• LinkedIn and job posting scraping: Automated scraping of LinkedIn with tools like linkedin2username or manual review of job postings reveals technology stacks, named vendors, and partner integrations referenced in job descriptions — all free intelligence about trust dependencies.

This technique is attractive precisely because it generates zero alerts on the victim's side — the attacker builds a complete picture of your trust surface using only public data and social channels, making it nearly costless and nearly invisible.

Detection Strategy

Required Telemetry

• DNS query logs (recursive resolver): Enable full query logging on your internal DNS servers. For Windows DNS Server, enable debug logging via dnscmd /Config /LogLevel 0x8100F333 and set a log file path. For BIND, set querylog yes in named.conf. In cloud environments (AWS Route 53 Resolver, Azure DNS, GCP Cloud DNS), enable query log export to your SIEM. These logs reveal when internal users or systems are querying third-party partner or vendor domains at unusual volumes or times.
• Web proxy / secure web gateway logs: Ensure all outbound HTTP/HTTPS traffic is proxied and logged with full URI, user-agent, referrer, response code, and authenticated username. Tools like Zscaler, Bluecoat, or Squid all support this — without proxy logs you are blind to browser-based OSINT activity from insider threats or compromised endpoints.
• Email gateway logs (inbound phishing for information): Enable header-level logging on your email gateway (Exchange Online, Proofpoint, Mimecast). You need: sender, recipient, subject, reply-to, attachment names, and URLs extracted from message bodies. This is critical for detecting inbound phishing-for-information attempts targeting employees who hold vendor/partner knowledge.
• Windows Security Event Log — Logon events: Enable "Audit Logon Events" (Success and Failure) via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Logon/Logoff → Audit Logon. This generates Event ID 4624 (successful logon) and Event ID 4625 (failed logon). Correlate these against logins from third-party partner IP ranges to detect abuse of trusted relationships.
• Windows Security Event Log — Account and group enumeration: Enable "Audit Account Management" and "Audit Directory Service Access" in GPO. Key Event IDs: 4661 (handle requested to object), 4662 (operation performed on object — directory enumeration), 4728/4729 (security group member added/removed). These catch post-initial-access enumeration of trust configurations inside AD.
• Active Directory — LDAP query logging: Enable LDAP diagnostic logging by setting HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\15 Field Engineering = 5 on domain controllers. This logs expensive or suspicious LDAP queries to the Directory Services event log, catching tools like BloodHound or ADExplorer enumerating trust relationships programmatically.
• PowerShell Script Block Logging: Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. This generates Event ID 4104 and captures full PowerShell script content, catching cmdlets like Get-ADTrust, nltest /domain_trusts called via PowerShell, or custom enumeration scripts.
• Process creation logging (Windows): Enable "Audit Process Creation" in GPO and ensure command-line capture: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. This generates Event ID 4688 with full command lines, or use Sysmon Event ID 1 for richer parent-child process data.
• Network flow / NetFlow data: Collect NetFlow or IPFIX from perimeter routers and firewalls. You need: source IP, destination IP, destination port, bytes transferred, and session duration. This lets you detect unusual outbound connections from internal hosts to known OSINT aggregation services or certificate transparency APIs.
• Cloud audit logs (if applicable): Enable AWS CloudTrail, Azure Activity Log / Microsoft Entra ID Sign-in Logs, or GCP Cloud Audit Logs. These capture API calls that enumerate federated identity providers, cross-tenant trust configurations, or third-party SaaS integrations — all high-value trust dependency intelligence.

Key Indicators

• Suspicious DNS enumeration to OSINT/CT infrastructure: In DNS query logs, look for query.name resolving to known certificate transparency services: crt.sh, censys.io, shodan.io, securitytrails.com. Flag any internal host making more than 20 queries per hour to these domains. Also watch for DNS zone transfer attempts: log entries where query.type = AXFR or query.type = IXFR originating from non-authoritative sources.
• Web proxy hits on recon tooling destinations: In proxy logs, check cs-uri-stem (or equivalent URL field) for paths like /api/v1/domain/ on securitytrails.com, /dns/search on censys.io, or any request to crt.sh/?q= with your organization's domain as a parameter. Flag requests where cs-username is a privileged account or service account.
• Command-line indicators — AD trust enumeration: In Event ID 4688 or Sysmon Event ID 1, look for CommandLine containing: nltest /domain_trusts, nltest /trusted_domains, Get-ADTrust -Filter *, ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships(), or netdom trust. Any of these on a non-DC workstation should alert immediately.
• BloodHound / SharpHound execution indicators: In process creation logs, flag CommandLine matching patterns like SharpHound.exe -c All, -CollectionMethod All, or any process with Image name SharpHound*. In LDAP diagnostic logs, flag queries where the filter contains msDS-AllowedToActOnBehalfOfOtherIdentity or (objectClass=trustedDomain) from a non-DC source IP.
• PowerShell trust enumeration (Event ID 4104): In Script Block Logging events, flag ScriptBlockText containing Get-ADTrust, GetAllTrustRelationships, TrustType, ForestTransitive, or netdom. Also flag encoded commands: CommandLine containing -EncodedCommand followed by base64 blobs that decode to any of the above.
• Inbound phishing-for-information patterns: In email gateway logs, flag inbound emails where subject contains terms like "vendor list," "MSP contact," "network diagram," "firewall rules," or "trust relationship" AND sender_domain is external AND reply_to_domain differs from sender_domain (reply-to mismatch is a classic social engineering indicator).
• Unusual third-party login attempts: In Event ID 4624/4625 or cloud sign-in logs, flag authentication events where IpAddress falls within known partner/vendor IP ranges but LogonType = 3 (network) occurs outside business hours, or where AuthenticationMethod is legacy (NTLM instead of Kerberos), suggesting credential stuffing against trusted accounts.
• Cloud enumeration of federated trust configs: In AWS CloudTrail, flag eventName values: ListSAMLProviders, GetSAMLProvider, ListOpenIDConnectProviders, DescribeTrustedAdvisorChecks. In Azure Entra ID logs, flag operationName containing Get federation settings or List trustedCAsForPasswordlessAuth from non-administrative user principals.

Detection Logic

Rule 1 (Broad — High Sensitivity): Internal Host Querying Known OSINT/Recon Infrastructure
IF dns.query.name IN ["crt.sh", "censys.io", "shodan.io", "securitytrails.com", "dnsdumpster.com", "hackertarget.com"] AND source.ip IN internal_ip_ranges AND NOT source.ip IN [approved_pentest_hosts] THEN alert(severity=LOW, "Internal host queried OSINT recon service")

This catches the earliest stage of passive reconnaissance when an attacker on an already-compromised internal host — or a malicious insider — reaches out to certificate transparency or threat intelligence APIs to map trust dependencies. Expect moderate false positive volume since some security team members legitimately use these services; tune by excluding known security analyst workstations after confirming with the team.

Rule 2 (Moderate): AD Trust Enumeration via Command-Line Tools
IF (process.command_line CONTAINS "nltest" AND process.command_line CONTAINS "domain_trusts") OR (process.command_line CONTAINS "Get-ADTrust") OR (process.command_line CONTAINS "netdom trust") AND process.parent_name NOT IN ["mmc.exe", "ServerManager.exe"] AND host.name NOT IN [domain_controller_hostnames] THEN alert(severity=HIGH, "AD trust enumeration from non-DC host")

This detects active post-compromise reconnaissance of Active Directory trust relationships from workstations or member servers — highly abnormal outside a DC context. Alert volume should be very low; each alert warrants immediate investigation.

Rule 3 (Moderate): Suspicious LDAP Queries Matching Trust Enumeration Patterns
IF event.id = 4662 AND object.type = "trustedDomain" AND source.host NOT IN [domain_controller_hostnames] AND NOT (user.name IN [known_ad_admin_accounts] AND time BETWEEN business_hours) THEN alert(severity=HIGH, "LDAP query for trustedDomain objects from non-authoritative host")

This targets the specific Active Directory object class that stores inter-forest and inter-domain trust configurations. Querying trustedDomain objects directly is rarely a legitimate workstation activity and almost always indicates automated enumeration (BloodHound, ADExplorer) or hands-on-keyboard attacker activity. Expect very low volume.

Rule 4 (Narrow — High Precision): Phishing Email with Trust-Dependency Social Engineering Keywords
IF email.direction = "inbound" AND email.subject MATCHES_REGEX "(vendor list|MSP contact|network diagram|trusted partner|firewall access|VPN credentials|contractor access)" AND email.sender_domain NOT IN [known_partner_domains] AND email.reply_to_domain != email.sender_domain THEN alert(severity=MEDIUM, "Potential phishing-for-information targeting trust dependency knowledge")

This catches socially engineered emails attempting to extract network trust information from employees. The reply-to mismatch combined with trust-related keywords is a high-precision indicator. Expect low volume with occasional false positives from legitimate mailing list tools that use different reply-to addresses — tune by adding known email marketing platform domains to an exclusion list.

Tuning Guidance

• Security team analyst workstations querying OSINT services: Legitimate threat intelligence analysts and red team members use shodan.io, censys.io, and crt.sh regularly. Build and maintain a named asset group (e.g., security_analyst_hosts) and exclude these from Rule 1 after confirming membership with the security team manager. Re-audit this list quarterly.
• Authorized penetration tests: During scheduled pentests, testers will run nltest, BloodHound, and LDAP enumeration legitimately. Require your pentest team to provide a test window and source IP list before the engagement; add these as time-bounded exclusions (source.ip IN [pentest_ips] AND time BETWEEN [engagement_window]) rather than permanent suppression rules.
• Domain controller administrative activity: AD administrators running Get-ADTrust or reviewing trust configurations from management workstations is normal. Exclude accounts in a named group like AD_Admins during business hours, but keep alerting on after-hours activity even for these accounts — legitimate admin work at 2 AM is a flag worth reviewing.
• Automated monitoring and SIEM enrichment tools: Some SIEM connectors and asset management tools (e.g., Tenable, ServiceNow Discovery) make LDAP queries that may match trust enumeration patterns. Identify the service accounts and source hosts these tools use and add specific exclusions like user.name IN [svc_tenable, svc_snow_discovery] AND source.ip IN [approved_scanner_hosts].
• Legitimate bulk email platforms triggering phishing rule: Marketing automation platforms (Marketo, HubSpot, Mailchimp) often send from a sending domain that differs from the reply-to domain. Add known sending infrastructure domains (identifiable from SPF records of known vendors) to a known_email_marketing_domains list and exclude from Rule 4 to reduce noise from legitimate vendor newsletters.

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event exists in the source log. Pull the raw event from your SIEM using the event ID, timestamp, and host name from the alert. Confirm the log was not duplicated or incorrectly parsed by checking that field values (command line, source IP, user name) are intact and not truncated.
2. Identify the affected host and user — flag if privileged. Query your asset inventory (CMDB, Active Directory, or cloud console) to determine whether the host is a server, workstation, or privileged access workstation, and whether the user account holds elevated roles such as Domain Admin, Global Admin, or has access to vendor management systems. Privileged account involvement escalates severity immediately.
3. Pull the full command-line and parent process chain. In Sysmon Event ID 1 logs (or Event ID 4688), retrieve the full CommandLine, ParentImage, ParentCommandLine, and User fields for the suspicious process and walk the chain up at least three levels. An nltest spawned by cmd.exe spawned by powershell.exe spawned by a Word macro is a very different risk profile than one launched directly by an administrator from a terminal.
4. Check for network connections and files written to disk contemporaneously. Using Sysmon Event ID 3 (network connection) and Event ID 11 (file created), look for any outbound connections or new files written within a ±5 minute window of the suspicious process execution. Pay special attention to connections to external IPs and files written to %TEMP%, %APPDATA%, or user-writable directories — these may be exfiltrated recon results or dropped tools.
5. Search DNS and proxy logs for OSINT infrastructure queries from the same host and user. Query your DNS resolver logs and web proxy logs for the same source.ip or cs-username over the past 7 days. Look for queries to certificate transparency services, OSINT aggregators, or your own public-facing domain from an internal host — this pattern suggests deliberate trust mapping and significantly raises suspicion.
6. Look for lateral movement originating from this host. Search Windows Security Event ID 4624 with LogonType = 3 (network logon) where the source workstation matches the affected host. Cross-reference with Sysmon network events (Event ID 3) for SMB (port 445), WinRM (port 5985/5986), or RDP (port 3389) connections to other internal hosts. Any lateral movement within 24 hours of the recon activity should be treated as confirmed compromise.
7. Escalation decision — separate confirmed incident from benign. Escalate to a confirmed incident if two or more of the following are true: the process chain is anomalous (unexpected parent process), network connections to external OSINT or C2 infrastructure are present, the user denies performing the activity when contacted, lateral movement is detected, or privileged credentials are involved. A single nltest run by a known admin during business hours with a clean process chain and no network anomalies can be closed as a false positive after documenting the finding.

Response Playbook

Containment

• Isolate the affected host — keep it powered on: Use your EDR console (CrowdStrike, Defender for Endpoint, SentinelOne) to network-isolate the host immediately. Do not power it off — volatile memory may contain attacker tooling, active sessions, or decrypted credentials needed for forensic analysis. If no EDR is available, apply a host-based firewall policy via GPO blocking all inbound and outbound traffic except to your forensic collection server.
• Disable the affected user account: In Active Directory, run Disable-ADAccount -Identity [username] or use the Azure Entra admin portal to disable the account. If the account is a service account, coordinate with application owners before disabling to understand downstream impact — but disable it anyway if compromise is confirmed.
• Block identified external IPs and domains at the firewall and DNS: Submit any external IPs or domains identified in Step 4 and Step 5 of the investigation to your firewall team for immediate block. Also create a DNS sinkhole entry for any malicious domains on your internal resolver so that other potentially compromised hosts cannot reach them.
• Revoke active sessions and tokens: In Azure Entra ID, run Revoke-AzureADUserAllRefreshToken -ObjectId [user_object_id] to invalidate all active sessions. In AWS, deactivate any access keys associated with the affected IAM user or role. For VPN sessions, terminate the user's active tunnel in your VPN management console and revoke their certificate if certificate-based auth is in use.
• Notify third-party partners that may be targeted: If the recon evidence suggests the attacker was mapping relationships to specific MSPs or vendors, contact those third parties' security teams and alert them that they may be targets of a follow-on attack. Provide them with the IOCs you have discovered so they can search their own environments.

Eradication

• Remove identified persistence mechanisms: Run Get-ScheduledTask and audit HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and the HKLM\SYSTEM\CurrentControlSet\Services registry hive on the affected host for unauthorized entries. Cross-reference findings against your known-good baseline from your configuration management tool.
• Search for and delete dropped payloads and tools: Scan the host for known attacker tools by hash (SharpHound, BloodHound collectors, Mimikatz, Cobalt Strike beacons) using your EDR's custom IOC search. Also search %TEMP%, %APPDATA%\Roaming, C:\ProgramData, and any user Desktop or Downloads folders for recently created executables, scripts, or archive files with recon output.
• Reset credentials for all accounts that touched the affected host: Force password resets for the primary affected account and any other accounts that authenticated to the host during the suspicious period (visible in Event ID 4624 logs). If NTLM hashes may have been captured (e.g., Mimikatz indicators present), treat all accounts that logged on as compromised and reset accordingly.
• Check lateral movement targets for backdoors: For any hosts identified in Step 6 of the investigation, run the same persistence mechanism checks above. Pay particular attention to any servers the attacker accessed that hold trust-relevant data: AD domain controllers, identity providers, VPN servers, and third-party integration middleware.
• Rotate all secrets and API keys potentially exposed: Audit any secrets management system (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for access by the compromised account during the incident window. Rotate any secrets accessed during that window. If the host ran automated scripts, review those scripts for embedded credentials and rotate every one of them regardless of whether direct access was confirmed.

Recovery

• Verify the host is clean before reconnecting — re-image if confidence is low: If your EDR and forensic review give you high confidence that persistence has been fully removed, you may reconnect the host to the network and monitor closely. If there is any doubt — attacker dwell time was long, tools were sophisticated, or investigation was incomplete — re-image from a known-good golden image rather than risk reintroducing a hidden backdoor.
• Re-enable the user account only after confirming no persistence remains: Before restoring account access, confirm with the user that they understand why the account was disabled, brief them on phishing awareness (especially relevant if the initial vector was phishing for information), and ensure their workstation has been cleaned or rebuilt. Document the re-enablement action in your ticketing system with the approving analyst's name.
• Monitor the affected host and user for 72 hours post-remediation: Create a temporary high-sensitivity detection rule scoped specifically to the affected host name and user account that alerts on any of the indicators identified during this investigation. Set it to expire automatically after 72 hours. Review alerts generated by this rule in your morning briefing for three days.
• Notify affected third-party partners of the outcome: Follow up with any partner organizations you notified during containment. Share a sanitized incident summary including the TTPs observed and any IOCs relevant to them. This is both a trust-building measure and a practical security step — they need to know whether the attacker succeeded in mapping their relationship with you.
• Document the full timeline and close the incident with lessons learned: Write a complete incident timeline from first indicator through remediation and recovery. Identify any detection gaps this incident exposed — for example, if the attacker ran BloodHound for two hours before any alert fired, document that gap and file a detection engineering ticket to close it. Update your detection rules with any new IOCs discovered and schedule a 30-day review to confirm the rules remain active and tuned.