BeRoot(s) is a post exploitation tool to check common Windows misconfigurations to find a way to escalate our privilege.
A compiled version is available here.
It has been added to the pupy project as a post exploitation module (it's executed in memory without touching the disk).
This tool is only used to detect and not to exploit. If something is found, templates could be used to exploit it. To use it, just create a test.bat file located next to the service / DLL used. It should execute it once called. Depending on the Redistributable Packages installed on the target host, these binaries may not work.
|====================================================================|
| |
| Windows Privilege Escalation |
| |
| ! BANG BANG ! |
| |
|====================================================================|
usage: beRoot.exe [-h] [-l]
Windows Privilege Escalation
optional arguments:
-h, --help show this help message and exit
-l, --list list all softwares installed (not run by default)
All detection methods are described on the following document.
Consider the following file path:
C:\Program Files\Some Test\binary.exe
If the path contains spaces and no quotes, Windows would try to locate and execute programs in the following order:
C:\Program.exe
C:\Program Files\Some.exe
C:\Program Files\Some Folder\binary.exe
Following this example, if "C:\" folder is writable, it would be possible to create a malicious executable binary called "Program.exe". If "binary.exe" run with high privilege, it could be a good way to escalate our privilege.
Note: BeRoot realized these checks on every service path, scheduled tasks and startup keys located in HKLM.
How to exploit:
The vulnerable path runs as:
- a service: create a malicious service (or compile the service template)
- a classic executable: Create your own executable.
Consider the following file path:
C:\Program Files\Some Test\binary.exe
If the root directory of "binary.exe" is writable ("C:\Program Files\Some Test") and run with high privilege, it could be used to elevate our privileges.
Note: BeRoot realized these checks on every service path, scheduled tasks and startup keys located in HKLM.
How to exploit:
-
The service is not running:
- Replace the legitimate service by our own, restart it or check how it's triggered (at reboot, when another process is started, etc.).
-
The service is running and could not be stopped:
- Most exploitation will be like that, checks for dll hijacking and try to restart the service using previous techniques.
This technique affects the following Windows version:
6.0 => Windows Vista / Windows Server 2008
6.1 => Windows 7 / Windows Server 2008 R2
6.2 => Windows 8 / Windows Server 2012
On a classic Windows installation, when DLLs are loaded by a binary, Windows would try to locate it using these following steps:
- Directory where the binary is located
- C:\Windows\System32
- C:\Windows\System
- C:\Windows\
- Current directory where the binary has been launched
- Directory present in %PATH% environment variable
If a directory on the %PATH% variable is writable, it would be possible to realize DLL hijacking attacks. Then, the goal would be to find a service which loads a DLL not present on each of these path. This is the case of the default "IKEEXT" service which loads the non existent "wlbsctrl.dll".
How to exploit: Create a malicious DLL called "wlbsctrl.dll" (use the DLL template) and add it to the writable path listed on the %PATH% variable. Start the service "IKEEXT". To start the IKEEXT service without high privilege, a technique describe on the french magazine MISC 90 explains the following method:
Create a file as following:
C:\Users\bob\Desktop>type test.txt
[IKEEXTPOC]
MEDIA=rastapi
Port=VPN2-0
Device=Wan Miniport (IKEv2)
DEVICE=vpn
PhoneNumber=127.0.0.1
Use the "rasdial" binary to start the IKEEXT service. Even if the connection failed, the service should have been started.
C:\Users\bob\Desktop>rasdial IKEEXTPOC test test /PHONEBOOK:test.txt
Or you can try using these tools:
- Ikeext-Privesc powershell script
- Wlbsctrl_poc in C++
AlwaysInstallElevated is a setting that allows non-privileged users the ability to run Microsoft Windows Installer Package Files (MSI) with elevated (SYSTEM) permissions. To allow it, two registry entries have to be set to 1:
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated
How to exploit: create a malicious msi binary and execute it.
This file contains all the configuration settings that were set during the installation process, some of which can include the configuration of local accounts including Administrator accounts. These files are available on these following path:
C:\Windows\Panther\Unattend.xml
C:\Windows\Panther\Unattended.xml
C:\Windows\Panther\Unattend\Unattended.xml
C:\Windows\Panther\Unattend\Unattend.xml
C:\Windows\System32\Sysprep\unattend.xml
C:\Windows\System32\Sysprep\Panther\unattend.xml
How to exploit: open the unattend.xml file to check if passwords are present on it. Should looks like:
<UserAccounts>
<LocalAccounts>
<LocalAccount>
<Password>
<Value>RmFrZVBhc3N3MHJk</Value>
<PlainText>false</PlainText>
</Password>
<Description>Local Administrator</Description>
<DisplayName>Administrator</DisplayName>
<Group>Administrators</Group>
<Name>Administrator</Name>
</LocalAccount>
</LocalAccounts>
</UserAccounts>
Checks if it's possible to:
- Modify an existing service
- Create a new service
Note: Checks on path are performed on all services ("Path containing space without quotes" and "Writable directory")
Check if it's possible to modify the directory where all scheduled tasks are stored: "C:\Windows\system32\Tasks"
Note: Checks on path are performed on all scheduled tasks ("Path containing space without quotes" and "Writable directory")
Check if it's possible to modify a startup key (on HKLM)
Note: Checks on path are performed on all startup keys ("Path containing space without quotes" and "Writable directory")
Thanks to Andrea Pierini's work, some interesting Windows privileges could be used to escalate privileges. These privileges are:
- SeDebug
- SeRestore & SeBackup & SeTakeOwnership
- SeTcb & SeCreateToken
- SeLoadDriver
- SeImpersonate & SeAssignPrimaryToken
Beroot lists all privileges we have and highlight if we have one of these tokens.
How to exploit: Everything is well explained on Andrea Pierini's pdf.
All local accounts are tested to detect empty password.
Idea comes from 0xRick 's write up.
Checking for user account options, we could see this kind of output:
> net user username
....
Password Required No
...
This means than the option /passwordreq:no has been set
> net user /passwordreq:no username
This directive allows us to use runas without needed the user account password.
> runas /user:username /savecred cmd.exe
Check 0xRick blog post to have a better example.
Some misconfigurations that could lead to privilege escalation are not checked by Beroot. These actions need monitoring and should be done manually:
- When a privilege account access a non privilege file: http://offsec.provadys.com/intro-to-file-operation-abuse-on-Windows.html
- Dll Hijacking
- Outdated Windows (use Watson or wesng and check on github for exploits).
- From Local/Network service account to admin. Check itm4n's write up and his tool
- Good description of each checks: https://toshellandback.com/2015/11/24/ms-priv-esc/
- Andrea Pierini work