Windows Security Internals

Forshaw has found more Windows privilege-escalation bugs than most teams, and this book is the model he uses to find them, written out formally. Its distinguishing feature is that every structure it describes can be inspected live: the book is built around his PowerShell module, so you read about a token and then print your own.

Two modules cite it, one for authentication and one for privilege escalation, and it is the reference to reach for whenever a challenge is Windows-shaped and the question is who is allowed to do what.

Why it is on this shelf

Because Windows authorisation is a model rather than a set of rules, and guessing at it does not work. Once you know that access is decided by comparing a token against a descriptor by a documented algorithm, the questions become answerable: which entry matched, which privilege was enabled, which principal was actually asking.

Chapter 4, Security Access Tokens

The token is the object that says who a process is. It carries the user's security identifier, the groups they belong to, a list of privileges, an integrity level, and flags describing whether it is a primary token or an impersonation token and at what level.

Two things in here are worth memorising for escalation work. The first is that privileges are not permissions: a privilege such as the one that allows taking ownership of any object, or the one that allows loading a driver, bypasses the access check entirely rather than passing it. A handful of privileges are equivalent to administrator, and an account holding one is already the answer. The second is impersonation, which is how a service acts on a client's behalf, and which is the mechanism behind a whole family of escalation techniques where a privileged process is persuaded to authenticate to something you control.

Windows tokens and privileges covers the CTF-relevant subset with the specific privileges named.

Chapter 7, The Access Check Process

The algorithm itself, step by step. Take the token, take the object's security descriptor, walk the discretionary access control list in order, and accumulate granted access until the request is satisfied or a deny entry stops you.

The ordering is the part that produces bugs. Entries are evaluated in the order they appear, deny entries are conventionally placed first and are not automatically first, and inheritance means a descriptor may not say what its author thought. That is why permissions on Windows are so often wrong in ways nobody notices until somebody enumerates them properly.

For a challenge, the practical form is to enumerate the descriptors rather than reason about them. Writable service configuration, a writable path on a service binary, a registry key with permissive rights - all of these are found by asking the system what the descriptor says.

Chapter 13, Network Authentication

NTLM, in enough detail to explain both the crackable artefact and the relay attack. The protocol is challenge and response: the server sends a challenge, the client computes a response using a key derived from the password hash, and the server checks it. The password never crosses the wire, and neither does anything that can be replayed as-is.

What that means for a capture is precise and worth being clear about. What you have recovered from a network capture is a challenge and a response, not a hash you can pass. It can be attacked offline by guessing the password, computing the response and comparing - which is why these are cracked rather than replayed - and it is a different artefact from the stored hash on the host, even though both are commonly called an NTLM hash. That distinction is the reason the hashing module cites this chapter, and hash cracking with the hash identifier is where it becomes practical.

The relay section is the other half: since the response authenticates the exchange rather than the endpoint, an attacker who can persuade a client to authenticate to them can forward the whole conversation to a third party, and where signing is not required it succeeds. That is a protocol design failure rather than an implementation bug, which is what makes it durable.

Where it stops

It is a model book, not an exploitation book. It explains the mechanism and leaves the technique to you - there are no named escalation exploits and no tooling walkthroughs. It is also dense, and it is not the place to learn Windows in general.

Nothing in it addresses malware, forensics or memory analysis. For those, Evasive Malware and Rootkits and Bootkits sit next to it on the same shelf.

What to take into a challenge

Enumerate the model rather than trying things. On Windows the system will tell you what your token holds and what a descriptor grants, and reading those two answers takes less time than a single failed exploitation attempt. Nearly every intended escalation path in a Windows challenge is visible in one of them.