Security News New GhostHook Attack Bypasses Windows PatchGuard Protections

LASER_oneXM

Level 37
Thread author
Verified
Top Poster
Well-known
Forum Veteran
Feb 4, 2016
2,516
15,624
3,578
53
Germany / Poland
...some quotes from the article:

Security experts have discovered a method of bypassing Windows PatchGuard protections and hooking malicious code into the Windows kernel, which allows an attacker to plant rootkits on systems previously thought to be impregnable.
PatchGuard, known under its official name of Kernel Patch Protection (KPP), is a security feature for Windows 64-bit editions that prevents third-party code from patching the Windows kernel with additional routines.
Microsoft introduced PatchGuard in 2005, starting with Windows XP, and the feature has prevented most rootkits from working on 64-bit editions.

Microsoft won't patch GhostHook attack vector
CyberArk says it contacted Microsoft about the GhostHook attack, but the OS maker declined to issue a security update. Microsoft said it might patch the issue during its regular bug fixing cycle, but would not treat GhostHook as a security flaw.

Microsoft justified its decision by saying that an attacker needs to have kernel-level access on an infected machine to perform a GhostHook attack. An attacker with kernel-level rights could perform many other malicious actions, and users should focus on preventing an attacker from gaining this much level of access in the first place.

Responding to Microsoft's refusal to patch this attack vector, CyberArk reiterated that the issue is "the bypassing of PatchGuard" which opens the door for rootkits on 64-bit Windows versions, and not necessarily the attacker's access level.

The real problem is that attackers have a technique at their disposal to implant rootkits on platforms they did not have access in past years.
 
Yes in 2005 Microsoft introduced a Kernel Patching Protection for 64 bit systems, making uneffective the user mode hooking using remote thread.
Now, If for example, you open the file ntoskrnl.exe ( located in the System32/SysWOW64 folder ) with your disassembler, you will noticed a KeServiceDescriptorTable symbol being exported.
It works as a big lookup table of Windows Native System Services, a list of kernel API such as NtTerminateProcess, NtLoadDriver, etc.
As you might correctly guess, if it’s exported it can be read and afterwards modified by a kernel driver with some hacks to temporary disable writing protection.