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

Improve this question
2
  • 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, 2014 at 16:30
  • It might be difficult to provide a definite answer without looking at the code?
    – schroeder ♦
    Dec 1, 2014 at 17:44

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .