"You have at least two race condition bugs in your code: manual traverse of ActiveProcessLinks without locking the list, and same issue with process objects you're working with. Correct approach: use appropriate kernel functions to reference needed _EPROCESS in error safe way."
"Seriously, never ever touch nt!PsActiveProcessHead list with your own code, nt!ZwQuerySystemInformation() with SystemProcessInformation info class can do it for you without any risks to catch BSoD ... and if you want direct _EPROCESS pointer for your fuckery -- it's better to obtain it with nt!PsLookupProcessByProcessId() and free it with nt!ObDereferenceObject() call at the end."
Haha, the guy is writing shellcode not production software. Some of the criticism is good but malware developers hardly care about the proper way of doing things or race conditions.
In case anyone doesn't get it, this isn't an exploit in itself. It's a function you can use to gain system (root) privileges once you've found a bug in the Windows kernel that that gives you remote code execution.
Do you mean privilage escalation or have I misunderstood? i.e. you could for example exploit one of the recent Exchange vulnerabilities then use this to get SYSTEM and own the box.
No, this is the code that you inject using your vulnerability. The vulnerability is the privilege escalation part and this is what you do with your privilege. Exploiters call this shellcode since a common way this manifests is that the code will launch a root shell.
Shellcode can be hard to write since it might be a small amount of code you can execute, you might not be able to jump precisely to your code, it might have to use a limited range of values (such as correctly parsing as something else) or other challenges.
> Windows x64 kernel-mode handcrafted shellcode to replace primary access token of executing process with SYSTEM process token for Elevation of Privilege(EoP).
No, not just privilege escalation. This is shellcode that needs to be inserted into a vulnerable driver, as it has to run from kernel space. Being privileged isn’t enough to run this function.
Would something like the Linux kernel randstruct plugin, make this kind of escalation code more complicated? Suspend your disbelief and assume that every windows user compiled his own Windows kernel on installation :).
It would make it a lot harder, either way - depending on the struct, you could possibly use heuristics to guess where you have to look. Either way, I don't think this would ever be possible for Windows. A surprising amount of legitimate software actually depends on these being the way they are (mostly Antivirus software that you don't want on your system in the first place, but they exist nonetheless).
They aren't. AV and AC software continue hooking system functions to this day. PatchGuard doesn't cover every .data ptr and procedure.
You can do things with IoAllocateMdl, MmProbeAndLockProcessPages, MmMapLockedPagesSpecifyCache, MmProtectMdlSystemAddress to achieve such tasks.
They don't even need to be public, you can just walk the exports of ntoskrnl.exe etc.
You can even do insane shit like changing the PML4 of a process to the PML4 of another and have them point to the same memory. Or change the Win32Thread of your KTHREAD structure to that of explorer.exe and draw on the screen from kernel with GDI commands.
If I understand correctly, this is just a kernel-mode snippit to copy the System process token to your target process. It assumes you've already found a vulnerable driver to execute code in the kernel. If you can execute code in the kernel then yeah, you can give processes privileges they didn't have before.
Some critique from a seasoned kernel exploiter https://twitter.com/d_olex/status/1544008208641306624:
"You have at least two race condition bugs in your code: manual traverse of ActiveProcessLinks without locking the list, and same issue with process objects you're working with. Correct approach: use appropriate kernel functions to reference needed _EPROCESS in error safe way."
And https://twitter.com/d_olex/status/1544013068388433920:
"Seriously, never ever touch nt!PsActiveProcessHead list with your own code, nt!ZwQuerySystemInformation() with SystemProcessInformation info class can do it for you without any risks to catch BSoD ... and if you want direct _EPROCESS pointer for your fuckery -- it's better to obtain it with nt!PsLookupProcessByProcessId() and free it with nt!ObDereferenceObject() call at the end."
Haha, the guy is writing shellcode not production software. Some of the criticism is good but malware developers hardly care about the proper way of doing things or race conditions.
>malware developers hardly care about the proper way of doing things or race conditions
Yes they do, they absolutely do - especially at this level. An easy way to get caught is to show up in a crashdump that automated software flags.
Fair point, you're right that makes sense.
In case anyone doesn't get it, this isn't an exploit in itself. It's a function you can use to gain system (root) privileges once you've found a bug in the Windows kernel that that gives you remote code execution.
Do you mean privilage escalation or have I misunderstood? i.e. you could for example exploit one of the recent Exchange vulnerabilities then use this to get SYSTEM and own the box.
No, this is the code that you inject using your vulnerability. The vulnerability is the privilege escalation part and this is what you do with your privilege. Exploiters call this shellcode since a common way this manifests is that the code will launch a root shell.
Shellcode can be hard to write since it might be a small amount of code you can execute, you might not be able to jump precisely to your code, it might have to use a limited range of values (such as correctly parsing as something else) or other challenges.
The first line in the README:
> Windows x64 kernel-mode handcrafted shellcode to replace primary access token of executing process with SYSTEM process token for Elevation of Privilege(EoP).
So yes, privilege escalation.
No, not just privilege escalation. This is shellcode that needs to be inserted into a vulnerable driver, as it has to run from kernel space. Being privileged isn’t enough to run this function.
Clean. I love reading nicely commented assembler, something about it just makes my coding brain happy.
Wow that is pretty.
Would something like the Linux kernel randstruct plugin, make this kind of escalation code more complicated? Suspend your disbelief and assume that every windows user compiled his own Windows kernel on installation :).
It would make it a lot harder, either way - depending on the struct, you could possibly use heuristics to guess where you have to look. Either way, I don't think this would ever be possible for Windows. A surprising amount of legitimate software actually depends on these being the way they are (mostly Antivirus software that you don't want on your system in the first place, but they exist nonetheless).
I thought with x64 the days of AV hooking up random places of the kernel were over?
They aren't. AV and AC software continue hooking system functions to this day. PatchGuard doesn't cover every .data ptr and procedure.
You can do things with IoAllocateMdl, MmProbeAndLockProcessPages, MmMapLockedPagesSpecifyCache, MmProtectMdlSystemAddress to achieve such tasks.
They don't even need to be public, you can just walk the exports of ntoskrnl.exe etc.
You can even do insane shit like changing the PML4 of a process to the PML4 of another and have them point to the same memory. Or change the Win32Thread of your KTHREAD structure to that of explorer.exe and draw on the screen from kernel with GDI commands.
If I understand correctly, this is just a kernel-mode snippit to copy the System process token to your target process. It assumes you've already found a vulnerable driver to execute code in the kernel. If you can execute code in the kernel then yeah, you can give processes privileges they didn't have before.
I feel like I’ve seen something really similar to this (but in powershell) that does the TrustedInstaller elevation trick.