# Windows Security

Windows Architecture

![1646408037.png](img/1646408037.png)

Note: Windows has `kernel mode drivers` and `user mode drivers`

### Security Subsystem

- Runs in user mode
- `Logon` processes (`winlogon`, `LogonUI`)
- Local security authority (`LSA`)
    - Checks users’ accounts
    - Provides access token
    - Responsible for auditing
- Security Account manager (`SAM`)
    - Maintains user account database used by `LSA`
    - Encrypts / hashes passwords
- Windows predominantly uses **Access Control Lists**, and has done since Windows NT
- Extends the usual read, write and execute with:
    - Take ownership
    - Change permissions
    - Delete
        - This allows finer control over files for example a user will be able to read a file but not delete it
- 32-bit access masks (unlike Unix’s 9 bits)
- A higher degree of control, with the associated complexity increase

### Access Control Matrix

- Access rights are defined individually for each combination of subject and object
    - Quite an abstract concept, but would allow for very fine-grained control
    - Not practical, think of the memory required in scaling it up

![1646409469.png](img/1646409469.png)

##### Capabilities

- A list of capabilities defined per user, equivalent to a row in the access control matrix

![1646409614.png](img/1646409614.png)

Windows doesn’t do this, it does the opposite storing columns called the **Access Control List**

##### Access Control List

- Stored with an object itself, corresponding to a column of an ACM

![1646409753.png](img/1646409753.png)

The access control list can be found by right clicking on a file -> properties -> security.

### Access Control

- Access control in Windows treats more than just files, also:
    - Registry keys
    - Active directory objects
    - Groups
- Inheritance is implemented
    - File can inherit ACLs from parent directories

#### Principals

- Principals are more broadly defined as well:
- Local users
- Domain users
- Groups
- Machines

Each principal has a human-readable name and security ID (`SID`)

```
S-1-5-21-2475811070-2421845406-3333283485-1005
S-1-5-21-1664130791-3153540899-3044996548-279530
```

These are examples of `SID` from Windows, but why are they so long?

This is a form of future proofing. Imagine company A buys company B, you can merge the users onto one active directory without two `SID`s clashing. (also 96 bits of memory isn’t a lot in the grand scheme of things)

##### Local / Domain Principals

- LSA creates local principals
    - principal = `MACHINE\principal`
- Domain principals administered on DC by domain admins
    - principal@domain = DOMAIN\principal
        - net user /domain
        - net group /domain
        - net localgroup /domain

#### Groups

- Groups are collections of `SID`s (object-orientated)
- Group can itself be an `SID`
- Groups can thus be nested
- Groups are not nest-able on local machines
- Managed by a domain controller within Active Directory

#### Objects

- Objects are passive entities in access operations
- In Windows:
    - Executive objects (processes, threads, etc)
    - Private objects (files, directories)
- Securable objects have a security descriptor
    - Built-in securable objects managed by the OS
    - Private objects managed by the application software

### Access Tokens

- Instead of passing a number as in Linux, we pass an access token
- It is the security credentials for a login session stored in the **access token**
- Identifies the user, the user’s groups, and the user’s privileges

#### Subjects

- Windows subjects: Processes and threads
- New processes get a **copy** of the parent access token, possibly modified
- Individual access tokens are immutable and can live beyond policy changes
    - The access token checked is the one given at login, not the current access token
    - This is a TOCTTOU issue (Time-of-check to Time-of-use)
    - Admins can force a user to log off to update their access token

### User Account Control

- After Vista, administrator users do not use an administrative access token by default
- Users have two tokens, one heavily restricted and used by default
- A prompt allows a user to spawn a process with the administrative token, or switch a process’ token.
    - Similar to `sudo`
    - Can be swapped mid-execution

#### Domains

- Single sign-on for network resources
- Centralised security administration
- Domain controller (DC)
    - Handles user accounts and access control
    - Trusted 3rd party for authentication
- Multiple DCs allow for decentralisation by design

#### Interactive Logon

- The Windows interactive logon allows a user to authenticate
- Windows logon begins with the Secure Attention Sequence `Ctrl+Alt+Del`
    - Can prevent spoofing - is tied directly to `winlogon`
- The logon process differs slightly for local and domain authentication

##### Local Logon

1. `Ctrl+Alt+Del` initiates a login prompt using `GINA`
2. These collect credentials which are passed to the `LSA`
3. The `LSA` uses `NTLM` to check the credentials against the `SAM` database
4. Successful login produces an access token, which is used to spawn a shell (explorer.exe)

![1646411476.png](img/1646411476.png)

##### Domain Logon

- Replaces `NTLM` with `Kerberos`
- Replaces `SAM` with an Active Directory Domain Controller
- Checks of a user are now performed on the remote `LSA`

![1646411494.png](img/1646411494.png)