This post is focused on refining some of my understanding of the Windows OS and the data structures/rules that determine who can do "what". I'll also attempt to tie each to topic to a security implications with examples and research public to the security community.
Every action on a Windows operating system occurs under the context of an identity or "principal". These include:
- User Accounts
- Computer Accounts
- Service identifier
- Application Identifier
- And more.
The above mentioned principals will receive their "powers" based on one or more of the following attributes:
- User Rights
- Integrity Levels
Permissions are also called Access Control Lists. (ACLs). An access control list (ACL) is a list of access control entries (ACE). Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, or audited for that trustee. The security descriptor for a securable object can contain two types of ACLs: a DACL and a SACL. Be sure to check out the card talk (how I remember it). Andy Robbins and Will Schoeder really put these things into perspective on how ACEs can be used to establish persistence, among other things.
Permissions are always assigned to a specific object. They are are placed in different objects like NTFS/ReFS files and folders, SMB shared folders, Active Directory OU, Sites, Users, etc. The list goes on and on. Another example of why to be weary of permissions is how attackers can perform DCSync against the domain. Below are the only three permissions required for ANY authenticated user to DCSync the domain:
- The “DS-Replication-Get-Changes” extended right
- The “Replicating Directory Changes All” extended right
- The "Replicating Directory Changes In Filtered Set" (required for few environments).
By default, this is limited to the Domain Admins, Enterprise Admins, Administrators, and Domain Controllers groups.
When I think of user rights, I remember two words, "Allow" or "Deny". User rights are applied at the local device level, and they allow users to perform tasks on a device or in a domain. User rights include logon rights and permissions. Logon rights control who is authorized to log on to a device and how they can log on. User rights permissions control access to computer and domain resources, and they can override permissions that have been set on specific objects.
- Allow or Deny log on Locally.
- Allow or Deny access to computers from the network.
- Allow or Deny log on through remote desktop protocol.
There is a great blog post here that can walk you through how to play around with the different user rights with links to Microsoft Docs (yay). Rapid7 does a good job of bringing forth methods on how attackers leverage these.
A privilege is the right of an account, such as a user or group account, to perform various system-related operations on the local computer, such as shutting down the system, loading device drivers, or changing the system time. Each system has an account database that stores the privileges held by user and group accounts. When a user logs on, the system produces an access token that contains a list of the user's privileges, including those granted to the user or to groups to which the user belongs. Process Hacker is an excellent tool to learn about these Security Access Tokens (SAT) linked to your running processes.
Another way to get these based on your current user are
whoami /priv. Juicy Potato is one of the privilege abuse tactics I've used. Check out this recent talk that walks through tons of privileges abuses. Incognito is tool for you to play around with impersonating clients and stealing tokens.
Mandatory Integrity Control (MIC) Levels
As defined by Microsoft, "MIC provides a mechanism for controlling access to securable objects. This mechanism is in addition to discretionary access control and evaluates access before access checks against an object's discretionary access control list (DACL) are evaluated.". MIC is a partial implementation of the Biba Mandatory access control model for preserving data integrity. MIC ultimately assigns a "label" to each securable object. These objects can include folders, files, threads, processes, etc. Below is a list of the MIC labels:
When an object lacks a MIC label, it defaults to "medium". As your using your OS and launching processes, those Security Access Tokens we spoke about are assign. Within the SAT is the users Security Identifier (SID) and SIDs of the groups you belong to. Another component of your SAT is an integrity SID that identifies your MIC level. One of the Access Control Entries (ACE) that we discussed earlier contains this integrity SID.
I hope this serves as an introduction to some of these concepts. Currently, it is all very complex to me. My plan is to continue on understanding the "inner-workings" of these complex "powers" and hopefully it will make detecting and exploiting some of the tactics I mentioned, much easier.
Feel free to reach out if I made any errors (which I am sure I did) or I need to clarify anything.