DLL is a part of windows that can’t be excluded, without DLL file your windows machine is not working correcly. But, in hacker hand the DLL file is can be very dangerous, attacker can inserting a backdoor to DLL file and exploit your machine.
IKEEXT DLL Hijacking Exploit Tool
This tool is intended for automatically detecting and exploiting the IKE and AuthIP IPsec Keyring Modules Service (IKEEXT) Missing DLL vulnerability.
A major weakness is present in Windows Vista, 7, 8, Server 2008, Server 2008 R2 and Server 2012, which allows any authenticated user to gain system privileges under certain circumstances.
In Windows there is a service called IKEEXT (IKE and AuthIP IPsec Keyring Modules), which runs as SYSTEM and tries to load a DLL that doesn’t exist. The default DLL search order of Windows includes several system directories and ends with PATH folders. To put it simple, if one of these folders is configured with weak permissions, any authenticated user can plant a malicious DLL to execute code as SYSTEM and thus elevate his/her privileges.
IKEEXT trying to load ‘wlbsctrl.dll’:
This PowerShell script consists of 2 Cmdlets:
- Invoke-IkeextCheck – Only checks whether the machine is vulnerable.
- Invoke-IkeextExploit – If the machine is vulnerable, exploit it by dropping a specifically crafted DLL to the first weak folder.
The Invoke-IkeextCheck Cmdlet performs the following checks:
- OS version – If the OS is Windows Vista/7/8 then the machine is potentially vulnerable.
- IKEEXT status and start type – If the service is enabled, the machine is potentially vulnerable (default).
- PATH folders with weak permissions – If at least one folder is found, the machine is potentially vulnerable.
- Is wlbsctrl.dll already present in some system folder (i.e. a folder where DLLs can be loaded from)? – If wlbsctrl.dlldoesn’t exist, the machine is potentially vulnerable (default).
If the machine is vulnerable, the Invoke-IkeextExploit Cmdlet will perform the following:
- Depending on the IKEEXT start type:
- AUTO – The exploit files will be dropped to the first weak PATH folder, provided that the switch ‘-Force’ was set in the command line (safety override).
- MANUAL – The exploit files will be dropped to the first weak PATH folder. Then, the service start will be triggered by trying to open a dummy VPN connection (using rasdial).
- The following exploit files will be dropped to the first vulnerable folder:
- wlbsctrl.dll – A specifically crafted DLL (32 & 64 bits), that starts a new CMD process and execute a BATCH file.
- wlbsctrl_payload.bat – The BATCH file that will be executed.
- BATCH payload:
- Default – A default BATCH payload is included in this script. It will use net user and net localgroup to create a new user (hacker with password [email protected]) and add it to the local administrators group (the name of the group is automatically retrieved by the script).
- Custom – A custom set of commands can be specified using the parameter -Payload .\Path\To\File.txt and a file containing one command per line.
- Log file – Each payload command’s ouput is redirected to a log file located in the same folder as the DLL’s. Its name will be something like wlbsctrl_xxxxxxxx.txt. So if this file is not created, it means that the payload was not executed.
2018-07-01 – The current folder doesn’t need to be writable anymore. The script will now try to create a dummy file in each PATH folder instead of creating one in the current folder and then trying to copy it.
2018-07-01 – The initial DLL payload executed the command line “cmd /c C:\PATH\TO\payload.bat”. The problem is that if the path contained spaces, a part of it would be interpreted as arguments to cmd. That’s why the full path is now between quotes.
2018-10-05 – There was a bug when only one vulnerable folder was returned by the check script using
-PassThru. When accessing the first entry of the array, the first character of the string was returned rather than the full path. It’s a kind of type confusion in a way. This was solved by casting the variable. Thanks @benichmt1 for reporting the issue.
High-Tech Bridge – Frédéric Bourla, who initially disovered the vulnerability and disclosed it on October 9, 2012. – https://www.htbridge.com/advisory/HTB23108
First of all, it’s important to note that this vulnerability was patched in Windows 8.1 and above. In these versions of Windows, wlbsctrl.dll search is limited to C:\Windows\System32\.
If you’re stuck with Windows 7 / Server 2008R2 because of compatibility issues for example, several counter measures can be applied:
- PATH folders with weak permissions – Some applications are installed directly in C:\ and add themselves to the PATH environment variable. By default, folders created in C:\ are writable by any authenticated user so make sure to drop these privileges.
- Disable IKEEXT – In most cases, IKEEXT could simply be disabled by applying a GPO. This can be a good solution for servers but it is not advised for workstations.
- Deploy you own DLL – Deploying a dummy wlbsctrl.dll in C:\Windows\System32\ for example is an efficient solution since this directory has a higher priority than PATH folders.