~/apparatus/the-guest-and-the-domain.md
The guest and the domain
These pages are props, not lessons. No tier, no order, and no exercise of their own. A lesson that names this page owes you the means, and this page pays.
The law travels with the props. Everything here runs on machines you own, on the host-only network lesson 031 built. The second machine on this page is a controller, which is a machine that behaves like a server while sitting on a virtual switch with nowhere to go. Nothing here reaches anything real, and the negative test from lesson 031 is still the one that matters.
The guest
Lesson 037 needs a Windows box to escalate on. This is that box, and it costs one guest on the hypervisor you already run.
The source is Microsoft's own Windows 11 download page, the multi edition ISO, the same file an ordinary user takes. Nothing here needs a licence ceremony. An unactivated Windows guest runs, with a watermark on the desktop and a settings page that nags. You are not keeping this machine. You are breaking it on purpose.
VirtualBox, from lesson 031, with the four settings that decide whether the rest of this works:
- Memory, 4096 MB. Below 2048 the installer itself struggles and every census runs slower than it needs to.
- Disk, 64 GB on a dynamically allocated disk.
- Network, the host-only adapter lesson 031 built, and nothing else. This is the setting that must not be NAT or bridged.
- Storage, the ISO attached to the optical drive.
Then boot it and answer the questions.
The first boot, what you should see, and why
Setup is the slowest twenty minutes on this page, and it looks broken twice before it is not.
What you should see: a language screen, a file copy, more than one reboot, the out of box experience, then a desktop.
The state that looks wrong but is fine: a black screen with a blinking cursor after the copy phase. The installed system is booting for the first time and it is slower than the installer was. Wait it out before reinstalling anything.
The failure state, and it is the dangerous one: the guest reaches your router or the internet. That means the adapter is NAT or bridged, which puts the guest on the house network as a peer of your real machines. Stop, open the adapter settings, and read the attached-to field before you run a single command.
The account, and the part that keeps moving
Windows pushes you at a Microsoft account and a lab guest wants a local one. The way to get one has changed more than once and it will change again. Two shapes that work as this is written:
X:\Sources> start ms-cxh:localonly
X:\Sources> reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v BypassNRO /t REG_DWORD /d 1 /f
X:\Sources> oobe\bypassnro
Both are typed into the console that Shift and F10 opens on the network screen. The prompt is the install media's own and the letter does not matter. The first line skips the account requirement outright. The second restores a bypass script that Microsoft removed from newer builds.
The fallback that always works: give it the Microsoft account, then add a local account in Settings and use that one for the exercises. Every exercise on this site cares about the seat, not about who installed the box.
A guide that hands you the local account trick without a date is telling you when it was written. That sentence applies to this paragraph as much as to any other Windows page you will read this year.
The seat, and why it changes every answer
This is the part worth reading twice.
Privileges belong to the token your process runs under. They are not a property of the machine. whoami /priv in an ordinary desktop session shows an ordinary user's list. The same command inside a service context, or as SYSTEM, shows a longer list, and that list usually carries SeImpersonatePrivilege.
That one line is the reason the potato family exists at all. A standard user asks the census a question and gets a short answer. A service asks and gets an invitation. So before you read any privilege list on a Windows box, know which seat produced it:
C:\> whoami /groups
C:\> whoami /priv
What you should see, and why: a user and a hostname you recognise, then two blocks of text. The groups block names the groups the token carries. The privilege block lists what that token is allowed to do.
What you should not accept: SeImpersonatePrivilege on a plain desktop login. If it is there, you are not looking at the seat lesson 037 assumes. You are looking at the after picture. That lesson plants a misconfiguration precisely so the before and the after are two different answers on one box, and a census taken from the wrong seat makes the planted state invisible.
The controller
Lesson 038 needs a domain, and the smallest domain that runs is two machines. This controller, and the guest above joined to it. Two VMs and one controller, which is the sentence the lesson uses.
The controller is a Windows Server evaluation ISO, from the same Microsoft download page. The evaluation is free, it runs for months, and it is the honest source for a lab. Build it the way you built the guest, with three changes:
- A fixed address on the host-only network. On a default VirtualBox install that range is
192.168.56.0/24, and checking what your adapter hands out is worth the ten seconds. - A name for the domain.
lab.localin the lesson's own example, and any name works as long as you use it everywhere. - The controller role, installed on top of the server, creating a new forest and a new domain.
Then the thing that decides whether a join succeeds or silently wastes your evening:
C:\> nslookup lab.local
The controller must answer for its own domain. When it does not, the member fails to find it and the error talks about credentials rather than about DNS, which is the most common misread in this exercise.
Then join the guest to the domain and log in as a domain user. That login is the moment tickets start existing on the member.
The tickets, seen from the Linux side
The attacker box from lesson 031 can ask the domain the same questions the lesson asks, and this is the smallest way to see a ticket.
Point the box at the domain, then ask for one:
$ sudo apt install krb5-user
$ kinit lab.local/<user>
$ klist -e -f
kinit asks the controller for a ticket for that user and caches it. klist -e -f prints it with the encryption types and the flags, which is the paperwork lesson 038 reads. What you should see, and why: a principal, a validity window measured in hours rather than days, and a flags column naming forwardable and renewable. Those flags are policies somebody chose, and reading them is reading decisions rather than defaults.
A ticket you can read is a ticket you can think about stealing, and that is the property the lesson is about.
The asking tool for the Kerberoast exercise is Impacket, which Kali ships. The lesson carries the invocation and the hashcat mode for the shape it returns.
What this costs
Honest numbers, because this rung is real. The controller wants 2048 MB, which is enough for a small forest and not enough to be pleasant. Both Windows guests want disk, and neither install is quick.
Count the machines. The attacker box and the target from lesson 031, plus the guest, plus the controller. Four guests on one host. On 16 GB that is comfortable. On 8 GB, build the guest alone and add the controller on the day a lesson actually needs it, because lesson 037 does not and lesson 038 does.
The snapshot, and the reset
The controller holds the domain's signing secret. That is the single most protected item in a healthy domain, and the reason a golden ticket is an end state rather than a step on the way to one.
Which gives you a reset button. Snapshot both Windows guests before you break anything, and know what restoring the controller means. A rebuilt controller is a new domain identity, so every ticket and every forged ticket made against the old one stops working. That is not a workaround for the exercises. It is the property the exercises demonstrate, and the reason the defensive advice about that secret is as short as it is.
Break the guest as often as you like. Break the controller once, learn what it means, then keep the snapshot.