Very nasty indeed. Undetectable kernel mode malware: http://www.securityweek.com/lockpos-adopts-new-injection-technique
What the hell? So are they claiming that not a single HIPS can block this stuff? Like I said, Windows need a redesign, it should become possible to simply block memory access to certain processes. AppContainer and the "Protected Process" feature could play a role in this. And perhaps M$ needs to open up parts of the kernel to trusted security tools. This would undo parts of PatchGuard.
Section objects are stored in directories within the kernel global root table as shown in the below screen shot. Not all of those areas are protected:
I'm not following. If I understood correctly, the only way to block this code injection technique is by monitoring the kernel. Apparently, monitoring certain API calls like NtCreateSection, NtMapViewOfSection and NtCreateThreadEx in user-mode is not enough. It sounds shocking to me, I don't think you can rely on HIPS to protect against code injection anymore. So we need ways to completely block access to process memory, but without breaking stuff. Only the Windows OS can provide this.
Refer to the Cyberbit article. The malware is basically "highjacking" the referral to ntdll.dll, one of the commonly loaded .dlls stored into kernel memory space, by using its own version of it. As such, no kernel space modifications are done. As the article notes, AV software if so capable would have hooked the kernel space ntdll.dll. The key to stopping this type of malware is: Win 10 1709 Windows Defender Exploit Guard's Validate Handle Usage mitigation for explorer.exe which "Causes an exception to be raised on any invalid handle references" might bear further analysis as a mitigation.
Yes, it does make use of NtCreateThreadEx or CreateRemoteThread to execute the mapped code, and normally this is monitored by HIPS. But they are still claiming HIPS would fail to block LockPoS.exe from injecting code, because of the evading techniques that are used. Cyberbit could only spot it with it's EDR solution, which blocks stuff after the system has already been infected. Actually, an EDR system for consumers would be quite cool. https://www.cyberbit.com/solutions/endpoint-detection-response/ So this guys claims that Cyberbit is talking nonsense? They basically say that this technique bypasses any AV hooks on ntdll.dll, and that's the problem.
Yes, but basically in a "non-destructive manner" so to speak as noted below. Again, it is basically "hijacking" the use of a commonly used .dll, ntdll.dll loaded into every process. It does this by creating a remote thread in explorer.exe to point to its own ntdll.dll loaded in memory. Note that hook and thread setting are two separate actions. You first set a hook and then a thread to use the hook. This new technique uses only thread setting. Most security products can detect hook setting, at least user mode setting, but not thread setting.
AFAIK, all HIPS monitor the CreateRemoteThread API, so that's why I didn't understand why thy claim that this malware bypasses HIPS and AV's.
Yes, in whatever processes they are monitoring; for example the browser. Note that the thread is set in explorer.exe and most HIPS's are not monitoring that for like activity.
Opcode didn't say that Cyberbit was saying nonsense Here's some words he asked me to pass on here: "Patching NtCreateThreadEx in user-mode is not necessary, Anti-Virus vendors can use PsSetCreateThreadNotifyRoutineEx from kernel-mode which is officially supported - a system call will not bypass this. On top of this, some vendors use the hyper-visor which allows them to patch the Windows Kernel on 64-bit systems, using techniques like patching of Model Specific Registers (MSRs)."
OK, I think I understand it a bit better now. So there should be ways to monitor this stuff. But if that's the case, then he basically does say that Cyberbit is talking nonsense, doesn't he?
