How T1199 trusted relationship lets attackers in through a partner
Trusted relationship (T1199) is the technique to watch when your vendors, managed service providers and federated partners hold legitimate access into your environment. Under MITRE ATT&CK, the Initial Access tactic (TA0001) describes the adversary's goal as trying to get into your network, and T1199 is one of the ways that goal is reached without exploiting your own perimeter. The mappings in this section target Enterprise ATT&CK version 20.0, so check the version your detection content names before you reuse it. For a SOC lead, the problem is that partner access looks normal. Remote support sessions, service accounts used by a managed provider, identity federation trusts and vendor-managed connectors all generate authenticated, expected traffic. When a partner's environment or credentials are compromised, an adversary can arrive through that legitimate path and blend into activity the partner is expected to perform. Initial Access is the tactic where this matters most, because the first foothold is granted by a relationship you approved rather than by a vulnerability you failed to patch.
The decisions that shape your exposure sit mostly outside the SOC. Your team should inventory which third parties hold accounts, network paths, API keys or federation trusts into your estate, and which of those paths are time-bound, monitored and separately segmented from the rest of your network. Ask each partner how they protect their own administrative identities and how they will notify you of a compromise. Confirm those answers in writing, because your contracts and monitoring will depend on them. It also helps to know which of your existing detections would catch partner-originated activity, and where they are blind. Partner logins, connections and data transfers should be attributable to a named account, a known source and an agreed purpose. If you cannot tie a partner session to a specific ticket or contact, treat that gap as a finding to close before a live incident, not after it.
Which telemetry reveals trusted relationship abuse
This table maps each telemetry source to the trusted relationship signal it can expose, the open-source collector that gathers it, and the platform it applies to. Read it as a starting point for coverage planning: confirm each data component against the ATT&CK 20.0 STIX bundle for T1199 and its platform list before you write detection logic.
| Telemetry source | Signal to look for | Open-source collector | Platform focus |
|---|---|---|---|
| Network Connection Creation (DC0082) | Session opened from a partner or vendor address space into a管理 segment that the partner does not normally reach | Zeek connection logs, Suricata flow records, Wazuh agent network events | Linux, macOS, IaaS network paths |
| Network Traffic Content (DC0085) | Protocol use on a vendor link that differs from the agreed baseline, such as new admin protocols or unexpected payload types | Zeek protocol analyzers, Suricata rule alerts, Security Onion dashboards | Cross-boundary links, VPN and site-to-site tunnels |
| Application Log Content (DC0038) | Sign-in or API calls made by a service account or partner identity outside its approved hours, hosts or scopes | Wazuh log collection from SSH, sudo and auth logs on Linux and macOS | Linux, macOS, identity-linked services |
| Network Traffic Flow (DC0078) | Volume or direction changes on a trusted link, such as sustained outbound transfers from a vendor-managed host | Zeek conn summaries, Suricata flow metadata, Security Onion session views | Network segments, VPN gateways |
| Process Creation (DC0032) | Administrative tooling launched under a vendor or managed-service account on a host it normally only monitors | Wazuh process monitoring, Auditd or Sysmon-equivalent event collection on Linux and macOS | Linux, macOS endpoints |
| IaaS control plane logs | Role assumption, key or policy changes, or new access grants made by an external or partner principal | Cloud-native audit logs forwarded to Wazuh or a SIEM for correlation | IaaS accounts and projects |
| Identity provider sign-in logs | Federated or guest sign-ins from a partner tenant, unusual conditional access results or new app consent events | Identity provider log export into Wazuh or Security Onion via an API connector | Identity provider, SaaS |
Detection ideas for trusted relationship logins and connections
Trusted relationship abuse looks like legitimate traffic, so detection depends on comparing partner activity against what that partner is documented to do. The four cards below cover identity, scope, network and service account signals, each with logic, tuning points and the maintenance windows that generate false positives.
Anomalous partner login patterns
Build a baseline for each partner or vendor account covering login hours, countries, autonomous systems and source networks. Alert when a login falls outside that baseline, such as a vendor account authenticating at an hour the vendor never works or from a network that is not in the contract. Tune the time window per partner, since follow-the-sun support teams break simple business-hours rules. Expect false positives from scheduled vendor maintenance, change windows and staff travel, so require a matching change ticket or a pre-registered maintenance calendar before suppressing an alert. Confirm the source ranges with each partner in writing before you enforce them.
Partner access outside documented scope
Map each partner identity to the applications, projects, tenants and data sets named in its access agreement or onboarding record. Alert when the identity reads or changes a resource outside that list, especially directory objects, backup repositories or production secrets stores. Start in report-only mode for two to three weeks to learn how partners actually use their access, then convert the stable exceptions into an allow list. Scope drift from legitimate projects is the most common false positive, so route these alerts to the account owner inside your organization for confirmation.
New connections from vendor ranges to sensitive segments
Use network connection telemetry and flow records to list every connection that starts from a vendor address range and terminates in a restricted segment such as database tiers, domain controllers or management networks. Alert on any first-seen pairing of source range and destination segment, since a new path is a strong signal even when the credentials are valid. Tune the rule by allowing known jump hosts and approved VPN concentrators, and review the allow list after each contract change. Vendor patching and scheduled diagnostics will create expected new pairings, so tie those windows to change records rather than to fixed time suppressions.
Unusual administrative actions by service accounts
Service accounts used by integrations and managed service providers often hold broad rights and rarely log in interactively. Alert on administrative actions performed by these accounts that fall outside their recorded task list, such as creating accounts, changing group membership, altering logging settings or disabling security tools. Set a threshold on the count of privileged changes per hour per account and alert on the first occurrence of any action type that the account has never performed. Scheduled automation, backup jobs and patch runs are the main false positive sources, so maintain a registry of expected actions per account and review it at each change window.
How to validate that trusted relationship detections fire
This sequence proves that detections for T1199 Trusted relationship fire when a partner identity or IaaS access path is abused in a controlled way. It produces documented evidence of time to alert, available fields and gaps, recorded against the ATT&CK version the team targets.
Define the partner access scenario
Write down one partner access path in scope, such as a managed service provider with a federated identity role into the staging IaaS tenant. Name the accounts, roles, source networks and the expected normal activity for that partner. The security engineering lead and the partner's named contact approve the scenario in writing. This step is done when the scenario has a single owner, a bounded set of accounts and a written list of behaviors that should look benign and behaviors that should alert.
Agree the emulation with the partner
Take the scenario to the partner and to your change control board before any activity runs. Agree the window, the emulation owner, the stop conditions, how partner staff will be told when activity starts and ends, and who can halt the test. Confirm that the partner's own monitoring will not treat the test as a live incident without notice. The step closes when the change record is approved and both parties have signed off on the rules of engagement.
Prepare the staging identity provider and IaaS tenant
Confirm that the staging identity provider and IaaS tenant mirror production logging for the partner path. Check that sign-in events, role assumption events, control-plane API calls and network flow records are all being forwarded to Wazuh or the SIEM, and that the partner's accounts carry the same role scope as production. Verify time synchronization across sources so timestamps can be compared. The step is complete when a known test event is visible end to end in the SIEM.
Run the emulation against staging
The emulation owner runs the agreed scenario in the staging tenant, using only the steps in the approved plan. The run covers both expected partner activity and the out-of-pattern activity defined in step one, such as access from an unexpected source network or use of a role outside the partner's scope. A second engineer records start and end times for every action in a shared log. The step is complete when every planned action has a matching timestamp in the log.
Check each detection fires in the SIEM
For each detection mapped to T1199, search the SIEM for the matching events from the run and confirm that the alert or hunt result appears. Check the Network Connection Creation, Network Traffic Content and Application Log Content signals that the detection depends on. Confirm that the rule is tied to the correct ATT&CK technique and detection strategy identifiers for the targeted version. The step closes when each planned action is either alerted on, or logged as a gap with a reason.
Record time to alert and fields present
For each alert, record the delay between the emulated action and the alert, and list the fields available in the event, such as partner identity, source address, role name and target resource. Mark any field that is missing or empty as a gap. Compare results against the expected baseline for the partner so that noisy but benign activity is also noted. The output is a results table with one row per action, showing time to alert, fields present and gaps.
Document results against the targeted ATT&CK version
Write the results up with the ATT&CK version number the team targeted, the detection strategy identifiers used and the data components relied on. Note any technique or mapping that MITRE has renamed, deprecated or revoked in the version in use, and record the date of the review. Assign an owner and a remediation item for each gap, such as adding a log source or tightening a rule. Confirm with the vendor or the MITRE updates page which version is current before the next review, and retain the report as evidence for the change record.
Mitigations that limit trusted relationship exposure
A trusted relationship gives an adversary a path into your environment through a party you already trust, so the controls that matter most sit at the boundary: who holds partner accounts, what those accounts can reach, and how the network separates vendor access from sensitive systems. The cards below cover the two ATT&CK mitigations that map to T1199 Trusted relationship, plus the recurring review that keeps both current.
Account lifecycle for partner identities
Every partner or vendor identity should have a named sponsor inside your organization, a documented business need, an expiry date, and a removal step tied to the end of the contract or project. Dormant partner accounts are a common way access outlives its purpose. Under ATT&CK mitigation User Account Management (M1018), check that account creation, change and deletion for external users follow the same workflow as internal joiners and leavers, and that orphaned accounts are reported on a fixed schedule. Ask whether any partner account has been active without an owner in the last review cycle.
Least privilege for partner accounts
Partner accounts should receive only the roles, groups and API scopes needed for the contracted task, and privileged roles should require a separate, justified grant. Shared credentials used by a vendor should be replaced with individually assigned identities so that activity can be attributed. Under M1018, confirm that each partner role is mapped to a written entitlement and that administrators can list every external identity and its effective permissions from one place. Test the mapping by checking whether a partner account can reach systems outside its documented scope.
Segmenting vendor access paths
Vendor connections such as remote support tunnels, VPN profiles, jump hosts and site-to-site links should terminate in a restricted zone, not directly on the network segments that hold production data, identity stores or backup infrastructure. Under ATT&CK mitigation Network Segmentation (M1030), document which source addresses and destinations each vendor path may use and enforce that with firewall or cloud network rules. Confirm that a compromised partner session cannot reach administrative interfaces of sensitive systems without passing a second, separately monitored control.
Monitoring partner sessions at the boundary
Segmentation limits reach, but you still need to see what partner sessions do inside the allowed zone. Log authentication events, session starts and stops, and administrative actions for external identities, and forward them to the same monitoring platform used for internal users. Alerts should flag logins outside the agreed hours or source ranges, and access to segments the partner should never touch. Confirm that the boundary logs have enough retention to support an investigation that starts after a vendor notifies you of an incident.
Reviewing partner access regularly
Partner access drifts as contracts change, staff move between vendors and projects close. Treat a periodic review of all external identities, their entitlements and their network paths as a control to confirm in your own environment, not a one-time clean-up. The review should compare current access against contract scope, record who approved each exception, and feed removals back into the lifecycle process. Ask your auditor or internal assurance team which review cadence and evidence they expect for third-party access in your regulatory context.
Triage and response when a trusted relationship alert fires
The first decision is whether the alert reflects an approved change or an unauthorized use of the partner path. Start by confirming the partner identity behind the activity: which service account, federated identity, VPN peer or API client was used, and which partner organization owns it. Then check the change calendar and the partner's agreed maintenance windows for a matching request. If nothing matches, treat the alert as a suspected compromise of the partner path until proven otherwise, and open an incident record before further action so that every later step is timestamped. Keep the triage narrow at this stage: the goal is a yes or no on legitimacy, not a full investigation.
Containment should cut the partner access path, not the whole integration, unless the evidence requires it. Depending on the platform, that means suspending the service account or federated trust in the identity provider, revoking the active tokens or sessions tied to that identity, or restricting the firewall rule or VPN peer that carries the traffic to the minimum set of hosts the partner needs. Before you change anything, export and hash the identity provider sign-in logs, the authentication and token records, the firewall or VPN session logs and the relevant application audit logs, so that containment does not erase the evidence you need. Confirm with the owners of the integration which business processes will stop when access is suspended, and record that decision.
Engage the partner through the contacts agreed before the incident, not through contacts found during the alert, since those may be the path under suspicion. Ask the partner to confirm whether the activity was theirs, to name the affected credentials, and to share their own logs for the same window. Then scope outward: list every account, host, API and data store reachable through the same relationship, and review each for the same activity pattern, including accounts that the partner can assume or delegate to. Feed the outcome back into detection tuning by documenting which legitimate maintenance patterns caused false positives, which signals were missing, and which owners needed to be contacted. Confirm your own partner contact list and escalation path against the current agreement before the next exercise.
Rehearsing trusted relationship detection in a private cyber range
The IaaS environment models a cloud tenant that a managed service provider or integration partner administers through a delegated role or cross-account trust. Build the tenant with a non-production account, a sample workload set, and the control plane logs forwarded to the range SIEM. The point of the exercise is to see whether the SOC notices a trusted partner identity doing things that fall outside its contracted pattern.
- Off-hours partner session (illustrative): A partner role authenticates at an hour outside its usual window and enumerates resources it does not normally touch. Expect an alert tied to the time and the action pattern, not to the role name alone.
- New trust or role change: Inject a change to the cross-account trust policy. Good detection flags the modification and correlates it with the identity that made it.
- Decision points: Does the analyst confirm the partner contact through a pre-agreed out-of-band channel? Is the role suspended, scoped down, or left running while the investigation continues?
- Good response: The SOC preserves control plane logs, reviews every API call made by the role since the last known-good state, and documents who authorized what.
Confirm with your IaaS provider which control plane audit logs are available for your account tier and how long they are retained in your configuration.
The identity environment models a federated relationship with a partner's identity provider, where users from the partner sign in to your applications through single sign-on. Use a test identity provider, a test relying party application, and sign-in logs routed to the range SIEM. The exercise tests whether the SOC can separate a legitimate federated sign-in from a partner account that has been compromised upstream.
- Impossible travel across federated sessions (illustrative): Two federated sign-ins for the same partner user originate from distant locations within a short window. Good detection raises the alert on the pair, not on either event alone.
- Unexpected application access: The partner user reaches an application outside their assigned group. Expect a correlation with the group membership record.
- Decision points: Does the analyst revoke active sessions, disable the federated user, or ask the partner's security team to confirm first? Who holds authority to make that call at each hour?
- Good response: The SOC pulls sign-in and token issuance logs from both sides of the trust, identifies every application reached, and checks whether the partner's identity provider reported the same activity.
Confirm with your identity provider vendor which federation logs carry the source IP, device details and token identifiers you need for this correlation.
The host environment models a group of Linux and macOS systems that a managed partner reaches through a remote management agent or a shared service account. Build the hosts with the agent installed, forward authentication and system logs to the range SIEM, and place the group on its own network segment. The exercise checks whether the SOC can spot a trusted management path being used for unplanned work.
- Service account used from an unexpected source (illustrative): The shared partner account logs in from a host that is not in the approved management list. Good detection compares the source against an asset inventory.
- Unplanned change activity: Inject configuration changes on several hosts outside the agreed maintenance window. Expect alerts tied to the window schedule.
- Decision points: Does the analyst isolate the segment, rotate the shared credential, or allow the partner session to continue while confirming? Who is authorized to rotate the credential?
- Good response: The SOC captures host logs and relevant network connections before containment changes, then checks which other hosts accepted the same credential.
Confirm with your agent vendor which activity the agent logs locally and whether those logs can be shipped to your central platform.
Questions SOC leads ask about detecting trusted relationship abuse
How do we separate partner logins from normal vendor support activity?
Start by treating each vendor relationship as its own identity population with a documented purpose, source networks, accounts and expected working hours. Partner logins become suspicious when they fall outside that baseline, not simply because they come from an external party. In practice, a detection should compare the partner account's source address, target system, time window and action type against an agreed profile maintained with the vendor. Where the identity provider or application logs record the account's role, a detection can flag privilege changes or access to systems the vendor's ticket does not reference. Confirm with each vendor how they route support sessions, because a shared jump host can hide the real operator. Illustrative example: a support account that normally signs in from one vendor address during business hours and suddenly authenticates from a new range at 2 a.m. should generate a case, not an automatic block.
How do we tune for noisy service accounts without blinding the SOC?
Tune by narrowing the expected behavior of each service account, not by excluding the account. Build a per-account baseline from Application Log Content and Network Connection Creation records over a representative period, then alert on deviations such as a new destination, a new protocol or interactive logon. Keep exclusions as time-bound, reviewed entries with an owner and an expiry date. Ask the platform team to document which service accounts are expected to be used by trusted third parties, because those accounts are the most likely to be abused silently. Review tuning changes against the ATT&CK version your rules target, since data component mappings can change between releases.
Does Zeek or Suricata alone cover trusted relationship detection?
Neither tool covers this technique alone. Zeek and Suricata are strong sources of Network Connection Creation and Network Traffic Content, which helps when a trusted connection carries unexpected protocols, unusual volumes or unknown destinations. However, much of the abuse happens through legitimate, authenticated sessions that look normal on the wire. For those cases you need identity provider logs, cloud control plane audit logs and application logs, typically collected in Wazuh or a similar platform. Confirm during design which of these sources you can actually collect from each vendor path, including encrypted tunnels where content inspection may not be possible.
How should we handle sub-technique changes between ATT&CK versions?
Pin each detection to a named ATT&CK version and record that version in the rule metadata, so you can see which mapping a detection was written against. Recent releases, including v18, v19 and v20, have changed detection content and data components, and releases can rename, deprecate or revoke techniques. Review the release notes for each new version, compare the STIX bundle for the technique and its sub-techniques, and update the mapping in your rule library. Schedule that review as recurring work, because the change is ongoing rather than a one-time project.
How do we measure detection coverage for this technique?
Measure coverage by mapping each detection to the specific data components and sub-techniques it addresses, then testing whether the expected telemetry arrives and the rule fires. A useful coverage view shows, for each vendor relationship, which data sources are collected, which detections are deployed and which tests have passed in the cyber range. Track gaps as explicit items with owners, rather than a single percentage. Confirm with your own asset inventory which trusted connections exist, because you cannot measure coverage for relationships nobody has recorded.
Which mitigations should we verify first for trusted relationships?
Verify User Account Management and Network Segmentation first, since ATT&CK maps both to this technique. For accounts, check that partner identities are provisioned individually, carry expiry dates, follow least privilege and are reviewed on a schedule you define. For networks, confirm that vendor connections land in restricted segments with explicit allow lists, and that a compromised partner cannot reach unrelated systems. Document the evidence for each control so an auditor can trace it to a detection and a test result.
What does DeployOpen do for trusted relationship detection?
DeployOpen implements and tests open-source detection pipelines in your own environment, including log collection, rule deployment and tuning against the vendor relationships you define in writing. It also runs security testing and private cyber range exercises that rehearse trusted relationship abuse scenarios with your SOC. DeployOpen prepares controls and evidence for compliance assessments, but independent auditors issue any reports or certifications. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen builds trusted relationship detections and range exercises
DeployOpen works on T1199 Trusted relationship as a scoped piece of platform work inside the client's own environment, covering the identity, network and application logging paths that third-party access uses. Each engagement ends with detections, tested evidence and a range exercise the client's own team can repeat.
How we scope
- Agree in writing which third-party accounts, IaaS tenants and identity providers fall inside the T1199 detection scope.
- Inventory the vendor connections, VPN paths and API integrations that carry trusted access into the client environment.
- Confirm which telemetry sources the client already collects for Network Connection Creation and Application Log Content before building.
How we build
- Map detection logic to the ATT&CK version the client targets, naming the version in every rule and mapping.
- Deploy open-source collection and detection content in Wazuh, Zeek, Suricata or Security Onion where the client already runs them.
- Document User Account Management and Network Segmentation controls that limit what a trusted partner account can reach.
How we hand over
- Deliver detection logic as readable Sigma rules with tuning notes, known gaps and the data each rule depends on.
- Provide a range exercise runbook that rehearses a trusted-relationship scenario in a private cyber range, with expected alerts listed.
- Record validation results and response steps so the client team can rerun the test without DeployOpen present.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement closes.
- Review detections when MITRE publishes new ATT&CK releases, since releases can rename, deprecate or revoke techniques.
- Ask for the retainer scope, review cadence and range access terms in the written quote before work starts.
