Step 261. Active Directory 1 — Understanding Domain Structure

Level 3 — Real-World CTF & Advanced Offensive Skills | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: Step 260’s Windows privilege escalation (services, token privileges). You don’t need to know Kerberos — that’s what you learn today.

What you need: Paper and pen (or a diagram tool). Today is a concept chapter — this environment has no AD domain, so enumeration command outputs are presented as output examples based on THM/HTB labs.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.

Until now your opponent was "a single machine." The moment you face a company, the world changes — hundreds of employee accounts, hundreds of PCs, file servers, printers, all tied into one central system. That is Active Directory (AD). And the existence of a center means, to an attacker, take the center and everything ends. In real penetration tests and competitions (HTB’s AD track), AD wears the face of the final boss. Today you draw that boss’s map — what a domain is, why the domain controller is the heart, how Kerberos authentication turns. Only with today’s map drawn accurately will the next two chapters’ attacks (Kerberoasting, Pass-the-Hash, BloodHound) show you "why they work."

1. Learning Objectives

By the end of this chapter, you will be able to:

Draw the relationship between domain, tree, forest, and domain controller (DC) as a diagram
Explain Kerberos authentication’s five steps in order (AS-REQ → AS-REP → TGS-REQ → TGS-REP → service access)
Know the difference between a TGT and a service ticket (TGS)
Read the output of basic AD enumeration commands like net user /domain
Explain what an SPN is and why it’s the foundation of the next chapter (Kerberoasting)

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Concept-focused — drawing diagrams on paper + lab command output examples
Today’s commands	`net user /domain`, `net group "Domain Admins" /domain`, `setspn -Q /` (all output examples)
Concepts needed	Domain/tree/forest, DC, TGT/TGS, SPN, trusts
Today’s deliverable	One hand-drawn Kerberos authentication flow + a domain terminology map

2-1. What Is Active Directory — A Company’s Master Registry

When an employee joins a company, an account must be created. When a new PC arrives, it must be registered; when someone leaves, access must be cut. What if there are a thousand employees? You can’t create accounts PC by PC. Hence Active Directory — a central management system where accounts, computers, groups, and policies are registered in one place, and every machine asks that place.

The server of this central registry is the Domain Controller (DC), and the territory a DC governs is a domain (a name like corp.local). Every PC in the domain doesn’t judge "is this person really an employee?" locally — it asks the DC. This one sentence — "authentication lives at the center" — is the starting point of all AD attack and defense.

2-2. Domain → Tree → Forest — The Hierarchy of Territory

As an organization grows, domains split. Under headquarters corp.local, a lab rnd.corp.local, an overseas branch us.corp.local. Domains bound under the same naming line (namespace) form a tree; the largest unit, where trees of different naming lines are bound into one trust system, is a forest.

What connects domains is a trust — a promise that "users authenticated by that domain’s DC, we’ll believe too." Translated into the attacker’s eye: a trust is a bridge across domains. When you take one domain, you can cross into another domain linked by trust, which is why the forest boundary is treated as the final boundary of a breach.

2-3. Kerberos — Authentication That Runs on Tickets

The protocol that proves "I’m Cheolsu and I’d like to use the file server" inside a domain is Kerberos. Instead of sending a password over the network every time, you get issued tickets and use those. The amusement-park analogy is exact — you wear an admission wristband (TGT) on your wrist, and in front of each ride (service) you receive a ride-specific pass (service ticket).

The cast has three members — the user, the KDC (Key Distribution Center — the ticket office inside the DC), and the service (file server etc.). The flow is five steps:

User                KDC (ticket office in the DC)        Service
  |  1. AS-REQ: "I'm alice, wristband please"  |              |
  | ------------------------------------------> |              |
  |  2. AS-REP: TGT issued (includes a part encrypted with a key from alice's password) |
  | <------------------------------------------ |              |
  |  3. TGS-REQ: "A file-server pass with this wristband, please" |
  | ------------------------------------------> |              |
  |  4. TGS-REP: service ticket issued (encrypted with a key from the service account's password) |
  | <------------------------------------------ |              |
  |  5. AP-REQ: present the service ticket      |              |
  | -----------------------------------------------------------> |

Two sentences to hold onto from here for the next chapter:

The step-2 TGT includes a part encrypted with a key derived from the user’s password.
The step-4 service ticket is encrypted with a key derived from the service account’s password.

"Whose password encrypted it?" is the whole of next chapter’s attack. For now, just make the diagram and the terms solid — AS-REQ/AS-REP (wristband issuance), TGS-REQ/TGS-REP (pass issuance).

2-4. SPN — The Service’s Name Tag

For the KDC to issue a "file-server pass," it must know who that service is in the domain. The unique name tag attached to each service is the SPN (Service Principal Name) — formats like MSSQLSvc/db01.corp.local:1433, HTTP/web.corp.local ("service-type/machine:port").

The important fact: any domain user can ask the KDC "give me a service ticket for that SPN." It’s a design needed for normal business. But recall sentence 2 from 2-3 — that ticket arrives encrypted with the service account’s password. "Anyone can request" + "encrypted with the service account’s password" = you can take it home and tear into it. This is the seed of Step 262, Kerberoasting. For today, wrapping up "SPN = the address at which you order a service ticket" is enough.

2-5. The Attacker’s First Job — Drawing the Domain Map

Only beginners hit the DC directly. A real attack’s first phase is quiet enumeration — how many users the domain has, who is in Domain Admins (the domain’s king group), which machines exist, what SPNs there are. Only with this map can you compute "the path from my current position to the throne" (Step 263’s BloodHound automates this computation). Most enumeration is possible with just one domain user account — which is why the true start of an AD attack is "obtaining the first domain account."

3. Follow Along

Today’s practice has two branches — ① drawing concepts by hand to internalize them, ② practicing reading lab command output examples. This environment has no AD domain, so all command outputs are output examples.

3-1. Hand-Drawing the Kerberos Flow

On paper, draw 2-3’s five steps without looking at anything. Erect the three pillars (user / KDC / service) and place five arrows. When done, write two sentences beside the arrows — "AS-REP is encrypted with alice’s key," "TGS-REP is encrypted with the service account’s key."

Completion check: If you can state "the difference between a TGT and a service ticket" without looking at the picture, you’ve succeeded. The correct instinct — a TGT is an ID card proving "I am an authenticated person" (for the ticket office); a service ticket is a pass saying "allowed into this service" (for the service). This picture gets reused as-is in Step 262 when attack arrows are laid on top.

3-2. Drawing the Domain Terminology Map

The second picture is a territory map. Draw this fictional company:

Forest: corp.local (root domain)
├── Tree: corp.local
│     ├── HQ domain corp.local — 2 DCs (DC01, DC02)
│     └── Lab rnd.corp.local — 1 DC (RNDDC01)
└── Trust: corp.local ↔ partner.com (external partner forest)

After drawing, ask yourself — ① if you take over rnd.corp.local, where can you go over trusts? ② How far does this company’s "final boundary" extend (domain? forest?)? Check your answers in section 5.

3-3. Enumerating Domain Users — Output Example

The first commands after connecting to a lab (an AD intro room on THM/HTB) with a domain account (output example):

net user /domain

User accounts for \\DC01

-------------------------------------------------------------------------------
Administrator            alice                    bob
Guest                    krbtgt                   svc_sql
svc_backup               ...
The command completed successfully.

How to read it: The full account list of the domain. Where the attacker’s eyes go — ① service accounts starting with svc_ (Step 262’s prey candidates), ② krbtgt (the KDC’s own account — AD’s crown jewel; just the name for now), ③ ordinary users (foothold candidates for the initial breach). On Korean Windows the last line reads "명령을 잘 실행했습니다."

3-4. Checking the King Group — Domain Admins

net group "Domain Admins" /domain

Output example:

Group name     Domain Admins
Comment        Designated administrators of the domain

Members
-------------------------------------------------------------------------------
Administrator            alice
The command completed successfully.

How to read it: This list is this course’s "throne roster." The terminus of a breach is obtaining one account from this group — because that account is administrator of every machine in the domain. Every time you enumerate, you cross-check against this roster — "is the account I got in here? If not, how do I get there?" The tool that computes that second question for you is Step 263’s BloodHound.

3-5. Enumerating SPNs — Output Example

setspn -Q */*

Output example (excerpt):

CN=svc_sql,OU=Service Accounts,DC=corp,DC=local
        MSSQLSvc/db01.corp.local:1433
CN=svc_backup,OU=Service Accounts,DC=corp,DC=local
        HTTP/backup.corp.local
...

How to read it: A list of "which accounts have which service name tags attached." svc_sql has an MSSQL tag, svc_backup an HTTP tag — meaning these two accounts have addresses at which service tickets can be ordered. This entire list becomes next chapter Kerberoasting’s "hunting list." Today, taking away the single line "SPN = service name tag = ticket-ordering address" is enough.

4. Missions & Exercises

Mission — Building the AD Map

Reproduce 3-1’s five-step Kerberos picture on blank paper, and write on it "whose key encrypts" the AS-REP and TGS-REP
Draw 3-2’s territory map and mark the trust bridge
Design your own map of a fictional company mega.corp — place 3 domains (HQ/lab/branch), DC placement, 2 Domain Admins, and 2 service accounts (with SPNs) on the map
Read the output examples of 3-3–3-5 and write one line each on "the information it gives an attacker"
Collect both pictures and the notes into ad-domain-map.md — you keep this file open through Steps 262–263

Exercises

Q1. In one sentence each, state why a domain-joined PC asks the DC instead of authenticating logins locally, and the implication that design gives an attacker.

Q2. Compare the TGT and the service ticket (TGS) from three perspectives: issuing party, purpose, and encryption key.

Q3. Explain why the fact that "any domain user can request a service ticket for an SPN" is a security tension point, connecting it to the ticket’s encryption key.

Q4. When two domains in a forest (A, B) are linked by a trust, what does B mean to an attacker who has taken A? Explain together with why the forest is called the "final boundary."

5. Model Answers & Completion Criteria

Mission Model Answer

How to verify the picture: Check that the five arrows’ names (AS-REQ/AS-REP/TGS-REQ/TGS-REP/AP-REQ) and directions are right, and that the "encryption key" annotations attach to AS-REP as the user and TGS-REP as the service account. If those two annotations are missing, the picture is half — because next chapter’s attacks strike exactly those two annotations.

Example of enumeration-command notes:

Command	Information it gives an attacker
`net user /domain`	Full account list — service-account candidates, foothold candidates
`net group "Domain Admins" /domain`	The throne roster — defines the breach’s terminus
`setspn -Q /`	SPN list — the Kerberoasting hunting list

Evaluation criteria for the fictional map: Is a DC placed in each of the 3 domains? Are the service accounts’ SPNs in "service-type/machine" format? Are trusts distinguished between inside the forest (inherited) and outside (external)?

Exercise Answers

A1. Reason: if account information were scattered across hundreds of PCs, creation, change, and deletion could never be synchronized, so registering at a center (the DC) that everyone asks is the only manageable design. Implication: since the center is the single authority on authentication, taking the DC puts the entire domain’s authentication in your hands — the attack’s payoff jumps from "one machine" to "everything."

A2. Issuing party: both come from the KDC. Purpose: the TGT is "an ID card used when returning to the ticket office" (the material for requesting service tickets); the service ticket is "a pass presented to a specific service." Encryption key: the TGT’s user part is encrypted with a key derived from the user’s password (and signed/protected with the krbtgt key); the service ticket is encrypted with a key derived from the service account’s password — this last line is Step 262’s core.

A3. A service ticket is data encrypted with a key derived from the service account’s password, yet any domain user can receive it. A received ticket can be carried off the network and cracked at leisure offline — the DC cannot know about cracking attempts. It’s a point where design and tension coexist: a "normal feature (ticket issuance)" becomes an attack channel as-is.

A4. B is "the next territory with a bridge already laid" — because of the trust, B trusts A’s authentication results, so taking A becomes a springboard into B. Trusts inside a forest are by default mutual and transitive, so reachability opens to anywhere in the forest. That’s why the final boundary of defense must be seen as the forest, not the individual domain — the practical consensus.

Completion Criteria Checklist

[ ] Can define domain, tree, forest, and DC in one sentence each
[ ] Can draw Kerberos’ five steps on blank paper
[ ] Know whose key encrypts the AS-REP and TGS-REP respectively
[ ] Can state the difference between a TGT and a service ticket
[ ] Can explain that an SPN is "a ticket-ordering address"
[ ] Can pick service-account candidates out of net user /domain output
[ ] Mission: completed ad-domain-map.md

6. Common Pitfalls & Fixes

Wall 1. The Kerberos terms get scrambled

Symptom: AS-REQ, TGS-REQ, TGT, TGS are a jumble.

Cause: Normal — four pairs of terms arrive at once. Don’t try to memorize them.

Fix: Take the names apart and you’re done — AS (Authentication Service) is the "wristband window," TGS (Ticket-Granting Service) is the "pass window." REQ is request, REP is response. So it’s all just "two windows, two round trips." Draw 3-1’s picture three times and it sticks.

Wall 2. The relationship between "tickets" and "passwords" is confusing

Symptom: You got a ticket but don’t see why password cracking enters the story.

Cause: You missed the ticket’s encryption material.

Fix: Fix it with this one sentence — "a ticket is a key and at the same time a ciphertext." A service ticket is a ciphertext encrypted with the service account’s password, so you can take it away and solve it by trying passwords (cracking). Normal use never needs to solve it, but for an attacker it becomes a cracking target.

Wall 3. I have the domain/forest size relationship backwards

Symptom: You confuse "domains are inside a forest" with "forests are inside a domain."

Cause: You remembered the direction of the forest/tree metaphor backwards.

Fix: The natural metaphor is literal — trees gather into a forest. Domains gather into a tree, trees gather into a forest. Boundary sizes come naturally too — domain < tree < forest (final boundary).

Wall 4. net user /domain errors out in the lab

Symptom (output example): System error 5 or Access is denied.

Candidate causes: ① The machine you’re on isn’t domain-joined (a workgroup machine). ② You’re logged in with a local account — /domain needs a domain context.

Fix: Check with whoami first — a "domain\user" form like corp\alice is fine, while PC01\alice is a local account. An AD room’s first assignment is always "securing a foothold in domain context" — which is why the first domain account is worth so much.

Wall 5. I get the concepts but can’t see "so what do I attack?"

Symptom: You understand the structure, but the connection to attacks feels abstract.

Cause: Normal — today was the day for drawing the map only. Attack arrows haven’t been laid on yet.

Fix: Lay just two question marks on the map — ① "If the TGS-REP arrives encrypted with the service account’s key, what if I take it and crack it?" (→ Step 262). ② "If who is admin where is fully enumerable, couldn’t I compute the path to the throne?" (→ Step 263). With question marks in place, the next chapters read as answers.

7. Summary

Today’s Concepts

Concept	One-line description
Active Directory	The central registry of accounts, machines, groups — a company’s master registry
Domain Controller (DC)	The single authority on authentication — taking it = the whole domain
Tree / forest	The hierarchy of domains — the forest is the final boundary
Trust	A bridge of faith between domains — the channel of lateral movement
Kerberos	Ticket-based authentication — AS (wristband) → TGS (pass)
TGT / service ticket	ID card / per-ride pass — each encrypted with a different key
SPN	Service name tag = ticket-ordering address — the seed of Kerberoasting
Domain Admins	The king group — the breach’s terminus

Today’s Commands (All Output Examples)

Command	What it does
`net user /domain`	Full account list of the domain
`net group "Domain Admins" /domain`	Check the throne roster
`setspn -Q /`	Enumerate SPNs (service name tags)
`whoami`	Check domain context (`domain\user` form)

The Instinct That Matters More Than Commands

If the fight against a single machine ended at "root/SYSTEM," the fight against AD is a fight against a map. Where the throne (Domain Admins) sits, which bridges (trusts) are laid, which tickets (SPNs) can be ordered — the side that draws the map first wins. And one sentence that must survive from today’s picture: "the service ticket arrives encrypted with the service account’s password." That sentence opens the next chapter’s door.

Once every box is checked, Step 261 is complete. Click the checkbox in the sidebar to save your progress.