3

I have been reading Symantec & Kaspersky Labs analysis of the Regin malware.

According to Symantec

[Stage 2] can also hide running instances of Stage 1. Once this happens, there are no remaining plainly visible code artifacts.

As I understand Stage 1 is implemented as a Windows Driver, and there exists no safe way to unload a Windows Driver without requiring a reboot (Even if so Stage 2 itself is another kernel driver as well).

Similarly, from what I can tell there exists no way (nor legitimately should there be) to intercept and manipulate the list of running Kernel drivers, the way a rootkit might for a file on the file system.

So how does Stage 2 hide running instances of Stage 1? There seems little information on this online?

Source: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/regin-analysis.pdf - Page 9

  • As a driver you can manipulate the internal kernel data structures to remove some driver from the lists. I don't have much kernel hacking experience, but I know that several game hacks used the userland equivalent of this technique to remove their dll from the list of loaded dlls. – CodesInChaos Dec 1 '14 at 16:30
  • It might be difficult to provide a definite answer without looking at the code? – schroeder Dec 1 '14 at 17:44
3

I'm not a kernel hacker, but from what I read the technique is analogous to a function hook in user space.

Premise

  • User space code interacts with the kernel through system calls.
  • There are system calls that reveal information about the state of the kernel, e. g. f returns list of loaded kernel modules.
  • The kernel manages a table t of system calls and the location of their implementation in memory.
  • A kernel module (a. k. a. “driver”) m becomes a part of the kernel, when it's loaded, thus gaining full access to everything the kernel can access.

Steps

  1. m is loaded/injected into the kernel in some way. Now it can do anything it wants to the OS including hooking into some of its infrastructure.

  2. m replaces entry tf holding a reference to function f, which would help to reveal the presence of m. In its stead m places a reference to a similar function f' into tf, which is a part of m and uses f but filters and/or transforms the results as to hide the traces of m.

  3. A user space program is looking for suspicious kernel modules and wants to call f. After receiving the system call the kernel looks up tf, because it expects tf to hold a reference to f. Instead it finds and calls f'. Thus the user space program will receive a result controlled by m.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.