Skills · learning

Forest and Domain Trusts

Study scope These are concept notes from the CRTO lesson, not a record that a trust lab or exam objective was completed. The pictured domains illustrate the course material; they are not observed hosts in a current lab.

Quick navigation

• Follow a lab sequence: parent-child trust or one-way inbound trust.
• Compare with the instructor's parent-child demonstration.
• Review my parent-child evidence and continuation.
• Review the inbound-trust discovery and ticket evidence.
• Review the separate outbound-trust lab.

Why trusts exist

A trust lets a domain or forest accept authentication from another domain or forest so that users can be granted access to resources across that boundary. The trust creates a possible authentication path; resource permissions and other controls still decide whether a particular user can access anything. Trusts can connect domains within one forest, a domain in each of two forests, or whole forests.

Types of trust

The picture uses fabrikam.com and contoso.com as roots of two trees in forest 1, dublin.contoso.com as a child domain, and partner.com and child.partner.com in forest 2. The cross-forest link from dublin.contoso.com to child.partner.com illustrates an external domain trust, distinct from the forest trust between the forest roots.

Transitivity

Transitivity asks whether a trust path can extend beyond the two domains that have the explicit link. With A ↔ B and B ↔ C as transitive relationships, A and C can have an implicit authentication path. A non-transitive external trust stays between its named partners. An implicit path is not an implicit grant of resource access.

Direction: trusted and trusting

The trusted domain holds the user identities. The trusting domain holds resources and accepts authentication for those identities. In the course diagram, C trusts A, so eligible A users may be granted access to C resources; the reverse does not follow from that one-way trust. A two-way trust enables the authentication path in both directions. Inbound and outbound are relative to the domain from which you view the trust; name that viewpoint before interpreting them.

Correction to my spoken shorthand: “There is no such thing as a two-way trust” is too absolute. Two-way/bidirectional is a real AD configuration (trustDirection = 3). It can be understood as two one-way trust directions operating in opposite directions. Both descriptions are useful; the bidirectional setting is real.

Trusted domain objects

AD stores trust information in trusted domain objects (TDOs). In the lesson, the Beacon query shown is:

ldapsearch (objectClass=trustedDomain)

This screenshot shows the query, not its output. In an authorized lab, a returned TDO can be examined for the partner, direction, and attributes. The direction value is relative to the local domain; a TDO alone does not prove that a resource is reachable or that an identity has access.

Realm, domain, and forest

• A Kerberos realm is the namespace administered by a KDC. In an AD deployment, a domain normally corresponds to a Kerberos realm, commonly written in uppercase (CONTOSO.COM). The realm is the authentication namespace; the AD domain also contains directory objects, groups, policies, and domain controllers.
• A forest is one or more AD domains sharing a schema, configuration, and within-forest trust structure. It is not itself a single Kerberos realm. dublin.contoso.com and contoso.com are separate domains/realms inside one forest.
• Inter-realm means crossing from one Kerberos realm to another. The referral TGT is an intermediate credential for asking the next realm's KDC for a service ticket. It is neither the foreign service ticket nor proof of permission on that service.

How an inter-realm referral works

For the simple, directly trusted case pictured:

1. The client has its home-realm TGT and asks the local KDC for a ticket to a service named in another realm.
2. The local KDC returns a referral TGT for the foreign realm. The trust account's shared secret derives the inter-realm key used to protect this referral ticket; the home realm's ordinary krbtgt key is used for ordinary home-realm TGTs.
3. The client presents the referral TGT to the foreign KDC and requests the target service ticket.
4. The foreign KDC validates the referral and, if the request is allowed, returns a ticket for the specific foreign service. The client then presents that service ticket to the service. A successful AP exchange still does not bypass the service's access checks.

Correction to my narration: the TGS response is not “signed by the TGT.” The referral ticket is protected with a trust-derived key, and the foreign KDC uses the corresponding trust secret to process it. Ticket encryption, PAC signatures, and the client's encrypted response are different pieces; do not collapse them into one signature.

The course capture labels the first request's realm as CONTOSO.COM while its requested sname is TERMSRV/par-jmp-1.partner.com. The realm field and the service name answer different questions; the local KDC uses the target name and trust path to refer the client onward. This capture is a lesson illustration, not a fresh packet capture from Ryan's lab.

In the later request, the client addresses PARTNER.COM and presents the referral ticket to that realm's KDC. The service name stays the specific TERMSRV target. Multiple trust hops would require additional referrals; the diagram shows one hop.

Trust account versus trusted domain object

The TDO records the relationship and its attributes, including partner and direction. A domain trust account represents the other domain as a principal and holds trust secret material used to derive inter-realm keys. These related objects are not the same thing, and a trust account is not a normal human user who automatically has resource access.

The supplied course screenshot shows sAMAccountType=805306370 returning PARTNER$ from a contoso.com LDAP query. Microsoft calls this account type SAM_TRUST_ACCOUNT (0x30000002). The image establishes a course example of a trust account listing; it does not show the secret or prove an accessible foreign service.

Parent-child trust and the SID question

A new child domain gets an automatic two-way, transitive trust with its parent. This creates an authentication path through the tree, including more distant descendants; it does not itself confer Enterprise Admin rights.

In the supplied course example, trustDirection: 3 means bidirectional and trustAttributes: 32 (0x20) means within the same forest. The screenshot does not show a live result from today's lab.

The domain SID is the prefix that identifies a domain; a RID appended to it identifies a principal or group. In this example, the root domain's SID matters because the Enterprise Admins group has RID 519 in the forest root. Its full SID is therefore <ROOT_DOMAIN_SID>-519. Microsoft documents sIDHistory as a migration mechanism that carries prior SIDs into authorization decisions.

The course illustrates a child-domain compromise followed by forged ticket authorization data containing a privileged root-domain SID. This needs control of the appropriate child-domain Kerberos key, a valid trust path, and acceptance of the added SID under the boundary's filtering rules. Domain Admin in a child domain is a serious forest-level risk, but it is not automatically a successful Enterprise Admin logon.

The read-only LDAP query Ryan quoted targets the root domain's objectSid through a root-domain DC. That SID identifies the group prefix to compare or construct in the lab. Reading it is neither secret recovery nor privilege escalation. See the redacted trust reference for the query shape.

Golden and diamond: what changes

Both need the relevant key; neither should be described as guaranteed stealthy or automatically accepted. The example /sids: value is an extra authorization SID, not the domain SID of the user. In the supplied examples, -519 denotes root Enterprise Admins and -512 denotes a domain's Domain Admins group; the suffix is meaningful only with the correct domain SID prefix. Rubeus's /tgtdeleg option in the diamond example obtains a starting TGT; it does not remove the requirement for /krbkey to modify and re-protect it. The pasted key, full SIDs, and ticket material are intentionally omitted from this note.

The final screenshot is a course example showing a directory listing after a ticket was injected into a logon session. It is not evidence that Ryan ran that step, reached lon-dc-1, or completed a current challenge. A ticket's creation and injection remain separate from proof of accepted authentication and authorization.

Guided lab routes

Use these runbooks only for the matching authorized course lab. The two routes solve different trust problems. Keep directory mapping, credential access, ticket construction, and resource proof as separate stages.

A trust, a group membership, a GPO link, a ticket, and successful resource access are different facts. Record the evidence for each link. A GPO link alone does not prove effective application; a ticket alone does not prove permission.

Parent-child lab: child golden TGT with parent group SID

Lab context: child domain dublin.contoso.com, child DC dub-dc-1, parent root contoso.com, parent DC lon-dc-1. The lab identity is DUBLIN\sguest. Do not carry raw keys or ticket blobs into the vault.

1. Read the trust from the child-domain Beacon.

   ldapsearch (objectClass=trustedDomain) --attributes trustPartner,trustDirection,trustAttributes,flatName
   

   Expected lab values: trustPartner=contoso.com, trustDirection=3 (bidirectional), trustAttributes=32 (0x20, within-forest), flatName=CONTOSO. Interpret the direction from the domain that owns the queried TDO. This is configuration evidence, not access.

2. Read the child domain SID and parent target-group SID.

   ldapsearch (objectClass=domain) --hostname dub-dc-1 --dn DC=dublin,DC=contoso,DC=com --attributes objectSid
   ldapsearch "(&(samAccountType=268435456)(samAccountName=Enterprise Admins))" --hostname lon-dc-1 --dn DC=contoso,DC=com --attributes objectSid
   

   Expected lab values: child SID S-1-5-21-690277740-3036021016-2883941857; parent Enterprise Admins SID S-1-5-21-3926355307-1661546229-813047887-519. The -519 RID means Enterprise Admins only when paired with the root-domain SID.

3. Confirm the lab identity and its permitted replication rights. The exercise describes sguest as a child-domain administrator. Treat that as a lab precondition; a process label or token-steal success alone does not verify group membership or DCSync rights. Request only the child krbtgt material required by the exercise:

   ps
   steal_token <PID_RUNNING_AS_DUBLIN_SGUEST>
   getuid
   dcsync dublin.contoso.com DUBLIN\krbtgt
   

   The result may contain AES/NTLM secrets. Keep them in the approved lab workflow only. DCSync is a secret-replication request; it does not create a ticket. Replication requests from a non-DC source can be anomalous and are a monitoring signal, not an OPSEC guarantee.

4. On the Attacker Desktop, create the child-realm ticket. Replace the key placeholder in memory with the authorized lab value; never paste the value into these notes. The output path/extension can vary by Rubeus build, so confirm the file actually written in the command output.

   C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe golden /user:Administrator /domain:dublin.contoso.com /sid:S-1-5-21-690277740-3036021016-2883941857 /sids:S-1-5-21-3926355307-1661546229-813047887-519 /aes256:<CHILD_KRBTGT_AES256> /outfile:C:\Users\Attacker\Desktop\golden
   

   The ticket is a TGT for the child realm. /sids adds the parent Enterprise Admins SID to its authorization data. A trust does not make the ticket automatically acceptable: trust SID filtering and the target's authorization still apply.

5. Apply the generated ticket to the intended Beacon session and verify its cache. Use the actual output path from step 4. Ryan's recorded continuation also used make_token DUBLIN\Administrator before ticket use to establish a netonly network context. That is a demonstrated variant, not a universal prerequisite; the placeholder password is not validated.

   kerberos_ticket_use C:\Users\Attacker\Desktop\<GENERATED-GOLDEN-TICKET>.kirbi
   run klist
   

   Look for a client in DUBLIN.CONTOSO.COM and a krbtgt/dublin.contoso.com TGT. kerberos_ticket_use injects/applies a ticket to the current session; do not assume it erased other cached tickets unless the cache output proves that. klist proves ticket presence, not target acceptance.

6. Test the one resource named by the lab.

   ls \\lon-dc-1\c$
   

   A directory listing is proof that this session accessed this share. It does not by itself prove every Enterprise Admin capability or unrestricted control of the parent domain. Remove temporary ticket files and clear the lab session's tickets only as the course cleanup requires.

Inbound-trust lab: Contoso group to Partner local admin

Lab context: the TDO is queried from Contoso; the foreign domain is partner.com; the target DC is par-dc-1.partner.com; the candidate jump host is par-jmp-1.partner.com. The objective has two parts: map the intended Partner authorization path, then test the named CIFS resource using the lab's Contoso identity. Do not treat the trust alone as access.

1. Interpret the trust from the Contoso viewpoint.

   ldapsearch (objectClass=trustedDomain) --attributes trustDirection,trustPartner,trustAttributes,flatname
   

   Expected lab values: Partner is the trust partner and trustDirection=1. From Contoso's view, Partner trusts Contoso, so eligible Contoso identities may authenticate to Partner, subject to Partner-side authorization. The screenshot set also showed trustAttributes=8 (forest-transitive); that bit does not change the one-way direction or grant access.

2. Find Partner's foreign security principal (FSP) for the Contoso group, then resolve that SID in Contoso.

   ldapsearch (objectClass=foreignSecurityPrincipal) --attributes objectSid,memberOf --hostname partner.com --dn DC=partner,DC=com
   ldapsearch (objectSid=S-1-5-21-3926355307-1661546229-813047887-6102) --attributes samAccountType,distinguishedName
   

   The FSP SID ending -6102 resolves to Contoso's Partner Jump Users group. In Partner, the FSP is nested in Contoso Users. An FSP is a placeholder for an external SID, not a second copy of the user or group.

3. Find who belongs to the Contoso jump group.

   ldapsearch "(&(|(samAccountType=805306368)(samAccountType=268435456))(memberof=CN=Partner Jump Users,CN=Users,DC=contoso,DC=com))" --attributes distinguishedName
   

   This memberOf filter checks direct membership. If nested membership is relevant, expand the chain with a separate recursive membership query rather than assuming this result includes nested members.

4. Locate a Partner DC and enumerate Partner's GPO metadata.

   nslookup _ldap._tcp.dc._msdcs.partner.com 10.10.120.1 SRV
   ldapsearch (objectClass=groupPolicyContainer) --hostname par-dc-1.partner.com --dn DC=partner,DC=com --attributes displayName,gPCFileSysPath
   

   The SRV query locates a DC, not a workstation. Find Contoso Jump Users and record its actual gPCFileSysPath/GUID from the result.

5. Inspect the GPO's local-group policy in SYSVOL. Use the GUID just returned (the lab GUID below is DFE606B4-CA59-4AD6-9BCE-55AF35888129).

   download \\partner.com\SysVol\partner.com\Policies\{DFE606B4-CA59-4AD6-9BCE-55AF35888129}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf
   

   In [Group Membership], the Partner group SID ending -1104 has __Memberof = *S-1-5-32-544. S-1-5-32-544 is the built-in local Administrators group. Resolve the Partner SID rather than guessing its name:

   ldapsearch (objectSid=S-1-5-21-4244029708-1901239654-2578485347-1104) --hostname par-dc-1.partner.com --dn DC=partner,DC=com --attributes samAccountType,samAccountName,member
   

   This maps the Partner group to its members, including the Contoso FSP path. GptTmpl.inf shows intended policy content, not proof that every candidate computer processed it.

6. Check the GPO link and enumerate concrete computers.

   ldapsearch "(&(|(objectClass=organizationalUnit)(objectClass=domain))(gPLink=*{DFE606B4-CA59-4AD6-9BCE-55AF35888129}*))" --hostname par-dc-1.partner.com --dn DC=partner,DC=com --attributes objectClass,name
   ldapsearch (samAccountType=805306369) --hostname par-dc-1.partner.com --dn DC=partner,DC=com --attributes distinguishedName
   

   The lab's GPO is linked at the Partner domain root and the computer list includes PAR-JMP-1. Before claiming effective local-admin rights, account for security filtering, link/enforcement state, WMI filters, inheritance, and whether the selected host actually processed the policy.

7. Confirm the Contoso identity, then follow the lab Kerberos chain. Select the high-integrity Beacon. The course describes dyork as a Contoso Domain Admin; the continuation used steal_token on dyork's process and then checked the Beacon identity. If using that route, run steal_token and verify with getuid. A token label alone does not prove replication rights. Then keep the three tickets distinct:

   dcsync contoso.com CONTOSO\rsteel
   krb_asktgt /user:rsteel /aes256:<RSTEEL_AES256>
   krb_asktgs /service:krbtgt/partner.com /ticket:<CONTOSO_TGT>
   krb_asktgs /service:cifs/par-jmp-1.partner.com /targetdomain:partner.com /dc:par-dc-1.partner.com /ticket:<PARTNER_REFERRAL_TGT>
   

   krb_asktgt requests a Contoso home-realm TGT for rsteel; the first krb_asktgs requests a Partner referral TGT; the second requests the final CIFS service ticket for the SMB share. Secret and ticket arguments are placeholders. A successful TGT/TGS request is not share-access proof.

8. Apply the final ticket if the Beacon alias returned it as Base64 rather than importing it. The lab continuation decoded the returned ticket.kirbi text to a file, established a netonly context, and then applied that file:

   [IO.File]::WriteAllBytes('C:\Users\Attacker\Desktop\jmp-cifs.kirbi', [Convert]::FromBase64String('<BASE64-CIFS-TICKET>'))
   

   make_token CONTOSO\rsteel <LAB_PLACEHOLDER_PASSWORD>
   kerberos_ticket_use C:\Users\Attacker\Desktop\jmp-cifs.kirbi
   run klist
   

   Use the conversion/import path only when the tool output requires it. In the continuation, make_token created a netonly network context before ticket use; its placeholder password was not validated. klist should show the intended client and cifs/par-jmp-1.partner.com service ticket. If the installed alias already imported it, verify the cache instead of duplicating the import.

9. Test only the named SMB resource.

   ls \\par-jmp-1.partner.com\c$
   

   A directory listing is the required proof for this lab target. In Ryan's supplied screenshots, the ticket workflow was observed but the final C$ result was not included; mark that share access as reported, not screenshot-verified until the output is captured. Restore the lab token, purge only the relevant session cache, and remove temporary ticket files as the exercise cleanup requires.

Instructor's child-to-root demonstration (video notes)

These are observations of the lesson video, not Ryan's own lab result. The screenshots show a sequence across dublin.contoso.com (child) and contoso.com (forest root). The example's key and complete forged-ticket command are omitted because they expose credential material. One screenshot with an identifying overlay is also omitted; the non-secret observation is recorded below.

Why DCSync appeared here

DCSync asks a domain controller for directory secret material using replication privileges, as though the requester were a replication partner. The instructor targeted the child domain's krbtgt account to obtain the key needed for a child-issued forged TGT. This is different from querying public SID metadata. The resulting key is powerful and can support persistent access if abused later, but DCSync itself is the secret-acquisition step. See MITRE's DCSync description.

When golden versus diamond makes sense in the course

• Golden: the operator already controls the relevant realm's krbtgt key and needs to construct a new TGT with the identity/authorization fields required by the authorized exercise. The video uses the child key to make a child-issued TGT carrying an added root-group SID. A normal password, trust direction, or domain SID alone is insufficient.
• Diamond: the operator has the same realm's krbtgt key and can first obtain a genuine TGT, for example as a controlled domain identity. Rubeus then edits and re-protects that issued ticket. It may retain ordinary issuance characteristics, but it is not inherently undetectable or a shortcut around the key requirement.

For both, the foreign or parent KDC must accept the referral and authorization data under the actual trust's SID-filtering rules, and the target service must accept the resulting identity and rights. A lab screenshot from a different domain topology is not a transferable recipe.

Ryan's Parent-Child Trust Lab - 5 November 2026

This section records Ryan's own lab attempt. The supplied Beacon screenshots are stamped 11/05 11:06–11:12; their timezone is not shown. This is separate from the instructor's video above and from any CRTO exam attempt. The lab objective and full rules of engagement were not supplied here, so this record covers only the shown, authorized course-lab activity.

Earlier checkpoint: trust and root group SID lookups succeeded; token impersonation reported success; the child-domain SID result and DUBLIN\sguest group/replication-rights evidence were not in that capture; the first DCSync attempt failed at pipe access. Ryan later continued the lab with a different Beacon/session context.

Ryan's Parent-Child Trust Lab - continuation

The following evidence continues the same authorized course lab on 5 November 2026. The images show a later Beacon/session context and the resulting ticket workflow. Raw key material and full ticket blobs are intentionally not stored.

Why the ticket was made on the Attacker Desktop

Rubeus ticket construction is a local cryptographic operation. The Attacker Desktop had the tool, the lab identifiers, and the key input; it did not need to be the Beacon host. The resulting .kirbi file then had to be available to the Beacon session for kerberos_ticket_use. Creating a file locally and applying it remotely are separate steps.

Why make_token appeared before kerberos_ticket_use

Fortra documents make_token as cloning the current token while setting network logon information for the supplied account; it does not validate the password and does not change local authorization. kerberos_ticket_use applies a ticket to the current session. In this lab sequence, make_token created the netonly/network logon context that the subsequent Kerberos ticket and SMB request used together. Treat that as the demonstrated session workflow, not a universal rule that every Beacon build requires make_token before ticket injection. The decisive evidence is the later klist output and successful parent-share listing.

Why the realm stayed DUBLIN.CONTOSO.COM

The ticket shown by klist is a TGT for the child realm. The root-domain SID in its authorization data is what supports the cross-domain authorization path under the trust. A child-realm TGT does not become a CONTOSO.COM TGT merely because it can be used to reach a root-domain resource. Verify the actual service ticket and resource result when the lab asks for more than the share listing.

Ryan's Inbound Trust Demo - screenshot session

The following records the next authorized course-lab demonstration. The supplied screenshots are timestamped 02/06 12:28 through 12:43; the year, timezone, and whether the display uses day/month or month/day ordering are not supplied. The DCSync output, raw AES key, and Base64 ticket blobs are intentionally not embedded or copied into the vault. The user/member result screenshot also has an identifying overlay, so its text is recorded without embedding that image.

What the screenshots establish

The trust-to-local-admin chain

flowchart LR
    U[CONTOSO user: Robert Steel] --> G[CONTOSO group: Partner Jump Users]
    G --> F[Partner FSP for the Contoso group SID]
    F --> PG[PARTNER group: Contoso Users]
    PG -->|domain-linked GPO| A[BUILTIN Administrators on in-scope Partner machines]

The important finding is not simply "there is a trust." It is the combination of a cross-domain group membership and a Partner GPO that places the Partner group in each in-scope computer's local Administrators group. The trust provides the authentication path; the group and GPO provide the authorization path.

Clarifications from this demo

• What does trustDirection: 1 mean? It is not a plain-English arrow that means "we can go into Partner." For a TDO whose primary/local domain is Contoso and whose trusted-domain partner is Partner, Microsoft defines 1 as inbound: the trusted domain (Partner) trusts the primary domain (Contoso) for name lookup and authentication. State the viewpoint and the primary/trusted labels before interpreting it. 2 is the reverse direction; 3 is both.
• Why could the Beacon query Partner objects? The trust makes cross-domain authentication possible, but it does not grant directory read or resource access by itself. The observed LDAP results depend on the current token, the bind/session, and the directory permissions exposed in the lab. Treat the FSP result as evidence of a directory relationship, not proof that every Partner object is readable.
• What is a foreign security principal? It is a local directory placeholder whose objectSid identifies a principal from outside the domain/forest. It lets a foreign user or group be placed into a local group. The placeholder is not a duplicate account and does not carry the foreign user's password or key.
• What are top, domain, and domainDNS? They are cumulative LDAP object classes. top is the base class; domain describes the domain object; domainDNS is the AD domain naming-context class. The result name: partner is the domain root object, not an OU and not a local Administrators group.
• What does gPLink tell us? It records links from sites, domains, and OUs to GPO containers. Finding the Contoso Jump Users GUID on the Partner domain object says the policy is linked at the domain root. It does not, by itself, prove that a particular user or computer received the policy; check security filtering, link options, WMI filters, inheritance, and the target's applied-policy result.
• What is GptTmpl.inf for? It is part of the GPO's Group Policy Template in SYSVOL. The [Group Membership] section is the security-template/Restricted Groups representation. S-1-5-32-544 is the well-known SID for the built-in Administrators group. The __Memberof directive is the evidence that the Partner group is added to local Administrators on machines where this GPO applies.
• Why query _ldap._tcp.dc._msdcs.partner.com? That SRV lookup discovers a Partner domain controller suitable for LDAP/Kerberos directory work. It does not locate the jump workstation. The later computer-account query is what identified PAR-JMP-1 as a candidate target.
• Why cifs/par-jmp-1.partner.com? The target action is access to C$, which is an SMB administrative share. Kerberos represents SMB with the cifs/<host> service principal. A ticket for krbtgt/PARTNER.COM is only the referral; the CIFS ticket is the service ticket presented to the jump host.
• What is the Kerberos sequence? krb_asktgt requests a home-realm TGT for rsteel; krb_asktgs with krbtgt/partner.com obtains an inter-realm referral; a second krb_asktgs for cifs/par-jmp-1.partner.com requests the foreign service ticket. A TGT, referral TGT, and service ticket are different artifacts.
• What remains unproven? The supplied images do not show a final successful ls \\\\par-jmp-1.partner.com\\c$, and the raw DCSync output is intentionally omitted. The note therefore records the authorization path and ticket workflow, not a completed lateral-movement result.

Inbound Trust Demo - continuation: ticket use

The later screenshots are timestamped 11/05 12:16 through 12:45 and show the same lab path moving from discovery into Kerberos ticket use. Secret-bearing screenshots containing the AES key or Base64 ticket data are not embedded. The final share-listing output is also not present, so the last access claim remains Ryan-reported rather than screenshot-proven.

steal_token versus inject

These commands solve different problems:

• steal_token <PID> tries to impersonate the access token of an existing process. It is the right fit when the target process already runs as the identity needed for a network action. rev2self returns Beacon to its original token.
• inject <PID> <arch> <payload> attempts code/payload execution inside another process. It is not required merely to borrow that process's identity. In this run, injection failed before steal_token succeeded, so the lab used token impersonation instead.

The safest way to choose is to state the objective first: borrow an existing identity means token work; run code in another process means injection. Neither command, by itself, proves Domain Admin membership.

Why the Base64 conversion was required

krb_asktgs printed the ticket in a Base64 representation labelled ticket.kirbi. Beacon's kerberos_ticket_use command takes a path to a ticket file, so the lab decoded the Base64 text into the binary jmp-cifs.kirbi file before applying it. Passing the display text instead of the file would not give Beacon a usable ticket artifact.

Why make_token came before kerberos_ticket_use here

The lab needed the Beacon session to have rsteel as its network logon context before the foreign CIFS ticket was applied. make_token established that netonly context; kerberos_ticket_use then added the Kerberos ticket used for the SMB request. This is the demonstrated workflow for this session, not a rule that every Beacon build or every ticket operation must always use make_token.

GPO in plain language

A Group Policy Object (GPO) is a reusable bundle of Windows configuration and security settings. It is not a trust and it does not connect domains. AD stores the GPO's directory metadata (the GPC), while SYSVOL stores the policy files (the GPT). A link tells Windows which site, domain, or OU is in scope for that GPO.

In this lab the reasoning was:

1. The GPO name and gPCFileSysPath revealed the policy's GUID and its SYSVOL location.
2. The gPLink=*{GPO_GUID}* search checked domain/OU objects to find where that GUID was linked.
3. The result was the Partner domain root, so the policy was a candidate for computers in that domain, subject to normal GPO filtering and processing.
4. GptTmpl.inf showed that a Partner group was placed in local Administrators (S-1-5-32-544).
5. Computer enumeration was therefore the next step: local-admin policy matters on concrete machines, and a concrete machine is needed to request a service ticket such as cifs/par-jmp-1.partner.com.

The domain link does not mean "connect every computer to every domain" and does not prove that every machine received the policy. It identifies where to look next and which target computers need an applied-policy check.

Ryan's Outbound Trust Lab - 6 November 2026

This section records the supplied course screenshots and Ryan's dictated notes for the one-way outbound-trust exercise. The lab starts as PARTNER\\webber. The newer screenshots show the trust inventory, TDO GUID, injected Beacon, DCSync task/result context, ticket-file preparation, and the final Contoso domain query. Timestamps show 11/06 01:18 through 01:29; timezone is not shown. Raw trust keys and the secret-bearing DCSync/TGT screenshots are intentionally not stored here.

What the trust direction means here

The Beacon context was:

getuid
You are PARTNER\\webber

ldapsearch (objectClass=trustedDomain)
name: contoso.com
trustDirection: 2
trustAttributes: 8
flatName: CONTOSO

trustDirection: 2 means outbound relative to the queried/primary domain per Microsoft's trustDirection definition. In this view, the queried domain is PARTNER and the TDO names CONTOSO as the trusted partner. The primary domain (PARTNER) trusts the named domain (CONTOSO) for authentication. Thus the trust path can let eligible Contoso identities reach Partner resources; it does not let a PARTNER\\webber identity use this one-way trust to enter CONTOSO. The direction value is not a standalone statement of which machine can be accessed: always identify the local domain and TDO partner first. Microsoft describes the forest as the security boundary, so a forest trust does not erase that boundary or grant every identity access to every resource.

trustAttributes: 8 is the FOREST_TRANSITIVE flag. It describes the trust's forest-transitive property; it does not change the one-way direction or establish resource authorization.

The dictated notes report this attempt to enumerate Contoso's domain object:

ldapsearch (objectClass=domain) --dn DC=contoso,DC=com --attributes name,objectSid --hostname contoso.com

Binding to contoso.com
[-] Bind Failed: 49

LDAP result code 49 is invalidCredentials in RFC 4511. This establishes that the attempted LDAP bind failed with the credentials/context then in use. In this lab, basic foreign-domain LDAP enumeration therefore did not work through the available trust path. Do not generalize one Bind Failed: 49 result into a claim that LDAP enumeration is always impossible across a one-way trust; another valid foreign-domain identity, authentication context, or permission could change the result.

Trust account route shown by the lesson

The lab's route is to obtain the shared inter-realm secret from the PARTNER side's TDO for Contoso, then request a TGT in Contoso for the interdomain trust account PARTNER$. That account exists in Contoso to represent the Partner side of the relationship; Microsoft's protocol documentation describes the interdomain trust account and its association with the TDO here. It is not a human user and its ticket does not imply administrator rights. The course's next goal is to use the resulting Contoso logon context for directory enumeration that the starting Partner identity could not perform.

The screenshot shows the read-only TDO GUID lookup:

ldapsearch (objectClass=trustedDomain) --attributes name,objectGUID
name: contoso.com
objectGUID: 288d9ee6-2b3c-42aa-bef8-959ab4e484ed

The screenshot shows the DCSync task targeting partner.com and this GUID. The returned output identifies contoso.com as the object RDN and displays the trust secret's current key material. DCSync uses Active Directory replication operations to request directory secret material; it is a privileged credential-acquisition action, not persistence and not ordinary LDAP enumeration. Here the returned material includes the inter-realm trust secret. The supplied output showed current and previous secret values and multiple key types. Those values are credentials; they are deliberately omitted. The trust secret is shared trust material, not the Partner account's ordinary password.

The course explanation identifies the vwebber process as running with Partner Domain Admin context, which supplies the replication rights needed for the demonstrated DCSync. The screenshot of the new Beacon shows webber on PAR-WKSTN-1 in sihost.exe (PID 5776) and a link back to the parent Beacon. That screenshot establishes the new session's host/process context; the user's Domain Admin group membership comes from the course scenario, not from that process-list row alone.

The lesson then used the trust secret's RC4 key to request a TGT for PARTNER$ in CONTOSO.COM:

execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe asktgt /user:PARTNER$ /domain:CONTOSO.COM /dc:lon-dc-1.contoso.com /rc4:<REDACTED_TRUST_KEY> /nowrap

Ryan's notes report that the TGT request succeeded. The displayed ticket metadata identified service krbtgt/CONTOSO.COM, user PARTNER$, and realm CONTOSO.COM. The ticket blob and key fields are not reproduced. The TGT is for the Contoso realm because that is the realm being requested; it is not a referral ticket back into Partner.

The Base64 ticket output was written to a .kirbi file with PowerShell's [IO.File]::WriteAllBytes and Base64 conversion. The supplied screenshot shows the file-writing operation but not the complete expression or encoded ticket, so the blob and a paste-ready command are omitted.

In the demonstrated Beacon workflow, make_token was run for CONTOSO\PARTNER$ before kerberos_ticket_use. The first ticket-use attempt named partner.kirbi and returned “does not exist”; the next task used C:\Users\Attacker\Desktop\trust.kirbi. This is the observed ordering for this lab session, not a universal rule for every ticket workflow. The password-like argument shown in the screenshot is treated as a lab placeholder and is not copied here. make_token establishes a netonly network logon context; it does not validate the supplied password.

After the ticket-use task, the Beacon queried the Contoso domain object and returned name: contoso and an objectSid. This is screenshot evidence that the query completed and returned directory data. The sequence supports the course conclusion that the trust-account ticket enabled this enumeration, but the screenshot does not independently show a getuid/ticket-cache result at the time of the query, so the exact effective identity is inferred from the preceding steps. The result establishes domain-object enumeration only; it does not establish access to other accounts, services, or resources.

Observed sequence and evidence limits

Clarifications from this lesson

• A one-way trust is directional. In this local view, PARTNER trusts CONTOSO; the starting Partner identity cannot use that trust alone to authenticate to Contoso resources. The reverse-side TDO view will express the same relationship from Contoso's perspective with the opposite direction value.
• A trust account is created to support interdomain trust operations. Here PARTNER$ is the account name used on the Contoso side, derived from Partner's flat/NetBIOS name. Its trust secret is maintained as shared trust material by the domains; the TDO and the account are related but are not the same AD object.
• DCSync requires sufficient replication rights and accesses secret directory data. The screenshot's displayed current/previous key types do not make those values safe to store. Keep raw keys, hashes, ticket blobs, and exported files out of study notes.
• The account's unusual trust purpose does not grant blanket access. The observed Contoso domain-object query succeeded after the trust-account ticket workflow; verify the ticket's client and realm and keep the claim scoped to the returned object and current session.
• The lesson's TGS request for krbtgt/CONTOSO.COM against the Partner KDC was described as returning KDC_ERR_S_PRINCIPAL_UNKNOWN. This is a course explanation supplied in Ryan's narration: the requested principal was not found at that KDC, so the described request did not produce a referral. Treat it as a failed request with a named KDC/error, not as evidence that referrals never occur in this trust.

Screenshot handling

The trust-enumeration, TDO-GUID, Beacon, task, ticket-file preparation, and domain-query screenshots are embedded above. The DCSync result and TGT output screenshots are not embedded because they expose trust keys and derived ticket material. The make_token screenshot is also omitted because it contains a password-like lab argument. Their non-secret lesson points are captured in the table. No keys, password-like values, or reusable ticket data are included in the vault.

Security boundary

The forest is the AD security boundary; a domain is primarily an administrative boundary. Enterprise Admins have forest-wide administrative reach. Domain Admins normally administer their own domain and are not automatically granted every resource permission in every sibling domain. However, Microsoft warns that service administrators who control a domain in a shared forest can gain access to other domains through that control. Separate domains in one forest therefore should not be treated as strong isolation from one another.

This is why the course later examines paths from a child domain toward a tree root. A trust or Domain Admin title alone is not proof that any specific cross-domain operation succeeded; the required rights and observed result still matter.

Practical review prompts

1. In the A/B/C diagram, what does transitivity provide, and what additional permission is still needed to open a resource in C?

2. If C trusts A, which domain contains the users and which contains the resources? How would you describe the same link from each side?

3. How do an external trust and a forest trust differ in reach and transitivity?

4. What can a trustedDomain query establish, and what can it not establish without output and access checks?

5. Why is a domain an administrative boundary while the forest is the security boundary?

6. What is the difference among dublin.contoso.com as a domain, DUBLIN.CONTOSO.COM as a realm, and the forest containing it?

7. Which key protects a referral TGT, and why is it different from an ordinary home-realm TGT?

8. Why is the root domain SID needed in the course's added-SID example, and why is reading that SID not enough to elevate access?

9. What does a diamond ticket start from that a golden ticket does not?

10. In the instructor's sequence, what was learned by LDAP, what was obtained by DCSync, and what was proven by the final share listing?

11. Does make_token prove the password is valid? What does kerberos_ticket_use add to the session?

12. In this attempt, what did steal_token prove, and what separate evidence would establish the token's domain rights?

13. Which stage did the ERROR_ACCESS_DENIED output actually reach, and which later stages remain untested?

14. Why does trustDirection: 1 need a stated viewpoint before you call it inbound or outbound?

15. Trace Robert Steel's authorization path from the Contoso group to local Administrators on a Partner workstation. Which link is trust, which link is group membership, and which link is GPO policy?

16. What does an FSP object store, and why is it not a second copy of the foreign account?

17. What does objectClass: top, domain, domainDNS tell you about the GPO link query?

18. Why is the GPO link evidence weaker than an applied-policy result on PAR-JMP-1?

19. Which Kerberos artifact is returned by each of the home-realm TGT request, krbtgt/PARTNER.COM request, and cifs/PAR-JMP-1 request?

20. What evidence would you require before marking the final SMB access step as successful?

21. Why was steal_token the appropriate fallback after the injection attempt failed?

22. Why is a successful TGS request still different from proof that the target share accepted the ticket?

23. What state should be cleaned up after the lab: impersonation token, ticket file, ticket cache, or all three?

24. From the Partner-side TDO view, what does trustDirection: 2 say, and which identities can use this trust path toward which side?

25. What did Bind Failed: 49 establish about the attempted LDAP bind, and what would you need before generalizing it to other credentials or queries?

26. How are the PARTNER$ interdomain trust account, the TDO, and the shared trust secret related, and which one is identified by the TDO GUID?

27. What does the successful PARTNER$ TGT request prove, and what does the later Contoso domain-object result establish?

28. Why did make_token precede kerberos_ticket_use in this Beacon workflow, and what did the first missing .kirbi path error tell you?

29. Compare the parent-child extra-SID route with the inbound FSP/group/GPO route. What authentication artifact and what resource result prove each route reached its goal?

Fact-check status

• Guided lab routes added: parent-child and inbound commands are course-specific; hashes and ticket blobs stay redacted. The inbound final C$ listing remains unverified in the supplied screenshots.

• Verified against Microsoft: parent–child trusts are automatically two-way and transitive; direction and transitivity are distinct; trustDirection = 3 is bidirectional; the forest is the security boundary.

• Verified against Microsoft and Rubeus: trust-derived referral keys, trust account type, trustDirection: 3, within-forest attribute 32, SID prefix/RID construction, and the golden/diamond starting-point distinction.

• Course illustration: the original twelve images plus four non-secret video screenshots explain concepts and instructor actions only; they do not document new Ryan-run commands. Two additional video screenshots were left out because one exposed the key and another carried an identifying overlay.

• Ryan's lab observed: one child-to-root TDO result, a root Enterprise Admins SID result, DUBLIN\sguest token impersonation, and a DCSync pipe-access failure. The child-domain SID result, effective replication rights, cross-domain authentication, parent resource authorization, lab completion, and exam result remain unobserved or unconfirmed.

• Inbound-trust demo verified against Microsoft: trustDirection value semantics, foreign-security-principal purpose, domain/domainDNS object classes, GPO scope/linking, Group Membership template semantics, and the well-known Administrators SID.

• Inbound-trust demo observed: an inbound TDO result, a foreign Contoso group represented in Partner, resolution to Partner Jump Users, a Robert Steel group-member result, Partner DC discovery, a domain-linked Contoso Jump Users GPO, a GptTmpl.inf local-Administrators directive, candidate Partner computers, and the TGT/referral/service-ticket workflow commands.

• Inbound-trust continuation observed: the GPO artifact was downloaded and inspected, three Partner computer objects were returned, injection failed with ERROR_NO_MORE_FILES, steal_token impersonated CONTOSO\dyork, the rsteel TGT request succeeded, the foreign CIFS TGS request succeeded, and the .kirbi ticket was applied after make_token.

• Inbound-trust continuation still unconfirmed: the final ls \\\\par-jmp-1.partner.com\\c$ output, whether the GPO was applied on the selected host, and the exact account rights behind dyork. AES keys and Base64 ticket material remain intentionally excluded.

• Inbound-trust demo still unconfirmed: the exact account rights of dyork, the raw DCSync result as stored evidence, whether the GPO was applied to PAR-JMP-1, and the final C$ directory listing. The sensitive hash and ticket screenshots remain intentionally excluded.

• Outbound-trust lesson verified against Microsoft: trustDirection value semantics, the trust-account/TDO relationship, and the forest security-boundary model. trustAttributes: 8 is the forest-transitive flag.

• Outbound-trust lesson observed or Ryan-reported: starting identity PARTNER\\webber, Contoso TDO direction/attributes/GUID, LDAP bind error 49, a linked Beacon on PAR-WKSTN-1 running as webber, DCSync output containing trust-key material, and a successful TGT request for PARTNER$ in CONTOSO.COM.

• Outbound-trust continuation observed: Base64 ticket-file preparation, make_token before kerberos_ticket_use, a failed first ticket-file path followed by a task using trust.kirbi, and a successful LDAP query returning the Contoso domain object's SID. Attribution of that query to the trust-account logon is supported by the sequence but the effective identity/cache was not separately displayed. Raw trust keys, ticket data, and the password-like placeholder remain intentionally excluded.

This is a living study note. Sources and understanding may change as it is reviewed.